软件工程第8章软件测试.ppt

《软件工程第8章软件测试.ppt》由会员分享，可在线阅读，更多相关《软件工程第8章软件测试.ppt（159页珍藏版）》请在金锄头文库上搜索。

1、第八章第八章第八章第八章8 8软件测试本章内容8.1 软件测试背景8.2 软件测试的基本概念8.3 测试用例的设计8.4 软件测试过程8.1 软件测试背景 8.1.1 软件缺陷与故障软件缺陷与故障案例案例 软件缺陷的定义软件缺陷的定义软件缺陷的特征软件缺陷的特征8.1.2 软件缺陷产生的原因软件缺陷产生的原因8.1.1 软件缺陷与故障1、软件缺陷和软件故障案例、软件缺陷和软件故障案例案例案例1 美国迪斯尼公司的狮子王游戏软件美国迪斯尼公司的狮子王游戏软件bug 兼容性问题兼容性问题案例案例2 美国航天局火星登陆事故美国航天局火星登陆事故 系统测试系统测试 衔接问题衔接问题 案例案例3 跨世纪跨

2、世纪“千年虫千年虫”问题问题 案例案例4 爱国者导弹防御系统炸死自家人爱国者导弹防御系统炸死自家人 系统时钟误差积累系统时钟误差积累 案例案例5 英特尔奔腾浮点除法英特尔奔腾浮点除法上述所有实例中的软件问题在软件工程或软件测试中都被称为上述所有实例中的软件问题在软件工程或软件测试中都被称为软件软件缺陷或软件故障缺陷或软件故障。 软件缺陷与故障（续）（续） 2、软件缺陷的定义、软件缺陷的定义 （1）软件未达到产品说明书中已经标明的功能；）软件未达到产品说明书中已经标明的功能； （2）软件出现了产品说明书中指明不会出现的错误；）软件出现了产品说明书中指明不会出现的错误； （3）软件未达到产品说明书

3、中虽未指出但应当达到的目标；软件未达到产品说明书中虽未指出但应当达到的目标； （4）软件功能超出了产品说明书中指明的范围；软件功能超出了产品说明书中指明的范围； （5）软件测试人员认为软件难以理解、不易使用，或者最终软件测试人员认为软件难以理解、不易使用，或者最终用户认为该软件使用效果不良。用户认为该软件使用效果不良。软件缺陷与故障（续）（续）3、软件缺陷的特征、软件缺陷的特征“看不到看不到” 软件的特殊性决定了缺陷不易看到软件的特殊性决定了缺陷不易看到“看到但是抓不到看到但是抓不到” 发现了缺陷，但不易找到了缺陷，但不易找到问题发生的原因生的原因所在所在8.1.2 软件缺陷产生的原因 软件缺

4、陷的主要类型软件缺陷的主要类型/ /现象：现象：p 功能、特性没有实现或部分实现功能、特性没有实现或部分实现p 设计不合理，存在缺陷设计不合理，存在缺陷p 实际结果和预期结果不一致实际结果和预期结果不一致p 运行出错，包括运行中断、系统崩溃、界面混乱运行出错，包括运行中断、系统崩溃、界面混乱p 数据结果不正确、精度不够数据结果不正确、精度不够p 用户不能接受的其他问题，如存取时间过长、界用户不能接受的其他问题，如存取时间过长、界面不美观面不美观 常见导致错误的根源缺乏有效的沟通，或者没有进行沟通；软件复杂度不断变更的需求时间的压力缺乏文档的代码软件开发工具其他其他10%软件产品说明软件产品说明

5、书（需求）书（需求）56%编写代码编写代码7%设设 计计27%图图8-1 8-1 软件缺陷产生的原因分布软件缺陷产生的原因分布软件缺陷产生的原因有很多，但最主要的原因要归咎于产品描述软件缺陷产生的原因有很多，但最主要的原因要归咎于产品描述8.2 软件测试基础概念8.2.1 软件测试的定义8.2.2 软件测试的基本概念8.2.3 软件测试方法与策略8.2.1 8.2.1 软件测试定义软件测试定义 软软件件测测试试是是一一个个贯贯彻彻于于软软件件开开发发过过程程始始终终的的过过程程，是是为为了了发发现现错错误误而而执执行行程程序序的的过过程程，是是根根据据软软件件开开发发各各阶阶段段的的规规格格说

6、说明明和和程程序序的的内内部部结结构构结结构构而而精精心心设计一批测试用例。设计一批测试用例。什么是软件测试什么是软件测试l使用人工或者自动手段来运行使用人工或者自动手段来运行或测定某个或测定某个系统系统的过程的过程l目的在于检验它是否满足规定的需求、弄目的在于检验它是否满足规定的需求、弄清预期结果与实际结果之间清预期结果与实际结果之间的差别的差别l可简述为：按照特定规程，发现软件错误可简述为：按照特定规程，发现软件错误的过程的过程软件测试定义（续）软件测试定义（续）1. 软件测试的目的l软件测试的目标是以最少的时间和人力，系统的找出软件测试的目标是以最少的时间和人力，系统的找出软件中潜在的各

7、种错误和缺陷软件中潜在的各种错误和缺陷l测试测试是为了是为了发现程序中发现程序中的错误而执行程序的错误而执行程序的过程的过程l好的好的测试方案（测试用例）在于测试方案（测试用例）在于尽可能发现迄今为止尽可能发现迄今为止尚未发现尚未发现的错误的错误l成功的测试是发现了至今为止尚未发现的错误的测试成功的测试是发现了至今为止尚未发现的错误的测试8.2.2 8.2.2 8.2.2 8.2.2 软件测试基本概念软件测试基本概念软件测试基本概念软件测试基本概念软件测试目的（续）l测试并不仅仅是为了找出错误测试并不仅仅是为了找出错误. .通过分析错误产生通过分析错误产生的原因和错误的发生趋势的原因和错误的发

8、生趋势, ,可以帮助项目管理者发可以帮助项目管理者发现当前软件开发过程中的缺陷现当前软件开发过程中的缺陷, ,以便以便及时改进；及时改进；l这种分析也能帮助测试人员设计出有针对性的测试这种分析也能帮助测试人员设计出有针对性的测试方法方法, ,改善测试的效率和改善测试的效率和有效性；有效性；l没有发现错误的测试也是有价值的没有发现错误的测试也是有价值的, ,完整的测试是完整的测试是评定软件质量的一评定软件质量的一种方法种方法软件测试员的目标发现软件缺陷2. 软件测试的目标最终目的是确保软件的功能符合用户的需求，把尽可能多的问题在发布或交付前发现并改正：-确保软件完成了它所承诺或公布的功能（缺少规

9、范的书面文档？）-确保软件满足性能的要求（界面、操作、性能）-确保软件是健壮的和适应用户环境的（哪怕不健壮，也要给出解决方案）2. 软件测试的目标为软件的质量评估提供依据（项目验收）为软件质量改进和管理提供帮助（经验教训等知识转移）软件测试的生命周期需求规格说明设计缺陷分类缺陷解决缺陷隔离测试编码错误错误错误错误修复事故缺陷缺陷缺陷3. 软件测试的特性l软件测试与分析、设计、编码等工作相比，具有若干软件测试与分析、设计、编码等工作相比，具有若干特殊的性质：特殊的性质：挑剔性挑剔性。测试是一种。测试是一种“挑剔性挑剔性”行为，以证明程序有错行为，以证明程序有错的目的去进行测试，才能把程序中潜在的

