第11章软件测试精选文档.ppt

《第11章软件测试精选文档.ppt》由会员分享，可在线阅读，更多相关《第11章软件测试精选文档.ppt（74页珍藏版）》请在taowenge.com淘文阁网|工程机械CAD图纸|机械工程制图|CAD装配图下载|SolidWorks_CaTia_CAD_UG_PROE_设计图分享下载上搜索。

1、第第11章软件测试章软件测试本讲稿第一页，共七十四页内容摘要内容摘要1软件测试基础2白盒测试3黑盒测试4测试策略5面向对象测试6测试完成标准7调试本讲稿第二页，共七十四页内容摘要内容摘要1软件测试基础2白盒测试3黑盒测试4测试策略5面向对象测试6测试完成标准7调试本讲稿第三页，共七十四页软件测试基础软件测试基础1软件测试的目的软件测试的目的2软件测试的基本原则软件测试的基本原则3白盒测试和黑盒测试白盒测试和黑盒测试本讲稿第四页，共七十四页有关软件测试的错误观点有关软件测试的错误观点1 “软件测试是为了证明程序是正确的，即测试能发现程序中所有的错误”。u事实上这是不可能的。要通过测试发现程序中的

2、所有错误，就要穷举所有可能的输入数据。例如：(1)对于一个输入三个16位字长的整型数据的程序，输入数据的所有组合情况有2*48，如果测试一个数据需1ms，则即使一年365天一天24小时不停地测试，也需要约1万年。(2)对一个具有多重选择和循环嵌套的程序，不同的路径数目可能是天文数字。例如一个小程序的流程图，它包括了一个执行20次的循环，其循环体有五个分支。这个循环的不同执行路径数达5*20条，如果对每一条路径进行测试需要1毫秒，那么即使一年工作365 24小时，要想把所有路径测试完，大约需3170年。本讲稿第五页，共七十四页1“程序测试是证明程序正确地执行了预期的功能”。实际上，一个程序不仅要

3、完成它所需完成的功能，而且不应完成它不该做的事。例：三条边相等的三角形是等边三角形。如不能把边长为0、0、0的三条边判断为等边三角形。有关软件测试的错误观点有关软件测试的错误观点本讲稿第六页，共七十四页软件测试的目的软件测试的目的uGlen Myers给出的软件测试目的：给出的软件测试目的：测试是一个为了发现错误而执行程序的过程测试是一个为了发现错误而执行程序的过程一个好的测试用例是指很可能找到迄今为至尚未发现的错误的测一个好的测试用例是指很可能找到迄今为至尚未发现的错误的测试用例试用例一个成功的测试是指揭示了迄今为至尚未发现的错误的测试一个成功的测试是指揭示了迄今为至尚未发现的错误的测试 根

4、据这个测试目的，我们应该排除对测试的错误观点，设计合适的根据这个测试目的，我们应该排除对测试的错误观点，设计合适的测试用例，用尽可能少的测试用例，来发现尽可能多的软件错误。测试用例，用尽可能少的测试用例，来发现尽可能多的软件错误。本讲稿第七页，共七十四页软件测试的原则软件测试的原则Davis提出了一组指导软件测试的基本原则：提出了一组指导软件测试的基本原则：1.所有的测试都应可追溯到客户需求所有的测试都应可追溯到客户需求2.应该在测试工作真正开始前的较长时间就进行测试计划应该在测试工作真正开始前的较长时间就进行测试计划3.Pareto原则：测试中发现的原则：测试中发现的80%的错误可能来自于的

5、错误可能来自于20%的程序代码的程序代码4.测试应从测试应从“小规模小规模”开始，逐步转向开始，逐步转向“大规模大规模”5.穷举测试是不可能的穷举测试是不可能的6.为了达到最有效的测试，应由独立的第三方来承担测试为了达到最有效的测试，应由独立的第三方来承担测试本讲稿第八页，共七十四页其他的测试原则：其他的测试原则：1.在设计测试用例时，应包括合理的输入条件和不合理的输入条件在设计测试用例时，应包括合理的输入条件和不合理的输入条件2.严格执行测试计划，排除测试的随意性严格执行测试计划，排除测试的随意性3.应当对每一个测试结果做全面检查应当对每一个测试结果做全面检查4.妥善保存测试计划、测试用例、

6、出错统计和最终分析报告，为维护提供方便妥善保存测试计划、测试用例、出错统计和最终分析报告，为维护提供方便5.检查程序是否做了应做的事，仅仅是成功的一半，而成功的另一半是检查程序是否做了应做的事，仅仅是成功的一半，而成功的另一半是检查程序是否做了不该做的事检查程序是否做了不该做的事6.在规划测试时不要设想程序中不会查出错误在规划测试时不要设想程序中不会查出错误软件测试的原则软件测试的原则本讲稿第九页，共七十四页u测试用例u测试用例的设计是软件测试的关键所在u设计尽可能少的测试用例来发现尽可能多的错误u设计最有可能发现软件错误的测试用例，同时避免使用发现错误效果相同的测试用例u测试用例的设计方法大

