第五章第五章 软件测试与维护软件测试与维护Page 2任务任务5.1SAGM系统登录测试系统登录测试Page 35.1.1 案例描述案例描述 教职工津贴教职工津贴系统开发完毕，需要进行功能测试，本系统开发完毕，需要进行功能测试，本案例要求进行登录功能测试，设计详细的测试用例，完案例要求进行登录功能测试，设计详细的测试用例，完成黑盒测试。成黑盒测试。Page 45.1.2 案例分析案例分析 任何程序、系统中的问题，和产品设计书的不一致性，任何程序、系统中的问题，和产品设计书的不一致性，任何程序、系统中的问题，和产品设计书的不一致性，任何程序、系统中的问题，和产品设计书的不一致性，不能满足用户的需求不能满足用户的需求不能满足用户的需求不能满足用户的需求 必须意识到：必须意识到：必须意识到：必须意识到：“ “软件软件软件软件” ” 编程，它有自己的生命周编程，它有自己的生命周编程，它有自己的生命周编程，它有自己的生命周期期期期 (life cycle)(life cycle)。大型软件系统的开发与其它工程项目。大型软件系统的开发与其它工程项目。大型软件系统的开发与其它工程项目。大型软件系统的开发与其它工程项目如建造桥梁、制造飞机、轮船等的开发是同理的。如建造桥梁、制造飞机、轮船等的开发是同理的。如建造桥梁、制造飞机、轮船等的开发是同理的。如建造桥梁、制造飞机、轮船等的开发是同理的。 实践证明实践证明实践证明实践证明：对软件进行充分的测试：对软件进行充分的测试：对软件进行充分的测试：对软件进行充分的测试 才能够有效的保证软件质量才能够有效的保证软件质量才能够有效的保证软件质量才能够有效的保证软件质量！Page 55.1.3 知识准备知识准备IEEE (1983) 729 IEEE (1983) 729 软件缺陷一个标准的定义：软件缺陷一个标准的定义：p 从产品内部看，软件缺陷是软件产品开发或维护过程中所存在的错误、毛病等各种问题；p 从外部看，软件缺陷是系统所需要实现的某种功能的失效或违背。 软件缺陷的主要类型软件缺陷的主要类型/ /现象：现象：p 功能、特性没有实现或部分实现p 设计不合理，存在缺陷p 实际结果和预期结果不一致p 运行出错，包括运行中断、系统崩溃、界面混乱p 数据结果不正确、精度不够p 用户不能接受的其他问题，如存取时间过长、界面不美观 Page 65.1.3 知识准备知识准备软件缺陷的产生 技术问题技术问题算法错误，语法错误，计算和精度问题，接口参数传递不匹配团队工作团队工作误解、沟通不充分软件本身软件本身文档错误、用户使用场合(user scenario)，时间上不协调、或不一致性所带来的问题系统的自我恢复或数据的异地备份、灾难性恢复等问题Page 75.1.3 知识准备知识准备软件缺陷构成Page 85.1.3 知识准备知识准备在真正的程序测试之前，通过审查、评审会可以发现更多的缺陷。规格说明书的缺陷会在需求分析审查、设计、编码、测试等过程中会逐步发现，而不能在需求分析一个阶段发现Page 95.1.3 知识准备知识准备缺陷成本Page 105.1.3 知识准备知识准备软件测试的基本方法根据根据G.J. Myers观观点点-软件测试的目:n 软件件测试是是为了了发现错误而而执行程序的行程序的过程程n 一个好的一个好的测试能能够在第一在第一时间发现程序中存在的程序中存在的错误n 一个好的一个好的测试是是发现了至今尚未了至今尚未发现的的错误的的测试。软件测试是质量控制的重要手段，保证客软件测试是质量控制的重要手段，保证客软件测试是质量控制的重要手段，保证客软件测试是质量控制的重要手段，保证客户拿到或用户使用高质量的软件产品户拿到或用户使用高质量的软件产品户拿到或用户使用高质量的软件产品户拿到或用户使用高质量的软件产品Page 115.1.3 知识准备知识准备软件测试误区p 误区一：误区一：如果发布出去的软件有质量问题，都是软件测试人员的错p 误区二：误区二：软件测试技术要求不高，至少比编程容易多了p 误区三：误区三：有时间就多测试一些，来不及就少测试一些 p 误区四：误区四：软件测试是测试人员的事，与开发人员无关 p 误区五：误区五：根据软件开发瀑布模型，软件测试是开发后期的一个阶段Page 125.1.3 知识准备知识准备软件测试的原则所有测试的标准都是建立在用户需求用户需求之上。软件测试必须基于“质量第一质量第一”的思想去开展各项工作，当时间和质量冲突时，时间要服从质量。事先定义好产品的质量标准质量标准，只有有了质量标准，才能根据测试的结果，对产品的质量进行分析和评估。软件项目一启动，软件测试也就是开始软件项目一启动，软件测试也就是开始，而不是等程序写完，才开始进行测试。穷举测试是不可能的穷举测试是不可能的。甚至一个大小适度的程序，其路径排列的数量也非常大，因此，在测试中不可能运行路径的每一种组合。 Page 135.1.3 知识准备知识准备软件测试的原则第三方进行测试会更客观，更有效。软件测试计划是做好软件测试工作的前提。测试用例是设计出来的，不是写出来的，所以要根据测试的目的，采用相应的方法去设计测试用例，从而提高测试的效率，更多地发现错误，提高程序的可靠性。对发现错误较多的程序段，应进行更深入的测试。一般来说，一段程序中已发现的错误数越多，其中存在的错误概率也就越大。重视文档，妥善保存一切测试过程文档（测试计划、测试用例、测试报告等）Page 145.1.3 知识准备知识准备软件测试的原则l 应当把“尽早和不断地测试”作为测试人员的座右铭l 回归测试的关联性一定要引起充分的注意，修改一个错误而引起更多错误出现的现象并不少见l 测试应从“小规模”开始，逐步转向“大规模”。l 不可将测试用例置之度外，排除随意性。l 必须彻底检查每一个测试结果。l 一定要注意测试中的错误集中发生现象，这和程序员的编程水平和习惯有很大的关系l 对测试错误结果一定要有一个确认的过程。Page 155.1.3 知识准备知识准备测试方法 黑盒子和白盒子黑盒子和白盒子 静态的和动态的静态的和动态的 文档、代码审查文档、代码审查 数据输入边界条件法数据输入边界条件法 等价划分、数据流程图等价划分、数据流程图 状态变换图状态变换图 逻辑路径法逻辑路径法Page 165.1.3 知识准备知识准备黑盒子和白盒子功能测试功能测试数据驱动测试数据驱动测试 结构测试结构测试逻辑驱动测试逻辑驱动测试 客户需求事件驱动输入输出Page 175.1.3 知识准备知识准备静态的和动态的主持人主持人作者记录员列席人员内审员内审员技术专业人员用户代表不正式正式互审 走读 审查会议运行程序运行程序Page 185.1.3 知识准备知识准备自动测试和手工测试手工模拟用户手工模拟用户操作操作Page 195.1.3 知识准备知识准备软件测试分类方法方法目标目标/特性特性单元测试单元测试系统测试系统测试验收测试验收测试性能测试性能测试强壮性测试强壮性测试功能测试功能测试白盒测试白盒测试黑盒测试黑盒测试测试阶段或层次测试阶段或层次适用性测试适用性测试可靠性测试可靠性测试集成测试集成测试安全性测试安全性测试Page 205.1.3 知识准备知识准备软件测试阶段阶 段输 入 输 出 需求分析需求定义, 市场分析文档, 相关技术文档市场需求分析会议记要 , 功能设计, 技术设计设计审查 市场需求文档, 技术设计文档 测试计划, 测试用例功能验证 代码完成文件包,功能详细设计说明书最终技术文档完整测试用例,完备的测试计划, 缺陷报告,功能验证测试报告系统测试代码修改后的文件包 完整测试用例,完备的测试计划 缺陷报告缺陷状态报告项目阶段报告确认测试代码冻结文件包确认测试用例缺陷状态报告缺陷报告审查版本审查版本发布 代码发布文件包 测试计划检查清单当前版本已知问题的清单版本发布报告Page 215.1.3 知识准备知识准备测试阶段（SDLC)Page 225.1.4 案例实现案例实现需求：用户名长度为用户名长度为6 6至至1010位（含位（含6 6位和位和1010位）位）用户名由字符（用户名由字符（a-za-z、A-ZA-Z）和数字（）和数字（0-90-9）组成）组成不能为空、空格和特殊字符不能为空、空格和特殊字符密码规则同用户名规则密码规则同用户名规则Page 235.1.4 案例实现案例实现 简单：能够正确处理用户登录简单：能够正确处理用户登录一般：一般：l输入正确的用户名和密码可以进入系统输入正确的用户名和密码可以进入系统l输入用户名或密码错误无法进入系统输入用户名或密码错误无法进入系统Page 245.1.4 案例实现案例实现n详细：用户身份合法性验证n用户名验证n正常用户名的输入n含有特殊字符的用户名n为空或含有空格n字母大小写无关性测试n非法用户n密码验证n正常密码n含有特殊字符的密码n字母大小写敏感性测试n为空或含有空格n密码有效期验证n密码保存n忘记密码后找回密码功能Page 255.1.4 案例实现案例实现步骤：1、输入、输入2、输入、输入3、点击、点击OK按钮按钮结果：Page 265.1.4 案例实现案例实现“用户名”“密码”“预期结果”说明“user10”“pass10”进入系统进入系统正确的用户名和密码正确的用户名和密码(6位位)“user789”“pass789”进入系统进入系统正确的用户名和密码正确的用户名和密码(7-9位位)“user000010”“pass000010”进入系统进入系统正确的用户名和密码正确的用户名和密码(10位位)“”“pass”提示输入用户名提示输入用户名不能进入系统不能进入系统用户名为空用户名为空“空格空格”“pass”提示无效用户名提示无效用户名不能进入系统不能进入系统用户名为空格用户名为空格“user”“userpass”提示用户名太短提示用户名太短不能进入系统不能进入系统用户名小于用户名小于6位位“user0000011”“userpass”提示用户名太长提示用户名太长不能进入系统不能进入系统用户名大于用户名大于10位位Page 275.1.5 拓展训练拓展训练 教职工津贴教职工津贴系统中，完成用户添加、修改、删除的系统中，完成用户添加、修改、删除的功能测试，设计详细的测试用例，完成黑盒测试。功能测试，设计详细的测试用例，完成黑盒测试。Page 28任务任务5.2SAGM系统测试用例设计系统测试用例设计Page 295.2.2 知识准备知识准备黑盒测试法与白盒测试法 1. 1. 黑盒法黑盒法 该方法把被测试对象看成一个黑盒子，测试人员完全不考虑程序的内部结构和处理过程，只在软件的接口处进行测试， 依据需求说明书，检查程序是否满足功能要求。因此， 黑盒测试又称为功能测试或数据驱动测试。 通过黑盒测试主要发现以下错误： (1) 是否有不正确或遗漏了的功能。 (2) 在接口上，能否正确地接受输入数据， 能否产生正确的输出信息。 (3) 访问外部信息是否有错。 (4) 性能上是否满足要求等。 Page 305.2.2 知识准备知识准备黑盒测试法与白盒测试法 用黑盒法测试时，必须在所有可能的输入条件和输出条件中确定测试数据。是否要对每个数据都进行穷举测试呢？例如测试一个程序，需输入 3 个整数值。微机上，每个整数可能取值有216个，3个整数值的排列组合数为216216216=24831014。假设此程序执行一次为一毫秒， 用这些所有的数据去测试要用1万年！但这还不能算穷举测试， 还要输入一切不合法的数据。可见，穷举地输入测试数据进行黑盒测试是不可能的。 2. 2. 白盒法白盒法 该方法把测试对象看作一个打开的盒子， 测试人员须了解程序的内部结构和处理过程，以检查处理过程的细节为基础， 对程序中尽可能多的逻辑路径进行测试，检验内部控制结构和数据结构是否有错， 实际的运行状态与预期的状态是否一致。 Page 315.2.2 知识准备知识准备黑盒测试法与白盒测试法 用黑盒法测试时，必须在所有可能的输入条件和输出条件中确定测试数据。是否要对每个数据都进行穷举测试呢？例如测试一个程序，需输入 3 个整数值。微机上，每个整数可能取值有216个，3个整数值的排列组合数为216216216=24831014。假设此程序执行一次为一毫秒， 用这些所有的数据去测试要用1万年！但这还不能算穷举测试， 还要输入一切不合法的数据。可见，穷举地输入测试数据进行黑盒测试是不可能的。 2. 2. 白盒法白盒法 该方法把测试对象看作一个打开的盒子， 测试人员须了解程序的内部结构和处理过程，以检查处理过程的细节为基础， 对程序中尽可能多的逻辑路径进行测试，检验内部控制结构和数据结构是否有错， 实际的运行状态与预期的状态是否一致。 Page 325.2.2 知识准备知识准备黑盒测试法与白盒测试法 白盒法也不可能进行穷举测试，企图遍历所有的路径， 往往是做不到的。如测试一个循环20次的嵌套的IF语句， 循环体中有5条路径。测试这个程序的执行路径为520， 约为1014， 如果每毫秒完成一个路径的测试， 测试此程序需3170年！ 对于白盒测试，即使每条路径都测试了，程序仍可能有错。 例如要求编写一个升序的程序，错编成降序程序（功能错）， 就是穷举路径测试也无法发现。再如由于疏忽漏写了路径， 白盒测试也发现不了。 所以，黑盒法和白盒法都不能使测试达到彻底。为了用有限的测试发现更多的错误，需精心设计测试用例。黑盒法、 白盒法是设计测试用例的基本策略，每一种方法对应着多种设计测试用例的技术，每种技术可达到一定的软件质量标准要求。 下面分别介绍这两类方法对应的各种测试用例设计技术。 Page 33白盒技术白盒技术 由于白盒测试是结构测试，所以被测对象基本上是源程序， 以程序的内部逻辑结构为基础设计测试用例。 1. 逻辑覆盖逻辑覆盖 追求程序内部的逻辑结构覆盖程度，当程序中有循环时， 覆盖每条路径是不可能的，要设计使覆盖程度较高的或覆盖最有代表性的路径的测试用例。下面根据图5.1所示的程序，分别讨论几种常用的覆盖技术。 5.2.2 知识准备知识准备Page 34 1) 语句覆盖 为了提高发现错误的可能性，在测试时应该执行到程序中的每一个语句。 语句覆盖是指设计足够的测试用例，使被测程序中每个语句至少执行一次。 如图5.1是一个被测程序的程序流程图。 如果能测试路径124，就保证每个语句至少执行一次，选择测试数据为 a=2 ， b=0， x=3输入此组数据， 就能达到语句覆盖标准。 Page 35 2) 判定覆盖 判定覆盖指设计足够的测试用例， 使得被测程序中每个判定表达式至少获得一次“真”值和“假”值，从而使程序的每一个分支至少都通过一次， 因此判定覆盖也称分支覆盖。 设计测试用例，只要通过路径124, 135或者125, 134， 就达到判定覆盖标准。 选择两组数据： a=3， b=0， x=1（通过路径125） a=2， b=1， x=2（通过路径134） 对于多分支（嵌套IF, CASE）的判定，判定覆盖要使得每一个判定表达式获得每一种可能的值来测试。 Page 36 判定覆盖较语句覆盖严格，因为如果通过了各个分支， 则各个语句也执行了。但该测试仍不充分，上述数据只覆盖了全部路径的一半， 如果将第二个判定表达式中的“x1”错写成“x1”，仍查不出错误。 3) 条件覆盖 条件覆盖指设计足够的测试用例， 使得判定表达式中每个条件的各种可能的值至少出现一次。那么，上述程序中有 4 个条件： a1， b=0， a=2， x1Page 37 3) 条件覆盖 条件覆盖指设计足够的测试用例，使得判定表达式中每个条件的各种可能的值至少出现一次。那么，上述程序中有 4 个条件： a1， b=0， a=2， x1 要选择足够的数据， 使得图5.1中的第一个判定表达式出现结果： a1， b=0 a1， b0 并使第二个判定表达式出现结果： Page 38 a=2， x1 a2， x1 才能达到条件覆盖的标准。 为满足上述要求， 选择以下两组测试数据： a=2， b=0， x=3（满足a1， b=0， a=2， x1， 通过路径124） a=1， b=1， x=1（满足a1， b0， a2， x1，通过路径135） 以上两组测试用例不但覆盖了判定表达式中所有条件的可能取值，而且覆盖了所有判断的取“真”分支和取“假”分支。 在这种情况下，条件覆盖强于判定覆盖。但也有例外情况，设选择另外两组测试数据： Page 39 覆盖了所有条件的结果，满足条件覆盖。但只覆盖了第一个判定表达式的取“假”分支和第二个判定表达式的取“真”分支， 即只测试了路径134，此例不满足判定覆盖。 所以满足条件覆盖不一定满足判定覆盖，为了解决此问题， 需要对条件和分支兼顾。 4) 判定/条件覆盖 该覆盖标准指设计足够的测试用例，使得判定表达式中的每个条件的所有可能取值至少出现一次，并使每个判定表达式所有可能的结果也至少出现一次。对于上述程序，选择以下两组测试用例满足判定/条件覆盖:Page 40 a=2， b=0， x=3 a=1， b=1， x=1 这也是满足条件覆盖选取的数据。 从表面上看，判定/条件覆盖测试了所有条件的取值，但实际上条件组合中的某些条件会抑制其他条件。例如在含有“与”运算的判定表达式中， 第一个条件为“假”，则这个表达式中的后面几个条件均不起作用；在含有“或”运算的表达式中， 第一个条件为“真”，后边其他条件也不起作用，因此，后边其他条件若写错就测不出来。 Page 41 5) 条件组合覆盖 条件组合覆盖是比较强的覆盖标准，它是指设计足够的测试用例，使得每个判定表达式中条件的各种可能的值的组合都至少出现一次。 上述程序中， 两个判定表达式共有 4 个条件， 因此有 8 种组合： a1， b=0 a1， b0 a1， b=0 a1， b0 a=2， x1 a=2， x1 a2， x1 a2， x1 Page 42 下面 4 组测试用例就可以满足条件组合覆盖标准: a=2， b=0， x=2 覆盖条件组合和， 通过路径124 a=2， b=1， x=1 覆盖条件组合和， 通过路径134 a=1， b=0， x=2 覆盖条件组合和， 通过路径134 a=1， b=1， x=1 覆盖条件组合和， 通过路径135 显然，满足条件组合覆盖的测试一定满足“判定覆盖”、 “条件覆盖”和“判定/条件覆盖”，因为每个判定表达式、每个条件都不止一次地取到过“真”、“假”值。但也看到，该例没有覆盖程序可能执行的全部路径，125这条路径被漏掉了，如果这条路径有错， 就不能测出。 Page 43 6) 路径覆盖 路径覆盖是指设计足够的测试用例， 覆盖被测程序中所有可能的路径。对于上例， 选择以下测试用例， 覆盖程序中的 4 条路径： a=2， b=0， x=2 覆盖路径124， 覆盖条件组合和 a=2， b=1， x=1 覆盖路径134， 覆盖条件组合和 a=1， b=1， x=1 覆盖路径135， 覆盖条件组合和 a=3， b=0， x=1 覆盖路径125， 覆盖条件组合和 可看出满足路径覆盖却未满足条件组合覆盖。 现将这 6 种覆盖标准作比较， 见表5 - 1。Page 44Page 45 语句覆盖发现错误能力最弱。判定覆盖包含了语句覆盖， 但它可能会使一些条件得不到测试。条件覆盖对每一条件进行单独检查，一般情况它的检错能力较判定覆盖强，但有时达不到判定覆盖的要求。判定/条件覆盖包含了判定覆盖和条件覆盖的要求，但由于计算机系统软件实现方式的限制，实际上不一定达到条件覆盖的标准。条件组合覆盖发现错误能力较强， 凡满足其标准的测试用例，也必然满足前 4 种覆盖标准。 前 5 种覆盖标准把注意力集中在单个判定或判定的各个条件上，可能会使程序某些路径没有执行到。路径测试根据各判定表达式取值的组合，使程序沿着不同的路径执行，查错能力强。 Page 46 但由于它是从各判定的整体组合出发设计测试用例的， 可能使测试用例达不到条件组合覆盖的要求。在实际的逻辑覆盖测试中，一般以条件组合覆盖为主设计测试用例，然后再补充部分用例，以达到路径覆盖测试标准。 2. 循环覆盖循环覆盖 在逻辑覆盖的测试技术中，以上只讨论了程序内部有判定存在的逻辑结构的测试用例设计技术。而循环也是程序的主要逻辑结构，要覆盖含有循环结构的所有路径是不可能的， 但可通过限制循环次数来测试，下面给出设计原则供参考。 1) 单循环 设n为可允许执行循环的最大次数。 设计以下情况的测试用例： (1) 跳过循环。Page 47 (2) 只执行循环一次。 (3) 执行循环m次， 其中mn。 (4) 执行循环n-1次， n次， n+1次。 2) 嵌套循环 嵌套循环步骤为： (1) 置外循环处于最小循环计数值， 对内层进行单循环测试。 (2) 由里向外， 进行下一层的循环测试。 Page 48 3. 基本路径测试基本路径测试 图5.1的例子很简单，只有 4 条路径。但在实际问题中， 一个不太复杂的程序其路径是一个庞大的数字。为了解决这一难题，只得把覆盖的路径数压缩到一定的限度内，例如，循环体只执行一次。基本路径测试是在程序流程图的基础上，通过分析由控制构造的环路复杂性，导出基本路径集合，从而设计测试用例， 保证这些路径至少通过一次。 基本路径测试的步骤为： (1) 以详细设计或源程序为基础， 导出程序流程图的拓朴结构程序图。 Page 49图5.1 一个被测试程序的流程图Page 50 程序图是退化了的程序流程图，它是反映控制流程的有向图，其中小圆圈称为结点，代表了流程图中每个处理符号（矩形、菱形框），有箭头的连线表示控制流向，称为程序图中的边或路径。 图5.2（a）是一个程序流程图，可以将它转换成图5.2（b）的程序图（假设菱形框表示的判断内设有复合的条件）。在转换时注意: 一条边必须终止于一个结点，在选择结构中的分支汇聚处即使无语句也应有汇聚结点; 若判断中的逻辑表达式是复合条件，应分解为一系列只有单个条件的嵌套判断，如对于图5.3(a)的复合条件的判定应画成图5.3(b)所示的程序图。 Page 51 图 5.2程序流程图和程序图 (a) 程序流程图; (b) 程序图 Page 52图 5.3复合条件下的程序图 (a) 程序； (b) 程序图Page 53 (2) 计算程序图G的环路复杂性V（G）。 McCabe定义程序图的环路复杂性为此平面图中区域的个数。 区域个数为边和结点圈定的封闭区域数加上图形外的区域数1。 例如图5.2(b)的V(G)=4, 也可按另一种方法计算， 即V（G）=判定结点数+1。 (3) 确定只包含独立路径的基本路径集。 环路复杂性可导出程序基本路径集合中的独立路径条数， 这是确保程序中每个执行语句至少执行一次所必需的测试用例数目的上界。独立路径是指包括一组以前没有处理的语句或条件的一条路径。从程序图来看，一条独立路径是至少包含有一条在其他独立路径中未有过的边的路径，例如，在图5.2(b)所示的图中，一组独立的路径是： Page 54 path1： 1-11 path2： 1-2-3-4-5-10-1-11 path3： 1-2-3-6-8-9-10-1-11 path4： 1-2-3-6-7-9-10-1-11 从例中可知，一条新的路径必须包含有一条新边。这 4 条路径组成了图5.2(b)所示的程序图的一个基本路径集，4是构成这个基本路径集的独立路径数的上界，这也是设计测试用例的数目。只要测试用例确保这些基本路径的执行，就可以使程序中每个可执行语句至少执行一次，每个条件的取“真”和取“假”分支也能得到测试。 基本路径集不是唯一的，对于给定的程序图，可以得到不同的基本路径集。 Page 55黑盒技术黑盒技术 黑盒测试是功能测试，因此设计测试用例时，需要研究需求说明和概要设计说明中有关程序功能或输入、输出之间的关系等信息，从而与测试后的结果进行分析比较。用黑盒技术设计测试用例的方法一般有以下 4 种，但没有一种方法能提供一组完整的测试用例，以检查程序的全部功能，在实际测试中应该把各种方法结合起来使用。 1. 等价类划分等价类划分 为了保证软件质量，需要做尽量多的测试，但不可能用所有可能的输入数据来测试程序，而只能从输入数据中选择一个子集进行测试。 如何选择适当的子集，使其发现更多的错误呢？等价类划分是解决这一问题的办法。 Page 56 表 5 - 2 中合理等价类是指各种正确的输入数据，不合理的等价类是其他错误的输入数据。 划分等价类是一个比较复杂的问题， 以下提供了几条经验供参考： (1) 如果某个输入条件规定了取值范围或值的个数， 则可确定一个合理的等价类（输入值或数在此范围内）和两个不合理等价类（输入值或个数小于这个范围的最小值或大于这个范围的最大值）。 例如输入值是学生的成绩，范围为0100，确定一个合理的等价类为“0成绩100”，两个不合理的等价类为“成绩0”和“成绩100”。 Page 57表表5-2 等价类表等价类表输入条件输入条件合理等价类合理等价类不合理等价类不合理等价类Page 58 (2) 如果规定了输入数据的一组值，而且程序对不同的输入值做不同的处理，则每个允许的输入值是一个合理等价类， 此外还有一个不合理等价类（任何一个不允许的输入值）。 例如，输入条件上说明教师的职称可为助教、 讲师、 副教授及教授 4 种职称之一，则分别取这四个值作为4 个合理等价类，另外把 4 个职称之外的任何职称作为不合理等价类。(3) 如果规定了输入数据必须遵循的规则，可确定一个合理等价类（符合规则）和若干个不合理等价类（从各种不同角度违反规则）。 (4) 如果已划分的等价类中各元素在程序中的处理方式不同，则应将此等价类进一步划分为更小的等价类。 Page 59 以上这些划分输入数据等价类的经验也同样适用于输出数据，这些数据也只是测试时可能遇到的情况的很小部分。为了能正确划分等价类，一定要正确分析被测程序的功能。 2) 确定测试用例 根据已划分的等价类， 按以下步骤设计测试用例： (1) 为每一个等价类编号。 (2) 设计一个测试用例，使其尽可能多地覆盖尚未被覆盖过的合理等价类。重复这步，直到所有合理等价类被测试用例覆盖。 (3) 设计一个测试用例，使其只覆盖一个不合理等价类。 重复这一步，直到所有不合理等价类被覆盖。Page 60 例如：某一报表处理系统，要求用户输入处理报表的日期。 假设日期限制在1990年1月至1999年12月，即系统只能对该段时期内的报表进行处理。如果用户输入的日期不在此范围内，则显示输入错误信息。该系统规定日期由年、月的 6 位数字字符组成，前 4 位代表年，后两位代表月。现用等价类划分法设计测试用例，来测试程序的“日期检查功能”。 划分等价类并编号: 划分成 3 个有效等价类，7 个无效等价类， 如表5 - 3所示。 为合理等价类设计测试用例，对于表中编号为1, 5, 8对应的 3 个合理等价类， 用一个测试用例覆盖。 Page 61Page 62 为每一个不合理等价类至少设计一个测试用例: 测试数据 期望结果 覆盖范围 99MAY 输入无效 2 19995 输入无效 3 1999005 输入无效 4 198912 输入无效 6 200001 输入无效 7 199900 输入无效 9 199913 输入无效 10Page 63 2. 边界值分析边界值分析 实践经验表明， 程序往往在处理边界情况时发生错误。 边界情况指输入等价类和输出等价类边界上的情况。因此检查边界情况的测试用例是比较高效的，可以查出更多的错误。 例如， 在做三角形设计时，要输入三角形的 3 个边长 A, B和C。 这 3 个数值应当满足A0，B0，C0，A+BC， A+CB， B+CA， 才能构成三角形。但如果把 6 个不等式中的任何一个“”错写成“”， 那个不能构成三角形的问题恰出现在容易被疏忽的边界附近。 在选择测试用例时， 选择边界附近的值就能发现被疏忽的问题。 Page 64 (1) 如果输入条件规定了值的范围，可以选择正好等于边界值的数据作为合理的测试用例，同时还要选择刚好越过边界值的数据作为不合理的测试用例。如输入值的范围是1，100， 可取0，1，100，101等值作为测试数据。 (2) 如果输入条件指出了输入数据的个数， 则按最大个数、 最小个数、比最小个数少 1 及比最大个数多1等情况分别设计测试用例。 如一个输入文件可包括1255个记录， 则分别设计有1个记录、255个记录，以及0个记录和256个记录的输入文件的测试用例。 (3) 对每个输出条件分别按照以上两个原则确定输出值的边界情况。如一个学生成绩管理系统规定，只能查询9598级大学生的各科成绩， 可以设计测试用例，使得查询范围内的某一届或四届学生的学生成绩，还需设计查询94级、 99级学生成绩的测试用例（不合理输出等价类）。 Page 65 由于输出值的边界不与输入值的边界相对应，所以要检查输出值的边界不一定可能，要产生超出输出值之外的结果也不一定能做到， 但必要时还需试一试。 (4) 如果程序的需求说明给出的输入或输出域是个有序集合（如顺序文件、 线性表和链表元素和最后一个元素作为测试用例。 对上述报表处理系统中的报表日期输入条件， 以下用边界值分析设计测试用例。 程序中判断输入日期（年月）是否有效， 假设使用如下语句： Page 66IF（ReportDate=MinDate） THEN 产生指定日期报表 ELSE 显示错误信息 ENDIF 如果将程序中的“=”误写为“”， 则上例的等价类划分中所有测试用例都不能发现这一错误， 采用边界值分析法的测试用例如表5 - 4所示。 Page 67Page 68 3. 错误推测错误推测 在测试程序时，人们根据经验或直觉推测程序中可能存在的各种错误，从而有针对性地编写检查这些错误的测试用例， 这就是错误推测法。 错误推测法没有确定的步骤，凭经验进行。它的基本思想是列出程序中可能发生错误的情况，根据这些情况选择测试用例。 如输入、 输出数据为零是容易发生错误的情况；又如， 输入表格为空或输入表格只有一行是容易出错的情况等。 例如对于一个排序程序， 列出以下几项需特别测试的情况： (1) 输入表为空。 (2) 输入表只含一个元素。 (3) 输入表中所有元素均相同。 Page 69 (4) 输入表中已排好序。 又如， 测试一个采用二分法的检索程序， 考虑以下情况： (1) 表中只有一个元素。 (2) 表长是2的幂。 (3) 表长为2的幂减1或2的幂加1 因此， 要根据具体情况具体分析。 4. 因果图因果图 等价类划分和边界值分析方法都只是孤立地考虑各个输入数据的测试功能，而没有考虑多个输入数据的组合引起的错误。 因果图能有效地检测输入条件的各种组合可能会引起的错误。 Page 70 因果图的基本原理是通过画因果图，把用自然语言描述的功能说明转换为判定表，最后为判定表的每一列设计一个测试用例。 (1) 在任何情况下都应使用边界值分析法，用这种方法设计的用例暴露程序错误能力强。设计用例时，应该既包括输入数据的边界情况又包括输出数据的边界情况。 (2) 必要时用等价类划分方法补充一些测试用例。 (3) 再用错误推测法补充测试用例。 (4) 检查上述测试用例的逻辑覆盖程度， 如未满足所要求的覆盖标准， 再增加例子。 (5) 如果需求说明中含有输入条件的组合情况， 则一开始就可使用因果图法。 Page 71图 5.4 软件测试步骤Page 72图 5.5 软件测试与软件开发过程的关系Page 73九、课程学习资源九、课程学习资源n实践教学管理平台：http:/http:/59.76.156.25/sxglxt/ n课程在线学习平台 http:/bb.lzpcc.edu.cnn精品课程建设网http:/jpkc.lzpcc.com.cn/rjkfjs74任务结束任务结束 www.lzpcc.edu.cn