10、错误找出来。的目的去进行测试，才能把程序中潜在的错误找出来。复杂性复杂性。设计测试用例是一项需要细致和高度技巧的工。设计测试用例是一项需要细致和高度技巧的工作。作。不彻底性不彻底性。测试只能证明软件中存在错误，不能证明软。测试只能证明软件中存在错误，不能证明软件中不存在错误所谓彻底测试，也就是穷举测试，显然件中不存在错误所谓彻底测试，也就是穷举测试，显然在实际测试中无法实现或行不通。在实际测试中无法实现或行不通。经济性经济性。降低测试成本，应遵守的经济性原则：一，根。降低测试成本，应遵守的经济性原则：一，根据程序的重要性和一旦发生故障将造成的损失来确定他据程序的重要性和一旦发生故障将造成的损失

11、来确定他的可靠性等级，不要随意提高等级使测试成本增加；二，的可靠性等级，不要随意提高等级使测试成本增加；二，要认真研究测试策略，以便使用尽可能少的测试用例来要认真研究测试策略，以便使用尽可能少的测试用例来发现尽可能多的程序错误。发现尽可能多的程序错误。l 为保证测试质量，软件测试必须完成规定的文档。按照软件工程的要求，测试文档应包括测试计划和测试报告两方面内容。l 测试计划的主体是“测试内容说明”。它包括测试项目名称，各项测试的目的、步骤和进度，以及测试用例的设计等。l 测试报告的主体是“测试结果”，它包括测试项目名称，实测结果与期望结果的比较，发现的问题，以及测试达到的效果。4. 软件测试的

12、文档测试用例测试用例 = 测试数据测试数据 + 期望结果期望结果测试结果测试结果 = 测试数据测试数据 + 期望结果期望结果 + 实际结果实际结果软件测试国家标准lGB/T 9386-1988 计算机软件测试文件编制规范lGB/T 15532-1995 计算机软件单元测试规范lGB/T 17544-1998 信息技术 软件包 质量要求和测试lGB/T 16260.1-2003 软件工程 产品质量第1部份，质量模型lGB/T 16260.2-200X软件工程 产品质量第2部份，外部度量lGB/T 16260.3-200X软件工程 产品质量第3部份，内部度量lGB/T 16260.4-200X软件

13、工程 产品质量第4部份，使用质量度量lGB/T 18905.1-2002软件工程 产品质量第1部份，概述lGB/T 18905.2-2002软件工程 产品质量第2部份，策划和管理lGB/T 18905.3-2002软件工程 产品质量第3部份，开发者用的过程lGB/T 18905.4-2002软件工程 产品质量第4部份，需方用的过程lGB/T 18905.5-2002软件工程 产品质量第5部份，评价者用的过程lGB/T 18905.6-2002软件工程 产品质量第6部份，评价模块文档编写 国标来自的国际标l GB/T 16260.1-6 取自ISO/IEC 9126-1:2001 ISO/IEC

14、 9126-2:2003 ISO/IEC 9126-3:2003 ISO/IEC TR 9126-4:2004l GB/T 18905.1-6 取自ISO/IEC 14598-1:1999 ISO/IEC 14598-2:2000 ISO/IEC 14598-3:2000 ISO/IEC 14598-4:1999 ISO/IEC 14598-5:1998 ISO/IEC 14598-6:2001l GB/T 17544-1998 取自ISO/IEC 12119:19945. 软件测试的原则Good-enough: 一种权衡投入/产出比的原则：选择测试保证测试的覆盖程度，但穷举测试是不可能的：有

15、限测试所有的测试都应追溯到用户需求越早测试越好，测试过程与开发过程应是相结合的测试的规模由小而大，从单元测试到系统测试为了尽可能地发现错误，应该由独立的第三方来测试不能为了便于测试擅自修改程序既应该测试软件该做什么也应该测试软件不该做什么传统的瀑布模型中软件测试学仅处于运行维护阶段之前项目规划阶段：负责从单元测试到系统测试的整个测 试阶段的监控。需求分析阶段：确定测试需求分析、系统测试计划的 制定、评审后成为管理项目。详细设计和概要设计阶段：确保集成测试计划和单元 测试计划完成。编码阶段：由开发人员进行自己负责部分的测试代码。 在项目较大时，由专人进行编码阶段的测 试任务。测试阶段：依据测试代

16、码进行测试，并提交相应的测 试状态报告和测试结束报告。6、测试在开发各阶段的作用、测试在开发各阶段的作用图8-2 完整的开发流程项目规划项目规划项目需求分析项目需求分析项目概要分析项目概要分析项目详细分析项目详细分析代码编写代码编写测试代码编写测试代码编写测试需求分析测试需求分析系统测试计划系统测试计划集成测试计划集成测试计划单元测试计划单元测试计划产品发布产品发布系统测试系统测试集成测试集成测试单元测试单元测试7 7、完整的软件开发流程、完整的软件开发流程8. 8. 软件测试和缺陷修复的代价软件测试和缺陷修复的代价软件在从需求、设计、编码、测试一直到交付用户公开使用后的过程中，都有可能产生和

17、发现缺陷。随着整个开发过程的时间推移，更正缺陷或修复问题的费用呈几何级数增长。 图8-3 软件缺陷在不同阶段发现时修复的费用示意图0 02020404060608080100100编制说明书编制说明书设计阶段设计阶段编写代码编写代码测试测试发布发布软件测试是有风险的行为 如果决定如果决定不去测试不去测试所有的情所有的情况，那就况，那就是选择了是选择了风险风险 。软件缺陷的寄生虫性找到的软件缺陷越多，就说明软件缺陷越多找到的软件缺陷越多，就说明软件缺陷越多原因：程序员的疲倦程序员往往犯同样的错误某些软件的缺陷其实是大灾难的征兆软件测试的杀虫剂现象软件测试越多，其免疫力越强的现象软件测试越多，其免

18、疫力越强的现象克服方法：不断编写不同的新的测试程序对程序的不同部分进行测试软件测试的不修复原则并非所有并非所有软件软件缺陷都能修复缺陷都能修复不需要修复软件缺陷的原因：没有足够的时间不算真正的软件缺陷修复的风险太大不值得修复Pareto原则 Pareto原则暗原则暗示着测试发现示着测试发现的错误中的的错误中的80%很可能起很可能起源于程序模块源于程序模块中的中的20%。软件测试中的误区调试和测试是一样的；测试组应当为保证质量负责；把测试作为新员工的一个过渡工作；关注测试的执行而忽略测试的设计；测试自动化是万能的；测试是枯燥乏味，缺乏创造力的工作。8.2.3 软件测试方法与策略软件测试策略软件测

19、试方法测试关键词静态测试与动态测试白盒测试与黑盒测试软件测试模型软件测试策略什么是软件测试策略？ 是为软件工程过程定义的一个软件测试的模板，也就是把特定的测试用例方法放置进去的一系列步骤。软件测试策略包含的特征：（1）测试从模块层开始，然后扩大延伸到整个基于计算机的系统集合中。（2）不同的测试技术适用于不同的时间点。（3）测试是由软件的开发人员和（对于大型系统而言）独立的测试组来管理的。（4）测试和调试是不同的活动，但是调试必须能够适应任何的测试策略。软件测试策略l测试信息流l分析设计阶段l需求说明书评测l概要设计说明书评测l详细设计说明书评测l软件编码规范评测l开发阶段l单元测试l集成测试l

20、确认测试l系统测试l验收测试l软件验证和确认过程软件测试关键词l单元测试l集成测试l系统测试l确认测试l验收测试l白盒测试l黑盒测试l灰盒测试单元测试l单元测试又称模块测试l是针对软件设计的最小单元程序模块进行正确性检验的测试工作l其目的在于检查每个程序单元能否实 现详细设计说明中的模块功能、性能、接口和设计约束等要求，发现各模块内部可能存在的错误集成测试l集成测试，也叫组装测试或联合测试l在单元测试的基础上，将所有模块按照设计要求）如根据结构图组装成为子系统或系统，进行集成测试l集成测试是检验程序单元和部件的接口关系l实践表明，一些模块虽然能够单独地工作，但并不能保证连接起来也能正常的工作。