7、体可分为两类：白盒测试和黑盒测试，也称白箱测试和黑箱测试软件测试的原则软件测试的原则本讲稿第十页，共七十四页u白盒测试白盒测试（又称为结构测试）（又称为结构测试）把测试对象看作一个透明的盒子，测试人员根据把测试对象看作一个透明的盒子，测试人员根据程序内部的逻辑结构及有关信息设计测试用例，检查程序中所有逻辑路径程序内部的逻辑结构及有关信息设计测试用例，检查程序中所有逻辑路径是否都按预定的要求正确地工作。是否都按预定的要求正确地工作。u白盒测试主要用于对模块的测试，包括：白盒测试主要用于对模块的测试，包括：程序模块中的所有独立路径至少执行一次程序模块中的所有独立路径至少执行一次对所有逻辑判定的取值

8、（对所有逻辑判定的取值（“真真”与与“假假”）都至少测试一次）都至少测试一次在上下边界及可操作范围内运行所有循环在上下边界及可操作范围内运行所有循环测试内部数据结构的有效性等测试内部数据结构的有效性等白盒测试与黑盒测试白盒测试与黑盒测试本讲稿第十一页，共七十四页u黑盒测试黑盒测试（又称行为测试）把测试对象看做一个黑盒子，测试（又称行为测试）把测试对象看做一个黑盒子，测试人员完全不考虑程序内部的逻辑结构和内部特性，只依据程人员完全不考虑程序内部的逻辑结构和内部特性，只依据程序的需求规格说明书，检查程序的功能是否符合它的功能需序的需求规格说明书，检查程序的功能是否符合它的功能需求。求。u黑盒测试可

9、用于各种测试，它试图发现以下类型的错误：黑盒测试可用于各种测试，它试图发现以下类型的错误：不正确或遗漏的功能不正确或遗漏的功能接口错误，如输入接口错误，如输入/输出参数的个数、类型等输出参数的个数、类型等数据结构错误或外部信息数据结构错误或外部信息(如外部数据库如外部数据库)访问错误访问错误性能错误性能错误初始化和中止错误初始化和中止错误白盒测试与黑盒测试白盒测试与黑盒测试本讲稿第十二页，共七十四页内容摘要内容摘要1软件测试基础2白盒测试3黑盒测试4测试策略5面向对象测试6测试完成标准7调试本讲稿第十三页，共七十四页白盒测试白盒测试常用的白盒测试方法有：常用的白盒测试方法有：逻辑覆盖测试逻辑覆

10、盖测试基本路径覆盖测试基本路径覆盖测试数据流测试数据流测试循环测试循环测试本讲稿第十四页，共七十四页逻辑覆盖测试逻辑覆盖测试 语句覆盖语句覆盖 判定覆盖判定覆盖 条件覆盖条件覆盖 判定条件覆盖判定条件覆盖 条件组合覆盖条件组合覆盖 路径覆盖路径覆盖逻辑覆盖主要考察使用测试数据运行被测程序时对程序逻辑覆盖主要考察使用测试数据运行被测程序时对程序逻辑的覆盖程度。通常希望选择最少的测试用例来满足逻辑的覆盖程度。通常希望选择最少的测试用例来满足所需的覆盖标准。主要的覆盖标准有：所需的覆盖标准。主要的覆盖标准有：本讲稿第十五页，共七十四页逻辑表达式错误敏感的测试逻辑表达式错误敏感的测试u逻辑覆盖测试依赖

11、于程序中的逻辑条件，这些逻辑条件由逻辑表达式组成。对于一个含有n个逻辑变量，或n个关系表达式的逻辑表达式，通常需要2n个测试用例来覆盖其所有可能的条件组合。u当n较大时，我们可以选择对发现逻辑表达式错误比较敏感的组合条件进行测试，以较少的测试用例来发现逻辑表达式中的绝大多数错误。本讲稿第十六页，共七十四页基本路径测试基本路径测试u在实际问题中，一个不太复杂的程序，特别是包含循环的程序，其路径数可能非常大。因此测试常常难以做到覆盖程序中的所有路径，为此，我们希望把测试的程序路径数压缩到一定的范围内。u基本路径测试是Tom McCabe提出的一种白盒测试技术，这种方法首先根据程序或设计图画出控制流

