【文档说明】软件测试工程课件.ppt，共(192)页，1.825 MB，由小橙橙上传

转载请保留链接：https://www.ichengzhen.cn/view-50458.html

以下为本文档部分文字说明：

第五章软件测试工程概述软件开发过程必须伴有质量保证活动。软件测试是软件质量保证的关键元素，代表了规约、设计和编码的最终检查。第1页，共192页。软件产品最大的成本是检测软件错误、修正软件错误的成本。在整个软件开发中，测试工作量一

般占30%～40%，甚至≥50%。在人命关天的软件(如飞机控制、核反应堆等）测试所花费的时间往往是其它软件工程活动时间之和的三到五倍第2页，共192页。软件测试是为了发现错误而执行程序的过程，或者说

，软件测试是根据软件的规格说明（例如软件的功能、性能、运行环境等要求）以及程序内部结构而设计一批测试用例，并利用这些测试用例去运行程序，以发现软件错误的过程。第3页，共192页。测试用例是为了测试软件而设计的一组数据，它应该包括输入的数据和预期输出的结果两部分。测试用例={输入数据

+预期结果}第4页，共192页。软件测试背景软件是人编的—所以不完美实例:•Intel的pentium处理器•1994年浮点除法缺陷•2000年8月28日，1.13MHZ处理器一个可能导致运行程序被挂起的执行指令问题•1999年12月3日,美国航天局火星极地登陆飞船失踪•1991年爱

国者导弹防御系统系统时钟错误积累造成跟踪系统失去精确度•千年虫：世界各地解决2000年错误超过数亿美元第5页，共192页。质量管理领域权威人物J.M.Juran将质量定义为“决定产品性能和‘满意程度’的特征”

,测试注重于产品的满意度。测试应针对这样一种情况：软件产品在一些特定的范围内不能满足客户的合理要求。通过测试过程可以评定质量风险（可能的错误），了解被测试系统中存在的错误模式（观察到的错误症状）。第6页，共192页。软件测试是

一个查找错误的过程，所以软件测试只能证明错误的存在，而不是证明程序无错，不能保证经过测试的程序一定没有错误。软件测试仅仅是一个手段，根本的目的是为了纠错，即纠正软件中的错误，从而提高软件的质量。测试不可能发现所有错误，只能在

有限的时间和经济条件下，尽可能地发现错误。第7页，共192页。质量控制技术质量控制活动分类开发方法学配置管理验证技术评审正确性验证性能调试组件测试集成测试系统测试原子事务模块冗余性检错质量控制避免错误容错调试测试第8页，共

192页。测试的目的与地位G.J.Myers在《软件测试技巧》中认为:1.测试是为了寻找错误而运行程序的过程。2.一个好的测试用例是指很可能找到迄今为止尚未发现的错误的测试。3.一个成功的测试是揭示了迄今为止尚未发现的错误的测试。第9页，共192页。E.W.Dijkstra指出:“程序测试

能证明错误的存在,但不能证明错误不存在。”测试的目的是发现程序中的错误,是为了证明程序有错,而不是证明程序无错。第10页，共192页。把证明程序无错当作测试目的不仅是不正确的,完全做不到的，而且对做好测试没有任何益处，甚至是十分有害的。软件

测试要设法使软件发生故障,暴露软件错误。测试的“成功”与“失败”：能够发现错误的测试是成功的测试，否则是失败的测试。第11页，共192页。“测试的目的是说明程序正确地执行它应有的功能”这种说法正确吗？例：程序Triangle，输入三个整数，表示一个三角形的三个边长，

该程序产生一个结果，指出该三角形是等边三角形、等腰三角形还是不等边三角形。为说明其能正确执行它的功能，可使用“测试用例”(3,4,5),(5,5,6),(6,6,6),程序都能给出正确结果，是否就可认为程序是正确的？（两边之和必须大于第三边）

第12页，共192页。难以说清的软件缺陷古谚：“一片树叶飘落在森林中没有人听见，谁能说它发出了声音？”由于不能报告没有看见的问题，因此，没有看见就不能说存在软件缺陷。如果软件中的问题没有人发现，那么它算不算软件缺陷？”只有看到了，才能断言软件缺陷，尚未发现的软件缺陷只能说是未知软件缺陷

。眼见为实第13页，共192页。测试原则(1)所有的测试都应追溯到用户需求最严重的错误(从用户角度)是那些导致软件无法满足需求的错误。程序中的问题根源可能出现在开发前期的各阶段，纠正错误也必须追溯到前

期工作。第14页，共192页。测试与开发前期工作的关系决定软件与系统的配合关系需求分析概要设计详细设计编码单元测试集成测试确认测试系统测试第15页，共192页。开发前期出现错误的扩展计划需求分析设计编码测试AAB第16页，共192页。软件生存期各阶段间需保持的正确性用户要求用户:

我要什么?运行结果计算机:程序运行得到的结果源程序程序员:我要让计算机什么做?设计说明书设计员:我要让软件做什么?需求说明书分析员:我可以提供什么?12345理解正确性表达正确性理解正确性设计正确性表达正确性理解正确性编码正

确性运行正确性输入正确性相符吗?第17页，共192页。测试原则(2)应该尽早制定测试计划。概要设计时应完成测试计划，详细的测试用例定义可在设计模型确定后开始，所有测试可在任何代码被产生之前进行计划和设计。第18页，

共192页。测试原则(3)应该由第三方进行测试工作。一个软件项目的开发人员不应该同时是该软件的测试人员，基于心理因素，人们往往不愿意否定自己的工作。第19页，共192页。测试原则(4)穷举测试是不可能的。测试的最高目标是指发现错误的可能性最高的测试，所以，测试的关键技术是设计一组高产的测试用例，

好的测试方案是尽可能发现至今为止仍未发现的错误。从某种意义上说，测试是否成功，取决测试用例的选择。第20页，共192页。测试原则(5)充分注意到错误的群集现象经验表明，测试发现的错误中有80%的错误很可能是由20%的程序模块造成的，这

是一种错误群集性现象。也就是说，在程序段中，发现错误数目多的地方，则残存错误的数目也比较多，这一现象已为许多程序测试实践所证明。第21页，共192页。测试原则(6)测试应该从“小规模”到“大规模”通常，最初的测试重点往往是放在单个的程序模块中，然后，进一步的测试重点放在

集成的模块族，最后是对整个系统进行测试。随着测试的逐步深入展开，要集中测试容易出错的地方。第22页，共192页。软件测试流程软件配置测试测试配置测试工具结果分析排错可靠性分析测试结果错误预期结果出错率改正的软件预测的可靠性需求规格说明书软件设计说明书被测源

程序测试计划测试用例(测试数据)测试驱动程序第23页，共192页。软件配置：需求规格说明、设计说明书、源程序等。软件配置中还应包含测试配置。测试工具：为软件测试提供的某种服务程序。评价：测试结果与期望结果比较，如果有差异则往往程序有错，需要改正

。可靠性预测有3种情况可以考虑：A.如果测试发现严重错误，则软件的质量和可靠性一定不高;B.如果测试结果是软件功能完成正常，发现的问题不是严重错误,也容易修改，则可能：（1）软件质量和可靠性可以接受；（2）所进行的测试还不足以发现严重错误，错误被潜伏下来。C.

测试没有发现任何错误，则极有可能是测试配置选择不当（测试用例没有选好），错误被深深地潜伏下来，这是极危险。第24页，共192页。软件测试对象软件测试的对象应包括需求分析与设计以及编码等所获得一切的文档和程序。第

25页，共192页。软件测试方法软件测试方法一般可以分成静态测试和动态测试等。静态测试实际上是确认在给定的外部环境中软件的逻辑正确性，它应该包括需求规格说明和程序等的确认。动态测试也称为机器测试，动态测试主要是通过动态分析以及程序测试来检查程序的执行状态，以确认程序的正确性。第

26页，共192页。测试的方法与技术软件测试的策略和方法静态测试方法动态测试方法人工测试方法计算机辅助静态分析方法白盒测试方法黑盒测试方法第27页，共192页。静态和动态测试汽车的检查过程:•踩油门•看车漆•打开前盖检查•发动汽车•听听发动机声音•上路行使静态测试动态测试第

28页，共192页。静态测试：基本特征是对软件进行分析、检查和审阅，不实际运行被测试的软件。•静态测试约可找出30～70%的逻辑设计错误.•对需求规格说明书、软件设计说明书、源程序做检查和审阅，包括：①是否符合标准和规范；②通过结构分析、流图分析、符号执行指出软件

缺陷；第29页，共192页。静态测试方法（1）人工测试方法。人工测试就是通过人工阅读分析以及评审软件的文档、程序资料等等，以发现程序中的错误，尤其是一些设计上的逻辑错误在机器上不易发现，需要人工复查。根据统计，

好的人工评审，可以发现30%到70%的编码或逻辑设计错误。（2）计算机辅助静态分析。为了提高测试的效率，人们可以设计一些分析工具对被测试的程序进行静态分析，从中提取一些信息。例如，检查程序中的局部变量和全局变量、参数的匹配、判断与循环的嵌套匹

配、潜在的死循环、不执行的代码、过程调用层次等等。（3）程序正确性说明。程序正确性证明是试图找到某种方法，确切地证明程序是没有错误的。所谓证明，就是确信一个断言真实性的论证。这种证明可以形式化的或非形式化。第30页，共192页。动态测试：通过运行软件来检验软件的动态行为和运行结果的正确性。动态测试

的两个基本要素：被测试程序测试数据（测试用例）第31页，共192页。动态测试方法(1)选取定义域有效值,或定义域外无效值.(2)对已选取值决定预期的结果(3)用选取值执行程序(4)执行结果与(2)结果相比,不吻和则程序有错.第32页，共192页。动态黑盒测试—闭

着眼睛测试软件软件输入不深入代码细节的测试方法称为动态黑盒测试。软件测试员充当客户来使用它。输出第33页，共192页。动态白盒测试—带上X光眼镜测试软件??????????????3581322.293419985680302829734315250*(1+0.015)*((1

+0.015)^360-1)/0.015250*(1+0.015)*((1+0.015)^360-1)/0.015假如知道一个盒子包含一台计算机,而另一个盒子是人用纸笔计算,就会选择不同的测试用例了解软件的运作方式会影响测试手段第34页，共192页。穷举测试例:输入三条边长黑盒测试可采用的测试

用例数(设字长16位)执行时间:设测试一次需1ms共需一万年.=2X2X2≈3X1016161614第35页，共192页。穷举测试白盒测试例:含4个分支,循环次数≤20,从A到B的可能路径执行时间:设测试一次需2ms穷举测试需5亿年.=5+5+..+

5+5≈1020121914AB第一次为5，第二次为5*5第36页，共192页。不论黑盒还是白盒测试都不能进行穷尽测试,所以软件测试不可能发现程序中存在的所有错误,因此需精心设计测试方案,力争尽可能少的次数,测出尽可能多的错误.第

37页，共192页。两种类型的测试黑盒测试又称:功能测试数据驱动测试基于规格说明书的测试第38页，共192页。白盒测试又称:开盒测试结构测试玻璃盒测试基于覆盖的测试.根据被测程序的逻辑结构设计测试用例;力求提高测试覆

盖率;第39页，共192页。黑盒测试与白盒测试比较黑盒测试是从用户观点，按规格说明书要求的输入数据与输出数据的对应关系设计测试用例,是根据程序外部特征进行测试。白盒测试是根据程序内部逻辑结构进行测试。第40页，共192页。黑盒测试与白盒测试优缺点比较黑盒测试白盒测试优点缺点性质①适用于各阶段

测试②从产品功能角度测试③容易入手生成测试数据①可构成测试数据使特定程序部分得到测试②有一定的充分性度量手段③较多工具支持①某些代码得不到测试②如果规格说明有误，则无法发现③不易进行充分性测试①不易生成测试数据(通常)②无法对未实现规格说明

的部分进行测试③工作量大，通常只用于单元测试，有应用局限是一种确认技术，回答:“我们在构造一个正确的系统吗？”是一种验证技术，回答:“我们在正确地构造一个系统吗？”第41页，共192页。黑盒测试与白盒测试能发现

的错误CBAD-只能用黑盒测试发现的错误A-只能用白盒测试发现的错误-两种方法都能发现的错误-两种方法都不能发现的错误BCD第42页，共192页。测试用例设计选择测试用例是软件测试员最重要的一项工作。测试用例的属性:属性描述name测试用例的名称l

ocation可执行的完全路径名input输入数据或命令oracle与测试输入相比较的期待测试结果log测试生产的输出第43页，共192页。程序测试举例例：程序Triangle，输入三个整数，表示一个

三角形的三个边长，该程序产生一个结果，指出该三角形是等边三角形、等腰三角形还是不等边三角形。第44页，共192页。判断三角型的测试用例设计:输入数据预期结果(1)6;6;6等边(2)8;8;4等腰(3)4;5;6一般还应输入非法数据：0;7;9-7;3;5a;2;7等第

45页，共192页。白盒测试的测试用例设计逻辑覆盖法(1)语句覆盖(2)判定覆盖(3)条件覆盖(4)判定/条件覆盖(5)条件组合覆盖(6)路径覆盖(7)点覆盖(8)边覆盖第46页，共192页。例:PROCEDU

RESAMPAL(A，B：REAL；VARX：REAL);BEGINIF(A>1)AND(B=0)THENX:=X/AIF(A=2)OR(X>1)THENX:=X+1END;第47页，共192页。开始(A>1)AND(B=0)(A=2)OR(X>1

)返回X=X/AX=X+1FFTTabdce第48页，共192页。(1)语句覆盖使程序中每个语句至少执行一次第49页，共192页。语句覆盖开始(A>1)AND(B=0)(A=2)OR(X>1)返回X=X/AX=X+1FFTTabdc

e第50页，共192页。只需设计一个测试用例:输入数据：A=2，B=0，X=4则覆盖ace,可以执行程序中的每一条语句,即达到了语句覆盖;语句覆盖是最弱的逻辑覆盖第51页，共192页。(2)判定覆盖(分支覆盖)使每个判定的真假分支都至少执行一次第52页，共192页。判定覆盖开

始(A>1)AND(B=0)(A=2)OR(X>1)返回X=X/AX=X+1FFTTabdce第53页，共192页。例:可设计两组测试用例:A=3，B=0，X=3可覆盖c、d分支A=2，B=1，X=

1可覆盖b、e分支两组测试用例可覆盖所有判定的真假分支。语句覆盖仍是弱的逻辑覆盖。第54页，共192页。(3)条件覆盖使每个判定的每个条件的可能取值至少执行一次第55页，共192页。第一判定表达式:设条件A>1取真记为T1假T1条件B=1取真记为T2假T2第二判定表达式:设条件A=2

取真记为T3假T3条件X>1取真记为T4假T4第56页，共192页。条件覆盖开始(A>1)AND(B=0)(A=2)OR(X>1)返回X=X/AX=X+1FFTTabdce满足条件:T1,T1,T2,T2T3,T3T4,T4第57页，共192页。测试用例通过满

足的覆盖ABX路径条件分支103abeT1,T2,T3,T4b,e211abeT1,T2,T3,T4b,e两个测试用例覆盖了四个条件八种可能取值。未覆盖c、d分支，不满足判定覆盖的要求.条件覆盖不一定包含判定覆盖判定覆盖也不一定包含条件覆盖第58页，共192页。(4)判定/条件覆盖选

取足够多的测试用例，使判断中的每个条件的所有可能取值至少执行一次，同时每个判断本身的所有可能判断结果至少执行一次.第59页，共192页。判定/条件覆盖开始(A>1)AND(B=0)(A=2)OR(X>1)返回X=X/AX=X+1FFTTabdce满足条件:T1,T1,T2,T2T3,T3

T4,T4第60页，共192页。测试用例通过满足的覆盖ABX路径条件分支204aceT1,T2,T3,T4c,e211abdT1,T2,T3,T4b,d能同时满足判定、条件两种覆盖标准取值。第61页，共192页。测试用例通过满

足的覆盖ABX路径条件分支203aceT1,T2,T3,T4c,e211abeT1,T2,T3,T4b,e103abeT1,T2,T3,T4b,e111abdT1,T2,T3,T4b,d第62页，共192页。(5)条件组合覆盖所有可能的条件取值组合至少执行一次①A>1,B=0②A>1,B≠0③

A≤1,B=0④A≤1,B≠0⑤A=2,X>1⑥A=2,X≤1⑦A≠2,X>1⑧A≠2,X≤1第63页，共192页。测试用例通过满足的覆盖ABX路径条件分支204①⑤aceT1,T2,T3,T4c,e211②⑥abeT1,T2,T3,T4b

,e102③⑦abdT1,T2,T3,T4b,d111④⑧abdT1,T2,T3,T4b,d它是这几种覆盖标准中最强的第64页，共192页。(6)路径覆盖覆盖每一个可能的路径测试用例通过满足的覆盖ABX路径

条件分支111abdT1,T2,T3,T4b,d112abeT1,T2,T3,T4b,e301acdT1,T2,T3,T4c,d204aceT1,T2,T3,T4c,e第65页，共192页。循环测试（1）简单循环测试假设n是允许通过循环的最大次数，应该进行下列

的测试：跳过整个循环；只执行循环一次；执行循环两次；执行循环m次，其中，m＜n-1；执行循环n-1，n，n+1次。第66页，共192页。（2）嵌套循环测试如果把简单循环的方法直接用于嵌套循环，可能的测试次数会随着嵌套循环的层数的增加按几何级数增加，导致不现实的测试数目，可以进

行下列的测试：从最内层循环开始测试，把其他循环都设置为最小值；对最内层循环使用简单测试方法，使外层循环的迭代参数取最小值（例如，循环计算器等），并且，为越界或非法值增加一些额外的测试；由内向外，对下一个循环进行测试，保持它的所有外层循环为最小

值，其他的嵌套循环取“典型”值。如此继续进行，直到测试完所有循环。第67页，共192页。（3）串接循环测试如果串接循环的各个循环都彼此独立，则可以使用简单循环测试的方法来进行。但是，如果在两个串接循环中，第一个循环的循环计

算器的值是第二个循环的初始值，则这两个循环并不是独立的。这时，建议使用嵌套循环测试方法来进行。第68页，共192页。基本路径测试法通过分析由控制构造的环路的复杂性，导出基本路径集合，从而设计测试用例，保证这些路径至少通过一次。基本路径测试步骤：导出程序流程图的

拓扑结构-流图(程序图)计算流图G的环路复杂度V(G)确定只包含独立路径的基本路径集设计测试用例第69页，共192页。导出程序流程图的拓扑结构-流图12,364,571011a节点边R4区域1234587691011程序流程图89R1R

2R3第70页，共192页。计算流图G的环路复杂度V(G)V(G)=区域个数=4V(G)=边的条数-节点个数+2=4V(G)=判定节点个数+1=4第71页，共192页。确定只包含独立路径的基本路径集path1:1-

11path2:1-2-3-4-5-10-1-11path3:1-2-3-6-8-9-10-1-11path4:1-2-3-6-7-9-10-1-11一条新路径必须包含一条新边。这4条路径组成了一个基本路径集。4(环路复杂度V(G))是构成这个基

本路径集的独立路径数的上界，也是设计测试用例的数目。设计测试用例，保证基本路径集中每条路径的执行。第72页，共192页。黑盒测试的测试用例设计等价类划分法把所有可能的输入数据(有效的和无效的)划分成若干个等价的子集(称为等价类)，使得每个

子集中的一个典型值在测试中的作用与这一子集中所有其它值的作用相同.可从每个子集中选取一组数据来测试程序第73页，共192页。例:某报表处理系统要求用户输入处理报表的日期，日期限制在2001年1月至2005年12月，即系统只能对该段期间内的报表进行处理，如日期不在此范围内，则显示输入错误信息。系统日

期规定由年、月的6位数字字符组成，前四位代表年，后两位代表月。如何用等价类划分法设计测试用例,来测试程序的日期检查功能？第74页，共192页。如何划分等价类？•有效等价类(合理等价类)•无效等价类(不合理等价类)划分等价类的标准：•覆盖•不相

交•代表性第75页，共192页。划分等价类的规则(1)如果输入条件规定了取值范围，可定义一个有效等价类和两个无效等价类。例输入值是学生成绩，范围是0～1000100有效等价类1≤成绩≤100无效等价类成绩>100无效等价类成绩<0～第76页，共192页。划分等价类的规则：(2)如果输入条

件代表集合的某个元素，则可定义一个有效等价类和一个无效等价类。第77页，共192页。划分等价类的规则：(3)如规定了输入数据的一组值，且程序对不同输入值做不同处理，则每个允许的输入值是一个有效等价类，并有一个无效等价类(所有不允许的输入值的集合)。例：输入条件说

明学历可为:专科、本科、硕士、博士四种之一，则分别取这四个值作为四个有效等价类，另外把四种学历之外的任何学历作为无效等价类第78页，共192页。划分等价类的规则：(4)如果规定了输入数据必须遵循的规则，可确定一个有

效等价类（符合规则）和若干个无效等价类（从不同角度违反规则)。(5)如已划分的等价类各元素在程序中的处理方式不同，则应将此等价类进一步划分成更小的等价类。第79页，共192页。用等价类划分法设计测试用例