21、程序在某些局部反映不出来的问题，在全局上很可能暴露出来，影响功能的实现系统测试l 系统测试是将已经确认的软件、计算机硬件、外设、网络等其他元素结合在一起，进行信息系统的各种组装测试和确认测试，其目的是通过与系统的需求相比较，发现所开发的系统与用户需求不符或矛盾的地方l 系统测试的任务是近可能彻底的检查出程序中的错误，提高软件系统的可靠性，其目的是检验系统做得怎样？确认测试l确认测试的目的是向未来的用户表明系统能够像预定要求那样工作。经集成测试后，已经按照设计把所有的模块组装成一个完整的软件系统，接口错误也已经基本排除了，接着就应该进一步验证软件的有效性，这就是确认测试的任务，即软件的功能和性能

22、如同用户所合理期待的那样 l确认测试又称有效性测试。有效性测试是在模拟的环境下，运用黑盒测试的方法，验证被测软件是否满足需求规格说明书列出的需求。任务是验证软件的功能和性能及其他特性是否与用户的要求一致。对软件的功能和性能要求在软件需求规格说明书中已经明确规定，它包含的信息就是软件确认测试的基础验收测试l 系统开发生命周期方法论的一个阶段，这时相关的用户和或独立测试人员根据测试计划和结果对系统进行测试和接收。它让系统用户决定是否接收系统。它是一项确定产品是否能够满足合同或用户所规定需求的测试l 这是管理性和防御性控制的测试过程白盒测试l白盒测试也称结构测试或逻辑驱动测试，它是按照程序内部的结构

23、测试程序，通过测试来检测产品内部动作是否按照设计规格说明书的规定正常进行，检验程序中的每条通路是否都能按预定要求正确工作l是把测试对象看作一个打开的盒子，测试人员依据程序内部逻辑结构相关信息，设计或选择测试用例，对程序所有逻辑路径进行测试，通过在不同点检查程序的状态，确定实际的状态是否与预期的状态一致黑盒测试l黑盒测试也称功能测试，它是通过测试来检测每个功能是否都能正常使用。l在测试地，把程序看作一个不能打开的黑盒子，在完全不考虑程序内部结构和内部特性的情况下，在程序接口进行测试，它只检查程序功能是否按照需求规格说明书的规定正常使用，程序是否能适当地接收输入数据而产生正确的输出信息。l黑盒测试

24、着眼于程序外部结构，不考虑内部逻辑结构，主要针对软件界面和软件功能进行测试灰盒测试l 灰盒测试，确实是介于白盒测试与黑盒测试之间的测试l 灰盒测试关注输出对于输入的正确性，同时也关注内部表现，但这种关注不象白盒那样详细、完整，只是通过一些表征性的现象、事件、标志来判断内部的运行状态，有时候输出是正确的，但内部其实已经错误了，这种情况非常多，如果每次都通过白盒测试来操作，效率会很低，因此需要采取这样的一种灰盒的方法软件测试技术的发展趋势：软件测试技术的发展趋势：（1）软件验证技术（2）静态测试分析技术（3）测试数据的选择主要对测试用例进行选择 通常从下面几个方面评价测试用例的质量： 检测软件缺陷

25、的有效性、测试用例的可重用性、 测试用例的经济性、测试用例的可维护性（4）集成化测试研究如何实现软件测试的自动化过程以及相关的一系列内容。软件测试方法的分类按照软件测试用例的设计方法而论，软件测试可分为白盒测试法和黑盒测试法；按照软件测试是否执行程序而论，软件测试又可以分为静态测试和动态测试；按照软件设计方法是否采用面向对象设计技术而论，软件测试又可以分为传统测试方法和面向对象测试方法；按照网络环境下C/S应用结构的特定环境而论，软件测试又有其相应的方法。这些都是软件测试具体的测试方法。静态测试与动态测试1、静态测试静态测试不实际运行软件，主要是对软件的编程格式、结构等方面进行评估。静态测试包

26、括代码检查 、静态结构分析 、代码质量度量 等。它可以由人工进行，也可以借助软件工具自动进行。静态测试方法也可利用计算机作为对被测程序进行特性分析的工具，但与人工测试方式有着根本区别。另一方面，因它并不真正运行被测程序，只进行特性分析，这又与动态方法不同。所以，静态方法常常称为“分析”，静态测试是对被测程序进行特性分析方法的总称。静态测试与动态测试（续）（续）静态测试阶段的任务：（1）检查算法的逻辑正确性。（2）检查模块接口的正确性。（3）检查输入参数是否有合法性检查。（4）检查调用其他模块的接口是否正确。（5）检查是否设置了适当的出错处理。（6）检查表达式、语句是否正确，是否含有二义性。（7

27、）检查常量或全局变量使用是否正确。（8）检查标识符的使用是否规范、一致。（9）检查程序风格的一致性、规范性。（10）检查代码是否可以优化，算法效率是否最高。（11）检查代码注释是否完整，是否正确反映了代码的功能。静态测试与动态测试（续）（续）静态测试可以完成以下工作：（1）发现下列程序的错误：错用局部变量和全局变量；未定义的变量、不匹配的参数；不适当的循环嵌套或分支嵌套、死循环、不允许的递归；调用不存在的子程序，遗漏标号或代码。（2）找出以下问题的根源：从未使用过的变量；不会执行到的代码、从未使用过的标号；潜在的死循环。（3）提供程序缺陷的间接信息：所用变量和常量的交叉应用表；是否违背编码规则

28、；标识符的使用方法和过程的调用层次。（4）为进一步查找做好准备。（5）选择测试用例。（6）进行符号测试。静态测试与动态测试（续）（续）2、动态测试动态方法的主要特征是： 计算机必须真正运行被测试的程序，通过输入测试用例，对其运行情况即输入与输出的对应关系进行分析，以达到检测的目的。动态测试包括： （1）功能确认与接口测试 （2）覆盖率分析 （3）性能分析 （4）内存分析黑盒测试和白盒测试若测试规划是基于产品的功能，目的是检查程序各个功能是否能够实现，并检查其中的功能错误，则这种测试方法称为黑盒测试(Black-box Testing)方法。 黑盒测试又称为功能测试、数据驱动测试和基于规格说明的

29、测试。它是一种从用户观点出发的测试，一般被用来确认软件功能的正确性和可操作性。若测试规划基于产品的内部结构进行测试，检查内部操作是否按规定执行，软件各个部分功能是否得到充分使用，则这种测试方法称为白盒测试(White-box Testing)方法。 白盒测试又称为结构测试、逻辑驱动测试或基于程序的测试，一般用来分析程序的内部结构。 黑盒测试和白盒测试（续）（续）白盒测试白盒测试黑盒测试黑盒测试两种测试方法从完全不同的角度出发，两种测试方法从完全不同的角度出发，反映了测试思路的两方面情况，适用于反映了测试思路的两方面情况，适用于不同的测试阶段。不同的测试阶段。黑盒测试和白盒测试（续）（续）1、黑

30、盒测试黑盒测试的基本观点是：任何程序都可以看作是从输入定义域映射到输出值域的函数过程，被测程序被认为是一个打不开的黑盒子，黑盒中的内容（实现过程）完全不知道，只明确要做到什么。黑盒测试主要根据规格说明书设计测试用例，并不涉及程序内部构造和内部特性，只依靠被测程序输入和输出之间的关系或程序的功能设计测试用例。黑盒测试的特点：（1）黑盒测试与软件的具体实现过程无关，在软件实现的过程发生变化时，测试用例仍然可以使用。（2）黑盒测试用例的设计可以和软件实现同时进行，这样能够压缩总的开发时间。黑盒测试和白盒测试（续）（续）输入输入输入输入输出输出输出输出黑盒测试是在程序接口进行测试，它只是检查程黑盒测试