12、图，并计算其区域数，然后确定一组独立的程序执行路径（称为基本路径），最后为每一条基本路径设计一个测试用例。本讲稿第十七页，共七十四页数据流测试数据流测试u数据流测试是根据程序中变量的定义（赋值）和引用位置来选择测试用例u假定s为语句的标号（每个语句有唯一的标号），x为变量名。定义：DEF（s）=x|语句s中含有对x的定义USE（s）=x|语句s中含有对x的引用 当s为分支或循环语句时，DEF（s）=设变量x在语句s中被定义，如果存在一条从语句s到语句s 的路径，并且在这条路径上不存在对x的其它定义，则称变量x在s处定义在s处仍有效。本讲稿第十八页，共七十四页循环测试循环测试u循环分为4种不同类

13、型：简单循环、嵌套循环、串接循环和非结构循环。本讲稿第十九页，共七十四页循环测试循环测试 (1)简单循环简单循环 按照下列规则设计测试用例：按照下列规则设计测试用例：零次循环：从循环入口到出口零次循环：从循环入口到出口 一次循环：检查循环初始值一次循环：检查循环初始值 二次循环：检查多次循环二次循环：检查多次循环 m次循环：次循环：检查多次循环检查多次循环 最大次数循环最大次数循环 比最大次数多一次的循环比最大次数多一次的循环 比最大次数少一次的循环比最大次数少一次的循环本讲稿第二十页，共七十四页按照下列规则设计测试用例：先测试最内层循环：所有外层的循环变量置为最小值，最内层按简单循环测试；由

14、里向外，测试上一层循环：测试时此层以外的所有外层循环的循环变量取最小值，此层以内的所有嵌套内层循环的循环变量取“典型”值，该层按简单循环测试；重复上一条规则，直到所有各层循环测试完毕；对全部各层循环同时取最小循环次数，同时取最大循环次数(2)嵌套循环嵌套循环循环测试循环测试本讲稿第二十一页，共七十四页(3)串接循环串接循环如果串接的各个循环互相独立，则可以分别用简单循环的方法进行测试；但如果第一个循环的循环变量与第二个循环控制相关，则两个循环不独立，此时，把第一个循环看作外循环，第二个循环看作内循环，然后用测试嵌套循环的办法来处理。(4)非结构循环非结构循环这一类循环应该先将其结构化，然后再测

15、试。这一类循环应该先将其结构化，然后再测试。循环测试循环测试本讲稿第二十二页，共七十四页内容摘要内容摘要1软件测试基础2白盒测试3黑盒测试4测试策略5面向对象测试6测试完成标准7调试本讲稿第二十三页，共七十四页黑盒测试黑盒测试黑盒测试是依据软件的需求规约，检查程序的黑盒测试是依据软件的需求规约，检查程序的功能是否符合需求规约的要求。功能是否符合需求规约的要求。主要的黑盒测试方法有：主要的黑盒测试方法有：等价类划分等价类划分边界值分析边界值分析比较测试比较测试错误猜测错误猜测因果图因果图本讲稿第二十四页，共七十四页等价类划分等价类划分u由于不能穷举所有可能的输入数据来进行测试，所由于不能穷举所有

16、可能的输入数据来进行测试，所以只能以只能选择少量有代表性选择少量有代表性的输入数据，来揭露尽可的输入数据，来揭露尽可能多的程序错误能多的程序错误u等价类划分方法等价类划分方法将所有可能的输入数据划分成将所有可能的输入数据划分成若干个等价类，然后在每个等价类中选取一个若干个等价类，然后在每个等价类中选取一个代表性的数据作为测试用例代表性的数据作为测试用例本讲稿第二十五页，共七十四页1等价类划分方法把输入数据分为有效输入数据和无效输入数据2有效输入数据指符合规格说明要求的合理的输入数据，主要用来检验程序是否实现了规格说明中的功能3无效输入数据指不符合规格说明要求的不合理或非法的输入数据，主要用来检

17、验程序是否做了规格说明以外的事4在确定输入数据等价类时，常常还要分析输出数据的等价类，以便根据输出数据等价类导出输入数据等价类。等价类划分等价类划分本讲稿第二十六页，共七十四页等价类划分设计测试用例的步骤等价类划分设计测试用例的步骤1确定等价类确定等价类根据软件的规格说明，对每一个输入条件（通常是规格说明中的一根据软件的规格说明，对每一个输入条件（通常是规格说明中的一句话或一个短语）确定若干个有效等价类和若干个无效等价类。句话或一个短语）确定若干个有效等价类和若干个无效等价类。可使用如下表格可使用如下表格输入条件输入条件有效等价类有效等价类 无效等价类无效等价类本讲稿第二十七页，共七十四页1确