步骤：(1)形成等价类表，每一等价类规定一个唯一的编号；(2)设计一测试用例，使其尽可能多地覆盖尚未覆盖的有效等价类，重复这一步骤，直到所有有效等价类均被测试用例所覆盖；(3)设计一新测试用例，使其只覆盖一个无效

等价类，重复这一步骤直到所有无效等价类均被覆盖；第80页，共192页。第一步：等价类划分输入等价类有效等价类无效等价类报表日期的类型及长度6位数字字符(1)有非数字字符(4)少于6个数字字符(5)多于6个数字字符(6)年

份范围在2001～2005之间(2)小于2001(7)大于2005(8)月份范围在1～12之间(3)“报表日期”输入条件的等价类表小于1(9)大于12(10)第81页，共192页。第二步：为有效等价类设计

测试用例对表中编号为1,2,3的3个有效等价类用一个测试用例覆盖：测试数据期望结果覆盖范围200105等价类(1)(2)(3)输入有效第82页，共192页。第三步：为每一个无效等价类至少设计一个测试用例测试数据期望结果覆盖范围001MAY

等价类(4)输入无效20015等价类(5)输入无效2001005等价类(6)输入无效200005等价类(7)输入无效200805等价类(8)输入无效200100等价类(9)输入无效200113等价类(10)输入无效不能出现相同的测试用例本