31、是在程序接口进行测试，它只是检查程黑盒测试是在程序接口进行测试，它只是检查程黑盒测试是在程序接口进行测试，它只是检查程序功能是否按照规格说明书的规定正常使用。序功能是否按照规格说明书的规定正常使用。序功能是否按照规格说明书的规定正常使用。序功能是否按照规格说明书的规定正常使用。也也也也被称为用户测试被称为用户测试被称为用户测试被称为用户测试。黑盒测试和白盒测试（续）（续）黑盒测试主要是为了发现以下几类错误：是否有不正确或遗漏了的功能？在接口上，输入能否正确地接受？能否输出正确的结果？是否有数据结构错误或外部信息访问错误？性能上是否能够满足要求？是否有初始化或终止性错误？黑盒测试的难点：在哪个层

32、次上进行测试？黑盒测试的具体技术方法 ： 边界值分析法 等价类划分法 因果图法 错误猜想法 决策表法黑盒测试和白盒测试（续）（续）2、白盒测试白盒测试将被测程序看作一个打开的盒子，测试者能够看到被测源程序，可以分析被测程序的内部结构，此时测试的焦点集中在根据其内部结构设计测试用例。白盒测试要求是对某些程序的结构特性做到一定程度的覆盖，或者说这种测试是“基于覆盖率的测试”。通常的程序结构覆盖有： 语句覆盖 判定覆盖 条件覆盖 判定/条件覆盖 路径覆盖黑盒测试和白盒测试（续）（续）白盒测试需要白盒测试需要白盒测试需要白盒测试需要完全了解程序结构和处理过程，完全了解程序结构和处理过程，完全了解程序结

33、构和处理过程，完全了解程序结构和处理过程，它按照程序内部逻辑测试程序，检验程序中它按照程序内部逻辑测试程序，检验程序中它按照程序内部逻辑测试程序，检验程序中它按照程序内部逻辑测试程序，检验程序中每条通路是否按预定要求正确工作。每条通路是否按预定要求正确工作。每条通路是否按预定要求正确工作。每条通路是否按预定要求正确工作。也被称也被称也被称也被称为程序员测试。为程序员测试。为程序员测试。为程序员测试。应用程序应用程序黑盒测试和白盒测试（续）（续） ？ X = 2 y=2x Y=4 X = 2Y=4未知等式与已知等式黑盒黑盒白盒白盒3 3、黑盒测试法和白盒测试法的比较、黑盒测试法和白盒测试法的比较

34、黑盒测试和白盒测试（续）（续）黑盒测试： 以用户的观点，从输入数据与输出数据的对应关系，即根据程序外部特性进行测试，而不考虑内部结构及工作情况。 黑盒测试技术注重于软件的信息域（范围），通过划分程序的输入和输出域来确定测试用例。 若外部特性本身存在问题或规格说明的规定有误，则应用黑盒测试方法是不能发现问题的。 白盒测试： 只根据程序的内部结构进行测试。 测试用例的设计要保证测试时程序的所有语句至少执行一次，而且要检查所有的逻辑条件。 如果程序的结构本身有问题，比如说程序逻辑有错误或者有遗漏，那也是无法发现的。黑盒测试和白盒测试（续）（续）项目项目黑盒测试法黑盒测试法白盒测试法白盒测试法规划规划

35、方面方面功能的测试功能的测试结构的测试结构的测试优点优点方面方面 能确保从用户的角度能确保从用户的角度出发进行测试出发进行测试 能对程序内部的特定部位进能对程序内部的特定部位进行覆盖测试行覆盖测试缺点缺点方面方面无法测试程序内部特无法测试程序内部特定部位；当规格说明有定部位；当规格说明有误，则不能发现问题误，则不能发现问题无法检查程序的外部特性；无法检查程序的外部特性； 无法对未实现规格说明的程无法对未实现规格说明的程序内部欠缺部分进行测试序内部欠缺部分进行测试应用应用范围范围 边界分析法边界分析法 等价类划分法等价类划分法 因果图法因果图法 决策表测试决策表测试 语句覆盖，判定覆盖，语句覆盖

36、，判定覆盖， 条件覆盖，判定条件覆盖，判定/条件覆盖，条件覆盖， 路径覆盖，循环覆盖，路径覆盖，循环覆盖， 模块接口测试模块接口测试测试模型V模型 W模型 H模型 X模型V模型图W模型图H模型图 在整个生产周期中某个层次上的一次测试“微循环”。图中的其他流程图可以是任意开发流程。例如，设计流程和编码流程。也可以是其他非开发流程，例如，SQA流程，甚至是测试流程本身。只要测试条件成熟了，测试准备活动完成了，测试执行活动就可以进行了 X模型l X模型是由Marick提出的l X模型描述的是针对单独程序片段所进行的相互分离的编码和测试，此后将进行频繁的交换，通过集成最终合成为可执行的程序。l X模型

37、是一种探索测试模型X模型图 8.3 测试用例的设计测试用例的设计如何以最少的人力、资源投入，在最短的时间内完成测试，发现软件系统的缺陷，保证软件的优良品质，则是软件测试探索和追求的目标。测试用例是测试工作的指导，是软件测试的必须遵守的准则。更是软件测试质量稳定的根本保障。什么是测试用例什么是测试用例所谓的测试用例就是将软件测试的行为活动，做一个科学化的组织归纳。软件测试是有组织性、步骤性和计划性的，而设计软件测试用例的目的，就是为了能将软件测试的行为转换为可管理的模式。软件测试是软件质量管理中最实际的行动，同时也是耗时最多的一项。基于时间因素的考虑，软件测试行为必须能够加以量化，才能进一步让管

38、理阶层掌握所需要的测试过程，而测试用例就是将测试行为具体量化的方法之一。什么是测试用例什么是测试用例因为我们不可能进行穷举测试，为了节省时间和资源、提高测试效率，必须要从数量极大的可用测试数据中精心挑选出具有代表性或特殊性的测试数据来进行测试。目前研究室测试过程中，所有的测试用例都放在测试大纲中，使用测试大纲的好处：保证测试功能不被遗漏；使得功能不被重复测试，合理安排测试人员；使得软件测试不依赖于个人；测试用例内容测试用例内容实施一次测试而向被测系统提供的输入数据、操作或各种环境设置。对交互式系统，软件交互执行过程的控制也是一种测试用例。测试用例的设计与生成是依据测试大纲对其中每个测试项目的进

39、一步实例化。比如： 对于一个输入项的测试，应当设计一组测试数据，包括合法的、边界的和非法的数据等。测试用例设计生成的基本准则测试用例设计生成的基本准则测试用例的代表性：能够代表并覆盖各种合理的和不合理、合法的和非法的、边界的和越界的、以及极限的输入数据、操作和环境设置等;测试结果的可判定性：即测试执行结果的正确性是可判定的，每一个测试用例都应有相应的期望结果；测试结果的可再现性：即对同样的测试用例，系统的执行结果应当是相同的。测试用例的特征测试用例的特征最有可能抓住错误的；不是重复的、多余的；一组相似测试用例中最有效的；不要太简单，也不要太复杂。测试用例的组织和跟踪测试用例的组织和跟踪在执行测

40、试过程中，会遇到如下问题：在执行测试过程中，会遇到如下问题：计划执行哪些测试用例？执行需要多少时间？一轮测试需要多少测试计划执行哪些测试用例？执行需要多少时间？一轮测试需要多少测试人员？人员？能否挑出测试套装（相关测试用例子集）来测试某些特性或软件部分能否挑出测试套装（相关测试用例子集）来测试某些特性或软件部分？在执行测试用例时，能否记录哪些通过？哪些失败；在执行测试用例时，能否记录哪些通过？哪些失败；当前测试是否按计划进行？当前测试是否按计划进行？上次执行测试用例时通过的百分比是多少？上次执行测试用例时通过的百分比是多少？测试用例跟踪管理方式：测试用例追踪表测试用例跟踪管理方式：测试用例追踪

