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

第八章,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 跨世纪“千年虫”问题 案例4 爱国者导弹防御系统炸死自家人 系统时钟误差积累 案例5 英特尔奔腾浮点除法上述所有实例中的软件问题在软件工程或软件测试中都被称为软件缺陷或软件故障。,软件是复杂的、知识高度密集的逻辑产品，因此软件错误防不胜防。对于规模大、复杂性高的软件更是如此。这些错误中，有些神之石致命的，若不排除，会导致财产以及生命的重大损失。,1963年美国飞往火星的火箭爆炸，造成1000万美元的损失。原因是FORTRAN程序：DO 5 I=1，3 误写为：DO 5 I=1.3,1967年苏联“联盟一号”载人宇宙飞船在返航时，由于软件忽略一个小数点，导至在进入大气层时因打不开降落伞而烧毁。,软件危机,软件缺陷与故障（续）,2、软件缺陷的定义（1）软件未达到产品说明书中已经标明的功能；（2）软件出现了产品说明书中指明不会出现的错误；（3）软件未达到产品说明书中虽未指出但应当达到的目标；（4）软件功能超出了产品说明书中指明的范围；（5）软件测试人员认为软件难以理解、不易使用，或者最终用户认为该软件使用效果不良。,软件缺陷与故障（续）,3、软件缺陷的特征“看不到”软件的特殊性决定了缺陷不易看到“看到但是抓不到”发现了缺陷，但不易找到问题发生的原因所在,8.1.2 软件缺陷产生的原因,软件缺陷的主要类型/现象：功能、特性没有实现或部分实现 设计不合理，存在缺陷 实际结果和预期结果不一致 运行出错，包括运行中断、系统崩溃、界面混乱 数据结果不正确、精度不够 用户不能接受的其他问题，如存取时间过长、界面不美观,常见导致错误的根源,缺乏有效的沟通，或者没有进行沟通；软件复杂度不断变更的需求时间的压力缺乏文档的代码软件开发工具,图8-1 软件缺陷产生的原因分布,软件缺陷产生的原因有很多，但最主要的原因要归咎于产品描述,软件测试的复杂性分析（续）,8.2 软件测试基础概念,8.2.1 软件测试的定义8.2.2 软件测试的基本概念8.2.3 软件测试方法与策略,8.2.1 软件测试定义,软件测试是一个贯彻于软件开发过程始终的过程，是为了发现错误而执行程序的过程，是根据软件开发各阶段的规格说明和程序的内部结构结构而精心设计一批测试用例。,什么是软件测试,使用人工或者自动手段来运行或测定某个系统的过程目的在于检验它是否满足规定的需求、弄清预期结果与实际结果之间的差别可简述为：按照特定规程，发现软件错误的过程,软件测试定义（续）,1.软件测试的目的,软件测试的目标是以最少的时间和人力，系统的找出软件中潜在的各种错误和缺陷测试是为了发现程序中的错误而执行程序的过程好的测试方案（测试用例）在于尽可能发现迄今为止尚未发现的错误成功的测试是发现了至今为止尚未发现的错误的测试,8.2.2 软件测试基本概念,软件测试目的（续）,测试并不仅仅是为了找出错误.通过分析错误产生的原因和错误的发生趋势,可以帮助项目管理者发现当前软件开发过程中的缺陷,以便及时改进；这种分析也能帮助测试人员设计出有针对性的测试方法,改善测试的效率和有效性；没有发现错误的测试也是有价值的,完整的测试是评定软件质量的一种方法,软件测试员的目标,发现软件缺陷,2.软件测试的目标,最终目的是确保软件的功能符合用户的需求，把尽可能多的问题在发布或交付前发现并改正：确保软件完成了它所承诺或公布的功能（缺少规范的书面文档？）确保软件满足性能的要求（界面、操作、性能）确保软件是健壮的和适应用户环境的（哪怕不健壮，也要给出解决方案）,2.软件测试的目标,为软件的质量评估提供依据（项目验收）为软件质量改进和管理提供帮助（经验教训等知识转移）,软件测试的生命周期,3.软件测试的特性,软件测试与分析、设计、编码等工作相比，具有若干特殊的性质：挑剔性。测试是一种“挑剔性”行为，以证明程序有错的目的去进行测试，才能把程序中潜在的错误找出来。复杂性。设计测试用例是一项需要细致和高度技巧的工作。不彻底性。测试只能证明软件中存在错误，不能证明软件中不存在错误所谓彻底测试，也就是穷举测试，显然在实际测试中无法实现或行不通。经济性。降低测试成本，应遵守的经济性原则：一，根据程序的重要性和一旦发生故障将造成的损失来确定他的可靠性等级，不要随意提高等级使测试成本增加；二，要认真研究测试策略，以便使用尽可能少的测试用例来发现尽可能多的程序错误。,为保证测试质量，软件测试必须完成规定的文档。按照软件工程的要求，测试文档应包括测试计划和测试报告两方面内容。测试计划的主体是“测试内容说明”。它包括测试项目名称，各项测试的目的、步骤和进度，以及测试用例的设计等。测试报告的主体是“测试结果”，它包括测试项目名称，实测结果与期望结果的比较，发现的问题，以及测试达到的效果。,4.软件测试的文档,测试用例=测试数据+期望结果测试结果=测试数据+期望结果+实际结果,软件测试国家标准,GB/T 9386-1988 计算机软件测试文件编制规范GB/T 15532-1995 计算机软件单元测试规范GB/T 17544-1998 信息技术 软件包 质量要求和测试GB/T 16260.1-2003 软件工程 产品质量第1部份，质量模型GB/T 16260.2-200X软件工程 产品质量第2部份，外部度量GB/T 16260.3-200X软件工程 产品质量第3部份，内部度量GB/T 16260.4-200X软件工程 产品质量第4部份，使用质量度量GB/T 18905.1-2002软件工程 产品质量第1部份，概述GB/T 18905.2-2002软件工程 产品质量第2部份，策划和管理GB/T 18905.3-2002软件工程 产品质量第3部份，开发者用的过程GB/T 18905.4-2002软件工程 产品质量第4部份，需方用的过程GB/T 18905.5-2002软件工程 产品质量第5部份，评价者用的过程GB/T 18905.6-2002软件工程 产品质量第6部份，评价模块文档编写,国标来自的国际标,GB/T 16260.1-6 取自ISO/IEC 9126-1:2001 ISO/IEC 9126-2:2003 ISO/IEC 9126-3:2003 ISO/IEC TR 9126-4:2004 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:2001 GB/T 17544-1998 取自ISO/IEC 12119:1994,5.软件测试的原则,Good-enough:一种权衡投入/产出比的原则：选择测试保证测试的覆盖程度，但穷举测试是不可能的：有限测试所有的测试都应追溯到用户需求越早测试越好，测试过程与开发过程应是相结合的测试的规模由小而大，从单元测试到系统测试为了尽可能地发现错误，应该由独立的第三方来测试不能为了便于测试擅自修改程序既应该测试软件该做什么也应该测试软件不该做什么,传统的瀑布模型中软件测试学仅处于运行维护阶段之前,项目规划阶段：负责从单元测试到系统测试的整个测 试阶段的监控。需求分析阶段：确定测试需求分析、系统测试计划的 制定、评审后成为管理项目。详细设计和概要设计阶段：确保集成测试计划和单元 测试计划完成。编码阶段：由开发人员进行自己负责部分的测试代码。在项目较大时，由专人进行编码阶段的测 试任务。测试阶段：依据测试代码进行测试，并提交相应的测 试状态报告和测试结束报告。,6、测试在开发各阶段的作用,图8-2 完整的开发流程,7、完整的软件开发流程,8.软件测试和缺陷修复的代价,软件在从需求、设计、编码、测试一直到交付用户公开使用后的过程中，都有可能产生和发现缺陷。随着整个开发过程的时间推移，更正缺陷或修复问题的费用呈几何级数增长。,图8-3 软件缺陷在不同阶段发现时修复的费用示意图,软件测试是有风险的行为,如果决定不去测试所有的情况，那就是选择了风险。,软件缺陷的寄生虫性,找到的软件缺陷越多，就说明软件缺陷越多,原因：程序员的疲倦程序员往往犯同样的错误某些软件的缺陷其实是大灾难的征兆,软件测试的杀虫剂现象,软件测试越多，其免疫力越强的现象,克服方法：不断编写不同的新的测试程序对程序的不同部分进行测试,软件测试的不修复原则,并非所有软件缺陷都能修复,不需要修复软件缺陷的原因：没有足够的时间不算真正的软件缺陷修复的风险太大不值得修复,Pareto原则,Pareto原则暗示着测试发现的错误中的80%很可能起源于程序模块中的20%。,软件测试中的误区,调试和测试是一样的；测试组应当为保证质量负责；把测试作为新员工的一个过渡工作；关注测试的执行而忽略测试的设计；测试自动化是万能的；测试是枯燥乏味，缺乏创造力的工作。,8.2.3 软件测试方法与策略,软件测试策略软件测试方法测试关键词静态测试与动态测试白盒测试与黑盒测试软件测试模型,软件测试策略,什么是软件测试策略？是为软件工程过程定义的一个软件测试的模板，也就是把特定的测试用例方法放置进去的一系列步骤。软件测试策略包含的特征：（1）测试从模块层开始，然后扩大延伸到整个基于计算机的系统集合中。（2）不同的测试技术适用于不同的时间点。（3）测试是由软件的开发人员和（对于大型系统而言）独立的测试组来管理的。（4）测试和调试是不同的活动，但是调试必须能够适应任何的测试策略。,软件测试策略,测试信息流分析设计阶段需求说明书评测概要设计说明书评测详细设计说明书评测软件编码规范评测开发阶段单元测试集成测试确认测试系统测试验收测试软件验证和确认过程,软件测试关键词,单元测试集成测试系统测试确认测试验收测试白盒测试黑盒测试灰盒测试,单元测试,单元测试又称模块测试是针对软件设计的最小单元程序模块进行正确性检验的测试工作其目的在于检查每个程序单元能否实 现详细设计说明中的模块功能、性能、接口和设计约束等要求，发现各模块内部可能存在的错误,集成测试,集成测试，也叫组装测试或联合测试在单元测试的基础上，将所有模块按照设计要求）如根据结构图组装成为子系统或系统，进行集成测试集成测试是检验程序单元和部件的接口关系实践表明，一些模块虽然能够单独地工作，但并不能保证连接起来也能正常的工作。程序在某些局部反映不出来的问题，在全局上很可能暴露出来，影响功能的实现,系统测试,系统测试是将已经确认的软件、计算机硬件、外设、网络等其他元素结合在一起，进行信息系统的各种组装测试和确认测试，其目的是通过与系统的需求相比较，发现所开发的系统与用户需求不符或矛盾的地方 系统测试的任务是近可能彻底的检查出程序中的错误，提高软件系统的可靠性，其目的是检验系统做得怎样？,确认测试,确认测试的目的是向未来的用户表明系统能够像预定要求那样工作。经集成测试后，已经按照设计把所有的模块组装成一个完整的软件系统，接口错误也已经基本排除了，接着就应该进一步验证软件的有效性，这就是确认测试的任务，即软件的功能和性能如同用户所合理期待的那样 确认测试又称有效性测试。有效性测试是在模拟的环境下，运用黑盒测试的方法，验证被测软件是否满足需求规格说明书列出的需求。任务是验证软件的功能和性能及其他特性是否与用户的要求一致。对软件的功能和性能要求在软件需求规格说明书中已经明确规定，它包含的信息就是软件确认测试的基础,验收测试,系统开发生命周期方法论的一个阶段，这时相关的用户和或独立测试人员根据测试计划和结果对系统进行测试和接收。它让系统用户决定是否接收系统。它是一项确定产品是否能够满足合同或用户所规定需求的测试 这是管理性和防御性控制的测试过程,白盒测试,白盒测试也称结构测试或逻辑驱动测试，它是按照程序内部的结构测试程序，通过测试来检测产品内部动作是否按照设计规格说明书的规定正常进行，检验程序中的每条通路是否都能按预定要求正确工作是把测试对象看作一个打开的盒子，测试人员依据程序内部逻辑结构相关信息，设计或选择测试用例，对程序所有逻辑路径进行测试，通过在不同点检查程序的状态，确定实际的状态是否与预期的状态一致,黑盒测试,黑盒测试也称功能测试，它是通过测试来检测每个功能是否都能正常使用。在测试地，把程序看作一个不能打开的黑盒子，在完全不考虑程序内部结构和内部特性的情况下，在程序接口进行测试，它只检查程序功能是否按照需求规格说明书的规定正常使用，程序是否能适当地接收输入数据而产生正确的输出信息。黑盒测试着眼于程序外部结构，不考虑内部逻辑结构，主要针对软件界面和软件功能进行测试,灰盒测试,灰盒测试，确实是介于白盒测试与黑盒测试之间的测试 灰盒测试关注输出对于输入的正确性，同时也关注内部表现，但这种关注不象白盒那样详细、完整，只是通过一些表征性的现象、事件、标志来判断内部的运行状态，有时候输出是正确的，但内部其实已经错误了，这种情况非常多，如果每次都通过白盒测试来操作，效率会很低，因此需要采取这样的一种灰盒的方法,软件测试技术的发展趋势：（1）软件验证技术（2）静态测试分析技术（3）测试数据的选择主要对测试用例进行选择 通常从下面几个方面评价测试用例的质量：检测软件缺陷的有效性、测试用例的可重用性、测试用例的经济性、测试用例的可维护性（4）集成化测试研究如何实现软件测试的自动化过程以及相关的一系列内容。,软件测试方法的分类,按照软件测试用例的设计方法而论，软件测试可分为白盒测试法和黑盒测试法；按照软件测试是否执行程序而论，软件测试又可以分为静态测试和动态测试；按照软件设计方法是否采用面向对象设计技术而论，软件测试又可以分为传统测试方法和面向对象测试方法；按照网络环境下C/S应用结构的特定环境而论，软件测试又有其相应的方法。这些都是软件测试具体的测试方法。,静态测试与动态测试,1、静态测试静态测试不实际运行软件，主要是对软件的编程格式、结构等方面进行评估。静态测试包括代码检查、静态结构分析、代码质量度量 等。它可以由人工进行，也可以借助软件工具自动进行。静态测试方法也可利用计算机作为对被测程序进行特性分析的工具，但与人工测试方式有着根本区别。另一方面，因它并不真正运行被测程序，只进行特性分析，这又与动态方法不同。所以，静态方法常常称为“分析”，静态测试是对被测程序进行特性分析方法的总称。,静态测试与动态测试（续）,代码检查代码检查包括代码走查、桌面检查、代码审查等，主要检查代码和设计的一致性，代码对标准的遵循、可读性，代码的逻辑表达的正确性，代码结构的合理性等方面。代码检查的具体内容：变量检查、命名和类型审查、程序逻辑审查、程序语法检查和程序结构检查等。代码检查的优点：在实际使用中，代码检查比动态测试更有效率，能快速找到缺陷，发现30%70%的逻辑设计和编码缺陷；代码检查看到的是问题本身而非征兆。代码检查的缺点：非常耗费时间，而且代码检查需要知识和经验的积累。,静态测试与动态测试（续）,静态结构分析静态结构分析主要是以图形的方式表现程序的内部结构。例如函数调用关系图、函数内部控制流图。其中：函数调用关系图以直观的图形方式描述一个应用程序中各个函数的调用和被调用关系；控制流图显示一个函数的逻辑结构，由许多节点组成，一个节点代表一条语句或数条语句，连接结点的叫边，边表示节点间的控制流向。,静态测试与动态测试（续）,代码质量度量软件质量包括六个方面：功能性、可靠性、易用性、效率、可维护性和可移植性。软件的质量是软件属性的各种标准度量的组合。针对软件的可维护性，目前业界主要存在三种度量参数：Line复杂度、Halstead复杂度和McCabe复杂度。其中Line复杂度以代码的行数作为计算的基准。Halstead以程序中使用到的运算符与运算元数量作为计数目标（直接测量指标），然后可以据以计算出程序容量、工作量等。McCabe复杂度 一般称为圈复杂度，它将软件的流程图转化为有向图，然后以图论来衡量软件的质量。,静态测试与动态测试（续）,静态测试阶段的任务：（1）检查算法的逻辑正确性。（2）检查模块接口的正确性。（3）检查输入参数是否有合法性检查。（4）检查调用其他模块的接口是否正确。（5）检查是否设置了适当的出错处理。（6）检查表达式、语句是否正确，是否含有二义性。（7）检查常量或全局变量使用是否正确。（8）检查标识符的使用是否规范、一致。（9）检查程序风格的一致性、规范性。（10）检查代码是否可以优化，算法效率是否最高。（11）检查代码注释是否完整，是否正确反映了代码的功能。,静态测试与动态测试（续）,静态测试可以完成以下工作：（1）发现下列程序的错误：错用局部变量和全局变量；未定义的变量、不匹配的参数；不适当的循环嵌套或分支嵌套、死循环、不允许的递归；调用不存在的子程序，遗漏标号或代码。（2）找出以下问题的根源：从未使用过的变量；不会执行到的代码、从未使用过的标号；潜在的死循环。（3）提供程序缺陷的间接信息：所用变量和常量的交叉应用表；是否违背编码规则；标识符的使用方法和过程的调用层次。（4）为进一步查找做好准备。（5）选择测试用例。（6）进行符号测试。,静态测试与动态测试（续）,2、动态测试动态方法的主要特征是：计算机必须真正运行被测试的程序，通过输入测试用例，对其运行情况即输入与输出的对应关系进行分析，以达到检测的目的。动态测试包括：（1）功能确认与接口测试（2）覆盖率分析（3）性能分析（4）内存分析,黑盒测试和白盒测试,若测试规划是基于产品的功能，目的是检查程序各个功能是否能够实现，并检查其中的功能错误，则这种测试方法称为黑盒测试(Black-box Testing)方法。黑盒测试又称为功能测试、数据驱动测试和基于规格说明的测试。它是一种从用户观点出发的测试，一般被用来确认软件功能的正确性和可操作性。若测试规划基于产品的内部结构进行测试，检查内部操作是否按规定执行，软件各个部分功能是否得到充分使用，则这种测试方法称为白盒测试(White-box Testing)方法。白盒测试又称为结构测试、逻辑驱动测试或基于程序的测试，一般用来分析程序的内部结构。,黑盒测试和白盒测试（续）,两种测试方法从完全不同的角度出发，反映了测试思路的两方面情况，适用于不同的测试阶段。,黑盒测试和白盒测试（续）,1、黑盒测试黑盒测试的基本观点是：任何程序都可以看作是从输入定义域映射到输出值域的函数过程，被测程序被认为是一个打不开的黑盒子，黑盒中的内容（实现过程）完全不知道，只明确要做到什么。黑盒测试主要根据规格说明书设计测试用例，并不涉及程序内部构造和内部特性，只依靠被测程序输入和输出之间的关系或程序的功能设计测试用例。黑盒测试的特点：（1）黑盒测试与软件的具体实现过程无关，在软件实现的过程发生变化时，测试用例仍然可以使用。（2）黑盒测试用例的设计可以和软件实现同时进行，这样能够压缩总的开发时间。,黑盒测试和白盒测试（续）,黑盒测试和白盒测试（续）,黑盒测试主要是为了发现以下几类错误：是否有不正确或遗漏了的功能？在接口上，输入能否正确地接受？能否输出正确的结果？是否有数据结构错误或外部信息访问错误？性能上是否能够满足要求？是否有初始化或终止性错误？黑盒测试的难点：在哪个层次上进行测试？黑盒测试的具体技术方法：边界值分析法 等价类划分法 因果图法 错误猜想法 决策表法,黑盒测试和白盒测试（续）,2、白盒测试白盒测试将被测程序看作一个打开的盒子，测试者能够看到被测源程序，可以分析被测程序的内部结构，此时测试的焦点集中在根据其内部结构设计测试用例。白盒测试要求是对某些程序的结构特性做到一定程度的覆盖，或者说这种测试是“基于覆盖率的测试”。通常的程序结构覆盖有：语句覆盖 判定覆盖 条件覆盖 判定/条件覆盖 路径覆盖,黑盒测试和白盒测试（续）,黑盒测试和白盒测试（续）,3、黑盒测试法和白盒测试法的比较,黑盒测试和白盒测试（续）,黑盒测试：以用户的观点，从输入数据与输出数据的对应关系，即根据程序外部特性进行测试，而不考虑内部结构及工作情况。黑盒测试技术注重于软件的信息域（范围），通过划分程序的输入和输出域来确定测试用例。若外部特性本身存在问题或规格说明的规定有误，则应用黑盒测试方法是不能发现问题的。白盒测试：只根据程序的内部结构进行测试。测试用例的设计要保证测试时程序的所有语句至少执行一次，而且要检查所有的逻辑条件。如果程序的结构本身有问题，比如说程序逻辑有错误或者有遗漏，那也是无法发现的。,黑盒测试和白盒测试（续）,测试模型,V模型 W模型 H模型 X模型,V模型图,W模型图,H模型图,在整个生产周期中某个层次上的一次测试“微循环”。图中的其他流程图可以是任意开发流程。例如，设计流程和编码流程。也可以是其他非开发流程，例如，SQA流程，甚至是测试流程本身。只要测试条件成熟了，测试准备活动完成了，测试执行活动就可以进行了,X模型,X模型是由Marick提出的 X模型描述的是针对单独程序片段所进行的相互分离的编码和测试，此后将进行频繁的交换，通过集成最终合成为可执行的程序。X模型是一种探索测试模型,X模型图,8.3 测试用例的设计,如何以最少的人力、资源投入，在最短的时间内完成测试，发现软件系统的缺陷，保证软件的优良品质，则是软件测试探索和追求的目标。测试用例是测试工作的指导，是软件测试的必须遵守的准则。更是软件测试质量稳定的根本保障。,什么是测试用例,所谓的测试用例就是将软件测试的行为活动，做一个科学化的组织归纳。软件测试是有组织性、步骤性和计划性的，而设计软件测试用例的目的，就是为了能将软件测试的行为转换为可管理的模式。软件测试是软件质量管理中最实际的行动，同时也是耗时最多的一项。基于时间因素的考虑，软件测试行为必须能够加以量化，才能进一步让管理阶层掌握所需要的测试过程，而测试用例就是将测试行为具体量化的方法之一。,什么是测试用例,因为我们不可能进行穷举测试，为了节省时间和资源、提高测试效率，必须要从数量极大的可用测试数据中精心挑选出具有代表性或特殊性的测试数据来进行测试。目前研究室测试过程中，所有的测试用例都放在测试大纲中，使用测试大纲的好处：保证测试功能不被遗漏；使得功能不被重复测试，合理安排测试人员；使得软件测试不依赖于个人；,测试用例内容,实施一次测试而向被测系统提供的输入数据、操作或各种环境设置。对交互式系统，软件交互执行过程的控制也是一种测试用例。测试用例的设计与生成是依据测试大纲对其中每个测试项目的进一步实例化。比如：对于一个输入项的测试，应当设计一组测试数据，包括合法的、边界的和非法的数据等。,测试用例设计生成的基本准则,测试用例的代表性：能够代表并覆盖各种合理的和不合理、合法的和非法的、边界的和越界的、以及极限的输入数据、操作和环境设置等;测试结果的可判定性：即测试执行结果的正确性是可判定的，每一个测试用例都应有相应的期望结果；测试结果的可再现性：即对同样的测试用例，系统的执行结果应当是相同的。,测试用例的特征,最有可能抓住错误的；不是重复的、多余的；一组相似测试用例中最有效的；不要太简单，也不要太复杂。,测试用例的组织和跟踪,在执行测试过程中，会遇到如下问题：计划执行哪些测试用例？执行需要多少时间？一轮测试需要多少测试人员？能否挑出测试套装（相关测试用例子集）来测试某些特性或软件部分？在执行测试用例时，能否记录哪些通过？哪些失败；当前测试是否按计划进行？上次执行测试用例时通过的百分比是多少？测试用例跟踪管理方式：测试用例追踪表,测试用例的意义,使用测试用例的好处主要体现在以下几个方面：在开始实施测试之前设计好测试用例，可以避免盲目测试并提高测试效率。测试用例的使用令软件测试的实施重点突出、目的明确。在软件版本更新后只需修正少部分的测试用例便可展开测试工作，降低工作强度、缩短项目周期。功能模块的通用化和复用化使软件易于开发，而相对于功能模块的测试用例的通用化和复用化则会使软件测试易于开展，并随着测试用例的不断精化其效率也不断攀升。,测试用例的意义,组织性有利于测试的组织；功能覆盖确保功能不被遗漏；重复性有利于测试的重复；跟踪有利于测试的跟踪；测试确认在少数高风险的测试中，必须证明确实执行了计划执行的测试；,8.3.1 白盒测试方法,为什么要进行白盒测试？如果所有软件错误的根源都可以追溯到某个唯一原因，那么问题就简单了。然而，事实上一个bug 常常是由多个因素共同导致的，如下图所示。,假设此时开发工作已结束，程序送交到测试组，没有人知道代码中有一个潜在的被 0 除的错误。若测试组采用的测试用例的执行路径没有同时经过x=0和y=5/x进行测试，显然测试工作似乎非常完善，测试用例覆盖了所有执行语句，也没有被 0 除的错误发生。,白盒测试方法（续）,白盒测试也称结构测试或逻辑驱动测试，是针对被测单元内部是如何进行工作的测试。它根据程序的控制结构设计测试用例，主要用于软件或程序验证。白盒测试法检查程序内部逻辑结构，对所有逻辑路径进行测试，是一种穷举路径的测试方法。但即使每条路径都测试过了，仍然可能存在错误。因为：穷举路径测试无法检查出程序本身是否违反了设计规范，即程序是否是一个错误的程序。穷举路径测试不可能查出程序因为遗漏路径而出错。穷举路径测试发现不了一些与数据相关的错误。,白盒测试方法（续）,采用白盒测试方法必须遵循以下几条原则，才能达到测试的目的：保证一个模块中的所有独立路径至少被测试一次。所有逻辑值均需测试真(true)和假(false)两种情况。检查程序的内部数据结构，保证其结构的有效性。在上下边界及可操作范围内运行所有循环。白盒测试主要是检查程序的内部结构、逻辑、循环和路径。常用测试用例设计方法有：逻辑覆盖法（逻辑驱动测试）基本路径测试方法,8.3.1.1 白盒测试的基本概念,控制流图环形复杂度图矩阵,控制流图,控制流图（可简称流图）是对程序流程图进行简化后得到的，它可以更加突出的表示程序控制流的结构。控制流图中包括两种图形符号：节点和控制流线。节点由带标号的圆圈表示，可代表一个或多个语句、一个处理框序列和一个条件判定框（假设不包含复合条件）。控制流线由带箭头的弧或线表示，可称为边。它代表程序中的控制流。对于复合条件，则可将其分解为多个单个条件，并映射成控制流图。,常见结构的控制流图,常见结构的控制流图,其中，包含条件的节点被称为判定节点（也叫谓词节点），由判定节点发出的边必须终止于某一个节点，由边和节点所限定的范围被称为区域。,环形复杂度,环形复杂度也称为圈复杂度，它是一种为程序逻辑复杂度提供定量尺度的软件度量。环形复杂度的应用可以将环形复杂度用于基本路径方法，它可以提供：程序基本集的独立路径数量；确保所有语句至少执行一次的测试数量的上界。独立路径是指程序中至少引入了一个新的处理语句集合或一个新条件的程序通路。采用流图的术语，即独立路径必须至少包含一条在本次定义路径之前不曾用过的边。测试可以被设计为基本路径集的执行过程，但基本路径集通常并不唯一。,计算环形复杂度的方法,环形复杂度以图论为基础，为我们提供了非常有用的软件度量。可用如下三种方法之一来计算环形复杂度：控制流图中区域的数量对应于环形复杂度。给定控制流图G的环形复杂度V(G)，定义为 V(G)=E-N+2 其中，E是控制流图中边的数量，N是控制流图中的节点数量。给定控制流图G的环形复杂度V(G)，也可定义为 V(G)=P+1 其中，P是控制流图G中判定节点的数量。,图矩阵,图矩阵是控制流图的矩阵表示形式。图矩阵是一个方形矩阵，其维数等于控制流图的节点数。矩阵中的每列和每行都对应于标识的节点，矩阵元素对应于节点间的边。通常，控制流图中的结点用数字标识，边则用字母标识。如果在控制流图中从第 i 个结点到第 j 个结点有一个标识为 x 的边相连接，则在对应图矩阵的第 i 行第 j 列有一个非空的元素 x。,8.3.1.2 覆盖测试,测试覆盖率逻辑覆盖法面向对象的覆盖测试覆盖准则,测试覆盖率,测试覆盖率：用于确定测试所执行到的覆盖项的百分比。其中的覆盖项是指作为测试基础的一个入口或属性，比如语句、分支、条件等。测试覆盖率可以表示出测试的充分性，在测试分析报告中可以作为量化指标的依据，测试覆盖率越高效果越好。但覆盖率不是目标，只是一种手段。测试覆盖率包括功能点覆盖率和结构覆盖率：功能点覆盖率大致用于表示软件已经实现的功能与软件需要实现的功能之间的比例关系。结构覆盖率包括语句覆盖率、分支覆盖率、循环覆盖率、路径覆盖率等等。,逻辑覆盖法,根据覆盖目标的不同，逻辑覆盖又可分为语句覆盖、判定覆盖、条件覆盖、判定/条件覆盖、组合覆盖和路径覆盖。语句覆盖：选择足够多的测试用例，使得程序中的每个可执行语句至少执行一次。判定覆盖：通过执行足够的测试用例，使得程序中的每个判定至少都获得一次“真”值和“假”值，也就是使程序中的每个取“真”分支和取“假”分支至少均经历一次，也称为“分支覆盖”。条件覆盖：设计足够多的测试用例，使得程序中每个判定包含的每个条件的可能取值（真/假）都至少满足一次。,逻辑覆盖法（续）,判定/条件覆盖：设计足够多的测试用例，使得程序中每个判定包含的每个条件的所有情况（真/假）至少出现一次，并且每个判定本身的判定结果（真/假）也至少出现一次。满足判定/条件覆盖的测试用例一定同时满足判定覆盖和条件覆盖。组合覆盖：通过执行足够的测试用例，使得程序中每个判定的所有可能的条件取值组合都至少出现一次。满足组合覆盖的测试用例一定满足判定覆盖、条件覆盖和判定/条件覆盖。路径覆盖：设计足够多的测试用例，要求覆盖程序中所有可能的路径。,逻辑覆盖法（续）,逻辑覆盖法（续）,void DoWork(int x,int y,int z)int k=0,j=0;if(x3)/语句块3,逻辑覆盖法（续）,语句覆盖,要实现DoWork函数的语句覆盖，只需设计一个测试用例就可以覆盖程序中的所有可执行语句。测试用例输入为：x=4、y=5、z=5 程序执行的路径是：abd分析：语句覆盖可以保证程序中的每个语句都得到执行，但发现不了判定中逻辑运算的错误，即它并不是一种充分的检验方法。例如在第一个判定(x3)&(z10)中把“&”错误的写成了“|”，这时仍使用该测试用例，则程序仍会按照流程图上的路径abd执行。可以说语句覆盖是最弱的逻辑覆盖准则。,判定覆盖,要实现DoWork函数的判定覆盖，需要设计两个测试用例。测试用例的输入为：x=4、y=5、z=5；x=2、y=5、z=5程序执行的路径分别是：abd；ace分析：上述两个测试用例不仅满足了判定覆盖，同时还做到语句覆盖。从这点看似乎判定覆盖比语句覆盖更强一些，但仍然无法确定判定内部条件的错误。例如把第二个判定中的条件y5错误写为y5，使用上述测试用例，照样能按原路径执行而不影响结果。因此，需要有更强的逻辑覆盖准则去检验判定内的条件。,判定覆盖（续）,说明：以上仅考虑了两出口的判断，我们还应把判定覆盖准则扩充到多出口判断（如Case语句）的情况。因此，判定覆盖更为广泛的含义应该是使得每一个判定获得每一种可能的结果至少一次。,条件覆盖,在实际程序代码中，一个判定中通常都包含若干条件。条件覆盖的目的是设计若干测试用例，在执行被测程序后，要使每个判定中每个条件的可能值至少满足一次。对DoWork函数的各个判定的各种条件取值加以标记。对于第一个判定(x3)&(z3 取真值记为T1，取假值记为-T1 条件z5)：条件x=4 取真值记为T3，取假值记为-T3 条件y5 取真值记为T4，取假值记为-T4,条件覆盖（续）,根据条件覆盖的基本思想，要使上述4个条件可能产生的8种情况至少满足一次，设计测试用例如下：,分析：上面这组测试用例不但覆盖了4个条件的全部8种情况，而且将两个判定的4个分支b、c、d、e也同时覆盖了，即同时达到了条件覆盖和判定覆盖。,条件覆盖（续）,说明：虽然前面的一组测试用例同时达到了条件覆盖和判定覆盖，但是，并不是说满足条件覆盖就一定能满足判定覆盖。如果设计了下表中的这组测试用例，则虽然满足了条件覆盖，但只是覆盖了程序中第一个判定的取假分支c 和第二个判定的取真分支d，不满足判定覆盖的要求。,判定/条件覆盖,判定/条件覆盖实际上是将判定覆盖和条件覆盖结合起来的一种方法，即：设计足够的测试用例，使得判定中每个条件的所有可能取值至少满足一次，同时每个判定的可能结果也至少出现一次。根据判定/条件覆盖的基本思想，只需设计以下两个测试用例便可以覆盖4个条件的8种取值以及4个判定分支。,判定/条件覆盖（续）,分析：从表面上看，判定/条件覆盖测试了各个判定中的所有条件的取值，但实际上，编译器在检查含有多个条件的逻辑表达式时，某些情况下的某些条件将会被其它条件所掩盖。因此，判定/条件覆盖也不一定能够完全检查出逻辑表达式中的错误。例如：对于第一个判定(x3)&(z3和z3为假，则编译器将不再检查z5)来说，若条件x=4满足，就认为该判定为真，这时将不会再检查y5，那么同样也无法发现这个条件中的错误。,组合覆盖,组合覆盖的目的是要使设计的测试用例能覆盖每一个判定的所有可能的条件取值组合。对DoWork函数中的各个判定的条件取值组合加以标记：1、x3,z3,z=10 记做T1-T2，第一个判定的取假分支 3、x=10 记做-T1-T2，第一个判定的取假分支 5、x=4,y5 记做T3 T4，第二个判定的取真分支 6、x=4,y5 记做-T3 T4，第二个判定的取真分支 8、x!=4,y=5 记做-T3-T4，第二个判定的取假分支,组合覆盖（续）,根据组合覆盖的基本思想，设计测试用例如下：,分析：上面这组测试用例覆盖了所有8种条件取值的组合，覆盖了所有判定的真假分支，但是却丢失了一条路径abe。,路径覆盖,前面提到的5种逻辑覆盖都未涉及到路径的覆盖。事实上，只有当程序中的每一条路径都受到了检验，才能使程序受到全面检验。路径覆盖的目的就是要使设计的测试用例能覆盖被测程序中所有可能的路径。根据路径覆盖的基本思想，在满足组合覆盖的测试用例中修改其中一个测试用例，则可以实现路径覆盖：,路径覆盖（续）,分析：虽然前面一组测试用例满足了路径覆盖，但并没有覆盖程序中所有的条件组合（丢失了组合3和7），即满足路径覆盖的测试用例并不一定满足组合覆盖。说明：对于比较简单的小程序，实现路径覆盖是可能做到的。但如果程序中出现较多判断和较多循环，可能的路径数目将会急剧增长，要在测试中覆盖所有的路径是无法实现的。为了解决这个难题，只有把覆盖路径数量压缩到一定的限度内，如程序中的循环体只执行一次。在实际测试中，即使对于路径数很有限的程序已经做到路径覆盖，仍然不能保证被测试程序的正确性，还需要采用其他测试方法进行补充。,习题,为以下流程图所示的程序段设计一组测试用例，要求分别满足语句覆盖、判定覆盖、条件覆盖、判定/条件覆盖、组合覆盖和路径覆盖。,面向对象的覆盖,继承上下文覆盖由于传统的结构化度量没有考虑面向对象的一些特性（如多态、继承和封装等），所以在面向对象领域，传统的结构化覆盖必须被加强，以满足面向对象特性。继承上下文覆盖考虑在每个类的上下文内获得的覆盖率级别。它是扩展到面向对象领域里的一种覆盖率度量方法，用于度量在系统中的多态调用被测试得多好。继承上下文定义将基类上下文内例行程序的执行作为独立于继承类上下文内例行程序的执行。同样，它们在考虑继承类上下文内例行程序的执行也独立于基类上下文内例行程序的执行。为了获得100继承上下文覆盖，代码必须在每个适当的上下文内被完全执行。,面向对象的覆盖（续）,基于状态的上下文覆盖在绝大多数面向对象的系统中存在这样的一些类：这些类的对象可以存在于众多不同状态中的任何一种，并且由于类的行为依赖于状态，每个类的行为在每个可能的状态中其性质是