例的10个等价类至少需要8个测试用例第83页，共192页。例:对招干考试系统“输入学生成绩”子模块设计测试用例招干考试分三个专业,准考证号第一位为专业代号,如:1-行政专业,2-法律专业,3-财经专业.行政专业准考证号码为:110001～11

1215法律专业准考证号码为:210001～212006财经专业准考证号码为:310001～314015第84页，共192页。例:准考证号码的等价类划分有效等价类:(1)110001～111215(2)210001～212

006(3)310001～314015无效等价类:(4)-～110000(5)111216～210000(6)212007～310000(7)314016～+第85页，共192页。例:计算给定月份中天数的方法接口(java):ClassMyGreg

orianCalender{……publicstaticingetNumDaysInMonth(intmonth,intyear){…}……}getNumDaysInMonth()方法有两个参数,月和年,年份的有效输入是从0到maxInt.

第86页，共192页。等价类划分即把输入空间分解成一系列子域，软件在一个子域内的行为应是等价的。软件错误分为两类：计算错误域错误针对计算错误的测试方法针对域错误的测试方法:测试域边界划定的正确性第87页，共192页。边界值分析法边界值分析法与等价类划分法区别(1)边界值分析不是从某等价类

中随便挑一个作为代表，而是使这个等价类的每个边界都要作为测试条件。(2)边界值分析不仅考虑输入条件，还要考虑输出空间产生的测试情况被测试子域测试内点测试外点软件边界与悬崖很类似第88页，共192页。边界条件类型如果软件测试问题包含确定的边界,那么数据类型可能是:•数值•字符•位置•数量•