41、表测试用例的意义测试用例的意义使用测试用例的好处主要体现在以下几个方面：使用测试用例的好处主要体现在以下几个方面：在开始实施测试之前设计好测试用例，可以避免盲目测试并提高测试在开始实施测试之前设计好测试用例，可以避免盲目测试并提高测试效率。效率。测试用例的使用令软件测试的实施重点突出、目的明确。测试用例的使用令软件测试的实施重点突出、目的明确。在软件版本更新后只需修正少部分的测试用例便可展开测试工作，降在软件版本更新后只需修正少部分的测试用例便可展开测试工作，降低工作强度、缩短项目周期。低工作强度、缩短项目周期。功能模块的通用化和复用化使软件易于开发，而相对于功能模块的测功能模块的通用化和复用

42、化使软件易于开发，而相对于功能模块的测试用例的通用化和复用化则会使软件测试易于开展，并随着测试用例试用例的通用化和复用化则会使软件测试易于开展，并随着测试用例的不断精化其效率也不断攀升。的不断精化其效率也不断攀升。测试用例的意义测试用例的意义组织性有利于测试的组织；组织性有利于测试的组织；功能覆盖确保功能不被遗漏；功能覆盖确保功能不被遗漏；重复性有利于测试的重复；重复性有利于测试的重复；跟踪有利于测试的跟踪；跟踪有利于测试的跟踪；测试确认在少数高风险的测试中，必须证明确实执行了测试确认在少数高风险的测试中，必须证明确实执行了计划执行的测试；计划执行的测试；8.3.1 8.3.1 白盒测试方法白

43、盒测试方法为什么要进行白盒测试？ 如果所有软件错误的根源都可以追溯到某个唯一原因，那么问题就简单了。然而，事实上一个bug 常常是由多个因素共同导致的，如下图所示。 假设此时开发工作已结束，程序送交到测试组，没有人知道代码中有一个潜在的被 0 除的错误。若测试组采用的测试用例的执行路径没有同时经过x=0和y=5/x进行测试，显然测试工作似乎非常完善，测试用例覆盖了所有执行语句，也没有被 0 除的错误发生。白盒测试方法（续）（续）白盒测试也称结构测试或逻辑驱动测试，是针对被测单元内部是如何进行工作的测试。它根据程序的控制结构设计测试用例，主要用于软件或程序验证。白盒测试法检查程序内部逻辑结构，对

44、所有逻辑路径进行测试，是一种穷举路径的测试方法。但即使每条路径都测试过了，仍然可能存在错误。因为：穷举路径测试无法检查出程序本身是否违反了设计规范，即程序是否是一个错误的程序。穷举路径测试不可能查出程序因为遗漏路径而出错。穷举路径测试发现不了一些与数据相关的错误。白盒测试方法（续）（续）采用白盒测试方法必须遵循以下几条原则，才能达到测试的目的：保证一个模块中的所有独立路径至少被测试一次。所有逻辑值均需测试真 (true) 和假 (false) 两种情况。检查程序的内部数据结构，保证其结构的有效性。在上下边界及可操作范围内运行所有循环。白盒测试主要是检查程序的内部结构、逻辑、循环和路径。常用测试

45、用例设计方法有：逻辑覆盖法（逻辑驱动测试）基本路径测试方法8.3.1.1 白盒测试的基本概念控制流图环形复杂度图矩阵控制流图控制流图（可简称流图）是对程序流程图进行简化后得到的，它可以更加突出的表示程序控制流的结构。控制流图中包括两种图形符号：节点和控制流线。节点由带标号的圆圈表示，可代表一个或多个语句、一个处理框序列和一个条件判定框（假设不包含复合条件）。控制流线由带箭头的弧或线表示，可称为边。它代表程序中的控制流。对于复合条件，则可将其分解为多个单个条件，并映射成控制流图。常见结构的控制流图常见结构的控制流图环形复杂度环形复杂度也称为圈复杂度，它是一种为程序逻辑复杂度提供定量尺度的软件度量

46、。环形复杂度的应用可以将环形复杂度用于基本路径方法，它可以提供：程序基本集的独立路径数量；确保所有语句至少执行一次的测试数量的上界。独立路径是指程序中至少引入了一个新的处理语句集合或一个新条件的程序通路。采用流图的术语，即独立路径必须至少包含一条在本次定义路径之前不曾用过的边。测试可以被设计为基本路径集的执行过程，但基本路径集通常并不唯一。 计算环形复杂度的方法环形复杂度以图论为基础，为我们提供了非常有用的软件度量。可用如下三种方法之一来计算环形复杂度：控制流图中区域的数量对应于环形复杂度。给定控制流图G的环形复杂度V(G)，定义为 V(G) = E-N+2 其中，E是控制流图中边的数量，N是

47、控制流图中的节点数量。给定控制流图G的环形复杂度V(G)，也可定义为 V(G) = P+1 其中，P是控制流图G中判定节点的数量。图矩阵图矩阵是控制流图的矩阵表示形式。图矩阵是一个方形矩阵，其维数等于控制流图的节点数。矩阵中的每列和每行都对应于标识的节点，矩阵元素对应于节点间的边。通常，控制流图中的结点用数字标识，边则用字母标识。如果在控制流图中从第 i 个结点到第 j 个结点有一个标识为 x 的边相连接，则在对应图矩阵的第 i 行第 j 列有一个非空的元素 x 。8.3.1.2 覆盖测试测试覆盖率逻辑覆盖法面向对象的覆盖测试覆盖准则测试覆盖率测试覆盖率：用于确定测试所执行到的覆盖项的百分比。

48、其中的覆盖项是指作为测试基础的一个入口或属性，比如语句、分支、条件等。测试覆盖率可以表示出测试的充分性，在测试分析报告中可以作为量化指标的依据，测试覆盖率越高效果越好。但覆盖率不是目标，只是一种手段。 测试覆盖率包括功能点覆盖率和结构覆盖率：功能点覆盖率大致用于表示软件已经实现的功能与软件需要实现的功能之间的比例关系。结构覆盖率包括语句覆盖率、分支覆盖率、循环覆盖率、路径覆盖率等等。逻辑覆盖法根据覆盖目标的不同，逻辑覆盖又可分为语句覆盖、判定覆盖、条件覆盖、判定/条件覆盖、组合覆盖和路径覆盖。语句覆盖：选择足够多的测试用例，使得程序中的每个可执行语句至少执行一次。判定覆盖：通过执行足够的测试用

49、例，使得程序中的每个判定至少都获得一次“真”值和“假”值， 也就是使程序中的每个取“真”分支和取“假”分支至少均经历一次，也称为“分支覆盖”。条件覆盖：设计足够多的测试用例，使得程序中每个判定包含的每个条件的可能取值（真/假）都至少满足一次。逻辑覆盖法（续）（续）判定/条件覆盖：设计足够多的测试用例，使得程序中每个判定包含的每个条件的所有情况（真/假）至少出现一次，并且每个判定本身的判定结果（真/假）也至少出现一次。 满足判定/条件覆盖的测试用例一定同时满足判定覆盖和条件覆盖。组合覆盖：通过执行足够的测试用例，使得程序中每个判定的所有可能的条件取值组合都至少出现一次。 满足组合覆盖的测试用例一