18、定等价类的规则：确定等价类的规则：如果输入条件规定了取值范围，则可以确定一个有效等价类（输如果输入条件规定了取值范围，则可以确定一个有效等价类（输入值在此范围内）和两个无效等价类（输入值小于最小值及大于最大入值在此范围内）和两个无效等价类（输入值小于最小值及大于最大值）值）等价类划分设计测试用例的步骤等价类划分设计测试用例的步骤本讲稿第二十八页，共七十四页1设计测试用例设计测试用例在确定了等价类之后，建立等价类表，列出所有划分出的在确定了等价类之后，建立等价类表，列出所有划分出的等价类。并为每个有效等价类和无效等价类编号。等价类。并为每个有效等价类和无效等价类编号。等价类划分设计测试用例的步骤

19、等价类划分设计测试用例的步骤本讲稿第二十九页，共七十四页边界值分析边界值分析u边界值分析也是一种黑盒测试方法，是对等价类划分方边界值分析也是一种黑盒测试方法，是对等价类划分方法的补充。法的补充。u人们从长期的测试工作经验得知，人们从长期的测试工作经验得知，大量的错误是发生在输入或大量的错误是发生在输入或输出范围的边界上，输出范围的边界上，而不是在输入范围的内部。因此针对各而不是在输入范围的内部。因此针对各种边界情况设计测试用例，其揭露程序中错误的可能性就更种边界情况设计测试用例，其揭露程序中错误的可能性就更大。大。本讲稿第三十页，共七十四页u边界值分析方法选择测试用例的规则如下：1如果输入条件

20、规定了值的范围，则选择刚刚达到这个范围的边界的值以及刚刚超出这个范围的边界的值作为测试输入数据。2如果输入条件规定了值的个数，则分别选择最大个数、最小个数、比最大个数多1、比最小个数少1的数据作为测试输入数据。3对每个输出条件使用第1条。4对每个输出条件使用第2条。5如果程序的输入或输出是个有序集合，例如，顺序文件、表格，则应把注意力集中在有序集的第1个元素和最后一个元素上。6如果程序中定义的内部数据结构有预定义的边界，则应选择使得正好达到该数据结构边界以及刚好超出该数据结构边界的输入数据作为测试数据。7发挥你的智慧，找出其他可能的边界条件。边界值分析边界值分析本讲稿第三十一页，共七十四页比较

21、测试（比较测试（back to back）u在现实中，有些软件有很高的可靠性要求，特别是那些可能危及人的生命安全的软件系统，如航空航天控制软件、核电厂控制软件等，其软件可靠性绝对重要。此时，需要冗余的硬件和软件来减少错误发生的可能性。u通常，可由二支软件开发队伍，根据相同的需求规格说明分别开发二个软件版本，然后，用相同的测试用例对二个版本的软件分别进行测试，比较二个版本软件的测试结果，如果测试结果相同，则可认为二个版本的软件都是正确的，如果测试结果不同，则要分析各个版本，以发现错误的所在。这种测试称为比较测试或称为背靠背测试（backtoback testing）。大多数情况下，可用自动化工具

22、来进行比较测试。本讲稿第三十二页，共七十四页u值得注意的是，比较测试并不能保证软件没有错误，如果规格说明本身有错，那么所有的版本都可能反映这种错误。u另外，如果各个版本产生相同的，但都不正确的结果，那么比较测试也无法发现这种错误。比较测试（比较测试（back to back）本讲稿第三十三页，共七十四页错误推测法错误推测法u错误猜测是一种凭直觉和经验推测某些可能存在的错误，从而针对这些可能存在的错误设计测试用例的方法。u这种方法没有机械的执行步骤，主要依靠直觉和经验。u错误猜测法的基本思想是：列举出程序中所有可能的错误和容易发生错误的特殊情况，然后根据这些猜测设计测试用例。本讲稿第三十四页，共

23、七十四页内容摘要内容摘要1软件测试基础2白盒测试3黑盒测试4测试策略5面向对象测试6测试完成标准7调试本讲稿第三十五页，共七十四页测试策略测试策略u一种测试策略就是将测试分为单元测试、集成测试、确认测试和系统测试。u单元测试是针对程序中的模块或构件，主要揭露编码阶段产生的错误。u集成测试针对集成的软件系统，主要揭露设计阶段产生的错误。u确认测试是根据软件需求规约对集成的软件进行确认，主要揭露不符合需求规约的错误。u对于基于计算机系统中的软件，还需将它集成到基于计算机系统中，并进行系统测试，以揭露不符合系统工程中对软件要求的错误。本讲稿第三十六页，共七十四页uV模型：描述软件开发各阶段与测试策略