速度•地址•尺寸•„„还要考虑数据类型的特征:•第一个/最后一个•最小值/最大值•开始/完成•空/满•最慢/最快•相邻/最远•超过/在内•„„第89页，共192页。测试边界线n测试临近边界的合法数据,以及刚超过边界的非法

数据.n越界测试通常简单地加1或很小的数(对于最大值)和减1或很小的数(对于最小值).第90页，共192页。输入条件报表日期的类型及长度1个数字字符5个数字字符7个数字字符有1个非数字字符全部是非数字字符6个数字字符显示出错显示出错

显示出错显示出错显示出错输入有效日期范围月份范围“报表日期”边界值分析法测试用例测试用例说明测试数据期望结果选取理由52001520010052001.5MAY---200105月份为1月月份为12月月份<1月份>122001012001122001002001132

00101200512200100200513输入有效输入有效显示出错显示出错输入有效输入有效显示出错显示出错在有效范围边界上选取数据仅有1个合法字符比有效长度少1比有效长度多1只有1个非法字符6个非法字符类型及长度均有效最小日期最大日期刚好小于最小日期刚好大于最大日期最小

月份最大月份刚好小于最小月份刚好大于最大月份第91页，共192页。错误推测法(errorguessing)根据经验来设计测试用例的方法。例如，数据测试中的:•缺省值•空白•空值•零值•无第92页，共192页。状态测试软件必须测试程序的状态及其转换。•测试软件的逻辑流程•建立

状态转换图•减少要测试的状态及转换的数量空闲等待用户输入命令按下Esc键显示口令框口令错误消除口令正确初始状态消失空闲等待用户输入命令按下Esc键口令正确口令错误不同形式的状态转换图第93页，共192页。设置2Bwatch上的时间的顺序图:2Bwatch用户按下按钮1和2:

2Bwatch输入:2Bwatch显示:2Bwatch时间时间按下按钮1按下按钮2按下按钮1和2闪烁小时闪烁分钟增加分钟刷新提交更新时间停止闪烁第94页，共192页。2Bwatch设置时间功能的状态图和测试结果按左按钮按

右按钮按左按钮按右按钮4.2分钟以后测量时间设置时间电池没电3.按下左右按钮5.按下左右按钮/蜂鸣8.20年以后7.20年以后6.2.1.激励因素空集合测量时间1.初始变迁测试的变迁预期结果状态按下左边按钮测量时间2.同时按下两个按钮设置时间3.等2分钟测量时间4.超时

„„„„„„第95页，共192页。失败状态测试找到测试软件失败的案例。•竞争条件和时序错乱•重复•压迫•重负应联合使用，同时进行第96页，共192页。有效等价类和用来测试getNumDaysInMonth()方法所选的有效输入有效

等价类一个月有31天,非闰年19017(七月)一个月有31天,闰年19047(七月)一个月有30天,非闰年19016(六月)一个月有30天,闰年19046(六月)一个月为28或29天,非闰年19012(二月)

