软件工程模型与方法12、软件测试.ppt

《软件工程模型与方法12、软件测试.ppt》由会员分享，可在线阅读，更多相关《软件工程模型与方法12、软件测试.ppt（107页珍藏版）》请在课桌文档上搜索。

1、软件工程模型与方法Models&Methods of Software Engineering,本章内容,12.1 软件测试基础12.2 软件测试方法与技术12.3 软件测试过程12.4 面向对象的测试方法12.5 程序的静态分析方法12.6 软件调试方法12.7 软件测试工具12.8 软件的可靠性,12.1 软件测试基础,本节内容12.1.1 软件测试概述12.1.2 软件的可测试性12.1.3 软件测试的对象12.1.4 软件测试信息流12.1.5 软件测试步骤12.1.6 软件测试流程12.1.7 软件测试与软件开发各阶段的关系12.1.8 程序错误的分类,12.1.1 软件测试概述,软

2、件测试是为了发现错误而执行程序的过程。软件测试在软件生存期中横跨两个阶段：单元测试 综合测试 软件测试的目的：测试是程序的执行过程，目的在于发现错误，而不是证明软件的正确 一个好的测试用例在于能发现至今未发现的错误 一个成功的测试是发现了至今未发现的错误的测试。,12.1.1 软件测试概述,软件测试的原则：应当尽早地和不断地进行软件测试 测试用例应由测试输入数据和与之对应的预期输出结果这两部分组成程序员应避免测试自己的程序 在设计测试用例时，应当包括合理的输入条件和不合理的输入条件 充分注意测试中的群集现象 严格执行测试计划，排除测试的随意性 应当对每一个测试结果做全面检查 妥善保存测试计划，

3、测试用例，出错统计和最终分析报告，为维护提供方便。,12.1.2 软件的可测试性,影响软件可测试性的因素：可操作性：运行的越好，被测试的效率越高 可观察性：所看见的就是所测试的 可控制性：对软件的控制越好，测试越能被自动执行与优化 可分解性：通过控制测试范围，能够更快地分解问题，执行更灵巧的再测试 简单性：需要测试的内容越少，测试的速度越快 稳定性：改变越小，对测试的破坏越小 易理解性：得到的信息越多，进行的测试越灵巧,12.1.3 软件测试的对象,软件测试并不等于程序测试，应该贯穿于软件开发的整个期间。需求分析、概要设计、详细设计以及程序编码等各个阶段所得到的文档，都应该成为测试的对象。为了

4、把握各个环节的正确性，人们需要进行各种确认和验证工作：确认（Validation）：是一系列的活动和过程，其目的是证实在一个给定的外部环境中软件的逻辑正确性。需求规格说明的确认程序的确认 验证（Verification）：试图证明在软件生存期各个阶段，以及阶段间的逻辑协调性、完备性和正确性。,12.1.3 软件测试的对象,12.1.4 软件测试信息流,软件配置：包括软件需求规格说明、软件设计规格说明、源代码等 测试配置：包括测试计划、测试用例、测试驱动程序等 测试工具：测试工具为测试的实施提供某种服务。,12.1.5 软件测试步骤,12.1.6 软件测试流程,理解测试需求编写测试计划 设计测试

5、方案 开发测试用例 执行软件测试 评估测试效果 编写测试文档,软件测试文档,软件测试计划：根据系统/子系统需求规格说明定义的软件配置项，说明测试项目、测试用例、测试人员，使软件测试能有效地管理和控制。软件测试说明：测试项目的具体分析，区分自动测试和手工测试；构造测试平台；定义测试过程。软件测试记录：执行软件测试用例，记录测试结果。软件问题报告：软件测试的结果汇总，分析软件的质量和存在的问题，并通知开发单位。软件问题处理报告：开发单位根据问题处理得出的解决方法，软件重新提交测试。软件测试报告：是整个测试的总结性文档。,12.1.7软件测试与软件开发各阶段的关系,12.1.8 软件错误的分类,按错

6、误的影响和后果分类：较小错误：只对系统输出有一些非实质性影响。如，输出的数据格式不合要求等。中等错误：对系统的运行有局部影响。如输出的某些数据有错误或出现冗余。较严重错误：系统的行为因错误的干扰而出现明显不合情理的现象。比如开出了0.00元的支票，系统的输出完全不可信赖。严重错误：系统运行不可跟踪，一时不能掌握其规律，时好时坏。非常严重的错误：系统运行中突然停机，其原因不明，无法软启动。最严重的错误：系统运行导致环境破坏，或是造成事故，引起生命、财产的损失。,12.1.8 软件错误的分类,按错误的性质和范围分类：（1）功能错误：规格说明错误；功能错误；测试错误；测试标准引起的错误；（2）系统错