24、之间的对应关系模型：描述软件开发各阶段与测试策略之间的对应关系。系统工程系统工程需求分析需求分析设计设计编码编码系统测试系统测试确认测试确认测试集成测试集成测试单元测试单元测试测试策略测试策略本讲稿第三十七页，共七十四页uTom Gilb指出实现一个成功的软件测试策略必须涉及的问题：指出实现一个成功的软件测试策略必须涉及的问题：1.在着手开始测试之前的较长时间，就要以量化的形式确定产品的需求。在着手开始测试之前的较长时间，就要以量化的形式确定产品的需求。2.显式地陈述测试目标。显式地陈述测试目标。3.了解软件的用户并为每一类用户建立剖面（了解软件的用户并为每一类用户建立剖面（profile）图

25、）图4.建立一个强调建立一个强调“快速循环（快速循环（rapid cycle）测试）测试”的测试计划。的测试计划。5.构造构造“健壮健壮”的软件，它被设计成可测试自身。的软件，它被设计成可测试自身。6.使用有效的正式技术评审，作为测试之前的过滤器。使用有效的正式技术评审，作为测试之前的过滤器。7.使用正式技术评审，来评估测试策略和测试用例本身。使用正式技术评审，来评估测试策略和测试用例本身。8.为测试过程建立一种持续改进的方法。为测试过程建立一种持续改进的方法。测试策略测试策略本讲稿第三十八页，共七十四页单元测试单元测试(Unit Testing)u单元测试又称模块测试，它着重对软件设计的最小

26、单元（软件构件或模块）进行验证u单元测试根据设计描述，对重要的控制路径进行测试，以发现构件或模块内部的错误u单元测试通常采用白盒测试，并且多个构件或模块可以并行进行测试u这里将构件或模块统一称为模块本讲稿第三十九页，共七十四页 单元测试的内容u模块接口：确保模块的输入/输出参数信息是正确的。这些信息包括参数的个数、次序、类型等。u局部数据结构：确保临时存储的数据在算法执行的整个过程中都能维持其完整性。如不合适的类型说明、不同数据类型的比较或赋值、文件打开和关闭的遗漏、超越数据结构的边界等。u边界条件：确保程序单元在极限或严格的情况下仍能正确地执行。本讲稿第四十页，共七十四页u所有独立路径：确保

27、模块中的所有语句都至少执行一次。程序执行的路径实际上体现了计算的过程，计算中常见的错误有：不正确的操作优先级、不同类型数据间的操作、不正确的初始化、不精确的精度、不正确的循环中止、不适当地修改循环变量、发散的迭代等。u所有错误处理路径：单元测试应该对所有的错误处理路径进行测试。错误处理部分潜在的错误有：报错信息没有提供足够的信息来帮助确定错误的性质及其发生的位置、报错信息与真正的错误不一致、错误条件在错误处理之前就已引起系统异常、异常条件处理不正确等。单元测试的内容本讲稿第四十一页，共七十四页集成测试（集成测试（Integrated Testing）u集成测试 也称组装测试、联合测试u经单元测

28、试后，每个模块都能独立工作，但把它们放在一起往往不能正常工作。本讲稿第四十二页，共七十四页u主要问题在于：主要问题在于：数据可能在通过接口时丢失；数据可能在通过接口时丢失；一个模块可能对另一个模块产生非故意的、有害的影响（即副作用）；一个模块可能对另一个模块产生非故意的、有害的影响（即副作用）；当子功能被组合起来时，可能不能达到期望的主功能；当子功能被组合起来时，可能不能达到期望的主功能；单个模块可以接受的不精确性（如误差），连接起来后可能会扩大到无法接单个模块可以接受的不精确性（如误差），连接起来后可能会扩大到无法接受的程度；受的程度；全局数据结构可能会存在问题。全局数据结构可能会存在问题。

29、集成测试（集成测试（Integrated Testing）本讲稿第四十三页，共七十四页u集成的方式有两种：非增量式集成：使用“一步到位”的方法来构造程序。先将所有经过单元测试的模块组合在一起，然后对整个程序（作为一个整体）进行测试。这种测试在发现错误时，很难为错误定位。改正错误时容易引入新的错误，新旧错误混在一起，更难定位。增量式集成：根据程序结构图，按某种次序挑选一个（或一组）尚未测试过的模块，把它集成到已测试好的模块中一起进行测试，每次增加一个（或一组）模块，直至所有模块全部集成到程序中。在增量集成测试过程中发现的错误，往往与新加入的模块有关。集成测试（集成测试（Integrated Te

