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

第八章第八章第八章第八章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 跨世纪跨世纪“千年虫千年虫”问题问题 案例案例4 爱国者导弹防御系统炸死自家人爱国者导弹防御系统炸死自家人 系统时钟误差积累系统时钟误差积累 案例案例5 英特尔奔腾浮点除法英特尔奔腾浮点除法上述所有实例中的软件问题在软件工程或软件测试中都被称为上述所有实例中的软件问题在软件工程或软件测试中都被称为软件软件缺陷或软件故障缺陷或软件故障。软件缺陷与故障（续）（续）2、软件缺陷的定义、软件缺陷的定义（1）软件未达到产品说明书中已经标明的功能；）软件未达到产品说明书中已经标明的功能；（2）软件出现了产品说明书中指明不会出现的错误；）软件出现了产品说明书中指明不会出现的错误；（3）软件未达到产品说明书中虽未指出但应当达到的目标；软件未达到产品说明书中虽未指出但应当达到的目标；（4）软件功能超出了产品说明书中指明的范围；软件功能超出了产品说明书中指明的范围；（5）软件测试人员认为软件难以理解、不易使用，或者最终软件测试人员认为软件难以理解、不易使用，或者最终用户认为该软件使用效果不良。用户认为该软件使用效果不良。软件缺陷与故障（续）（续）3、软件缺陷的特征、软件缺陷的特征“看不到看不到”软件的特殊性决定了缺陷不易看到软件的特殊性决定了缺陷不易看到“看到但是抓不到看到但是抓不到”发现发现了缺陷，但不易找到了缺陷，但不易找到问题发问题发生的原因生的原因所在所在8.1.2 软件缺陷产生的原因 软件缺陷的主要类型软件缺陷的主要类型/现象：现象：p 功能、特性没有实现或部分实现功能、特性没有实现或部分实现p 设计不合理，存在缺陷设计不合理，存在缺陷p 实际结果和预期结果不一致实际结果和预期结果不一致p 运行出错，包括运行中断、系统崩溃、界面混乱运行出错，包括运行中断、系统崩溃、界面混乱p 数据结果不正确、精度不够数据结果不正确、精度不够p 用户不能接受的其他问题，如存取时间过长、界用户不能接受的其他问题，如存取时间过长、界面不美观面不美观 常见导致错误的根源缺乏有效的沟通，或者没有进行沟通；软件复杂度不断变更的需求时间的压力缺乏文档的代码软件开发工具其他其他10%软件产品说明软件产品说明书（需求）书（需求）56%编写代码编写代码7%设设 计计27%图图8-1 8-1 软件缺陷产生的原因分布软件缺陷产生的原因分布软件缺陷产生的原因有很多，但最主要的原因要归咎于产品描述软件缺陷产生的原因有很多，但最主要的原因要归咎于产品描述8.2 软件测试基础概念8.2.1 软件测试的定义8.2.2 软件测试的基本概念8.2.3 软件测试方法与策略8.2.1 8.2.1 软件测试定义软件测试定义 软软件件测测试试是是一一个个贯贯彻彻于于软软件件开开发发过过程程始始终终的的过过程程，是是为为了了发发现现错错误误而而执执行行程程序序的的过过程程，是是根根据据软软件件开开发发各各阶阶段段的的规规格格说说明明和和程程序序的的内内部部结结构构结结构构而而精精心心设计一批测试用例。设计一批测试用例。什么是软件测试什么是软件测试l使用人工或者自动手段来运行使用人工或者自动手段来运行或测定某个或测定某个系统系统的过程的过程l目的在于检验它是否满足规定的需求、弄目的在于检验它是否满足规定的需求、弄清预期结果与实际结果之间清预期结果与实际结果之间的差别的差别l可简述为：按照特定规程，发现软件错误可简述为：按照特定规程，发现软件错误的过程的过程软件测试定义（续）软件测试定义（续）1.软件测试的目的l软件测试的目标是以最少的时间和人力，系统的找出软件测试的目标是以最少的时间和人力，系统的找出软件中潜在的各种错误和缺陷软件中潜在的各种错误和缺陷l测试测试是为了是为了发现程序中发现程序中的错误而执行程序的错误而执行程序的过程的过程l好的好的测试方案（测试用例）在于测试方案（测试用例）在于尽可能发现迄今为止尽可能发现迄今为止尚未发现尚未发现的错误的错误l成功的测试是发现了至今为止尚未发现的错误的测试成功的测试是发现了至今为止尚未发现的错误的测试8.2.2 8.2.2 8.2.2 8.2.2 软件测试基本概念软件测试基本概念软件测试基本概念软件测试基本概念软件测试目的（续）l测试并不仅仅是为了找出错误测试并不仅仅是为了找出错误.通过分析错误产生通过分析错误产生的原因和错误的发生趋势的原因和错误的发生趋势,可以帮助项目管理者发可以帮助项目管理者发现当前软件开发过程中的缺陷现当前软件开发过程中的缺陷,以便以便及时改进；及时改进；l这种分析也能帮助测试人员设计出有针对性的测试这种分析也能帮助测试人员设计出有针对性的测试方法方法,改善测试的效率和改善测试的效率和有效性；有效性；l没有发现错误的测试也是有价值的没有发现错误的测试也是有价值的,完整的测试是完整的测试是评定软件质量的一评定软件质量的一种方法种方法软件测试员的目标发现软件缺陷2.软件测试的目标最终目的是确保软件的功能符合用户的需求，把尽可能多的问题在发布或交付前发现并改正：-确保软件完成了它所承诺或公布的功能（缺少规范的书面文档？）-确保软件满足性能的要求（界面、操作、性能）-确保软件是健壮的和适应用户环境的（哪怕不健壮，也要给出解决方案）2.软件测试的目标为软件的质量评估提供依据（项目验收）为软件质量改进和管理提供帮助（经验教训等知识转移）软件测试的生命周期需求规格说明设计缺陷分类缺陷解决缺陷隔离测试编码错误错误错误错误修复事故缺陷缺陷缺陷3.软件测试的特性l软件测试与分析、设计、编码等工作相比，具有若干软件测试与分析、设计、编码等工作相比，具有若干特殊的性质：特殊的性质：挑剔性挑剔性。测试是一种。测试是一种“挑剔性挑剔性”行为，以证明程序有错行为，以证明程序有错的目的去进行测试，才能把程序中潜在的错误找出来。的目的去进行测试，才能把程序中潜在的错误找出来。复杂性复杂性。设计测试用例是一项需要细致和高度技巧的工。设计测试用例是一项需要细致和高度技巧的工作。作。不彻底性不彻底性。测试只能证明软件中存在错误，不能证明软。测试只能证明软件中存在错误，不能证明软件中不存在错误所谓彻底测试，也就是穷举测试，显然件中不存在错误所谓彻底测试，也就是穷举测试，显然在实际测试中无法实现或行不通。在实际测试中无法实现或行不通。经济性经济性。降低测试成本，应遵守的经济性原则：一，根。降低测试成本，应遵守的经济性原则：一，根据程序的重要性和一旦发生故障将造成的损失来确定他据程序的重要性和一旦发生故障将造成的损失来确定他的可靠性等级，不要随意提高等级使测试成本增加；二，的可靠性等级，不要随意提高等级使测试成本增加；二，要认真研究测试策略，以便使用尽可能少的测试用例来要认真研究测试策略，以便使用尽可能少的测试用例来发现尽可能多的程序错误。发现尽可能多的程序错误。l 为保证测试质量，软件测试必须完成规定的文档。按照软件工程的要求，测试文档应包括测试计划和测试报告两方面内容。l 测试计划的主体是“测试内容说明”。它包括测试项目名称，各项测试的目的、步骤和进度，以及测试用例的设计等。l 测试报告的主体是“测试结果”，它包括测试项目名称，实测结果与期望结果的比较，发现的问题，以及测试达到的效果。4.软件测试的文档测试用例测试用例=测试数据测试数据+期望结果期望结果测试结果测试结果=测试数据测试数据+期望结果期望结果+实际结果实际结果软件测试国家标准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软件工程 产品质量第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 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:一种权衡投入/产出比的原则：选择测试保证测试的覆盖程度，但穷举测试是不可能的：有限测试所有的测试都应追溯到用户需求越早测试越好，测试过程与开发过程应是相结合的测试的规模由小而大，从单元测试到系统测试为了尽可能地发现错误，应该由独立的第三方来测试不能为了便于测试擅自修改程序既应该测试软件该做什么也应该测试软件不该做什么传统的瀑布模型中软件测试学仅处于运行维护阶段之前项目规划阶段：负责从单元测试到系统测试的整个测 试阶段的监控。需求分析阶段：确定测试需求分析、系统测试计划的 制定、评审后成为管理项目。详细设计和概要设计阶段：确保集成测试计划和单元 测试计划完成。编码阶段：由开发人员进行自己负责部分的测试代码。在项目较大时，由专人进行编码阶段的测 试任务。测试阶段：依据测试代码进行测试，并提交相应的测 试状态报告和测试结束报告。6、测试在开发各阶段的作用、测试在开发各阶段的作用图8-2 完整的开发流程项目规划项目规划项目需求分析项目需求分析项目概要分析项目概要分析项目详细分析项目详细分析代码编写代码编写测试代码编写测试代码编写测试需求分析测试需求分析系统测试计划系统测试计划集成测试计划集成测试计划单元测试计划单元测试计划产品发布产品发布系统测试系统测试集成测试集成测试单元测试单元测试7 7、完整的软件开发流程、完整的软件开发流程8.8.软件测试和缺陷修复的代价软件测试和缺陷修复的代价软件在从需求、设计、编码、测试一直到交付用户公开使用后的过程中，都有可能产生和发现缺陷。随着整个开发过程的时间推移，更正缺陷或修复问题的费用呈几何级数增长。图8-3 软件缺陷在不同阶段发现时修复的费用示意图0 02020404060608080100100编制说明书编制说明书设计阶段设计阶段编写代码编写代码测试测试发布发布软件测试是有风险的行为 如果决定如果决定不去测试不去测试所有的情所有的情况，那就况，那就是选择了是选择了风险风险 。软件缺陷的寄生虫性找到的软件缺陷越多，就说明软件缺陷越多找到的软件缺陷越多，就说明软件缺陷越多原因：程序员的疲倦程序员往往犯同样的错误某些软件的缺陷其实是大灾难的征兆软件测试的杀虫剂现象软件测试越多，其免疫力越强的现象软件测试越多，其免疫力越强的现象克服方法：不断编写不同的新的测试程序对程序的不同部分进行测试软件测试的不修复原则并非所有并非所有软件软件缺陷都能修复缺陷都能修复不需要修复软件缺陷的原因：没有足够的时间不算真正的软件缺陷修复的风险太大不值得修复Pareto原则 Pareto原则暗原则暗示着测试发现示着测试发现的错误中的的错误中的80%很可能起很可能起源于程序模块源于程序模块中的中的20%。软件测试中的误区调试和测试是一样的；测试组应当为保证质量负责；把测试作为新员工的一个过渡工作；关注测试的执行而忽略测试的设计；测试自动化是万能的；测试是枯燥乏味，缺乏创造力的工作。8.2.3 软件测试方法与策略软件测试策略软件测试方法测试关键词静态测试与动态测试白盒测试与黑盒测试软件测试模型软件测试策略什么是软件测试策略？是为软件工程过程定义的一个软件测试的模板，也就是把特定的测试用例方法放置进去的一系列步骤。软件测试策略包含的特征：（1）测试从模块层开始，然后扩大延伸到整个基于计算机的系统集合中。（2）不同的测试技术适用于不同的时间点。（3）测试是由软件的开发人员和（对于大型系统而言）独立的测试组来管理的。（4）测试和调试是不同的活动，但是调试必须能够适应任何的测试策略。软件测试策略l测试信息流l分析设计阶段l需求说明书评测l概要设计说明书评测l详细设计说明书评测l软件编码规范评测l开发阶段l单元测试l集成测试l确认测试l系统测试l验收测试l软件验证和确认过程软件测试关键词l单元测试l集成测试l系统测试l确认测试l验收测试l白盒测试l黑盒测试l灰盒测试单元测试l单元测试又称模块测试l是针对软件设计的最小单元程序模块进行正确性检验的测试工作l其目的在于检查每个程序单元能否实 现详细设计说明中的模块功能、性能、接口和设计约束等要求，发现各模块内部可能存在的错误集成测试l集成测试，也叫组装测试或联合测试l在单元测试的基础上，将所有模块按照设计要求）如根据结构图组装成为子系统或系统，进行集成测试l集成测试是检验程序单元和部件的接口关系l实践表明，一些模块虽然能够单独地工作，但并不能保证连接起来也能正常的工作。程序在某些局部反映不出来的问题，在全局上很可能暴露出来，影响功能的实现系统测试l 系统测试是将已经确认的软件、计算机硬件、外设、网络等其他元素结合在一起，进行信息系统的各种组装测试和确认测试，其目的是通过与系统的需求相比较，发现所开发的系统与用户需求不符或矛盾的地方l 系统测试的任务是近可能彻底的检查出程序中的错误，提高软件系统的可靠性，其目的是检验系统做得怎样？确认测试l确认测试的目的是向未来的用户表明系统能够像预定要求那样工作。经集成测试后，已经按照设计把所有的模块组装成一个完整的软件系统，接口错误也已经基本排除了，接着就应该进一步验证软件的有效性，这就是确认测试的任务，即软件的功能和性能如同用户所合理期待的那样 l确认测试又称有效性测试。有效性测试是在模拟的环境下，运用黑盒测试的方法，验证被测软件是否满足需求规格说明书列出的需求。任务是验证软件的功能和性能及其他特性是否与用户的要求一致。对软件的功能和性能要求在软件需求规格说明书中已经明确规定，它包含的信息就是软件确认测试的基础验收测试l 系统开发生命周期方法论的一个阶段，这时相关的用户和或独立测试人员根据测试计划和结果对系统进行测试和接收。它让系统用户决定是否接收系统。它是一项确定产品是否能够满足合同或用户所规定需求的测试l 这是管理性和防御性控制的测试过程白盒测试l白盒测试也称结构测试或逻辑驱动测试，它是按照程序内部的结构测试程序，通过测试来检测产品内部动作是否按照设计规格说明书的规定正常进行，检验程序中的每条通路是否都能按预定要求正确工作l是把测试对象看作一个打开的盒子，测试人员依据程序内部逻辑结构相关信息，设计或选择测试用例，对程序所有逻辑路径进行测试，通过在不同点检查程序的状态，确定实际的状态是否与预期的状态一致黑盒测试l黑盒测试也称功能测试，它是通过测试来检测每个功能是否都能正常使用。l在测试地，把程序看作一个不能打开的黑盒子，在完全不考虑程序内部结构和内部特性的情况下，在程序接口进行测试，它只检查程序功能是否按照需求规格说明书的规定正常使用，程序是否能适当地接收输入数据而产生正确的输出信息。l黑盒测试着眼于程序外部结构，不考虑内部逻辑结构，主要针对软件界面和软件功能进行测试灰盒测试l 灰盒测试，确实是介于白盒测试与黑盒测试之间的测试l 灰盒测试关注输出对于输入的正确性，同时也关注内部表现，但这种关注不象白盒那样详细、完整，只是通过一些表征性的现象、事件、标志来判断内部的运行状态，有时候输出是正确的，但内部其实已经错误了，这种情况非常多，如果每次都通过白盒测试来操作，效率会很低，因此需要采取这样的一种灰盒的方法软件测试技术的发展趋势：软件测试技术的发展趋势：（1）软件验证技术（2）静态测试分析技术（3）测试数据的选择主要对测试用例进行选择 通常从下面几个方面评价测试用例的质量：检测软件缺陷的有效性、测试用例的可重用性、测试用例的经济性、测试用例的可维护性（4）集成化测试研究如何实现软件测试的自动化过程以及相关的一系列内容。软件测试方法的分类按照软件测试用例的设计方法而论，软件测试可分为白盒测试法和黑盒测试法；按照软件测试是否执行程序而论，软件测试又可以分为静态测试和动态测试；按照软件设计方法是否采用面向对象设计技术而论，软件测试又可以分为传统测试方法和面向对象测试方法；按照网络环境下C/S应用结构的特定环境而论，软件测试又有其相应的方法。这些都是软件测试具体的测试方法。静态测试与动态测试1、静态测试静态测试不实际运行软件，主要是对软件的编程格式、结构等方面进行评估。静态测试包括代码检查 、静态结构分析 、代码质量度量 等。它可以由人工进行，也可以借助软件工具自动进行。静态测试方法也可利用计算机作为对被测程序进行特性分析的工具，但与人工测试方式有着根本区别。另一方面，因它并不真正运行被测程序，只进行特性分析，这又与动态方法不同。所以，静态方法常常称为“分析”，静态测试是对被测程序进行特性分析方法的总称。静态测试与动态测试（续）（续）静态测试阶段的任务：（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、白盒测试白盒测试将被测程序看作一个打开的盒子，测试者能够看到被测源程序，可以分析被测程序的内部结构，此时测试的焦点集中在根据其内部结构设计测试用例。白盒测试要求是对某些程序的结构特性做到一定程度的覆盖，或者说这种测试是“基于覆盖率的测试”。通常的程序结构覆盖有：语句覆盖 判定覆盖 条件覆盖 判定/条件覆盖 路径覆盖黑盒测试和白盒测试（续）（续）白盒测试需要白盒测试需要白盒测试需要白盒测试需要完全了解程序结构和处理过程，完全了解程序结构和处理过程，完全了解程序结构和处理过程，完全了解程序结构和处理过程，它按照程序内部逻辑测试程序，检验程序中它按照程序内部逻辑测试程序，检验程序中它按照程序内部逻辑测试程序，检验程序中它按照程序内部逻辑测试程序，检验程序中每条通路是否按预定要求正确工作。每条通路是否按预定要求正确工作。每条通路是否按预定要求正确工作。每条通路是否按预定要求正确工作。也被称也被称也被称也被称为程序员测试。为程序员测试。为程序员测试。为程序员测试。应用程序应用程序黑盒测试和白盒测试（续）（续）？X=2 y=2x Y=4 X=2Y=4未知等式与已知等式黑盒黑盒白盒白盒3 3、黑盒测试法和白盒测试法的比较、黑盒测试法和白盒测试法的比较黑盒测试和白盒测试（续）（续）黑盒测试：以用户的观点，从输入数据与输出数据的对应关系，即根据程序外部特性进行测试，而不考虑内部结构及工作情况。黑盒测试技术注重于软件的信息域（范围），通过划分程序的输入和输出域来确定测试用例。若外部特性本身存在问题或规格说明的规定有误，则应用黑盒测试方法是不能发现问题的。白盒测试：只根据程序的内部结构进行测试。测试用例的设计要保证测试时程序的所有语句至少执行一次，而且要检查所有的逻辑条件。如果程序的结构本身有问题，比如说程序逻辑有错误或者有遗漏，那也是无法发现的。黑盒测试和白盒测试（续）（续）项目项目黑盒测试法黑盒测试法白盒测试法白盒测试法规划规划方面方面功能的测试功能的测试结构的测试结构的测试优点优点方面方面 能确保从用户的角度能确保从用户的角度出发进行测试出发进行测试 能对程序内部的特定部位进能对程序内部的特定部位进行覆盖测试行覆盖测试缺点缺点方面方面无法测试程序内部特无法测试程序内部特定部位；当规格说明有定部位；当规格说明有误，则不能发现问题误，则不能发现问题无法检查程序的外部特性；无法检查程序的外部特性；无法对未实现规格说明的程无法对未实现规格说明的程序内部欠缺部分进行测试序内部欠缺部分进行测试应用应用范围范围 边界分析法边界分析法 等价类划分法等价类划分法 因果图法因果图法 决策表测试决策表测试 语句覆盖，判定覆盖，语句覆盖，判定覆盖，条件覆盖，判定条件覆盖，判定/条件覆盖，条件覆盖，路径覆盖，循环覆盖，路径覆盖，循环覆盖，模块接口测试模块接口测试测试模型V模型 W模型 H模型 X模型V模型图W模型图H模型图 在整个生产周期中某个层次上的一次测试“微循环”。图中的其他流程图可以是任意开发流程。例如，设计流程和编码流程。也可以是其他非开发流程，例如，SQA流程，甚至是测试流程本身。只要测试条件成熟了，测试准备活动完成了，测试执行活动就可以进行了 X模型l X模型是由Marick提出的l X模型描述的是针对单独程序片段所进行的相互分离的编码和测试，此后将进行频繁的交换，通过集成最终合成为可执行的程序。l X模型是一种探索测试模型X模型图 8.3 测试用例的设计测试用例的设计如何以最少的人力、资源投入，在最短的时间内完成测试，发现软件系统的缺陷，保证软件的优良品质，则是软件测试探索和追求的目标。测试用例是测试工作的指导，是软件测试的必须遵守的准则。更是软件测试质量稳定的根本保障。什么是测试用例什么是测试用例所谓的测试用例就是将软件测试的行为活动，做一个科学化的组织归纳。软件测试是有组织性、步骤性和计划性的，而设计软件测试用例的目的，就是为了能将软件测试的行为转换为可管理的模式。软件测试是软件质量管理中最实际的行动，同时也是耗时最多的一项。基于时间因素的考虑，软件测试行为必须能够加以量化，才能进一步让管理阶层掌握所需要的测试过程，而测试用例就是将测试行为具体量化的方法之一。什么是测试用例什么是测试用例因为我们不可能进行穷举测试，为了节省时间和资源、提高测试效率，必须要从数量极大的可用测试数据中精心挑选出具有代表性或特殊性的测试数据来进行测试。目前研究室测试过程中，所有的测试用例都放在测试大纲中，使用测试大纲的好处：保证测试功能不被遗漏；使得功能不被重复测试，合理安排测试人员；使得软件测试不依赖于个人；测试用例内容测试用例内容实施一次测试而向被测系统提供的输入数据、操作或各种环境设置。对交互式系统，软件交互执行过程的控制也是一种测试用例。测试用例的设计与生成是依据测试大纲对其中每个测试项目的进一步实例化。比如：对于一个输入项的测试，应当设计一组测试数据，包括合法的、边界的和非法的数据等。测试用例设计生成的基本准则测试用例设计生成的基本准则测试用例的代表性：能够代表并覆盖各种合理的和不合理、合法的和非法的、边界的和越界的、以及极限的输入数据、操作和环境设置等;测试结果的可判定性：即测试执行结果的正确性是可判定的，每一个测试用例都应有相应的期望结果；测试结果的可再现性：即对同样的测试用例，系统的执行结果应当是相同的。测试用例的特征测试用例的特征最有可能抓住错误的；不是重复的、多余的；一组相似测试用例中最有效的；不要太简单，也不要太复杂。测试用例的组织和跟踪测试用例的组织和跟踪在执行测试过程中，会遇到如下问题：在执行测试过程中，会遇到如下问题：计划执行哪些测试用例？执行需要多少时间？一轮测试需要多少测试计划执行哪些测试用例？执行需要多少时间？一轮测试需要多少测试人员？人员？能否挑出测试套装（相关测试用例子集）来测试某些特性或软件部分能否挑出测试套装（相关测试用例子集）来测试某些特性或软件部分？在执行测试用例时，能否记录哪些通过？哪些失败；在执行测试用例时，能否记录哪些通过？哪些失败；当前测试是否按计划进行？当前测试是否按计划进行？上次执行测试用例时通过的百分比是多少？上次执行测试用例时通过的百分比是多少？测试用例跟踪管理方式：测试用例追踪表测试用例跟踪管理方式：测试用例追踪表测试用例的意义测试用例的意义使用测试用例的好处主要体现在以下几个方面：使用测试用例的好处主要体现在以下几个方面：在开始实施测试之前设计好测试用例，可以避免盲目测试并提高测试在开始实施测试之前设计好测试用例，可以避免盲目测试并提高测试效率。效率。测试用例的使用令软件测试的实施重点突出、目的明确。测试用例的使用令软件测试的实施重点突出、目的明确。在软件版本更新后只需修正少部分的测试用例便可展开测试工作，降在软件版本更新后只需修正少部分的测试用例便可展开测试工作，降低工作强度、缩短项目周期。低工作强度、缩短项目周期。功能模块的通用化和复用化使软件易于开发，而相对于功能模块的测功能模块的通用化和复用化使软件易于开发，而相对于功能模块的测试用例的通用化和复用化则会使软件测试易于开展，并随着测试用例试用例的通用化和复用化则会使软件测试易于开展，并随着测试用例的不断精化其效率也不断攀升。的不断精化其效率也不断攀升。测试用例的意义测试用例的意义组织性有利于测试的组织；组织性有利于测试的组织；功能覆盖确保功能不被遗漏；功能覆盖确保功能不被遗漏；重复性有利于测试的重复；重复性有利于测试的重复；跟踪有利于测试的跟踪；跟踪有利于测试的跟踪；测试确认在少数高风险的测试中，必须证明确实执行了测试确认在少数高风险的测试中，必须证明确实执行了计划执行的测试；计划执行的测试；8.3.1 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)&(z5)j=x*y+10;/语句块2 j=j%3;/语句块3逻辑覆盖法（续）（续）X3&z5执行语句块执行语句块3FFTTabdce语句覆盖要实现DoWork函数的语句覆盖，只需设计一个测试用例就可以覆盖程序中的所有可执行语句。测试用例输入为：x=4、y=5、z=5 程序执行的路径是：abd分析：语句覆盖可以保证程序中的每个语句都得到执行，但发现不了判定中逻辑运算的错误，即它并不是一种充分的检验方法。例如在第一个判定(x3)&(z5错误写为y3)&(z3 取真值记为T