月份输入值年份输入值一个月为28或29天,闰年2(二月)1904第97页，共192页。用来测试getNumDaysInMonth()方法的附加边界值等价类可以被400整除的闰年20002(二月)可以被100整除的非闰

年19002(二月)非正数无效月份12910正数无效月份131513月份输入值年份输入值第98页，共192页。因果图法因果图适合于描述对于多种输入条件的组合，相应产生多个动作的形式来设计测试用例。因果图方法最终生成的是判定表。第99页，共192页。因果图方法实例某电力公

司有A、B、C、D四类收费标准,并规定：居民用电<100度/月按A类收费≥100度/月按B类收费动力用电<10000度/月,非高峰,B类收费≥10000度/月,非高峰,C类收费<10000度/月,高峰,C类收费≥1000

0度/月,高峰,D类收费第100页，共192页。用因果图表明输入和输出间的逻辑关系1I12B∨∧4AC35∧DI4I3I2∨∧∧∧∧第101页，共192页。把因果图转换为判定表组合条件条件(原因)动作(结果)ABC1231234561011000110

00110000100001104101050011D000110010000测试用例第102页，共192页。为判定表每一列设计一个测试用例:1列居民电,90度/月A2列居民电,110度/月B3列动力电,非高峰,8000度/月B4列动力电,非高峰,1.2万度/月C5列动力电

,高峰,0.9万度/月C6列动力电,高峰,1.1万度/月D条件测试用例预期结果组合(输入数据)(输出动作)第103页，共192页。软件测试的过程被测模块单元测试设计信息集成测试被测模块单元测试被测模块单元测试测试过的模块确认测试系统测试软件需求其它系统元素装配好的软件确认的软件可运行的软件软件测试

的步骤第104页，共192页。软件测试策略单元测试UCDRSIVST集成测试确认测试系统测试系统工程软件需求分析软件设计代码编写第105页，共192页。单元测试一.单元测试的内容主要对模块的五个基本特性进行评价模块错误处理

模块接口局部数据结构重要的执行路径边界条件第106页，共192页。1.常见错误类型•接口错误•I/O错误•数据结构错误•算法错误•比较及控制逻辑错误•错误处理错误第107页，共192页。2.单元测试基

本原则•至少一次测试所有语句•测试所有可能的执行或逻辑路径的组合•测试每个模块的所有入口和出口第108页，共192页。3.确定单元测试数据集•值域•值类•离散值•值的次序集(测试顺序文件和表)第109页，共192页。

二.单元测试的方法单元测试一般为编码步骤的附属部分。模块不是独立的程序,自己不能运行,要靠其它部分来调用和驱动,要为每个单元测试开发两个软件:(1)驱动模块(驱动程序):相当于主模块(2)桩模块(测试存根、连接程序):代替

所测模块调用的子模块第110页，共192页。单元测试的测试环境举例:BACDE待测试模块第111页，共192页。单元测试的测试环境举例:被测模块B驱动模块(模拟模块A)桩模块(测试存根)(模拟模块E)测试用例测试结果许多模块不能用简单的软件进

行充分的单元测试,此时,完全的测试可放到集成测试阶段再进行。第112页，共192页。单元测试的测试环境举例:实际软件华氏到慑氏转换模块温度数据实际配置测试用例数据结果测试驱动软件华氏到慑氏转换模块结果测试驱动际配置第113页，共192页。单元测试的测试环境举例温度显示模块温度接口模块实际配置

测试驱动实际配置温度显示模块程序员编写的桩模块(测试存根)温度值的测试文件第114页，共192页。结构性模式(structuralpatterns)•适配器模式(Adapter)—打包器(Wrapper)

•桥模式(Bridge)—句柄(Handle)•组合模式(Composite)•修饰模式(Decorator)—包装器(Wrapper)•外观模式(Facade)•轻量模式(Flyweight)•代理模式—(Proxy)第115页，共192页。ImplementorOperationaImp(

)桥模式(Bridge)意图：将抽象部分和实现部分分离，使他们都可以独立地变化AbstractionContextinterface()ConcreteImplementorAOperationaImp()ConcreteImplem

entorBOperationaImp()RefinedAbstraction第116页，共192页。支持多种窗口系统的设计—窗口与窗口实现分离WindowRaise()DrawRact(…)Application

WindowIconWindowDialogWindowMacWindowlmpDeviceRaise()DeviceRect(…)……PMWindowlmpDeviceRaise()DeviceRect(…)……XWindowlmpDeviceRaise()DeviceRect(…)…

…WindowlmpDeviceRaise()DeviceRect(…)……第117页，共192页。利用Bridge设计模式与未完成、未知或在测试另一组件时不可用组件的接口（UML类图）用户接口数据库户接口数据库

户接口测试存根数据库可用Bridge设计模式实现测试存根，用户接口子系统访问测试不能访问的数据库子系统。将数据库接口和数据库实现分离开来。第118页，共192页。集成测试(组装测试)集成测试需考虑的问题:数据穿越接口可能丢失.一模块可能破坏另一模块功能.子功能组

装可能未产生所要求的主功能.全程数据结构可能出问题.误差累积问题.第119页，共192页。集成测试方法通常采用黑盒测试技术实施策略:非增量式系统集成增量式系统集成深度优先广度优先自顶向下结合自底向上结合第

120页，共192页。一.非增量式系统集成一次就把所有通过了单元测试的模块组合在一起进行全程序的测试。缺点:发现错误难以诊断定位,又称“莽撞测试”。第121页，共192页。二.增量式系统集成从一个模块开始,测一次添加一个模块，边组装边测试，以发现与接口相联系的问题。第122

页，共192页。自顶向下结合方式举例:ADBE模块测试结合顺序CF深度优先:A、B、E、C、D、F广度优先:A、B、C、D、E、F第123页，共192页。自顶向下结合方式举例:(深度优先)A测试AS2S1S3A加入BS2BS3

S4A加入ES2BS3EA加入CCBS3E加入DCBDE加入FCBDEAAFS5第124页，共192页。自底向上结合方式举例:ACBDFEEd1Cd3Fd4Bd2EDd5F第125页，共192页。自底向上结合方式举例:McD1MaMbD2D3簇1簇2簇3第

126页，共192页。自顶向下自底向上优点可在测试早期设计测试用例容易实现并验证系统主要功能不需驱动模块不需桩模块缺点需桩模块只有到最后程序才能作为一个整体3.混合集成测试方法一般对软件结构的上层使用自顶向下结合的方法;对下层使用自底向上结合的方法;第127页，共192页。接口测试接口测试的

目的是检查由于接口错误或者接口进行无效假设造成的系统缺陷。程序组件的接口有很多的类型，例如：参数接口。主要是数据和函数指针等，它们由一个构件传递到另一个构件。共享内存接口。有一个被子系统共享的内存块。由一个子系统把数据放在该内存中，然后被另一个子系统取出。程序接口。由一个