30、sting）本讲稿第四十四页，共七十四页u增量式集成又可分为自顶向下集成和自底增量式集成又可分为自顶向下集成和自底向上集成。向上集成。集成测试（集成测试（Integrated Testing）本讲稿第四十五页，共七十四页回归测试（回归测试（Regression Testing）u在集成测试过程中，每当增加一个（或一组）新模块时，原先已集成的软件就发生了改变。新的数据流路径被建立，新的I/O操作可能出现，还可能激活新的控制逻辑，这些改变可能使原本正常的功能产生错误。u当测试时发现错误后，需修改程序；或者在软件维护时也需修改程序。这些对程序的修改也可能使原本正常的功能产生错误。u回归测试就是对已经

31、进行过的测试的子集的重新执行，以确保对程序的改变和修改，没有传播非故意的副作用。本讲稿第四十六页，共七十四页u回归测试集（已经过测试的子集）包括三种不同回归测试集（已经过测试的子集）包括三种不同类型的测试用例：类型的测试用例：能测试软件所有功能的代表性测试用例能测试软件所有功能的代表性测试用例专门针对可能会被修改影响的软件功能的附加测试专门针对可能会被修改影响的软件功能的附加测试注重于修改过的软件模块的测试注重于修改过的软件模块的测试回归测试（回归测试（Regression Testing）本讲稿第四十七页，共七十四页确认测试（确认测试（Validation Testing）u确认测试标准确认

32、测试标准u确认测试以确认测试以软件需求规约为依据软件需求规约为依据，以发现软件与需求不一致的错误。，以发现软件与需求不一致的错误。u主要检查软件是否实现了规约规定的全部功能要求，文档资料是主要检查软件是否实现了规约规定的全部功能要求，文档资料是否完整、正确、合理，其他的需求，如可移植性、可维护性、兼否完整、正确、合理，其他的需求，如可移植性、可维护性、兼容性、错误恢复能力等是否满足。容性、错误恢复能力等是否满足。本讲稿第四十八页，共七十四页u 确认测试的结果可分为两类：确认测试的结果可分为两类：满足需求规约要求的功能或性能特性，用户可以接受。发现与需求规约有偏差，此时需列出问题清单。确认测试（

33、确认测试（Validation Testing）本讲稿第四十九页，共七十四页u软件配置评审软件配置评审软件配置评审也称软件审计（audit），其目的是保证软件配置的所有成分都齐全，各方面的质量都符合要求，具有维护阶段必需的细节，而且已经编排好分类目录。软件配置主要包括计算机程序（源代码和可执行程序），针对开发者和用户的各类文档，包含在程序内部或程序外部的数据。软件配置评审本讲稿第五十页，共七十四页u如果软件是为一个客户开发的，那么，最后由客户进行验收测试（acceptance test），以使客户确认该软件是他所需要的。u如果软件是给许多客户使用的（如市场上销售的各种软件），那么让每个客户做验

34、收测试是不现实的。大多数软件厂商都使用一种称为测试和测试的过程，来发现那些似乎只有最终用户才能发现的错误。测试和测试本讲稿第五十一页，共七十四页u测试是由一个用户在开发者的场所进行的，软件在开发者在用户的“指导下”进行测试。经测试后的软件称为版软件。u测试是由软件的最终用户在一个或多个用户场所进行的，与测试不同，开发者通常不在测试现场，因此，测试是软件在一个开发者不能控制的环境中的“活的”应用，用户记录所有在测试中遇到的（真正的或想象的）问题，并定期把这些问题报告给开发者，在接到测试的问题报告后，开发者对软件进行最后的修改，然后着手准备向所有的用户发布最终的软件产品。测试和测试本讲稿第五十二页

35、，共七十四页系统测试（系统测试（System Testing）u系统测试是对整个基于计算机的系统进行的一系列测试。u系统测试的种类很多，每种测试都有不同的目的，它们从不同的角度测试计算机系统是否被正常地集成，并完成相应的功能。u常用的系统测试包括：恢复测试（recovery testing）安全测试（security testing）压力测试（stress testing）性能测试（performance testing）本讲稿第五十三页，共七十四页恢复测试（恢复测试（recovery testing）u恢复测试是通过各种手段，强制软件发生故障，然后来验证系统能否在指定的时间间隔内恢复正常，包

36、括修正错误并重新启动系统。u如果恢复是由系统自身来完成的，那么，需验证重新初始化、检查点机制、数据恢复和重启动等的正确性。u如果恢复需要人工干预，那么要估算平均修复时间MTTR（mean time to repair）是否在用户可以接受的范围内。本讲稿第五十四页，共七十四页安全测试（安全测试（security testing）u安全测试用来验证集成在系统中的保护机制能否实际保护系统不受非法侵入。u在安全测试过程中，测试者扮演一个试图攻击系统的角色，采用各种方式攻击系统。例如，截取或码译密码；借助特殊软件攻击系统；“制服”系统，使他人无法访问；故意导致系统失效，企图在系统恢复之机侵入系统；通过浏