7、误：外部/内部接口错误；硬件结构错误；操作系统错误；软件结构错误；控制与顺序错误；资源管理错误；（3）加工错误：算术与操作错误；初始化错误；控制和次序错误；静态逻辑错误；（4）数据错误：动态/静态数据错误；数据内容错误；数据结构错误；数据属性错误；（5）代码错误：语法错误；打字错误；对语句或指令不正确理解所产生的错误。,12.1.8 软件错误的分类,按软件生存期阶段分类（1）问题定义（需求分析）错误：由于需求分析没有准确定义用户要求（2）规格说明错误：规格说明与问题定义不一致；（3）设计错误：设计与规格说明不相符（4）编码错误：编码未很好实现设计结果，包括：数据使用类错误、控制流错误、界面错误

8、、输入输出错误等。,12.2 软件测试方法与技术,本节内容12.2.1 测试技术分类12.2.2 白盒测试技术12.2.3 黑盒测试技术12.2.4 测试方法选择的综合策略12.2.5 针对专门环境和应用的测试,12.2.1 测试技术分类,软件测试技术从大的方面可以分为两类：静态测试：对软件进行分析、检查和审阅，不实际运行被测试的软件。约可找出3070%的逻辑设计错误 动态测试：通过运行软件来检验软件的动态行为和运行结果的正确性 黑盒测试：已知产品的功能设计规格，可以进行测试证明每个实现了的功能是否符合要。白盒测试：已知产品的内部工作过程，可以通过测试证明每种内部操作是否符合设计规格的要求。,

9、黑盒测试,黑盒测试：在不考虑程序内部结构和内部特征的情况下，根据软件产品的功能设计规格说明，在计算机上进行测试，以证实每个实现了的功能是否符合要求。又叫做功能测试、数据驱动测试或基于规格说明的测试。黑盒测试主要是为了发现以下几类错误：功能错误或遗漏 输入和输出接口的正确性 数据结构或外部信息访问错误 性能要求满足情况 初始化或终止性错误,白盒测试,白盒测试：指根据软件产品的内部工作过程，在计算机上进行测试，以证实每种内部操作是否符合设计规格要求，所有内部成分是否已经过检查。又称为结构测试、逻辑驱动测试或基于程序的测试。白盒测试方法主要对程序模块进行如下检查：程序模块所有独立执行路径至少测试一次

10、 所有逻辑判定分支至少测试一次 循环边界和运行界限内执行情况 程序内部数据结构的有效性,黑盒测试与白盒测试的比较,测试用例的选择,唯一能够保证程序正确的测试方法就是“穷举测试”，但是对于一般的软件系统，无论是黑盒测试还是白盒测试，可能的测试用例都是天文数字。,假设一个程序P有输入X和Y及输出Z，字长为32位的计算机上运行。如果X、Y只取整数，考虑把所有的X、Y值都作为测试数据，测试数据组（Xi,Yi）的最大可能数目为：232232264。如果程序P测试一组X、Y数据需要1毫秒，且一天工作24小时，一年工作365天，要完成264组测试，需要5亿年。,测试用例的选择,任何软件开发项目都要受到期限、

11、费用、人力和机时等条件的限制，实行穷举测试工作量过大，实施起来是不现实的。为了节省时间和资源，提高测试效率，必须从数量极大的可用测试用例中精心地挑选少量的测试数据，使得采用这些测试数据能够达到最佳的测试效果，于是人们对如何挑选有效的测试用例进行了研究，下面就分别介绍几种行之有效的测试用例设计方法。,12.2.2白盒测试技术,基本白盒测试技术：1.逻辑覆盖2.基本路径测试3.控制结构测试,1.逻辑覆盖,逻辑覆盖是以程序内部的逻辑结构为基础的设计测试用例的一种白盒测试技术。可分为：语句覆盖判定覆盖判定条件覆盖条件组合覆盖路径覆盖,语句覆盖,语句覆盖:语句覆盖就是设计若干个测试用例，运行被测程序，使