子系统封装了的一组程序，这些程序可以被其他子系统调用。例如，对象（类）和抽象数据类型就存在这种接口。消息传递接口。子系统通过消息传递来请求其他子系统的服务，返回的消息也包含了该服务的运行结果。例如，一些面向对象系统、客户机/服务器系统存在这种接口。第12

8页，共192页。接口错误可以分成3类：接口误用。调用者（组件）在调用其他组件时，接口使用不当而产生错误，例如，在使用参数接口时，参数类型和传递顺序以及参数个数不对等。接口误解。调用者（组件）误解了被调用组件的接口描述而产生错误，被调用组件没有按照预期的行为执行。计时错误。这类

错误一般发生在实时控制系统中，系统使用了共享内存接口或者消息传递接口而产生接口错误。例如，数据的生产和消费可能以不同的速度进行，由于生产者没有及时更新共享接口的信息导致消费者访问了过期的数据。第129页，共192页。接口测

试的一般准则：检查代码并明确地列出对外部构件的调用。对传给外部构件的参数值，应选择取值范围的边缘值作为测试用例，这样可能发现接口的不一致性。如果有指针从接口传递，应该用空指针参数来进行测试。如果通过程序接口调用构件，可以设计一些容易引起构件失败的测试。如果是通过消息传

递到系统进行强度测试，应该设计大量的消息，可能发现计时错误。当构件之间是通过共享内存进行交互时，设计测试用例时，改变激活构件的次序，这样可能发现共享数据的生产和消费的顺序的错误。第130页，共192页。集成测试的标准应包括：接口完整性。每一个模块集成到整个系统结构中，都

要对它的内部和外部接口进行测试。功能有效性。为发现功能性错误进行的测试。信息内容。为发现与局部数据结构或者全局数据结构有关错误的测试。性能。为验证软件设计过程中建立的性能边界的测试。第131页，共192页。回归测试在软件集成测试的过程

中，每当一个模块加入到系统时，软件就发生变化，模块之间的影响也可能有改变。新的数据路径被建立，也可能出现新的输入/输出操作。很有可能激活新的控制逻辑，所有这些改变的因素可能会导致原来工作正常的系统产生错误。回归测试是对已经进行过测试的子集（模块）重新测试，以确保

新添加的模块不会对系统产生无法预料的副作用。第132页，共192页。确认测试有效性测试软件配置审查管理机构裁决选择测试人员软件计划用户文档开发文档源程序文本支持环境交用户运行维护测试报告软件配置构造测试用例实际运行测试专家鉴定会第133页，共192页。有效性测试通过黑盒测试,证实软件功能与用户需

求是否一致.软件配置审查与验收确认测试软件配置审查主管部门批准集成的软件软件需求用户文档设计文档源程序测试文档交付的软件确认的软件确认的配置第134页，共192页。确认测试结果测试完成后可能出现两种情况:(1)测试与预期相符,可接受。(2)不相符,列出软件缺陷表,与用户协商解决。第135页，共

192页。α测试和β测试α测试(Alpha)在开发者的场所由用户进行,在开发者关注和控制的环境下进行。β测试(Beta)最终用户在自己的场所进行。第136页，共192页。系统测试软件只是计算机系统的一个元素，软件最终要与其他系统元素（如新硬件、信息等)相结合，进

行各种集成测试和确认测试.第137页，共192页。用于系统测试的测试类型:(1)恢复测试(2)安全性测试(3)强度测试(4)性能测试第138页，共192页。(1)恢复测试以不同的方式强使软件出现故障,检测软件能否恰当地完成恢复.自动恢复:检测重新初始化、检测点设置、数据恢复

、重新启动等是否正确.人工干预恢复:检测平均恢复时间是否在允许范围内.第139页，共192页。(2)安全性测试设计测试用例,突破软件安全保护机构的安全保密措施,检验系统预防机制的漏洞.(3)强度测试设计测试用例,检验系统能

力最高能达到的实际限度,让系统处于资源的异常数量、异常频率、异常批量的条件下测试系统的承受能力。一般比平常限度高5-10倍的限度做测试用例.第140页，共192页。强度测试是一种敏感性测试技术。在某种情况下,包含在程序有效数据边界内的非

常小范围的数据变动可能导致极端的,甚至错误的处理,会使系统性能严重下降。第141页，共192页。(4)性能测试设计测试用例，并记录软件运行性能，与性能要求比较，检验是否达到性能要求规格。第142页，共192页。面向对象的软

件测试测试目标：在现实的时间跨度内应用可管理的工作量去发现最大可能数量的错误•基本目标不变，但由于OO程序的性质改变了测试策略和测试战术•更多的设计模式复用是否将减轻OO系统的繁重测试？Binder,R.V.在“Object-OrientedSoftwareTesting”中讨论改问题:“每次复用

是一个新的使用语境,并且重新测试是谨慎的.为了获得面向对象系统的高可靠性,似乎可能需要更多而不是更少的测试.”第143页，共192页。OOA和OOD的模型测试每个阶段的所有面向对象模型都应被测试。OOA和OOD的模型不能被执行，对它们不能进行传统意义上的测试。可通过技

术复审检查OOA和OOD的模型的正确性和一致性。扩大测试的视角第144页，共192页。面向对象测试策略•信息隐蔽对测试的影响•封装和继承对测试的影响面向对象程序的特点对软件测试的影响：•单元和集成测试策略必须有很大的改变•测试用例的设计必须

考虑OO软件的特征第145页，共192页。1.OO的单元测试•一个类可以包含一组不同的操作，而一个特定的操作也可能存在于一组不同的类中。不再孤立地测试单个操作(这是传统单元测试的视角)•OO软件的类测试等价于传统的单元测

试.•传统软件的单元测试关注算法细节和模块接口间流动的数据OO软件的类测试是由封装在类中的操作和类的状态行为驱动的单元概念的变化—封装的类或对象作为最小的可测试单位第146页，共192页。2.OO的集成

测试OO软件没有层次的控制结构,传统的自顶向下和自底向上的集成策略没有意义.OO软件的集成两种策略:•基于线程的测试(thread-basedtesting)集成响应系统的一个输入或事件所需的一组类,

每个线程被个体地集成和测试,通过回归测试保证没有副作用产生;•基于使用的测试(use-basedtesting)通过测试几乎不使用服务器的类(独立类)来开始系统的构造,测试完独立类后,使用独立类按层逐步完成

依赖类的测试直至完整的系统被构造;第147页，共192页。3.OO的确认测试在确认和系统测试层次,类连接的细节消失.•和传统的确认测试一样,OO软件的确认关注用户可见的动作和用户可识别的系统输出.•为辅助确认测试的导出,应利用分析模型中的用例图提供的场景来提高