37、览非保密数据，从中找出进入系统的钥匙等等。u一般来说，只要有足够的时间和资源，好的完全测试一定能最终侵入系统。系统设计者的任务是把系统设计成：攻破系统所付出攻破系统所付出的代价大于攻破系统后得到信息的价值。的代价大于攻破系统后得到信息的价值。本讲稿第五十五页，共七十四页压力测试（压力测试（stress testing）u压力测试也称强度测试，它是在一种需要非正常数量、频率或容量的方式下执行系统，其目的是检查系统对非正常情况的承受程度。u例如：当系统的中断频率是每秒1或2个时，执行每秒10个中断的测试用例将输入数据的数量提高一个数量级来测试输入功能如何响应执行需要最大内存或其它资源的测试用例执行

38、可能导致大量磁盘驻留数据的测试用例本讲稿第五十六页，共七十四页性能测试（性能测试（performance testing）u性能测试用来测试软件在集成的系统中的运行性能。它对实时系统和嵌入式系统尤为重要。u性能测试可以发生在测试过程的所有步骤中单元测试时，主要测试一个独立模块的性能，如算法的执行速度。软件集成后，进行软件整体的性能测试。计算机系统集成后，进行整个计算机系统的性能测试。u性能测试常常需要与压力测试结合起来进行，而且常常需要一些硬件和软件测试设备，以监测系统的运行情况。本讲稿第五十七页，共七十四页内容摘要内容摘要1软件测试基础2白盒测试3黑盒测试4测试策略5面向对象测试6测试完成标

39、准7调试本讲稿第五十八页，共七十四页面向对象测试面向对象测试u面向对象软件的测试目标仍然是用最少时间和工作量来发现尽可能多的错误u但面向对象软件的性质改变了测试的策略和测试战术。面向对象软件的测试也给软件工程师带来新的挑战。本讲稿第五十九页，共七十四页面向对象语境对测试的影响面向对象语境对测试的影响u继承、封装、多态性、基于消息的通信等概念都是面向对象软件继承、封装、多态性、基于消息的通信等概念都是面向对象软件的重要特征，它们对面向对象测试有很大的影响。的重要特征，它们对面向对象测试有很大的影响。u单元单元适用于面向对象测试的两种单元定义适用于面向对象测试的两种单元定义单元是可以编译和执行的最

40、小软件部件单元是可以编译和执行的最小软件部件单元是决不会指派给多个设计人员开发的软件部件单元是决不会指派给多个设计人员开发的软件部件类是面向对象软件中的单元类是面向对象软件中的单元本讲稿第六十页，共七十四页封装由于属性和操作被封装在类中，因此测试时很难获得对象的某些具体信息（除非提供内置操作来报告这些信息），从而给测试带来困难。继承测试了父类的操作后，并不表示其子类就不必对继承的操作进行测试。多态性在测试时，应覆盖反映多态的所有实现方法。基于消息的通信面向对象软件是通过消息通信来实现类之间的协作，它们没有明显的层次控制结构，因此，传统的自顶向下和自底向上集成策略不适用于面向对象软件测试。面向对

41、象测试面向对象测试本讲稿第六十一页，共七十四页面向对象的测试策略u把类作为面向对象软件的单元，传统的单元测试等价于面向对象中的类测试，也称类内测试。它包括类内的方法测试和类的行为测试。u面向对象中的类间测试（interclass testing）相当于面向对象的集成测试。它有两种集成策略：基于线程的测试（threadbased testing）：集成一组互相协作的类来响应系统的一个输入或事件，每个线程逐一被集成和测试，并通过回归测试保证其没有产生副作用。基于使用的测试（usebased testing）：按使用层次来集成系统。把那些几乎不使用其他类提供的服务的类称为独立类，把使用类的类称为依赖

42、类。集成从测试独立类开始，然后集成直接依赖于独立类的那些类，并对其测试。按照依赖的层次关系，逐层集成并测试，直至所有的类被集成。本讲稿第六十二页，共七十四页内容摘要内容摘要1软件测试基础2白盒测试3黑盒测试4测试策略5面向对象测试6测试完成标准7调试本讲稿第六十三页，共七十四页测试完成的标准测试完成的标准u因为无法判定当前查出的错误是否是最后一个错误，所以决定什么时候停止程序测试就成了最困难的问题，但是测试最后一定要停止的。u几种实用的测试完成标准：Musa和Ackerman提出了一个基于统计标准的答复：“不，我们不能绝对地认定软件永远也不会再出错，但是相对于一个理论上合理的和在试验中有效的统