50、定满足判定覆盖、条件覆盖和判定/条件覆盖。路径覆盖：设计足够多的测试用例，要求覆盖程序中所有可能的路径。 逻辑覆盖法（续）（续）组合覆盖判断/条件覆盖判断覆盖条件覆盖语句覆盖逻辑覆盖法（续）（续）void DoWork (int x,int y,int z) int k=0,j=0; if ( (x3)&(z5) ) j=x*y+10; /语句块2 j=j%3; /语句块3逻辑覆盖法（续）（续）X3 & z5执行语句块执行语句块3FFTTabdce语句覆盖要实现DoWork函数的语句覆盖，只需设计一个测试用例就可以覆盖程序中的所有可执行语句。测试用例输入为： x=4、y=5、z=5 程序执行的

51、路径是：abd分析： 语句覆盖可以保证程序中的每个语句都得到执行，但发现不了判定中逻辑运算的错误，即它并不是一种充分的检验方法。例如在第一个判定(x3)&(z5错误写为y3)&(z3 取真值记为T1，取假值记为-T1 条件z5) )： 条件x=4 取真值记为T3，取假值记为-T3 条件y5 取真值记为T4，取假值记为-T4条件覆盖（续）（续）根据条件覆盖的基本思想，要使上述4个条件可能产生的8种情况至少满足一次，设计测试用例如下： 测试用例 执行路径 覆盖条件 覆盖分支 x=4、y=6、z=5 abd T1、T2、T3、T4 bd x=2、y=5、 z=15 ace -T1、-T2、 -T3、

52、-T4 ce分析：上面这组测试用例不但覆盖了4个条件的全部8种情况，而且将两个判定的4个分支b、c、d、e也同时覆盖了，即同时达到了条件覆盖和判定覆盖。条件覆盖（续）（续）说明：虽然前面的一组测试用例同时达到了条件覆盖和判定覆盖，但是，并不是说满足条件覆盖就一定能满足判定覆盖。如果设计了下表中的这组测试用例，则虽然满足了条件覆盖，但只是覆盖了程序中第一个判定的取假分支c 和第二个判定的取真分支d，不满足判定覆盖的要求。 测试用例 执行路径 覆盖条件覆盖分支x=2、y=6、z=5 acd-T1、T2、 -T3、T4 cdx=4、y=5、z=15 acdT1、-T2、 T3、-T4 cd判定/条件

53、覆盖判定/条件覆盖实际上是将判定覆盖和条件覆盖结合起来的一种方法，即：设计足够的测试用例，使得判定中每个条件的所有可能取值至少满足一次，同时每个判定的可能结果也至少出现一次。根据判定/条件覆盖的基本思想，只需设计以下两个测试用例便可以覆盖4个条件的8种取值以及4个判定分支。 测试用例 执行路径 覆盖条件覆盖分支x=4、y=6、z=5 abdT1、T2、 T3、T4 bdx=2、y=5、z=15ace-T1、-T2、 -T3、-T4 ce判定/条件覆盖（续）（续）分析：从表面上看，判定/条件覆盖测试了各个判定中的所有条件的取值，但实际上，编译器在检查含有多个条件的逻辑表达式时，某些情况下的某些条

54、件将会被其它条件所掩盖。因此，判定/条件覆盖也不一定能够完全检查出逻辑表达式中的错误。 例如：对于第一个判定(x3)&(z3和z3为假，则编译器将不再检查z5)来说，若条件x=4满足，就认为该判定为真，这时将不会再检查y5，那么同样也无法发现这个条件中的错误。组合覆盖组合覆盖的目的是要使设计的测试用例能覆盖每一个判定的所有可能的条件取值组合。对DoWork函数中的各个判定的条件取值组合加以标记： 1、x3, z3, z=10 记做T1 -T2，第一个判定的取假分支 3、x=3, z10 记做-T1 T2，第一个判定的取假分支 4、x=10 记做-T1 -T2，第一个判定的取假分支 5、x=4,

55、 y5 记做T3 T4，第二个判定的取真分支 6、x=4, y5 记做-T3 T4，第二个判定的取真分支 8、x!=4, y8 AND Y5X0 OR Y0引用语句1引用语句2NYNYX16 OR Y10引用语句3NY面向对象的覆盖继承上下文覆盖继承上下文覆盖由于传统的结构化度量没有考虑面向对象的一些特性（如多态、继承和封装等），所以在面向对象领域，传统的结构化覆盖必须被加强，以满足面向对象特性。继承上下文覆盖考虑在每个类的上下文内获得的覆盖率级别。它是扩展到面向对象领域里的一种覆盖率度量方法，用于度量在系统中的多态调用被测试得多好。继承上下文定义将基类上下文内例行程序的执行作为独立于继承类上

56、下文内例行程序的执行。同样，它们在考虑继承类上下文内例行程序的执行也独立于基类上下文内例行程序的执行。为了获得100继承上下文覆盖，代码必须在每个适当的上下文内被完全执行。 面向对象的覆盖（续）（续）基于状态的上下文覆盖基于状态的上下文覆盖在绝大多数面向对象的系统中存在这样的一些类：这些类的对象可以存在于众多不同状态中的任何一种，并且由于类的行为依赖于状态，每个类的行为在每个可能的状态中其性质是不同的。基于状态的上下文覆盖对应于被测类对象的潜在状态。这样基于状态的上下文覆盖把一个状态上下文内的一个例行程序的执行认为是独立于另一个状态内相同例行程序的执行。为了达到100的基于状态的上下文覆盖，例

57、行程序必须在每个适当的上下文（状态）内被执行。测试覆盖准则逻辑覆盖的出发点是合理的、完善的。所谓“覆盖”，就是想要做到全面而无遗漏，但逻辑覆盖并不能真正做到无遗漏。例如：我们不小心将前面提到的程序段中的 if (x3 & Z=3 & Z10) 按照我们前面设计的测试用例（x的值取2或4）来看，逻辑覆盖对这样的小问题都无能为力。分析出现这一情况的原因在于：错误区域仅仅在x=3这个点上，即仅当x的值取3时，测试才能发现错误。面对这类情况，我们应该从中吸取的教训是测试工作要有重点，要多针对容易发生问题的地方设计测试用例。测试覆盖准则（续）（续）ESTCA覆盖准则：在容易发生问题的地方设计测试用例，即

58、重视程序中谓词（条件判断）的取值。ESTCA覆盖准则是一套错误敏感用例分析规则。这一规则虽然并不完备，但在普通程序中却是有效的。原因在于这是一种经验型的覆盖准则，规则本身针对了程序编写人员容易发生的错误，或是围绕着发生错误的频繁区域，从而提高了发现错误的命中率。具体规则如下： 规则1 对于A rel B型 (rel可以是) 的分支谓词，应适当的选择A与B的值，使得测试执行到该分支语句时，AB的情况分别出现一次。 这是为了检测逻辑符号写错的情况，如将“AB”。测试覆盖准则（续）（续）规则2 对于A rel C型 (rel可以是或, A是变量，C是常量)的分支谓词：当rel为时，应适当的选择A的值

59、，使A=C+M。 这是为了检测“差1”之类的错误，如“A1”错写成“A0”。规则3 对外部输入变量赋值，使其在每一个测试用例中均有不同的值与符号，并与同一组测试用例中其他变量的值与符号不同。 这是为了检测程序语句中的错误，如应该引用某一变量而错成引用另一个常量。测试覆盖准则（续）（续）关于LCSAJLCSAJ (Linear Code Sequence and Jump) 的字面含义是线性代码序列与跳转。在程序中，一个LCSAJ是一组顺序执行的代码，以控制跳转为其结束点。LCSAJ的起点是根据程序本身决定的。它的起点可以是程序第一行或转移语句的入口点，或是控制流可跳达的点。如果有几个LCSAJ

