软件测试资料整合v13.docx
- 文档编号:9504185
- 上传时间:2023-05-19
- 格式:DOCX
- 页数:39
- 大小:1.71MB
软件测试资料整合v13.docx
《软件测试资料整合v13.docx》由会员分享,可在线阅读,更多相关《软件测试资料整合v13.docx(39页珍藏版)》请在冰点文库上搜索。
软件测试资料整合v13
软件测试资料整合
Ch1
P6
1.问题、错误、和缺陷也许是最常用的术语。
(Problem,error,andbugareprobablythemostgenerictermsused.)
产品说明书(productspecification),简称说明(spec)或产品说明(productspec),是软件开发小组的一个协定。
他对开发的产品进行定义,给出产品的细节、如何做、做什么、不能做什么。
Fault(defect)缺陷:
是出错的根源,指代码里面的错误;
Error错误:
从调查的角度获得的数据与标准不一致;
Failure失败:
一个测试用例结果有误
区别:
有fault不一定有failure
▪Failure :
theinabilityofasystemorcomponenttoperformitsrequiredfunctionswithinspecifiedperformancerequirements
▪behavioraldeviationfromtheuserrequirementorproductspecification
▪Fault:
anincorrectstep,process,ordatadefinitioninacomputerprogram
▪anunderlyingconditionwithinasoftwarethatcausescertainfailurestooccur
▪Error:
ahumanactionthatproducesanincorrectresult
▪allarecalled defect
▪whatisthedifference?
▪whenaprogrammeriswritingaprogram,hemakesaerrorinhiscode(3,5as3.5).Whenthisprogramiscompiledorintegratedintoasystem,thesystemhasafault.Whenyourunthissystem,itmaycausefailure.
▪notallerrorcausefault,notallfaultcausefailure
P7
2.
1.软件未实现产品说明书要求的功能
2.软件出现了产品说明书指明不应该出现的错误。
3.软件实现了产品说明书未提到的功能
4.软件未实现产品说明书虽未明确提及但应该实现的目标
5.软件难以理解、不易使用、运行缓慢或者——从测试员的角度看——最终用户会认为不好。
1.3Whydobugsoccur?
看一下(※)P9
Thenumberonecauseofsoftwarebugsisthespecification.
导致软件缺陷最大的原因是产品说明书
1.4ThecostofBugs(※)P10
Thecostsarelogarithmic—thatis,theyincreasetenfoldastimeincreases.
费用指数级的增长—也就是说,随着时间的推移,费用成十倍的增长。
1.5Whatexactlydoesasoftwaretesterdo?
(※)P11
Thegoalofasoftwaretesteristofindbugs,findthemasearlyaspossible,andmakesuretheygetfixed.
软件测试员的目标是尽可能早地找出软件缺陷,并确保其得以修复。
1.6Whatmakesagoodsoftwaretester?
(※)
他们是群探索者。
不会害怕进入陌生环境,喜欢拿到新软件,安装在自己的机器上,查看结果。
他们是故障排除元。
善于发现问题症结。
喜欢解谜。
他们不放过任何蛛丝马迹。
总在不停的尝试。
可能会碰到转瞬即逝或者难以重现的软件缺陷。
不会当做偶然而轻易放过,尽一切方法去发现他们。
他们具有创造性。
他们的工作是要设想出富有创意甚至超常的手段来寻找缺陷。
他们是群追求完美者。
力求完美,某些无法企及时,也不去苛求,尽力接近目标。
他们判断准确。
决定测试内容、时间以及看到的问题是否是真正的缺陷。
他们注重策略和外交。
常常带来坏消息。
告诉程序员错误很丑。
怎样策略和职业的处理,如何和不够冷静的程序员合作。
他们善于说服。
找出的缺陷有时被认为不重要。
测试员要善于清晰表达观点,说明缺陷为何必须修复,并推进缺陷的修复。
Quiz:
2.公司或者开发小组用来称呼软件问题的术语很重要?
错。
这虽然不重要,但是使用什么属于常常反映了小组的个性及其寻找、报告和确定问题的方法。
3.仅仅测试程序是否按预期方式运行有何问题?
这最多只能算测试问题的一半。
用户不一定遵守规则,软件测试员需要证实不按操作有何后果。
此外,如果测试员进行测试没有打破沙锅问到底的态度就会遗漏某些软件缺陷。
5.软件测试员的目标是什么?
尽可能早的找出软件缺陷,并确保其得以修复。
6.好的测试员坚持不懈的追求完美?
错。
好的测试员知道何时完美无法企及,何时达到“够好”。
Ch2
常用软件设计文档清单:
结构文档、数据流图、状态转换图、流程图、代码注释
2.3SoftwareDevelopmentLifecycleModels
软件开发生命周期模式:
(※)
Big-BangModel
优点:
简单!
!
但几乎没有测试!
!
Code-and-fixModel
threepoints:
1.非常强调产品的定义
2.各步骤分立,无交叉
3.无法回溯
SpiralModel(※)
螺旋模式每一次循环的6个步骤:
(※)
1)确定目标、可选方案和限制条件
2)明确并化解风险
3)评估可选方案
4)当前阶段开发和测试、
5)计划下一阶段
6)确定进入下一阶段的方法
大爆炸模式:
优点:
简单。
没有正规开发过程,不考虑产品需求,只有开发软件和编写代码。
多数情况下,大爆炸模式几乎没有什么测试。
边写边改模式:
默认的开发模式。
开头几乎没有计划和文档编制,然后是来回编写、测试和修改缺陷的过程。
并未强调测试。
测试需要循环往复。
极其适合快速制作且用完就扔的小项目。
是最有可能在软件测试工作期间碰到的模式。
瀑布模式:
(比其他模式更有优势)
目标:
在编写代码前解决所有未知问题并明确所有细节。
优点:
简捷、精致、很有意义,在合适的项目中效果显著。
缺点:
开发时间太长,不能跟上当今变化迅速的时代。
测试在最后进行,根本性问题所需修改时间长,软件缺陷修复费用太大。
该模式的步骤:
构思、分析、设计、开发、测试——>最终产品
每一步骤结束时,进行审查,决定是否进入下一步。
三点强调:
1强调产品定义。
开发或者代码编制阶段只是其中单独的一块。
2各步骤奋力,不交叉
3无法回溯。
一旦进入某一步骤,就要完成它,才能向下。
螺旋模式:
(2.3.4)(相当好的开发模式)
总体思想:
一开始不必详细定义所有细节。
从小开始,定义重要功能,努力实现这些功能,接受客户反馈,然后进入下一阶段。
重复上述过程,直至得到最终产品。
特点:
发现问题早,成本低。
螺旋模式的每一次:
边写边改模式。
软件测试员的测试一直在进行,最后一步只是一个验证表面所有部分都没有问题。
Quiz:
3软件开发大爆炸模式的最大优点是什么?
简单
4.采用边写边改模式时,如何得知软件发布时间?
边写边改模式没有真正的退出标准,除非某人或者进度决定该结束了。
5.瀑布模式为什么不好用?
每一步都是跟着上一步的独立、离散的过程。
如果走到头发现有些事情应该早些做时,想退回来就来不及了。
6.测试员为什么最喜欢螺旋模式?
他们很早就开始参与开发过程,有机会尽早发现问题,为项目节省时间和金钱。
Ch3
3.1
P23
测试的原则(了解)TestingAxioms(※)
It’simpossibletotestaprogramcompletely
完全测试程序是不可能的,主要原因:
1.输入量太大
2.输出结果太多
3.软件执行路径太多
4.软件说明书是主观的,可以说从旁观者看是缺陷
SoftwareTestingisarisk-basedexercise
软件测试是有风险的行为
Testcan’tshowthatbugsdon’texist.
测试无法显示潜伏的软件缺陷
Themorebugsyoufind,themorebugsthereare
找到的软件缺陷越多,就说明软件缺陷越多。
ThePesticideParadox
杀虫剂怪事
Notallthebugsyoufindwillbefixed
并非所有软件缺陷都要修复
Whenabug’sabugisdifficulttosay
什么时候才叫缺陷难以说清
ProductSpecificationsareneverfinal
产品说明书从没有最终版本
SoftwareTestersaren’tthemostpopularmembersofaProjectTeam
软件测试员在产品小组中不受欢迎
SoftwareTestingisadisciplinedtechnicalprofession
软件测试是一项讲究条理的技术专业
Quiz:
1.假定无法完全测试某一程序,在决定是否应该停止测试时要考虑哪些问题?
终止测试没有一定的时间,每一个项目都会有所不同。
决定时要考虑的因素有:
仍然会发现大量软件缺陷?
项目小组对已执行的测试满意吗?
报告的软件缺陷是否经过评估定下来哪些修复,哪些不修复?
产品按照客户的要求验证了吗
5.为什么不可能完全测试程序?
出了极短小的简单程序,完全测试需要太多输入、输出和分支组合。
此外,软件说明书也许不客观,可以用多种方式解释。
Ch4
黑盒测试和白盒测试black-box&white-box(※※)
黑盒测试有时又称为功能测试或行为测试。
软件测试员只需要知道软件要做什么而无法看到盒子里的软件是如何运行的。
白盒测试有时称为透明盒测试,软件测试员可以访问程序员的代码,并通过检查代码的线索来协助测试。
但因其要以适应代码操作来定制测试,容易形成偏见而无法进行客观测试。
静态测试和动态测试static&dynamic(※)
静态测试是指测试不运行的部分——只是检查和审核。
动态测试是指通常意义上的测试——使用和运行软件。
Q:
对产品说明书进行高级审查:
Pretendtobethecustomer
假设自己是客户
Researchexistingstandardsandguidelines
研究现有的标准和规范
Reviewandtestsimilarsoftware
审查和测试类似软件
4.3产品说明书属性检查清单:
(※)P39(填空题)——对产品说明书的低层次测试
完整
准确
精确、不含糊、清晰、
一致
贴切
合理
代码无关
可测试性
Quiz:
1.软件测试员可以根据产品说明书进行白盒测试吗?
是的。
白盒测试就是使用如何设计影响如何测试的概念进行的。
测试员可以参加焦点人群,易用性研究和市场会议,了解用于定义功能特性和整个产品的过程。
但是这村爱一定的分享,因为这些信息诱使测试员倾向于假定说明书是正确的。
4.解释软件测试员应该担心下述产品说明的哪些内容,尽管通常连接不超过一百万个,但是该软件允许多达一亿个并发的连接。
可测试性。
如果产品说明书声明有一亿种可能性,那么,以一个连接都要测试。
测试员需要设法测试这么多可能性,或者让说明书作者把最大可能性降低到接近典型应用的数目。
Ch5(黑盒测试可参考5.3,5.4,5.5的内容,主要为功能测试和用户界面测试)
5.1动态黑盒测试:
带上眼罩测试软件--不深入代码细节测试软件的方法
什么是探索测试(※)
当采用大爆炸模式或边写边改模式,没有产品说明书时,采用“探索测试”。
解决方案:
了解软件、设计测试、执行测试同时进行。
静态黑盒技术检查+动态黑盒技术测试
无法判定是否遗漏功能,但可以系统测试软件,找到软件缺陷。
?
test-to-pass(通过性测试)(※):
用以确认软件能做什么,仅仅运用最简单、最直观的测试用例
?
test-to-fail(失效性测试或错误强制测试)(※):
纯粹为了破坏软件而设计和执行的测试用例
5.3等价类划分
Equivalencepartitioningistheprocessofmethodicallyreducingthehuge(infinite)setofpossibletestcasesintoamuchsmaller,butstillequallyeffective,set.(※)
等价类划分是指分步骤的把海量(无限)的测试用例集减得很小,但过程同样有效。
5.4DataTesting数据测试
软件分为数据和程序两部分。
数据包括键盘输入、鼠标单击、磁盘文件、打印输出等。
程序是指可执行的流程、转换、逻辑和运算。
等价划分的原则:
边界条件(BoundaryConditions)、次边界条件(sub-boundaryconditionsorinternalboundaryconditions)、空值和无效数据
5.4.1BoundaryConditions:
边界条件是指软件运行在计划操作界限的边界情况
5.4.1.1.可能的边界条件(边界条件类型):
数据类型:
数值、速度、字符、地点、位置、尺寸、数量
考虑以上类型的下述特征:
第一个/最后一个最小值/最大值开始/完成超过/在内空/满最短/最长最慢/最快最早/最迟最大/最小最高/最低相邻/最远
5.4.1.2测试边界:
边界测试建立两个等价划分。
1.认为应该正确的数据——在边界内部最后一两个合法的数据2.认为可能出现错误的数据——边界之外——一到两个非法的数据点
越界测试的做法例如:
第一个减1/最后一个加1;开始减1/完成加1;空了再减/满了再加;慢上加慢/快上加快;最大数加1/最小数减1;刚好超过/刚好在内等
5.4.2.次边界条件:
在产品说明书中没有定义或者在使用软件的过程中不明显的边界条件
如:
软件中的2的幂(P50,中文),ASCII值(P51,中文)
5.4.3.默认、空白、空值、零值和无输入(Default,Empty,Blank,Null,Zero,None)等条件的等价划分
5.4.4.非法、错误、不正确和垃圾数据(失效性测试的对象)
5.5状态测试
软件状态是指软件当前所处的条件或者模式(软件测试员必须测试程序的状态及其转换)
如何进行测试:
1.确定要测试的状态及其转换2.检查所有状态变量(与进入和退出相关的静态条件、信息、值、功能等)3.失败状态测试:
竞争条件、重复、压迫和重负——重复测试是不断执行同样的操作(检查是否存在内存泄漏);压迫测试是软件再不够理想的状态下进行如内存小,磁盘空间少,CPU速度慢等;重负测试是尽量提供条件让其发挥,与压力测试相反。
Quiz:
Ans:
1.在没有产品说明书和需求文档的条件下可以进行动态黑盒测试
(等价划分)
对。
该技术称为探索测试,基本上把软件用作产品说明书。
这不是理想的过程,但是急了也能用。
最大的风险是不知道特性是否被遗漏。
2.可以尝试打印时不加纸,或者使其卡纸。
可以脱机打印,拔掉电源,断开打印机电缆。
可以尝试在墨粉不足的条件下打印,甚至不加墨盒。
为了明确所有可能性,可以查看打印机的操作手册,找出支持的错误处理,设法建立使用的错误情况
3.如果选择Page选项,From和To文本域就变为可用状态。
明显的边界条件是0到99999,即文本域的最小值和最大值。
增加测试254,255,256,1023,1024和1025等内部边界是明智的做法。
此外,还有其他的内部边界。
试着从只有6页的文档打印第1-8页。
注意在本例中,软件必须在打印完第六页之后停止,是因为数据没有了,而不是接到停止命令。
这是一个不同的内部边界。
看看是够还能想出别的。
4.
(1)合法的5位数字邮政编码。
合法是指所有字符都是数值,不是指投入使用的现有邮编——但这可以构成另一个区间。
(2)合法的9位数字(带连线的9位数字)邮政编码
(3)5位以下数字。
例如只有4位数字
(4)9位以下数字。
例如只有8位数字
(5)5位以上数字。
例如不带连线的8位数字。
这是否与9位以下数字区间相同呢
(6)9位以上数字,尽管不可能输入0位以上带连线的数字,但是测试员应该尝试一下
(7)10位数字,无连线。
与9位以上数字区间稍有差别
(8)连线位置不对
(9)连线不止一条
(10)无数字和无连线
5.错。
想想游览遍布美国的50个不同的城市。
可以制定到达每个城市的旅游计划,但是不可能走遍所有城市之间的道路——这将是走遍美国的所有道路
6.
(1)软件可能处于的每个状态
(2)从一个状态转移到另一个状态所需的输入和条件(3)当进入和退出状态时产生的条件、变量和输出
7.初始显示值和内部中间值置为0.存储寄存器(MC,MR,MS和M+按钮)置为0.剪切板内容(暂存剪切、复制和粘贴数据)保持不变
另一个初始状态变量是计算器启动时出现在屏幕上的位置。
打开计算器程序的多个副本,注意其位置不一定相同(至少在Windows95/98中如此)。
作为他所测试的练习,看能够找出计算器打开时出现位置的规则
8.尝试同时做几件事。
他们可以是相关的,例如从一个应用程序同时向两台打印机输出打印;也可以是无关的,例如在计算机计算时按各种键。
所作的目的是迫使软件执行某一功能时出现于自己竞争的状况
9.错。
任何测试都是合理的。
软件测试员的任务是发现软件缺陷。
但是,由于软件测试的实质,在这种情况下发现的任何缺陷可能都不会修复
Ch6
6.1
White-boxtestingimpleshavingaccesstothecode,beingabletoseeitandreviewit.
白盒(透明盒)测试是指访问代码,能够查看和审查。
Staticwhite-boxtestinisstructuralanalysis.(※)
静态白盒测试有时称为结构化分析。
(不执行软件,通过审查设计、体系结构、代码——>找出软件缺陷)
进行静态白盒测试的首要原因:
尽早发现软件缺陷,以找出动态黑盒测试难以发现或隔离的软件缺陷。
另一个好处:
为黑盒测试员在接受软件进行测试时设计和应用测试用例提供思路。
(不必了解代码细节,通过听审查评论,确定易产生软件缺陷的特性范围)
P63
6.2FormalReviews(正式审查):
正式审查:
进行静态白盒测试的过程。
正式审查的4个基本要素:
确定问题:
审查的目的是找出软件的问题——出错的项目+遗漏的项目。
全部的批评应该直指代码和设计。
参与者之间不应该互相指责。
遵守规则:
审查要遵守一套固定的规则,规则:
要审查的代码量,花费的时间,要做评价的内容。
重要性:
参与者了解自己的角色和目标,使审查进展顺利。
准备:
每一个参与者都要为审查做准备,根据审查的类型,扮演不同的角色,了解自己的责任和义务,积极参与审查。
在审查过程中找出的问题大部分是在准备期间发现,而不是实际审查期间。
编写报告:
审查小组必须作出审查结果的书面总结报告,并使报告便于开发小组成员使用。
将会议结果尽快告诉别人。
1.PeerReviews(伙伴审查buddyReviews):
同事审查:
聚集起来审查代码
2.Walkthroughs走查:
编代码人员向测试人员做正式陈述。
3.Inspections检查:
最正式,表述者+检查员
CodingStandardsandguidelines编码标准和规范(※)
坚持标准和规范的三个重要原因:
可靠性:
按照某种标准或规范编写的代码更加可靠和安全
可读性/维护性:
符合设备标准和规范的代码易于阅读、理解和维护。
移植性:
代码符合设备标准,在迁移到不同的硬件中或是使用不同的编译器运行也没有障碍
6.4通用代码审查清单:
(GenericCodeReviewChecklist)
数据引用错误(DataReferenceerror)、数据声明错误(DataDeclarationsErrors)、计算错误(ComputationErrors)、比较错误(ComparisonErrors)、控制流程错误(ControlFlowErrors)、子程序错误(SubroutineParameterErrors)、输入/输出错误(Input/OutputErrors),其他检查(OtherChecks)
Quiz:
ANS:
1.说出进行静态白盒测试的几个好处:
1.在开发早期发现软件缺陷,大幅降低修复时间和费用
2.测试员得到软件运作信息,存在的弱点和危险,与程序员建立良好伙伴关系。
3.将项目状态传达给参与测试的所有小组成员。
2.静态白盒测试可以找出遗漏之处和问题?
对。
遗漏问题更重要。
根据公布的标准和规范检查代码,在正式审查中仔细分析,可以通过静态白盒测试找出遗漏问题。
3.正式审查有哪些关键要素组成?
(答案见“6.2正式审查基本要素”)
过程。
按照过程进行时正式检查和两个程序员之间互查代码的区别。
(答案有误)
4.除了更正式外,检查与其他审查类型有什么重大差别?
主要区别:
检验时在场的不是代码原创者。
迫使另一个人完全理解要检查的软件。
比让其他人只是审查软件寻找软件缺陷更有效。
5.如果要求程序员在命名变量时只能使用8个字符且首字母必须打些,是标准还是规范?
标准。
如果被告知用超过8个字符命名,那就是规范。
Ch7(白盒测试主要掌握:
语句、分支、条件、循环测试以及控制流&数据流覆盖)
P71
7.2DynamicWhite-BoxTestingVersusDebugging(动态白盒测试和调试)(※)
目标不同:
动态白盒测试的目标:
寻找软件缺陷
调试目标:
修复缺陷
相同:
他们都包括处理软件缺陷和查看代码的过程。
且他们在隔离软件缺陷的位置和原因上确实存在交叉现象。
(软件测试人员把问题缩减为能够演示软件缺陷的最简化测试用例。
还要包括值得怀疑的代码行信息。
调试程序员从这里继续,判断是什么导致软件缺陷,并设法修复。
)
P72
7.3分段测试
UnitandIntegrationTesting(单元和集成测试)(※)
单元测试(模块测试):
在底层进行的测试
集成测试:
对模块的组合
递增测试的两条途径:
自底向上(bottom-up)和自顶向下(top-down)
自底向上:
编写称为测试驱动的模块,这个模块正在调用测试的模块。
测试驱动模块以和将来真正模块同
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 软件 测试 资料 整合 v13