12、得每一可执行语句至少执行一次。这种覆盖又称为点覆盖，它使得程序中每个可执行语句都得到执行。测试用例：A=2，B=0，X=4语句覆盖是最弱的逻辑覆盖准则。,判定覆盖,判定覆盖：判定覆盖就是设计若干个测试用例，运行被测程序，使得程序中每个判断的取真分支和取假分支至少经历一次。测试用例：A=3，B=0，X=3 可覆盖a、c、d分支A=2，B=1，X=1 可覆盖a、b、e分支判定覆盖只比语句覆盖稍强一些，但还是很弱。,条件覆盖,条件覆盖：条件覆盖就是设计若干个测试用例，运行被测程序，使得程序中每个判断的每个条件的可能取值至少执行一次。,判定条件覆盖,判定条件覆盖：判定条件覆盖就是设计足够的测试用例，使

13、得判断中每个条件的所有可能取值至少执行一次，同时每个判断本身的所有可能判断结果至少执行一次。,多重条件覆盖,多重条件覆盖：多重条件覆盖就是设计足够的测试用例，运行被测程序，使得每个判断的条件结果的所有可能取值组合至少执行一次。,路径测试,路径测试：路径测试就是设计足够的测试用例，覆盖程序中所有可能的路径;路径测试是最强的覆盖准则。,2.基本路径测试,路径测试是最强的覆盖准则，但实际上，一个不太复杂的程序，路径数都是非常庞大的，所以真正做到完全路径覆盖是很困难的，必须把覆盖路径数目压缩到一定限度。基本路径测试是在程序控制流图的基础上，通过分析控制构造的环路复杂性，导出基本可执行路径集合，从而设计

14、测试用例的方法。,基本路径测试步骤,导出程序流程图的拓扑结构-控制流图 计算控制流图G的环路复杂度V(G)确定只包含独立路径的基本路径集设计测试用例,导出程序的控制流图,复合条件表达式,如果判断语句中是复合条件，即由一个或多个逻辑运算符：or,and,nand,nor连接的逻辑表达式，则需要将判断改为一系列单条件的嵌套判断。,计算程序环路复杂性,进行程序的基本路径测试时，程序的环路复杂性给出了程序基本路径集合中的独立路径条数，这是确保程序中每个可执行语句至少执行一次所必需的测试用例数目的上界。所谓独立路径，是指包括一组以前没有处理的语句或条件的一条路径。通常环路复杂性可用以下三种方法求得:将环

15、路复杂性定义为控制流图中的区域数。设E为控制流图的边数，N为图的结点数，则定义环路复杂性为 V(G)EN2。若设P为控制流图中的判定结点数，则有 V(G)P1。,基本路径集,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,导出测试用例,采用基本路径法导出测试用例的步骤为：以详细设计或源代码为基础，导出程序的控制流图；计算得到的控制流图G的环路复杂性V（G）；确定现行无关的路径基本集；利用逻辑覆盖方法生成测试用例，确保基本路径集中每条路径的执行。,3.控制结构测试,关于分支结构

16、路径数的讨论,嵌套型分支若有n个判定语句，则需要n+1个测试用例,连锁型分支若有n个判定语句，则需要2n个测试用例,减少测试用例,为减少测试用例的数目，可采用试验设计法，抽取部分路径进行测试。1）设耦合型分支结构中有n个判定，计算满足关系式 n+12m 的最小自然数m；2）设t=2m，取正交表Lt，并利用它设计测试数据。,条件测试的策略,程序中的条件分为简单条件和复合条件。简单条件是一个布尔变量或一个关系表达式（可加前缀NOT）；复合条件由简单条件通过逻辑运算符（AND、OR、NOT）和括号连接而成。如果条件出错，至少是条件中某一成分有错。条件中可能的出错类型有：布尔运算符错、布尔变量错、布尔

17、括号错、关系运算符错、算术表达式错。,BRO 测试法,BRO（分支与关系运算符）测试法可以发现多个布尔运算符或关系运算符错，以及其它错误。BRO策略引入条件约束的概念。设有n个简单条件的复合条件C，其条件约束为D=（D1,D2,Dn），其中Di（1in）是条件C中第i个简单条件的输出约束。如果在C的执行过程中，其每个简单条件的输出都满足D中对应的约束，则称条件C的条件约束D由C的执行所覆盖。特别地，布尔变量或布尔表达式的输出约束必须是真（t）或假（f）；关系表达式的输出约束为符号、=、。,循环测试,简单循环测试,对于简单循环，测试应包括以下几种。其中的 n 表示循环允许的最大次数。零次循环：从