交互需求中发现错误的可能性第148页，共192页。OO软件的测试用例设计•每个测试用例应被唯一标识，并应显式地和与被测试类相关联•测试的目的应被陈述•对每个测试应开发一组测试步骤，包括：•将被测试对象的

一组特定状态•将被作为测试的结果使用的一组消息和操作•当对象被测试时可能产生的一组异常•一组外部条件(进行测试必须的软件外部环境的变化)•将辅助理解或实现测试的补充信息OO软件的测试用例设计还处于成型期.Binder,R.V

.在“EssaysonObject-OrientedSoftwareEngineering”中建议了对OO软件的测试用例设计的整体方法:第149页，共192页。1.OO概念的测试用例设计的含义•封装可能会成为测试的障碍测试需要报告对象的具体和抽象状态，而封装使得对象的

状态快照难于获得。•继承，特别是多继承使测试复杂化第150页，共192页。子类继承或重载的父类成员函数的测试问题•继承的成员函数是否都不需要测试?对父类中已经测试过的成员函数,两种情况需要在子类中重新测试:继承的成员函数在子类中做了改动;成员函数调用了

改动过的成员函数的部分;例如:父类Base有两个成员函数Inherited()和Redefined(),子类Derived只对Redefined()做了改动.Derived∷Redefined()—需要重新测试Derived∷Inher

ited()—如果它调用了Redefined()的语句,则需重新测试,否则不必第151页，共192页。子类继承或重载的父类成员函数的测试问题•对父类的测试是否能够照搬到子类?上例中:Base∷Redefined(

)和Derived∷Redefined()已是两个不同的成员函数,照理应对Derived∷Redefined()重新进行测试分析,设计测试用例,但由于它们的相似性,只需在Base∷Redefined()的测试要求和测试用例上添加对Derived∷Redefined()的新的测试要求和增补相

应的测试用例.第152页，共192页。2.传统测试用例设计方法的可用性•白盒测试方法可用于类定义的操作的测试•对具有简洁结构的类，白盒测试最好用于类级别的测试•黑盒测试方法也适合OO系统第153页，共1

92页。测试单个类的方法（1）随机测试例:银行系统的account(帐户)类有下列操作：•open(打开)•setup(建立)•deposit(存款)•withdraw(取款)•balance(余额)•summarize(清单)•creditLimit(透支限额)•close(

关闭)系统对操作的限制：•必须在应用其它操作之前先打开帐户,在完成了全部操作之后才能关闭帐户;•……在限制下还是存在操作的许多排列第154页，共192页。一个account类实例的最小行为历史包括下列操作:open.setup.deposit.withdraw.

closeaccount类的最小测试序列大量的其它行为可能在下面序列中发生:open.setup.deposit.[deposit|withdraw|balance|summarize|creditLimit]n.withdraw.c

lose一系列不同的操作序列可以随机地产生,例如:测试用例r1:open.setup.deposit.deposit.balance.summarize.creditLimit.withdraw.close测试用例r2:open.setup.deposit.withdraw.

deposit.balance.creditLimit.withdraw.close这些和其它的随机顺序测试被进行,以测试不同的类实例的生存历史.第155页，共192页。测试单个类的方法（2）划分测试(partitiontesting)与测试传统软件时采用的等价类划分方法类似.划分类别的方法

:•基于状态的划分•基于属性的划分•基于功能的划分第156页，共192页。基于状态的划分根据类操作改变类状态的能力来划分类操作.例：银行系统的account(帐户)类状态操作包括:deposit(存款)withdraw(取款)非状态操作包括:balanc

e(余额)summarize(清单)creditLimit(透支限额)测试用例p1(测试改变状态的操作):open.setup.deposit.deposit..withdraw.close测试用例p2(测试不改变状态的操作,在最小测试序列中的操作除外):open.setup.dep

osit.summarize.creditLimit.withdraw.close第157页，共192页。基于属性的划分根据类操作使用的属性来划分类操作.例：银行系统的account(帐户)类可根据balance属性来定义划分,把操作划分为三个类别:•使用balance的操作•修改

balance的操作•不使用也不修改balance的操作为上述每个类别设计测试序列第158页，共192页。基于功能的划分根据类操作所完成的功能来划分类操作.例：银行系统的account(帐户)类中的操作可划分为三个类别:•初始化操作(open,setup)•计

算操作(deposit,withdraw)•查询操作(balance,summarize,creditLimit)•终止操作(close)为上述每个类别设计测试序列第159页，共192页。测试类和方法（3）基于故障的测试(fault_basedte

sting)与测试传统软件时采用的错误推测法类似.第160页，共192页。面向对象的集成测试(类间测试用例的设计)在OO系统的集成开始时,开始类间的协作测试.和单个类的测试一样,类协作测试可通过随机和划分方法以及基于场景的测试和行为测试来完成.第161页，共192页。ATMBank银行系统的类

协作图ATMUserInterfaceAccountCashierverifyAcctverifyPINverifyPolicywithdrawReqdepositReqacctInfoReqcardInsertedpassworddepo

sitwithdrawaccentStatusterminatevalidPINvalidAcctcreditLimitaccentTypebalancewithdrawdepositcloseopen

AcctinitialDepositauthorizeCarddeuthorizecloseAcctValidationInfoverifyStatusdepositStatusdispenseCaseprintAccentStatr

eadCardInfogetCaseAmnt第162页，共192页。OO集成测试方法（1）多个类测试Kirani,S.andW.T.Tsai,在“SpecificationandVerificationofObject-O

rientedPrograms”中建议了下面的步骤序列以生成多个类随机测试用例:1.对每个客户类,使用类操作列表来生成一系列随机测试序列,这些操作发送消息给服务器类;2.对生成的每个消息,确定在服务器对象中的协作者类和对应的操作

;3.对服务器对象中的每个操作(已经被来自客户对象的消息调用),确定传递的消息;4.对每个消息,确定下一层被调用的操作,并把这些操作结合进测试序列中.第163页，共192页。ATMBank银行系统的类协作图ATMUserInterface

AccountCashierverifyAcctverifyPINverifyPolicywithdrawReqdepositReqacctInfoReqcardInsertedpassworddepositwith

drawaccentStatusterminatevalidPINvalidAcctcreditLimitaccentTypebalancewithdrawdepositcloseopenAcctinitialDepositauthorizeCarddeuthorizecloseAcctValid

ationInfoverifyStatusdepositStatusdispenseCaseprintAccentStatreadCardInfogetCaseAmnt第164页，共192页。银行系统中Bank类和ATM类

的操作序列:verifyAcct•verifyPIN•[[verifyPolicy•withdrawReq]|depositReq|acctInfoReq]n对Bank类的随机测试用例可能是:测试用例r3:verifyAcct•verify

PIN•depositReq为了考虑测试中涉及的协作者,需要考虑与测试用例r3中每个操作相关联的消息:Bank必须和ValidationInfo协作以执行verifyAcct和verifyPINBank还必须和Account协作以执行de