43、计模型来说，如果一个在按照概率的方法定义的环境中，1000个CPU小时内不出错运行的概率大于0995的话，那么我们就有95%的信心说，我们已经进行了足够的测试”。本讲稿第六十四页，共七十四页1.使用指定的测试用例设计方法产生测试用例，运行这些测试用例均未发使用指定的测试用例设计方法产生测试用例，运行这些测试用例均未发现错误（包括发现错误后已被纠正的情况），则测试可终止。现错误（包括发现错误后已被纠正的情况），则测试可终止。2.观察测试阶段中单位时间内发现错误数目的曲线：观察测试阶段中单位时间内发现错误数目的曲线：单发单发位现位现时的时的间错间错内误内误数数周（或天）周（或天）可可以以停停止止单

44、发单发位现位现时的时的间错间错内误内误数数周（或天）周（或天）不不应应停停止止测试完成的标准测试完成的标准本讲稿第六十五页，共七十四页内容摘要内容摘要1软件测试基础2白盒测试3黑盒测试4测试策略5面向对象测试6测试完成标准7调试本讲稿第六十六页，共七十四页调试（调试（Debugging）u测试的目的是发现错误，调试（也称测试的目的是发现错误，调试（也称排错）的目的是确定错误的原因和准排错）的目的是确定错误的原因和准确位置，并加以纠正确位置，并加以纠正u调试过程调试过程本讲稿第六十七页，共七十四页测试测试用例用例执行执行测试用例测试用例追加测试追加测试被怀疑的原因被怀疑的原因已识别的原因已识别的

45、原因回归测试回归测试修正程序修正程序调试调试结果结果调试（调试（Debugging）本讲稿第六十八页，共七十四页调试方法调试方法u蛮力法蛮力法u蛮力法是一种最省脑筋但又最低效的方法。它通过在程序中设置断点，输出寄蛮力法是一种最省脑筋但又最低效的方法。它通过在程序中设置断点，输出寄存器、存储器的内容，打印有关变量的值等手段，获取大量现场信息，从中找存器、存储器的内容，打印有关变量的值等手段，获取大量现场信息，从中找出错误的原因。出错误的原因。u这种方法效率低，输出的信息大多是无用的，通常在其他调试方法未能找到错这种方法效率低，输出的信息大多是无用的，通常在其他调试方法未能找到错误原因时，才使用这

46、种方法。误原因时，才使用这种方法。u可以采用二分法来逐步缩小出错的范围。可以采用二分法来逐步缩小出错的范围。本讲稿第六十九页，共七十四页回溯法回溯法是从错误的征兆出发，人工沿着控制流程往回跟踪，直至发现错误的根源。这种方法适用于小型程序，对大型程序，由于回溯的路径太多，难以彻底回溯。调试（调试（Debugging）本讲稿第七十页，共七十四页原因排除法原因排除法原因排除法又可分为原因排除法又可分为归纳法归纳法和和演绎法。演绎法。u归纳法归纳法是一种从特殊推断一般的系统化思考方法。其基本思想是：从一些线索是一种从特殊推断一般的系统化思考方法。其基本思想是：从一些线索（错误征兆）着手，通过分析它们之

47、间的关系来找出错误的原因。（错误征兆）着手，通过分析它们之间的关系来找出错误的原因。组织数据组织数据收集收集有关数据有关数据研究数据研究数据之间的关之间的关系系导出假设导出假设证明假设证明假设纠正错误纠正错误能能不能不能能能不能不能调试（调试（Debugging）本讲稿第七十一页，共七十四页u演绎法演绎法 演绎法从一般原理或前提出发，假设所有可能出错的原因，演绎法从一般原理或前提出发，假设所有可能出错的原因，排除不可能正确的假设，最后推导出结论。排除不可能正确的假设，最后推导出结论。排除排除不正确原因不正确原因列出列出可能的原因可能的原因精化精化剩余的假设剩余的假设证明假设证明假设收集收集更多

48、数据更多数据纠正错误纠正错误无剩余无剩余能能有有剩剩余余不能不能调试（调试（Debugging）本讲稿第七十二页，共七十四页u纠正错误纠正错误修改一个错误常常会引入新的错误。修改一个错误常常会引入新的错误。在为纠正某个错误而修改程序之前应该回答三个问题：在为纠正某个错误而修改程序之前应该回答三个问题：在程序的其他地方是否也存在同类的错误？在程序的其他地方是否也存在同类的错误？本次修改可能会引发什么新的错误？本次修改可能会引发什么新的错误？为了防止这个错误，我们应该做什么？为了防止这个错误，我们应该做什么？调试（调试（Debugging）本讲稿第七十三页，共七十四页内容小结内容小结1软件测试基础2白盒测试3黑盒测试4测试策略5面向对象测试6测试完成标准7调试本讲稿第七十四页，共七十四页