18、循环入口直接跳到循环出口。一次循环：查找循环初始值方面的错误。二次循环：检查在多次循环时才能暴露的错误。m次循环：此时的mn，也是检查在多次循环时才能暴露的错误。最大次数循环、比最大次数多一次的循环、比最大次数少一次的循环。,嵌套循环测试,对于嵌套循环，不能将简单循环的测试方法简单地扩大到嵌套循环，下面给出一种有助于减少测试数目的测试方法。除最内层循环外，从最内层循环开始，置所有其它层的循环为最小值；对最内层循环做简单循环的全部测试。测试时保持所有外层循环的循环变量为最小值。另外，对越界值和非法值做类似的测试。逐步外推，对其外面一层循环进行测试。测试时保持所有外层循环的循环变量取最小值，所有其

19、它嵌套内层循环的循环变量取“典型”值。反复进行，直到所有各层循环测试完毕。对全部各层循环同时取最小循环次数，或者同时取最大循环次数。对于后一种测试，由于测试量太大，需人为指定最大循环次数。,连锁与非结构循环测试,对于连锁循环，要区别两种情况。如果各个循环互相独立，则连锁循环可以用与简单循环相同的方法进行测试。但如果几个循环不是互相独立的，则需要使用测试嵌套循环的办法来处理。对于非结构循环，应该使用结构化程序设计方法重新设计测试用例。,12.2.3黑盒测试技术,等价类划分边界值分析错误推测法因果图法,1.等价类划分,等价类划分是一种典型的黑盒测试方法。该方法是把所有可能的输入数据划分为若干部分，

20、从每一部分中选取少数有代表性的数据作为测试用例。所谓等价类是指某个输入域的子集合，在该子集合中，各个输入数据对于揭露程序中的错误都是等效的。并合理地假定：测试某等价类的代表值就等价于对这一类其它值的测试。采用等价类方法测试系统步骤：划分等价类确定测试用例,划分等价类,等价类的划分有两种不同的情况：有效等价类：是指对于程序规格说明来说，是合理的，有意义的输入数据构成的集合。利用它，可以检验程序是否实现了规格说明预先规定的功能和性能。无效等价类：是指对于程序规格说明来说，是不合理的，无意义的输入数据构成的集合。利用它，可以检查程序中功能和性能的实现是否有不符合规格说明要求的地方。,划分等价类的原则

21、,按区间划分，可得一有二无；按数值集合划分，可得一有一无；如果输入条件是一个布尔量，可得一有一无 按数值划分，可得多有一无；按限制条件或规则划分，可得一有多无；如果已划分的等价类中各元素在程序中的处理方式不同，进一步划分成更小的等价类。,确定测试用例,形成等价类表，每一等价类有一个唯一的编号；设计一个测试用例，使其尽可能多地覆盖尚未覆盖的有效等价类，重复这一步骤，直到所有有效等价类均被测试用例所覆盖。设计一新测试用例，使其只覆盖一个无效等价类，重复这一步骤直到所有无效等价类均被覆盖。,2.边界值分析,人们从长期的测试工作经验得知，大量的错误是发生在输入或输出范围的边界上，而不是在输入范围的内部

22、。通常输入等价类与输出等价类的边界，就是应着重测试的边界情况。应当选取正好等于，刚刚大于，或刚刚小于边界的值作为测试数据，而不是选取等价类中的典型值或任意值作为测试数据。,边界值分析法原则,如果输入条件规定了值的范围，则应选取刚达到这个范围的边界值，以及刚刚超过这个范围的边界值作为测试输入数据 如果输入条件规定了值的个数，则用最大个数、最小个数、比最大个数多1、比最小个数少1的数作为测试用例 如果输出结果限定在某个范围内，则应选取测试用例，使输出结果刚刚达到这个范围的边界值，或刚刚超过这个边界值 如果输出结果规定了个数，则选用使输出结果为最大个数、最小个数、比最大个数多1、比最小个数少1的数作

23、为测试用例 如果输入与输出是有序集合，则应选取集合的第一个元素和最后一个元素作为测试用例 如果程序中使用了一个内部数据结构，则应当选择这个内部数据结构的边界的值作为测试用例 分析规格说明书，找到其他可能的边界条件进行测试。,3.错误推测法,错误推测法的基本想法是：列举出程序中所有可能有的错误和容易发生错误的特殊情况，根据它们选择测试用例。例如：输入输出为0输入表格为空排序中输入空、一个数据、相等数据、顺序数据、逆序数据等情况,4.因果图法,在测试时必须考虑输入条件的各种组合，可能的组合数将是天文数字。因此必须考虑使用一种适合于描述对于多种条件的组合，相应产生多个动作的形式来考虑设计测试用例，这