positReq因此,测试这些协作的新的测试用例是:测试用例r4:verifyAcctBank•[validAcctValidationInfo]•verifyPINBank•[validPINValidati

onInfo]•depositReq•[depositAccount]第165页，共192页。OO集成测试方法（2）从动态模型导出测试用例设计的测试用例应达到完全的状态覆盖,即操作序列应导致account类的变迁穿越所有允许的状态:测试用例s1:open•setupAcce

nt•deposit(initial)•withdraw(final)•close(最小测试序列)向最小序列中加入附加的测试序列,例如:测试用例s2:open•setupAccent•deposit(initial)•deposit•balance•credit•withdraw

(final)•close测试用例s3:open•setupAccent•deposit(initial)•deposit•withdraw•accntInfo•withdraw(final)•close……导出更

多的测试用例以保证该类的所有行为都被适当地测试第166页，共192页。setupacctaccount类的状态转换图emptyacctdeadacctsetupAaccentbalancecreditacctInfoclosedeposit(initial)depositwithdrawempt

yacctopenwithdrawal(final)nonworkingacct第167页，共192页。调试(纠错技术)测试是找出软件错误的过程，调试是确定错误的位置、性质并纠正。调试的困难在于错误的定位。第168页，共192页。调试的执行步骤错误现场

结果执行案例改正测试用例调试已识别的原因被怀疑的原因回归测试附加测试第169页，共192页。程序修改过程应注意：在出现错误的地方很可能还有别的错误；不要只修改错误的征兆和表现，要找到产生错误的真正原因，修改错误的本质；当心修改一个错误时可能引入新的

错误；不要试图直接修改目标代码来修改错误，应当修改源程序。因为，当程序重新编译或汇编时，错误又会再重现。第170页，共192页。排错策略方法一.强行排错(bruteforce)常见形式:(1)打印出所有存储内容、代码(2)程序中设打印语句(3)用自动纠错工具效率最低第171页，共192页。二

.回溯法(跟踪法)根据错误症状位置，人工沿程序控制流程向回追踪源代码。适用于小程序，路径数目很大时无法进行。第172页，共192页。三.消去原因(causelimination)列出可能原因,逐个排除,找出问题(1)试探法(2)归纳法(3)演绎法(4)二分查找法第173页，共192页。(1)

归纳法收集有关数据组织数据构造线索研究线索关系假设错误原因证明假设纠正错误能不能证明线索关系错误线索能不能第174页，共192页。(2)演绎法列举可能错误原因排除不会发生原因对保留的假设推断证明留下的假设确定错误待定错因剩余错因能出错原因不能收集更多数据无剩余第175页，共

192页。修改错误原则•注意错误的群集现象，在错误近邻检查。•找到错误的本质并修改。•采用回归测试，避免因修改引起的新错误。•修改源程序。第176页，共192页。自动测试和测试工具自动化和工具的好处•速度

•效率•准确度和精确度•坚持不懈第177页，共192页。测试工具•静态分析工具•动态测试工具•测试数据自动生成工具•集成化测试环境第178页，共192页。查看器和监视器1#计算机软件正在测试2#计算机软件正

在测试3#计算机查看测试工具通信线路监听线路通信分析器可以查看两个系统之间传输的原始数据第179页，共192页。驱动程序普通系统配置测试驱动配置键盘电缆鼠标电缆一台计算机可以作为驱动程序测试工具取代被测试系统的键盘和鼠标从外部计算机

发送击键鼠标的移动信息,被测试他不被侵入,如果测试软件时在同一系统中执行驱动程序,它就会侵入系统,这种测试情况可能无法接受第180页，共192页。管道和仿真器普通系统配置测试存根配置一台计算机可以充当管道,代替打印机,能够对测试

输出进行更有效的分析第181页，共192页。其它工具类型:•施压工具和增负工具•干扰发生器和噪声发生器•分析工具第182页，共192页。测试工具产品实例Junit:Java单元测试工具Dunit:Delphi的终极测试工具第183页，共192页。测试自动化

另一类软件测试工具,可以自动执行测试用例、查找软件缺陷、分析并记录测试结果。第184页，共192页。测试工作台(下游CASE工具)源代码预测器测试管理器测试预估模拟器文件比较器报告生成器动态分析器被测试的程序测试数据测试结

果测试结果报告执行报告测试数据生成器规约第185页，共192页。随机测试自动化工具:猴子测试员只要不停电,偶尔能够得到香蕉,猴子就会永远测试下去一个想法:“如果让一百万只猴子在一百万只键盘上敲一百万年,它们最终就可能写出莎士比亚话剧等巨著”.第186页，共192页。猴子的进步

笨猴子:一点也不懂测试软件,只是随机地单击或按键,直至发生两件事情之一:完成循环或系统崩溃.不太笨的猴子:具有崩溃辨认能力,能够重新启动系统开始测试聪明猴子:能够从它的笨兄弟那里获得随机测试的结果,增

加了对环境的认知能力,有目的地敲键盘,不仅限于查找崩溃缺陷,同时查看数据,检查操作结果,找出与预期结果的差别第187页，共192页。自动化测试工具实例美国国际软件自动化（ISA）公司的PanoramaforC/C++，j、Java和VB产品，自动化功能包括：•软件结构分析与

逻辑框图的自动化•软件静态分析•数据分析•复杂性分析与分析结果列表的自动化•软件质量分析•动态性能分析•软件代码分支或条件覆盖率分析•软件测试用例有效性分析与测试用例最小集的自动选取•软件界面手工操作过程的自动记录与自动再执行(Playback)第188页，共192页。测

试中的可靠性分析开发过程中，利用测试的统计数据来估算软件的可靠性，以控制软件的质量。推测错误的产生频度推测残留在程序中的错误数评价测试的精确度和覆盖率第189页，共192页。推测错误的产生频度（推测错误产生的时间间隔）1K(ET/IT-Ec(t)/IT)方法:估算平

均故障时间(MTTF估算公式)当故障率为独立于时间的常量λ:MTTF＝K:经验常数ET:程序中原有的残留错误数IT:程序长度t:测试时间Ec(t):在0-t期间内发现的错误总数λ1=第190页，共192页。推测残留在

程序中的错误数错误植入模型Mills将播种模型用于程序中残留错误的估算,称错误植入模型播种模型：N：程序中原有残留的错误数Nt：新植入的错误数n:测试发现的原有错误数nt:测试发现的植入错误数NNnnt≈tNNnnt=t第191页，共192页。Hym

an对错误植入模型的改进ET:程序中原有的残留错误数E1:1号测试员在某一时间内发现的错误数E2:2号测试员在同一时间内发现的错误数E0:两位测试员共同发现的错误数EEEE1≈0=2TETE1E2/E0第192页，共192

页。