60、首尾相接，且第一个LCSAJ起点为程序起点，最后一个LCSAJ终点为程序终点，这样的LCSAJ串就组成了程序的一条路径（LCSAJ路径）。一条LCSAJ程序路径可能是由2个、3个或多个LCSAJ组成的。测试覆盖准则（续）（续）基于LCSAJ与路径的关系，提出了层次LCSAJ覆盖准则。它是一个分层的覆盖准则，可以概括的描述为：第一层 语句覆盖。第二层 分支覆盖。第三层 LCSAJ覆盖，即程序中的每一个LCSAJ都至少在测试中经历过一次。第四层 两两LCSAJ覆盖，即程序中的每两个相连的LCSAJ组合起来在测试中都要经历一次。第n+2层 每n个首尾相连的LCSAJ组合在测试中都要经历一次。 在实施

61、测试时，若要实现上述的层次LCSAJ覆盖，需要产生被测程序的所有LCSAJ。测试覆盖准则（续）（续）例：找出前面DoWork函数的所有LCSAJ和LCSAJ路径。LCSAJ（5个）： （1）int k=0,j=0; if ( (x3)&(z5) ) （3）if ( (x=4)|(y5) ) （4）j=x*y+10; j=j%3 （5）j=j%3LCSAJ路径（4条）： （1）-（2）-（4） （1）-（2）-（5） （1）-（3）-（4） （1）-（3）-（5）8.3.1.3 路径测试路径表达式基本路径测试方法循环测试方法产生测试用例Return路径表达式为了满足路径覆盖，必须首先确定具体的路

62、径以及路径的个数。我们通常采用控制流图的边（弧）序列和节点序列表示某一条具体路径，更为概括的表示方法为：（1）弧a和弧b相乘，表示为ab，它表明路径是先经历弧a，接着再经历弧b，弧a和弧b是先后相接的。（2）弧a和弧b相加，表示为a+b，它表明两条弧是“或”的关系，是并行的路段。路径数的计算： 在路径表达式中，将所有弧均以数值1来代替，再进行表达式的相乘和相加运算，最后得到的数值即为该程序的路径数。基本路径测试方法路径测试就是从一个程序的入口开始，执行所经历的各个语句的完整过程。从广义的角度讲，任何有关路径分析的测试都可以被称为路径测试。完成路径测试的理想情况是做到路径覆盖，但对于复杂性大的程

63、序要做到所有路径覆盖（测试所有可执行路径）是不可能的。在不能做到所有路径覆盖的前提下，如果某一程序的每一个独立路径都被测试过，那么可以认为程序中的每个语句都已经检验过了，即达到了语句覆盖。这种测试方法就是通常所说的基本路径测试方法。 基本路径测试方法（续）（续）基本路径测试方法是在控制流图的基础上，通过分析控制结构的环形复杂度，导出执行路径的基本集，再从该基本集设计测试用例。基本路径测试方法包括以下4个步骤：（1）画出程序的控制流图。（2）计算程序的环形复杂度，导出程序基本路径集中的独立路径条数，这是确定程序中每个可执行语句至少执行一次所必须的测试用例数目的上界。（3）导出基本路径集，确定程序

64、的独立路径。（4）根据（3）中的独立路径，设计测试用例的输入数据和预期输出。基本路径测试方法（续）（续）void Sort ( int iRecordNum, int iType )1 2 int x=0;3 int y=0;4 while ( iRecordNum- 0 )5 6 If ( iType=0 )7x=y+2;8 else9 If ( iType=1 )10 x=y+10;11 else12 x=y+20;13 14 基本路径测试方法（续）（续）画出控制流图： 如右图所示计算环形复杂度： 10（条边）- 8（个节点）+ 2 = 4导出独立路径（用语句编号表示） 路径1：414 路

65、径2：46714 路径3：4691013414 路径4：4691213414467910121314基本路径测试方法（续）（续）输入数据预期输出测试用例1irecordnum = 0itype = 0x = 0y = 0测试用例2irecordnum = 1itype = 0x = 0y = 0测试用例3irecordnum = 1itype = 1x = 10y = 0测试用例4irecordnum = 1itype = 2x = 0y = 20设计测试用例：习题1、使用基本路径测试方法，为以下程序段设计测试用例。 void Do (int X,int A,int B) 1 if ( (A1

66、)&(B=0) ) 2 X = X/A; 3 if ( (A=2)|(X1) ) 4 X = X+1; 5 2、在三角形问题中，要求输入三个边长：a，b，c。当三边不可能构成三角形时提示错误，可构成三角形时计算三角形的周长。若是等腰三角形打印“等腰三角形”，若是等边三角形，则打印“等边三角形”。画出相应的程序流程图，并采用基本路径测试方法为该程序设计测试用例。循环测试方法从本质上说，循环测试的目的就是检查循环结构的有效性。通常，循环可以划分为简单循环、嵌套循环、串接循环和 非结构循环4类。（1）测试简单循环。设其循环的最大次数为n ，可采用以下测试集：跳过整个循环；只循环一次；只循环两次；循环

67、 m 次，其中m8 AND Y5X0 OR Y0引用语句1引用语句2NYNYX16 OR Y10引用语句3NY习题2、某程序所画出的N-S图如右图所示的，至少需要多少个测试用例才能对该程序实现逻辑覆盖？8.3.2 黑盒测试技术黑盒测试被称为功能测试或数据驱动测试。在测试时，把被测程序视为一个不能打开的黑盒子，在完全不考虑程序内部结构和内部特性的情况下进行。采用黑盒测试的目的主要是在已知软件产品所应具有的功能的基础上，进行：（1）检查程序功能能否按需求规格说明书的规定正常使用，测试各个功能是否有遗漏，检测性能等特性要求是否满足。（2）检测人机交互是否错误，检测数据结构或外部数据库访问是否错误，程

68、序是否能适当地接收输入数据而产生正确的输出结果，并保持外部信息（如数据库或文件）的完整性。（3）检测程序初始化和终止方面的错误。三角形问题与NextDate函数 1、三角形问题 输入三个整数a、b、c，分别作为三角形的三条边，现通过程序判断由三条边构成的三角形的类型为等边三角形、等腰三角形、一般三角形（特殊的还有直角三角形），以及构不成三角形。 现在要求输入三个整数a、b、c，必须满足以下条件： 条件1 1a100 条件4 ab+ c 条件2 1b100 条件5 ba+ c 条件3 1c100 条件6 ca+ b 三角形问题与NextDate函数（续）（续）如果输入值a、b、c不满足条件1、条

69、件2和条件3 ，程序给出“边的取值超出允许范围”的信息。如果输入值a、b、c 满足条件1、条件2和条件3，则输出下列四种情况之一：（1）如果不满足条件4、条件5和条件6中的一个，则程序输出为“非三角形”。（2）如果三条边相等，则程序输出为“等边三角形”。（3）如果恰好有两条边相等，则程序输出为“等腰三角形”。（4）如果三条边都不相等，则程序输出为“一般三角形”。结论结论：三角形问题的复杂之处在于输入与输出之间的关系比较复杂。三角形问题与NextDate函数（续）（续） 2、NextDate函数 NextDate函数说明另一种复杂的关系，即输入变量之间逻辑关系的复杂性。 NextDate函数包含

70、三个变量month、day和year，函数的输出为输入日期后一天的日期。 要求输入变量month、day和year均为整数值，并且满足下列条件： 条件1 1 month 12 条件2 1 day 31 条件3 1912 year 2050结论：结论：在NextDate函数中有两种复杂性的输入来源，一是输入域的复杂性，二是确定闰年的规则并要增加“额外天”。8.3.2.1 等价类划分法等价类的划分原则等价类划分法的测试用例设计常见等价类划分测试形式使用等价类划分法测试的实例Return等价类划分法等价类划分法是一种重要的、常用的黑盒测试方法，它将不能穷举的测试过程进行合理分类，从而保证设计出来的测