24、就需要利用因果图。因果图方法最终生成的就是判定表。它适合于检查程序输入条件的各种组合情况。,因果图生成步骤,分析软件规格说明描述中：哪些是原因（即输入条件或输入条件的等价类），哪些是结果（即输出条件），并给每个原因和结果赋予一个标识符；分析软件规格说明描述中的语义，找出原因与结果之间，原因与原因之间对应的关系，根据这些关系，画出因果图；由于语法或环境限制，有些原因与原因之间，原因与结果之间的组合情况不可能出现。为表明这些特殊情况，在因果图上用一些记号标明约束或限制条件；把因果图转换成判定表；把判定表的每一列拿出来作为依据，设计测试用例；,在因果图中，用Ci表示原因，Ei表示结果：恒等：若原因出

25、现，则结果出现。若原因不出现，则结果也不出现。非：若原因出现，则结果不出现。若原因不出现，反而结果出现。或（）：若几个原因中有一个出现，则结果出现，几个原因都不出现，结果不出现。与（）：若几个原因都出现，结果才出现。若其中有一个原因不出现，结果不出现。,为了表示原因与原因之间，结果与结果之间可能存在的约束条件，在因果图中可以附加一些表示约束条件的符号:E（互斥）：a，b不会同时成立，两个中最多有一个可能成立。I（包含）：a，b，c中至少有一个必须成立。O（唯一）：a和b当中必须有一个，且仅有一个成立。R（要求）：当a出现时，b必须也出现。不可能a出现，b不出现。M（屏蔽）：表示当a是1时，b必

26、须是0。而当a为0时，b的值不定。,因果图法举例,有一个处理单价为5角钱的饮料的自动售货机软件测试用例的设计。其规格说明如下：“若投入5角钱或1元钱的硬币，按下橙汁或啤酒的按钮，则相应的饮料就送出来。若售货机没有零钱找，则一个显示零钱找完的红灯亮，这时再投入1元硬币并按下按钮后，饮料不送出来而且1元硬币也退出来；若有零钱找，则显示零钱找完的红灯灭，在送出饮料的同时退还5角硬币。”,（1）分析这一段说明，列出原因和结果,（2）画出因果图（3）由于 2 与 3，4 与 5 不能同时发生，分别加上约束条件E（4）转换成判定表,在判定表中，阴影部分表示因违反约束条件的不可能出现的情况，删去,12.2.

27、4 测试方法选择的综合策略,Myers提出使用各种测试方法的综合策略：在任何情况下都必须使用边界值分析方法 必要时用等价类划分方法补充一些测试用例 用错误推测法再追加一些测试用例 对照程序逻辑，检查已设计出的测试用例的逻辑覆盖程度 如果程序的功能说明中含有输入条件的组合情况，则一开始就可选用因果图法。,12.2.5 针对专门环境和应用的测试,GUI测试：图形用户界面（GUI）对软件工程师提出了有趣的挑战，因为GUI开发环境有可复用的构件，开发用户界面更加省时和精确，但同时GUI的复杂性也增加了，从而增加了设计和执行测试用例的难度。窗口 下拉式菜单和鼠标操作 数据项,12.2.5针对专门环境和应

28、用的测试,2.客户/服务器（C/S）软件测试客户/服务器（C/S）软件系统是比较复杂的软件产品，其具有的分布性、事物处理相关性、跨平台性、网络通讯的复杂性、中心数据库为多个客户服务和服务器的协调一致性等特点，使得对C/S结构的软件系统测试非常困难。C/S常用测试方法包括：客户端应用功能测试；服务器测试（协调和数据管理功能、性能）；数据库测试；事务测试；网络通信测试。,12.2.5针对专门环境和应用的测试,3.实时系统测试实时系统的时间依赖性和异步性给软件测试带来新的困难时间。测试用例设计者考虑的不仅是白盒和黑盒测试用例，而且包括事件处理(如中断处理)、数据的时间安排以及处理数据的任务(进程)的

29、并发性。另外、实时系统的软件和硬件之间的密切关系也会导致测试问题，软件测试必须考虑硬件故障对软件处理的影响。,12.3软件测试过程,本节内容12.3.1 单元测试12.3.2 集成测试12.3.3 确认测试12.3.4 系统测试12.3.5 何时停止测试,12.3.1单元测试,单元测试又称为模块测试，是针对程序模块进行正确性检验的测试。其目的在于发现各模块内部可能存在的各种差错。单元测试主要采用白盒测试为主、黑盒测试为辅的测试方法。,单元测试的步骤,单元测试在编码阶段进行，是编码步骤的附属部分。单元测试需要编写一些辅助模块去模拟与被测模块相联系的其它模块。模块并不是一个独立的程序。,驱动模块与

30、桩模块,这些辅助模块分为两种：驱动模块（driver）：相当于被测模块的主程序。它接收测试数据，把这些数据传送给被测模块，最后输出实测结果。桩模块（stub）：也叫做存根模块，用以代替被测模块调用的子模块。桩模块可以做少量的数据操作，不需要把子模块所有功能都带进来，但不允许什么事情也不做。,12.3.2集成测试,在单元测试的基础上，需要将所有模块按照设计要求组装成为系统。模块组装成为系统有两种方式：一次性集成方式 增殖式集成方式 自顶向下的增殖方式 自底向上的增殖方式 混合增殖式测试 三种常见的综合增殖方式:衍变的自顶向下的增殖测试 自底向上-自顶向下的增殖测试 回归测试,12.3.3确认测试

31、,确认测试又称有效性测试，它的任务是验证软件的有效性，即验证软件的功能和性能及其它特性是否与用户的要求一致。,12.3.3确认测试,进行有效性测试（功能测试）有效性测试是在模拟的环境（可能就是开发的环境）下，运用黑盒测试的方法，验证被测软件是否满足需求规格说明书列出的需求。软件配置复查 软件配置复查的目的是保证软件配置的所有成分都齐全，各方面的质量都符合要求，具有维护阶段所必需的细节，而且已经编排好分类的目录。,12.3.3确认测试,测试和测试 测试是由一个用户在开发环境下进行的测试，也可以是公司内部的用户在模拟实际操作环境下进行的测试。这是在受控制的环境下进行的测试。测试是由软件的多个用户在

32、一个或多个用户的实际使用环境下进行的测试。与测试不同的是，开发者通常不在测试现场。测试是在开发者无法控制的环境下进行的软件现场应用。验收测试 验收测试是以用户为主的测试。软件开发人员和QA（质量保证）人员也应参加。,12.3.4 系统测试,所谓系统测试，是将通过确认测试的软件，作为基于计算机系统的一个元素，与计算机硬件、外设、某些支持软件、数据和人员等其它系统元素结合在一起，在实际运行（使用）环境下，对计算机系统进行一系列的组装测试和确认测试。系统测试的目的在于通过与系统的需求定义作比较，发现软件与系统定义不符合或与之矛盾的地方 恢复测试 压力测试 性能测试 安全测试,12.3.5 何时停止测

33、试,Musa 和AckermanMUS89提出：“我们不能绝对地认定软件永远也不会再出错，但是相对于一个理论上合理的和在试验中有效的统计模型来说，如果一个在按照概率的方法定义的环境中，1000 个CPU 小时内不出错的操作概率大于0.995 的话，那么我们就有95的信心说我们已经进行了足够的测试。”一个称为对数泊松执行时间模型(logarithmic Poisson execution-time model)的软件故障模型为：f(t)=(1/p)1n(l0pt+1),12.3.5 何时停止测试,其中：f(t)=软件在一定的测试时间t 后，可能会发生故障的预期累计数目。l0=在测试刚开始时的初始

34、软件故障密度(单位时间内的故障数)。p=错误被发现和修正的过程中故障密度的指数递减值。瞬时的故障密度，l(t)可以使用f(t)的导数得出 l(t)=l0/(l0pt+1),故障密度作为执行时间的函数,12.4 面向对象的测试方法,本节内容12.4.1面向对象测试与传统测试的区别 12.4.2面向对象的测试模型 12.4.3面向对象分析的测试 12.4.4面向对象设计的测试 12.4.5面向对象编程的测试 12.4.6面向对象的单元测试 12.4.7面向对象的集成测试 12.4.8面向对象的系统测试,12.4.1 面向对象测试与传统测试的区别,传统的测试计算机软件的策略是从“小型测试”开始，逐步