71、试用例具有完整性和代表性。举例：设计这样的测试用例，来实现一个对所有实数进行开平方运算（ y = sqrt(x) ）的程序的测试。思考方向： 由于开平方运算只对非负实数有效，这时需要将所有的实数（输入域x）进行划分，可以分成：正实数、0 和 负实数。假设我们选定+1.4444代表正实数，-2.345代表负实数，则为该程序设计的测试用例的输入为+1.4444、 0 和 -2.345。等价类划分法（续）（续）等价类划分法是把所有可能的输入数据，即程序的输入域等价类划分法是把所有可能的输入数据，即程序的输入域划分为若干部分（子集），然后从每一个子集中选取少数划分为若干部分（子集），然后从每一个子集中

72、选取少数具有代表性的数据作为测试用例。具有代表性的数据作为测试用例。所谓等价类是指某个输入域的子集合。所谓等价类是指某个输入域的子集合。在该子集合中，各个输入数据对于揭露程序中的错误都是等效的，它们具有等价特性，即每一类的代表性数据在测试中的作用都等价于这一类中的其它数据。这样，对于表征该类的数据输入将能代表整个子集合的输入。因此，可以合理的假定： 测试某等价类的代表值就是等效于对于这一类其它值的测试。等价类的划分原则等价类是输入域的某个子集合，而所有等价类的并集就是整个输入域。因此，等价类对于测试有两个重要的意义：完备性完备性整个输入域提供一种形式的完备性无冗余性无冗余性若互不相交则可保证一

73、种形式的无冗余性如何划分？如何划分？先从程序的规格说明书中找出各个输入条件，再为每个输入条件划分两个或多个等价类，形成若干的互不相交的子集。采用等价类划分法设计测试用例通常分两步进行： （1）确定等价类，列出等价类表。确定等价类，列出等价类表。 （2）确定测试用例。）确定测试用例。等价类的划分原则（续）（续）划分等价类可分为两种情况：（1）有效等价类 是指对软件规格说明而言，是有意义的、合理的输入数据所组成的集合。利用有效等价类，能够检验程序是否实现了规格说明中预先规定的功能和性能。（2）无效等价类 是指对软件规格说明而言，是无意义的、不合理的输入数据所构成的集合。利用无效等价类，可以鉴别程序

74、异常处理的情况，检查被测对象的功能和性能的实现是否有不符合规格说明要求的地方。 等价类的划分原则（续）（续）进行等价类划分的依据：（1）按照区间划分 在输入条件规定了取值范围或值的个数的情况下，可以确定一个有效等价类和两个无效等价类。例：例：程序输入条件为小于程序输入条件为小于100100大于大于1010的整数的整数x x，则有效等价类，则有效等价类为为1010x x100100，两个无效等价类为，两个无效等价类为x10x10和和x100x100。例：程序输入x取值于一个固定的枚举类型1,3,7,15，且程序 中对这4个数值分别进行了处理，则有效等价类为x=1、x=3、 x=7、x=15，无效

75、等价类为x1,3,7,15的值的集合。（2）按照数值划分 在规定了一组输入数据（假设包括 n个 输入值），并且程序要对每一个输入值分别进行处理的情况下，可确定 n 个有效等价类（每个值确定一个有效等价类）和一个无效等价类（所有不允许的输入值的集合）。等价类的划分原则（续）（续）（3）按照数值集合划分 在输入条件规定了输入值的集合或规定了“必须如何”的条件下，可以确定一个有效等价类和一个无效等价类（该集合有效值之外）。例：例：程序输入条件为取值为奇数的整数程序输入条件为取值为奇数的整数x x，则有效等价类为，则有效等价类为x x的值为奇数的整数，无效等价类为的值为奇数的整数，无效等价类为x x的

76、值不为奇数的整数。的值不为奇数的整数。例：例：程序输入条件为以字符程序输入条件为以字符 aa开头、长度为开头、长度为8 8的字符串，并的字符串，并且字符串不包含且字符串不包含 a za z之外的其它字符，则有效等价类之外的其它字符，则有效等价类为满足了上述所有条件的字符串，无效等价类为不以为满足了上述所有条件的字符串，无效等价类为不以 aa开开头的字符串、长度不为头的字符串、长度不为8 8的字符串和包含了的字符串和包含了 a za z之外之外其它字符的字符串。其它字符的字符串。（5）细分等价类 在确知已划分的等价类中各元素在程序中的处理方式不同的情况下，则应再将该等价类进一步划分为更小的等价类

77、，并建立等价类表。 （4）按照限制条件或规则划分 在规定了输入数据必须遵守的规则或限制条件的情况下，可确定一个有效等价类（符合规则）和若干个无效等价类（从不同角度违反规则）。等价类划分法的测试用例设计在设计测试用例时，应同时考虑有效等价类和无效等价类测试用例的设计。根据已列出的等价类表可确定测试用例，具体过程如下：（1）首先为等价类表中的每一个等价类分别规定一个唯一的编号。（2）设计一个新的测试用例，使它能够尽量覆盖尚未覆盖的有效等价类。重复这个步骤，直到所有的有效等价类均被测试用例所覆盖。（3）设计一个新的测试用例，使它仅覆盖一个尚未覆盖的无效等价类。重复这一步骤，直到所有的无效等价类均被测

78、试用例所覆盖。常见等价类划分测试形式针对是否对无效数据进行测试，可以将等价类测试分为 标准等价类测试和健壮等价类测试。标准等价类测试不考虑无效数据值，测试用例使用 每个等价类中的一个值。健壮等价类测试主要的出发点是考虑了无效等价类。对有效输入，测试用例从每个有效等价类中取一个值； 对无效输入，一个测试用例有一个无效值，其他值均取 有效值。 健壮等价类测试存在两个问题： （1）需要花费精力定义无效测试用例的期望输出 （2）对强类型的语言没有必要考虑无效的输入 使用等价类划分法测试的实例实例实例1 三角形问题三角形问题分析：分析：在多数情况下，是从输入域划分等价类的，但并非不能从被测程序的输出域反

79、过来定义等价类，事实上，这对于三角形问题却是最简单的划分方法。 在三角形问题中，有四种可能的输出：等边三角形、等腰三角形、一般三角形和非三角形。利用这些信息能够确定下列输出（值域）等价类。 R1 = : 边为a,b,c的等边三角形 R2 = : 边为a,b,c的等腰三角形 R3 = : 边为a,b,c的一般三角形 R4 = : 边为a,b,c不能组成三角形 标准等价类测试用例标准等价类测试用例健壮等价类测试用例健壮等价类测试用例使用等价类划分法测试的实例（续）（续）实例实例2 保险公司计算保费费率的程序保险公司计算保费费率的程序 某保险公司的人寿保险的保费计算方式为： 投保额保险费率 其中，保

80、险费率依点数不同而有别，10点及10点以上保险费率为0.6%，10点以下保险费率为0.1%；而点数又是由 投保人的年龄、性别、婚姻状况和抚养人数来决定，具体规则如下：年龄 性别婚姻抚养人数 2039 4059 其它 M F 已婚 未婚 1人扣0.5点 最多扣3点（四舍五入取整） 6点 4点 2点 5点 3点 3点 5点计算保费费率的程序（1）分析程序规格说明中给出和隐含的对输入条件的要求，列出等价类表（包括有效等价类和无效等价类）。年龄：一位或两位非零整数，值的有效范围为199性别：一位英文字符，只能取值M或F婚姻：字符，只能取值已婚或未婚抚养人数：空白或一位非零整数（19）点数 ：一位或两位非零整数，值的范围为199（2）根据（1）中的等价类表，设计能覆盖所有等价类的 测试用例。等价类表等价类表测试用例测试用例