35、走向“大型测试”首先从单元测试开始，然后逐步进入集成测试，最后是确认和系统测试 面向对象程序的结构不再是传统的功能模块结构，作为一个整体，原有集成测试所要求的逐步将开发的模块搭建在一起进行测试的方法已经不可能 面向对象软件抛弃了传统的开发模式，对每个开发阶段都有不同以往的要求和结果,已经不可能用功能细化的观点来检测面向对象分析和设计的结果,12.4.2 面向对象的测试模型,面向对象的开发模型将开发分为面向对象分析（OOA），面向对象设计（OOD），和面向对象编程（OOP）三个阶段 OOA Test和OOD Test是对分析结果和设计结果的测试 OOP Test主要针对编程风格和程序代码实现进行

36、测试,12.4.3 面向对象分析的测试,1对认定的对象的测试认定的对象是否全面，是否问题空间中所有涉及到的实例都反映在认定的抽象对象中 认定的对象是否具有多个属性 对认定为同一对象的实例是否有共同的，区别于其他实例的共同属性 如果系统没有必要始终保持对象代表的实例的信息，提供或者得到关于它的服务，认定的对象也无必要 认定的对象的名称应该尽量准确，适用,12.4.3 面向对象分析的测试,2对认定的结构的测试在Coad方法中，认定的结构指的是多种对象的组织方式，用来反映问题空间中的复杂实例和复杂关系 认定的结构分为两种：分类结构和组装结构 3对认定的主题的测试贯彻George Miller 的“7

37、+2”原则，如果主题个数超过7个，就要求对有较密切属性和服务的主题进行归并 主题所反映的一组对象和结构是否具有相同和相近的属性和服务 认定的主题是否是对象和结构更高层的抽象，是否便于理解OOA结果的概貌 主题间的消息联系（抽象）是否代表了主题所反映的对象和结构之间的所有关联。,12.4.3 面向对象分析的测试,4对定义的属性和实例关联的测试属性是用来描述对象或结构所反映的实例的特性。而实例关联是反映实例集合间的映射关系 5对定义的服务和消息关联的测试定义的服务，就是定义的每一种对象和结构在问题空间所要求的行为。由于问题空中实例间必要的通信，在OOA 中相应需要定义消息关联,12.4.4 面向对

38、象设计的测试,而面向对象设计（OOD）采用“造型的观点”，以OOA为基础归纳出类，并建立类结构或进一步构造成类库，实现分析结果对问题空间的抽象 OOD是OOA的进一步细化和更高层的抽象对认定的类的测试 对构造的类层次结构的测试 对构造的类层次结构的测试,12.4.5面向对象编程的测试,典型的面向对象程序具有继承、封装和多态的新特性，这使得传统的测试策略必须有所改变 在面向对象编程（OOP）阶段，忽略类功能实现的细则，将测试的目光集中在类功能的实现和相应的面向对象程序风格 数据成员是否满足数据封装的要求 类是否实现了要求的功能,12.4.6面向对象的单元测试,当考虑面向对象软件时，单元测试的对象

39、是类的成员函数 在设计测试用例选择输入数据时，可以基于以下两个假设：如果函数（程序）对某一类输入中的一个数据正确执行，对同类中的其他输入也能正确执行 如果函数（程序）对某一复杂度的输入正确执行，对更高复杂度的输入也能正确执行 面向对象编程的特性使得对成员函数的测试，又不完全等同于传统的函数或过程测试 Brian Marick 给出了两方面的考虑：继承的成员函数是否都不需要测试 对父类的测试是否能照搬到子类,12.4.7面向对象的集成测试,传统的集成测试 自顶向下集成 自底向上集成 具体设计测试用例，可参考下列步骤：先选定检测的类，参考OOD分析结果，分析出类的状态和相应的行为，类或成员函数间传

40、递的消息，输入或输出的界定等 确定覆盖标准 利用结构关系图确定待测类的所有关联 根据程序中类的对象构造测试用例，确认使用什么输入激发类的状态、使用类的服务和期望产生什么行为等,12.4.8面向对象的系统测试,系统测试应该尽量搭建与用户实际使用环境相同的测试平台，应该保证被测系统的完整性，对临时没有的系统设备部件，也应有相应的模拟手段 系统测试的具体测试内容包括：功能测试 强度测试 性能测试 安全测试 恢复测试 可用性测试 安装/卸载测试（install/uninstall test）等等,12.5 程序的静态分析方法,本节内容12.5.1 源程序静态分析 12.5.2 人工测试,12.5.1源

41、程序静态分析,1生成各种引用表直接从表中查出说明使用错误等 为用户提供辅助信息 用来做错误预测和程序复杂度计算 2.静态错误分析类型和单位分析 类型和单位分析 表达式分析 接口分析,12.5.2 人工测试,1桌前检查（Desk Checking）由程序员自己检查自己编写的程序。程序员在程序通过编译之后，进行单元测试设计之前，对源程序代码进行分析，检验，并补充相关的文档，目的是发现程序中的错误 2代码会审（Code Reading Review）代码会审是由若干程序员和测试员组成一个会审小组，通过阅读、讨论和争议，对程序进行静态分析的过程 3走查（Walkthroughs）,12.6 软件调试方

42、法,本节内容12.6.1 调试过程 12.6.2 调试原则 12.6.3 主要调试方法,12.6.1 调试过程,调试的执行步骤如下:从错误的外部表现形式入手，确定程序中出错位置 研究有关部分的程序，找出错误的内在原因 修改设计和代码，以排除这个错误 重复进行暴露了这个错误的原始测试或某些有关测试，以确认该错误是否被排除；是否引进了新的错误 如果所做的修正无效，则撤消这次改动，重复上述过程，直到找到一个有效的解决办法为止,12.6.1 调试过程,调试的执行步骤:,12.6.2调试原则,1确定错误的性质和位置的原则用头脑去分析思考与错误征兆有关的信息 避开死胡同 只把调试工具当作辅助手段来使用 避

43、免用试探法，最多只能把它当作最后手段 2修改错误的原则在出现错误的地方，很可能还有别的错误修改错误的一个常见失误是只修改了这个错误的征兆或这个错误的表现，而没有修改错误的本身 当心修正一个错误的同时有可能会引入新的错误 修改错误的过程将迫使人们暂时回到程序设计阶段 修改源代码程序，不要改变目标代码,12.6.3主要调试方法,1强行排错这是目前使用较多，效率较低的调试方法。它不需要过多的思考，比较省脑筋 2回溯法排错这是在小程序中常用的一种有效的排错方法 3归纳法排错,12.6.3主要调试方法,4演绎法排错,12.7软件测试工具,本节内容12.7.1软件测试工具分类 12.7.2常用的软件测试工

44、具简介,12.7.1软件测试工具分类,1白盒测试工具2黑盒测试工具3测试管理工具4静态分析工具5动态测试工具6测试数据自动生成工具7模块测试台8集成测试环境,12.7.2常用的软件测试工具简介,1按照测试功能分类 单元测试工具 C+Test,JUnit 测试管理工具 Suite TestStudio,Testexpert GUI测试工具 Rational robot 负载性能测试工具 PerfomanceStudio Web测试工具 SilkTset，SilkPerfomer，Surf,Web Application Stress 缺陷跟踪工具 Rational ClearQuest、Comp

45、uware公司的TrackRecord,12.7.2 常用的软件测试工具简介,2按照软件测试工具开发商分类 Mercury Interactive Topaz,Astra LoadTest RationalRose,ClearCase Compuware BoundsChecker,SmartCheck Microsoft NT/2000/XP Resource Kit,Web Application Stress,12.8软件的可靠性,本节内容12.8.1基本概念 12.8.2软件可靠性衡量方法,12.8.1基本概念,按照IEEE的规定 术语“错误”的含义是由开发人员造成的软件差错 术语“故

46、障”的含义是由错误引起的软件的不正确行为,12.8.2软件可靠性衡量方法,1估算平均无故障时间MTTF（Mean Time To Failure）估算公式（Shooman模型）为：K 是一个经验常数，美国一些统计数字表明，K的典型值是200 ET 是测试之前程序中原有的故障总数 IT 是程序长度 t是测试（包括排错）的时间 EC(t)是在0t期间内检出并排除的故障总数,12.8.2软件可靠性衡量方法,设EC()是0时间内检出并排除的故障总数，是测试时间(月)，则在同一段时间0内的单条指令累积规范化排除故障数曲线c()为：c()=EC()IT,12.8.2软件可靠性衡量方法,2估算软件中故障总数ET的方法利用Shooman模型估算程序中原来错误总量ET瞬间估算法：利用植入故障法估算程序中原有故障总数ET 捕获再捕获抽样法 Hyman分别测试法,