软件测试过程方法

1、软件测试技术2.1 全过程的软件测试方法概述2.2 软件测试的过程简介2.3 单元测试过程技术2.4 集成测试过程技术2.5 系统测试过程技术2.6 其它测试过程技术第四章第四章 软件测试过程方法软件测试过程方法4.1 4.1 软件测试过程方法概述软件测试过程方法概述工程硕士4经典的瀑布模型-测试是亡羊补牢需求分析需求分析概要设计概要设计详细设计详细设计编码编码系统测试系统测试测试测试单元测试单元测试集成测试集成测试维护维护验收测试验收测试测试是软件开发的最后阶段。当测试发现了需求的问题时，可能导致工作产品的大量返工，产品交付将因此延期。而这种情况在实际的测试工作中经常发生。工程硕士5V模型-

2、全流程的测试思想需求规格说明书需求规格说明书评审评审概要设计说明书概要设计说明书详细设计说明书详细设计说明书编码编码单元测试单元测试集成测试集成测试系统测试系统测试系统测试文档系统测试文档集成测试文档集成测试文档单元测试文档单元测试文档评审评审评审评审评审评审评审评审评审评审工程硕士6V模型全过程软件测试的思想l在瀑布模型中，测试是软件开发过程的最后阶段，而在V模型中，软件测试从软件项目需求分析阶段开始，贯穿于整个软件开发过程活动中l测试人员可以尽早进入项目1.测试人员更加熟悉产品，对设计出高质量的测试用例非常有帮助2.更多缺陷将在早期被发现，这有利于大幅度降低成本l在项目后期发现严重缺陷的风

3、险大大降低l很多组织选用V模型作为项目的开发模型全过程测试软件过程规范示例工程硕士7业务计划制定业务计划制定产品计划（软件计划）产品计划（软件计划）产品规格制定产品规格制定需求分析（需求分析（SDPSDP优化）优化）概要设计概要设计详细设计详细设计实现和单元测试实现和单元测试集成测试（执行）集成测试（执行）系统测试（执行）系统测试（执行）验收测试（执行）验收测试（执行）产品维护产品维护单元测试参考详细设计集成测试参考概要设计系统测试参考需求规格说明书全过程测试软件过程规范示例工程硕士8l系统需求系统需求l制订业务计划制订业务计划l业务计划业务计划l系统需求系统需求l分配系统需求分配系统需求l软

4、件子系统需求软件子系统需求l验收测试项验收测试项l软件子系统需求软件子系统需求lSDPSDPl制订和确认制订和确认SVVPSVVPlSVVPSVVPl软件子系统需求软件子系统需求lSDPSDPlSVVPSVVPlSDPSDP优化优化l制订和确认系统测试计划制订和确认系统测试计划lSVVPSVVP优化优化l系统测试计划系统测试计划业务计划制定业务计划制定产品计划（软件计划）产品计划（软件计划）产品规格制定产品规格制定需求分析（需求分析（SDPSDP优化）优化）全过程测试软件过程规范示例工程硕士9l单元测试计划单元测试计划l集成测试方案集成测试方案l系统测试用例系统测试用例l系统预测试用例系统预测

5、试用例lSRSlSTPl编写系统编写系统 测试方案测试方案l制定和确认集成测试计划制定和确认集成测试计划l集成测试计划集成测试计划l系统测试方案系统测试方案概要设计概要设计l需求规格说明书需求规格说明书l概要设计说明书概要设计说明书l系统测试计划、方案系统测试计划、方案l集成测试计划集成测试计划l编写系统测试用例编写系统测试用例l编写系统预测试项编写系统预测试项l编写集成测试方案编写集成测试方案l制定和确认单元测试计划制定和确认单元测试计划l进行软件测试测试工具评估进行软件测试测试工具评估详细设计详细设计l需求规格说明书需求规格说明书l概要设计说明书概要设计说明书l详细设计说明书详细设计说明书

6、l系统测试计划、方案、用例系统测试计划、方案、用例l集成测试计划、方案集成测试计划、方案l单元测试计划单元测试计划l编写系统测试用例编写系统测试用例l编写集成测试用例编写集成测试用例l编写单元测试方案、用例编写单元测试方案、用例l执行单元测试执行单元测试l单元测试方案、报告单元测试方案、报告l集成测试用例集成测试用例实现和单元测试实现和单元测试全过程测试软件过程规范示例工程硕士10l单元测试报告单元测试报告l集成测试计划集成测试计划l集成测试方案集成测试方案l集成测试用例集成测试用例l执行集成测试执行集成测试l集成测试报告集成测试报告l集成测试报告集成测试报告l系统测试计划系统测试计划l系统测

7、试方案系统测试方案l系统测试用例系统测试用例l系统预测试项系统预测试项l执行系统预测试执行系统预测试l转系统测试转系统测试l执行系统测试执行系统测试l系统预测试、报告系统预测试、报告l系统测试报告系统测试报告l安装包安装包l用户文档用户文档l用户数据用户数据l验收测试项验收测试项l执行验收测试执行验收测试l验收测试报告验收测试报告l安装包安装包l用户文档用户文档l用户数据用户数据l维护计划维护计划集成测试（执行）集成测试（执行）系统测试（执行）系统测试（执行）验收测试（执行）验收测试（执行）产品维护产品维护工程硕士11全过程测试软件过程规范示例制定制定软软件件验证验证和确和确认计划认计划（So

8、ftware Verification and Validation Plan SVVP）单单元元测试过测试过程程 涉及详细设计，实现和单元测试两个阶段 过程定义内容：各种角色职责、 进入准则、 输入、步骤、 输出集成集成测试过测试过程程 涉及概要设计、详细设计，实现和单元测试以及集成测试等阶段 过程定义内容：各种角色职责、 进入准则、 输入、步骤、 输出系系统测试过统测试过程程 涉及需求分析、概要设计、详细设计、实现和单元测试以及系统测试执行等阶段 过程定义内容：各种角色职责、 进入准则、 输入、步骤、 输出4.2 4.2 软件测试的过程简介软件测试的过程简介工程硕士13测试过程（阶段）规格

9、定义设计编码系统测试集成测试单元测试用户需求验收测试回归测试配置管理缺陷跟踪 工程硕士14软件开发过程中的测试执行过程 分为以下几个阶段： 单元测试：测试程序最小单位有无错误，单元可以是一个或一组过程（函数）、菜单、类等。 集成测试：将单元集成起来测试它们之间的交互。 系统测试：在一个完整的系统上执行测试，评价系统是否满足对规格说明书的要求。工程硕士15不同阶段的缺陷修复成本不同阶段的缺陷修复成本l上图表明上图表明l缺陷发现得越晚，它的修复成本可能是数十倍的上升l结论结论 l为了降低软件开发成本并交付高质量产品，启动测试越早越好工程硕士16不同阶段测试相同功能的成本不同阶段测试相同功能的成本l

10、上图表明上图表明l在不同的测试阶段，测试同样功能的测试成本有数倍差异l结论结论l为了降低测试成本，提高测试效率，最好随着软件开发过程一步步测试产品，也就是从单元测试到系统测试依次进行工程硕士17测试过程单元测试 单元测试（Unit Testing） 目标：(1) 检验程序最小单元有无错误(2) 检验单元编码与设计是否吻合 时机：编码完成后，首先要实施的测试 方法：黑盒测试白盒测试 责任：开发工程师接口数据结构边界覆盖逻辑工程硕士18测试过程集成测试 集成测试（Integration Testing） 目标：(1) 检验组成系统的模块接口有无错误(2) 代码实现的系统设计与需求定义是否吻合 时机

11、：主要的单元测试完成后，经常与单元测试同步进行 方法：黑盒测试/白盒测试 责任：开发工程师测试工程师工程硕士19测试过程系统测试 系统测试（System Testing） 目标：(1) 检验组成整个系统的代码、以及系统的软硬件配合有无错误(2) 代码实现的系统与用户需求是否吻合(3) 检验系统的文档等各种是否完整、有效(4) 模拟验收测试的要求，检查系统是否符合用户的验收标准 时机：多数集成测试完成后 方法：黑盒测试 责任：测试工程师工程硕士20测试过程验收测试 验收测试（Acceptance Testing） 目标：使客户验收签字系统是否符合事先约定的验收标准 时机：系统测试完成后，在项目组

12、看来开发和测试工作已经全部完成，可以交付使用 方法：黑盒测试责任：产品经理或其他高级经理开发工程师测试工程师用户工程硕士21测试过程回归测试 回归测试（Regression Testing） 目标：验证程序修改或者版本更新以后，以前正确的功能和其他指标仍旧正确。 时机：每次错误修改之后，或者版本更新之后 方法：白盒测试/黑盒测试 责任：开发工程师测试工程师工程硕士22测试过程缺陷跟踪 缺陷跟踪（Defect Tracing） 目标：确保所有发现的错误被正确记录、分发、评估、关闭、统计 时机：从错误发现开始到错误关闭为止，每次错误状态修改之后 方法：缺陷跟踪系统 责任：开发工程师测试工程师测试经

13、理用户4.3 4.3 单元测试过程技术单元测试过程技术相关概念单元测试用例设计及其实现单元测试环境单元测试执行及其工具Module to be tested 4.3.1 4.3.1 单元测试的基本概念单元测试的基本概念 一、一、单元测试的含义 单元测试是在软件开发过程中要进行的最低级别的测试活动，或者说是针对软件设计的最小单位程序模块，进行正确性检验的测试工作。其目的在于发现每个程序模块内部可能存在的差错。 对软件的基本组成单元进行的测试，检验程序最小单位有无错误。一般在编码之后，由开发人员完成。 二二、单元的含义 单元是软件开发中的最小的独立部分，具有一些基本属性，可清晰的与同一程序中的其他

14、单元划分开来。 没有精确的概念，可以小到一条语句，也可以大到多个模块的组合； 传统上，认为一个函数、子过程、菜单、一个界面、一个类是一个单元； 单元的最显著的特征就是可以作为一个整体； 例如：C语言中的单元可以是函数或者子过程；C+语言中的单元通常是类。 三、单元测试步骤与分工三、单元测试步骤与分工 在单元测试活动中，软件的独立单元将在与程序的其他部分相隔离的情况下进行测试，主要工作分为两个步骤：人工静态检查和动态执行跟踪。前者是尽可能地发现程序中没有发现的错误，后者是跟踪比较实际结果与预期结果来发现错误。 单元测试的分工大致如下：一般由开发组在开发组组长监督下进行，保证使用合适的测试技术，根

15、据单元测试计划和测试说明文档中制定的要求，执行充分的测试；由编写该单元的开发组中的成员设计所需要的测试用例，测试该单元并修改缺陷。 四、单元测试的目标四、单元测试的目标（P101P101）检查代码实现是否符合设计不能检查设计是否正确尽早发现错误Microsoft applicationsMicrosoft applications 10-20 10-20 defects/KLOC during unit testingdefects/KLOC during unit testing 0.5 defects/KLOC after release0.5 defects/KLOC after rel

16、ease性价比最好 五五、单元测试误区单元测试误区 1、单元测试是一种浪费时间的工作 2、单元测试只能证明代码做了什么 3、我是个很棒的程序员， 我是不是可以不进行单元测试？ 4、集成测试能捕捉到所有的Bug 5、单元测试的成本效率不高 目前状况： 实施效果非常好，但是实施阻力比较大(主要是人员和管理因素)，一般只在关键的程序单元中实施 有比较系统的理论和方法，但也依赖于系统的特殊性和开发人员的经验 有大量的辅助工具，开发人员也经常自己开发测试代码和测试工具 主要使用白盒测试和静态分析，也使用黑盒测试;工程硕士3.2、单元测试的内容与出发点、单元测试的内容与出发点 一、单元测

17、试的内容单元测试的内容 1.模块接口测试（P112）数据在接口处出错就好像丢掉了进入大门的钥匙，无法进行下一步的工作，只有在数据能正确流入、流出模块的前提下，其他测试才有意义。 2.模块局部数据结构测试（P112） 局部数据结构往往是错误的根源，对其检查主要是为了保证临时存储在模块内的数据在程序执行过程中完整、正确，因此应仔细设计测试用例。 32 3.模块边界条件测试（P110） 边界条件是指软件计划的操作界限所在的边缘条件。边界条件测试是单元测试中最后也是最重要的一项任务。在使用边界值测试的方法时，不妨结合实际项目参考以下测试技巧：输入了完全伪造或者和要求不一致的数据。 1）输入一个格式错误

18、的数据。 2）提供一个空值或者不完整的值。 3）与意料之中的值相差很远的值。 33 4）假如一个列表中不允许有重复的数值存在，就可以给它传入一组存在重复数值的列表；如果某个字段的值要求唯一，那么可以输入两个或多个相同的数值来进行测试。 5）假如一个列表中不允许有重复的数值存在，就可以给它传入一组存在重复数值的列表；如果某个字段的值 要求唯一，那么可以输入两个或多个相同的数值来进行测试。 6） 如果要求按照一定的顺序来存储一些数据，那么可以输入一些顺序打乱的数据来做测试。 7）对于一些做了安全限制的部分，尽量通过各种途径尝试能否绕过安全限制的测试。 8） 如果功能的启用有一定的顺序限制，就用和期

19、望不一致的顺序来进行测试。34 4.模块独立执行路径测试（P112） 在模块中应对每一条独立执行路径进行测试，单元测试的基本任务是保证模块中每条语句至少执行一次。 5.模块内部错误处理测试 二、单元测试的出发点单元测试的出发点 1、判断得到的结果是否正确？ 因为，对于测试而言，首要的任务就是察看一下所期望的结果是否正确，即对结果进行验证。 2、分析能否使用反向关联检查？ 在实际程序中，有一些方法可以使用反向的逻辑关系来验证它们。 3、分析是否能使用其他手段来交叉检查一下结果？ 一般而言，对某个值进行计算会有一种以上的算法，但我们会因考虑到运行效率或其他方面的原因而选择其中的一种。 4、分析是否

20、可以强制一些错误发生？ 5、分析出错处理是否正确？ 一个好的设计应能预见各种出错条件，并进行适当的出错处理，即预设各种出错处理通路。 4.3.3 4.3.3 单元测试与系统集成测试区别单元测试与系统集成测试区别 一、单元测试与集成测试区别一、单元测试与集成测试区别 单元测试与集成测试的主要区别在于测试的对象不同。单元测试对象是实现具体功能的单元，一般对应详细设计中所描述的设计单元。集成测试是针对概要设计所包含的模块以及模块组合进行的测试。 单元测试所使用的主要测试方法是基于代码的白盒测试。而集成测试所使用的主要测试方法是基于功能的黑盒测试。 因为集成测试要在所有要集成的模块都通过了单元测试之后

21、才能进行，也就是说在测试时间上，集成测试要晚于单元测试，所以单元测试的好坏直接影响着集成测试。 单元测试的工作内容包括模块内程序的逻辑、功能、参数传递、变量引用、出错处理、需求和设计中有具体的要求等方面测试。集成测试的工作内容主要是验证各个接口、接口之间的数据传递关系、模块组合后能否达到预期效果。 虽然单元测试和集成测试有一些区别，但是二者之间也有着千丝万缕的联系。目前集成测试和单元测试的界限趋向模糊。 二二、单元测试与系统测试区别单元测试与系统测试区别 单元测试与系统测试的区别不仅仅在于测试的对象和测试的层次的不同，最重要的区别是测试性质不同。在单元测试过程中，单元测试的执行早于系统测试，测

22、试的是软件单元的具体实现、内部逻辑结构以及数据流向等。系统测试属于后期测试，主要是根据需求规格说明书进行的，是从用户角度来进行的功能测试和性能测试等等，证明系统是否满足用户的需求。 单元测试中发现的错误容易进行定位，并且多个单元测试可以并行进行；而系统测试发现的错误比较难定位。Unit Test Environment工程硕士40 驱动器：替代调用被测模块的模块功能。一般只是一个接收测试数据，并将测试数据传送给被测模块，然后打印相关结果的“主程序”。 桩：替代被测模块所调用模块，需要使用子模块间的接口。 4.3.4 4.3.4 单单元元测试环测试环境境 由于一个模块或一个方法（Method）并

23、不是一个独立的程序，在考虑测试它时要同时考虑它和外界的联系，因此要用到一些辅助模块，来模拟与所测模块相联系的其他模块。一般把这些辅助模块分为两种： 1、驱动模块（driver）:相当于所测模块的主程序。 2、桩模块（stub）:用于代替所测模块调用的子模块。 那么，所测模块和与它相关的驱动模块及桩模块共同构成了一个“测试环境”，如图3-2所示。被测单元驱动模块桩模块1桩模块桩模块N测试结果测试用例图3-2 单元测试环境4.3.5 4.3.5 单元测试策略单元测试策略 单元测试包括：一是针对被测单元需求的功能测试，二是用于代码评审和代码走读的静态测试、白盒测试、状态转换测试和非功能测试。 为了提

24、高单元测试的质量，只了解这些单元测试技术还远远不够，还要选择合适的测试策略。在选择测试策略时，主要考虑如下3种方式：自顶向下（Top Down Unit Testing）的单元测试策略、自底向上的单元测试策略（Bottom up Unit Testing）和孤立的单元测试策略。 一一、自顶向下单元测试策略自顶向下单元测试策略 1、步骤 1)从最顶层开始，把顶层调用的单元做成桩模块。 2)对第二层测试，使用上面已测试的单元做驱动模块。 3)依次类推，直到全部单元测试结束。 先对最顶层的单元进行测试，把顶层所调用的单元做成桩模块，其次对第二层进行测试，使用上面已测试的单元作驱动。以此类推直到完成所

25、有模块。桩: 替代被测单元所调用模块的模块单元辅助测试模块。 2、优点 可以在集成测试之前为系统提供早期的集成途径。(提供较早的集成路径) 3、缺点 单元测试被桩模块控制，随着单元测试的不断进行，测试过程也会变得越来越复杂，测试难度以及开发和维护的成本都不断增加。(同详细设计顺序一样，越到下层测试过程越复杂，并行性不好，测试周期长，任何一单元的修改都将影响其相关单元被重新测试。) 要求的低层次的结构覆盖率也难以得到保证；由于需求变更或其他原因而必须更改任何一个单元时，就必须重新测试该单元下层调用的所有单元；低层单元测试依赖顶层测试，无法进行并行测试，使测试进度受到不同程度的影响，延长测试周期。

26、 从上述分析中，不难看出该测试策略的成本要高于孤立的单元测试成本，因此从测试成本方面来考虑，并不是最佳的单元测试策略。二二、自底向上的单元测试自底向上的单元测试 1.步骤： 1)先对模块调用图上的最底层模块开始测试，模拟调用该模块的模块为驱动模块。 2)对上一层模块进行单元测试，用已经被测试过的模块做桩模块。 3)依次类推，直到全部单元测试结束。 先对最底层的单元进行测试，把调用该单元的模块做成驱动模块，其次对上层进行测试，使用下面已测试的单元作桩。以此类推直到完成所有模块； 驱动：替代调用被测单元的模块功能的模块。 2)优点 不需要单独设计桩模块。(提供较早的集成路径) 3）缺点 随着单元测

27、试的不断进行，测试过程会变得越来越复杂，测试周期延长，测试和维护的成本增加；随着各个基本单元逐步加入，系统会变得异常庞大，因此测试人员不容易控制；越接近顶层的模块的测试其结构覆盖率就越难以保证； 另外，顶层测试易受底层模块变更的影响，任何一个模块修改之后，直接或间接调用该模块的所有单元都要重新测试。 同详细设计顺序一样，越到上层测试过程越复杂，并行性不好，测试周期长，任何一单元的修改都将影响其相关单元被重新测试。 由于只有在底层单元测试完毕之后才能够进行顶层单元的测试，所以并行性不好。另外，自底向上的单元测试也不能和详细设计、编码同步进行。 总结：相对其它测试策略而言，该测试策略比较合理,尤其

28、是需要考虑对象或复用时。它属于面向功能的测试，而非面向结构的测试。对那些以高覆盖率为目标或者软件开发时间紧张的软件项目来说，这种测试方法不适用。工程硕士50ADBCEFCd1s1Ds2Bd2d3As3s4s5单元测试进程策略 例： 三三、孤立测试孤立测试 1.步骤 无需考虑每个模块与其他模块之间的关系，分别为每个模块单独设计桩模块和驱动模块，逐一完成所有单元模块的测试。 2.优点：该方法简单、容易操作，因此所需测试时间短，能够达到高覆盖率。 3.缺点：不能为集成测试提供早期的集成途径。依赖结构设计信息，需要设计多个桩模块和驱动模块，增加了额外的测试成本。 总结：该方法是比较理想的单元测试方法。

29、如辅助适当的集成测试策略，有利于缩短项目的开发时间。 四、综合测试四、综合测试 在单元测试中，为了有效地减少开发桩模块的工作量，可以考虑综合自底向上测试策略和孤立测试策略。 工程硕士534.3.6 4.3.6 单元测试技术单元测试技术静态分析静态分析 含义：不实际运行程序，而是通过检查和阅读等手段来发现错误并评估代码质量的软件测试技术。也称为静态测试技术。 方法： 走查：WalkThrough 审查：Inspection 评审：Review工程硕士54单元测试技术静态分析（走查） 含义： 开发组内部进行的，采用讲解、讨论和模拟运行的方式进行的查找错误的活动。 经验： 限时避免跑题 参加人员经验

30、丰富的开发人员和本模块相关的开发人员本项目组的新人 由本模块的开发者进行讲解、回答问题并记录不要现场修改 检查要点逻辑错误代码标准/规范/风格是人工测试的方法，属于静态白盒测试，通过阅读程序源代码查找程序的错误。工程硕士55单元测试技术静态分析（审查） 含义： 开发组内部进行的，采用讲解、提问并使用Checklist方式进行的查找错误的活动。一般有正式的计划、流程和结果报告。 经验： 以会议的形式，制定会议目标、流程和规则，结束后要编写报告 参加人员经验丰富的开发人员和本模块相关的开发人员本项目组的新人 由另外一名开发者进行讲解、其他开发者主要按照Checklist进行提问并填表、本模块开发者

31、回答问题并记录不要现场修改 检查要点设计需求代码标准/规范/风格工程硕士56单元测试技术静态分析（评审）定义：开发组、测试组和相关人员(QA、产品经理等)联合进行的，采用讲解、提问并使用Checklist方式进行的查找错误的活动。一般有正式的计划、流程和结果报告。经验：以会议的形式，制定会议目标、流程和规则，结束后要编写报告。相关资料要在会议前下发并阅读。参加人员经验丰富的开发人员和本模块相关的开发人员测试组和相关人员由另外一名开发者进行讲解、其他开发者主要按照Checklist进行提问并填表、本模块开发者回答问题并记录不要现场修改检查要点设计需求代码标准/规范/风格文档的完整性和一致性工程硕

32、士574.3.7单元测试技术测试用例设计 黑盒方法 - 等价类 - 边界值 - 决策表 - 基于类定义 - 状态图 - 错误猜测法 考虑对象 - 模块接口 - 局部数据结构 - 独立路径 - 异常处理 - 边界条件 白盒方法 - 基本路径 - 分支-条件 - 循环 - 覆盖度工程硕士58 模块接口 检查进出模块的数据是否正确 Checklist： 模块的实际输入与定义的输入是否一致：个数、类型、顺序； 模块中对于非内部/局部变量是否合理使用； 使用其他模块时，是否检查可用性和处理结果； 使用外部资源时，是否检查可用性并及时释放资源，如内存、文件、硬盘、端口等 其他独立路径出错处理模块接口局部数

33、据结构边界条件单元测试用例分析工程硕士59 局部数据结构 检查局部数据结构能否保持完整性 Checklist： 变量从来没有被使用 可能别的地方使用了错误的变量名 变量没有初始化 错误的类型转换 数组越界 非法指针 变量或函数名称拼写错误 使用了外部变量或函数 其他独立路径出错处理模块接口边界条件局部数据结构单元测试用例分析工程硕士60独立路径出错处理模块接口边界条件局部数据结构单元测试用例分析 出错处理 检查内部错误处理设施是否有效 Checklist：是否检查错误出现资源使用前后其他模块使用前后出现错误，是否进行错误处理抛出错误通知用户进行记录错误处理是否有效在系统干预前处理报告和记录的错

34、误真实详细其他工程硕士61 独立路径 检查由于计算错误、判定错误、控制流错误导致的程序错误 Checklist： 死代码 错误的计算优先级 精度错误 比较运算错误 赋值错误 表达式的不正确符号 、=；=、=、!= 循环变量的使用错误 错误赋值 其他独立路径出错处理模块接口边界条件局部数据结构单元测试用例分析工程硕士62 边界条件 检查临界数据是否正确处理 Checklist： 普通合法数据是否正确处理 普通非法数据是否正确处理 边界内最接近边界的(合法)数据是否正确处理 边界外最接近边界的(非法)数据是否正确处理 其他独立路径出错处理模块接口边界条件局部数据结构单元测试用例分析工程硕士63 运

35、行时问题（C/C+） 容器越界访问 虚函数动态决议 函数动态链接 动态内存分配 异常处理 RTTI（Runtime Type Information ）单元测试用例分析工程硕士64单元测试用例分析例子（C语言的内存泄漏）工程硕士65修改后的代码例子（C语言的内存泄漏）工程硕士664.3.8 单元测试工具 单元测试的两种方式： 自己编写代码 使用单元测试工具 单元测试工具的种类 静态分析工具 代码规范审核工具 内存和资源检查工具 测试数据生成工具 测试框架工具 测试结果比较工具 测试度量工具 测试文档生成和管理工具工程硕士67单元测试工具 代码检查工具 Lint 覆盖率测试工具 IBM Rati

36、onal PureCoverage TrueCoverage 内存检查工具 IBM Rational Purify（http:/ BounderChecker JUnit Framework（http:/ 性能检查工具 Quantify 其他 HindSight LogiScope4.3.8 4.3.8 单元测试用例设计单元测试用例设计一、试用例设计概述试用例设计概述 单元测试用例的设计既可以使用白盒测试也可以使用黑盒测试，但以白盒测试为主。 白盒测试进入的前提条件是测试人员已经对被测试对象有了一定的了解，基本上明确了被测试软件的逻辑结构。 黑盒测试是要首先了解软件产品具备的功能和性能等需求，

37、再根据需求设计一批测试用例以验证程序内部活动是否符合设计要求的活动。 测试人员在实际工作中至少应该设计能够覆盖如下需求的基于功能的单元测试用例： 测试程序单元的功能是否实现； 测试程序单元性能是否满足要求（可选）； 是否有可选的其它测试特性，如边界、余量、安全性、可靠性、强度测试、人机交互界面测试等。 无论是白盒测试还是黑盒测试，每个测试用例都应该包含下面4 个关键元素： (1) 被测单元模块初始状态声明，即测试用例的开始状态（仅适用于被测单元维持了调用中间状态的情况)； (2) 被测单元的输入，包含由被测单元读入的任何外部数据值； (3) 该测试用例实际测试的代码，用被测单元的功能和测试用例

38、设计中使用的分析来说明，如：单元中哪一个决策条件被测试； (4) 测试用例的期望输出结果（在测试进行之前的测试说明中定义）。 二、测试用例设计步骤二、测试用例设计步骤 以下描述进行测试用例设计的6步通用过程。 步骤1：首先使被测单元运行； 这个阶段适合的技术有： 模块设计说明导出的测试 对等区间划分 步骤2：正面测试(Positive Testing) 这个阶段适合的技术： 设计说明导出的测试 对等区间划分 状态转换测试 步骤3：负面测试(Negative Testing) 适合的技术有： 错误猜测 边界值分析 内部边界值测试 状态转换测试 步骤4: 模块设计需求中其它测试特性用例设计 适合的

39、技术：设计说明导出的测试 步骤5：覆盖率测试用例设计 适合的技术： 分支测试 条件测试 数据定义使用测试 状态转换测试 步骤6：测试执行 步骤7：完善代码覆盖 适合的技术： 分支测试 条件测试 设计定义试验测试 状态转换测试 4.3.9 4.3.9 单元测试过程单元测试过程图3-7从宏观的角度概括了单元测试的工作过程图。 一、单元测试进入和退出准则 如表3-1和表3-2所示：表3-1 进入准则要素判断准则详细设计说明书单元测试用例 经过审查 获得批准 进入配置库 要素判断准则源代码文件源代码文件清单 源代码文件获得批准 源代码文件进入配置库的 源代码区 测试用例源代码通过同级 评审软件Bug

40、清单单元测试报告 提交测试负责人 提交软件产品配置管理表3-2 退出准则二、单元测试过程详 细 设 计 说 明 书原 程 序 文 件测 试 用 例 文 件单 元 测 试 报 告软 件 Bug清 单准备代码编制代码审查单元测试图3-7 单元测试工作过程（1）准备阶段（2）编制阶段（3）代码审查阶段（4）单元测试阶段（5）评审、提交阶段4.4 4.4 集成测试过程技术集成测试过程技术相关概念集成测试策略集成测试环境 4.4.1 4.4.1 集成测试概述集成测试概述 一、集成测试的含义 集成测试是指根据实际情况对程序模块采用适当的的集成测试策略组装起来，对系统的接口以及集成后的功能进行正确性检验的测

41、试工作。 在单元测试的基础上，将所有模块按照概要设计要求组装为子系统或者系统进行测试，关注各个模块之间的交互是否正确。 二二、集成测试与系统测试的区别集成测试与系统测试的区别 1、测试对象 集成测试的测试对象是由通过了单元测试的各个模块所集成起来的组件。而系统测试的测试对象，除了软件之外，还有计算机硬件及相关的外围设备、数据采集和传输机构、计算机系统操作人员等的整个系统。 2、 测试时间 集成测试是介于单元测试和系统测试之间的测试. 在测试时间上，先于系统测试。 3、测试方法 集成测试通常会采用灰盒测试。而系统测试通常使用黑盒测试。 4、测试内容 集成测试的主要内容就是各个单元模块之间的接口，

42、以及各个模块集成后所实现的功能。而系统测试的主要内容就是整个系统的功能和性能。 5、测试目的 集成测试的主要目的就是发现单元之间接口的错误，以及发现集成后的软件同软件概要设计说明不一致的地方。而系统测试的主要目的就是，通过与系统需求定义相比较之后发现软件与系统定义不符合或矛盾的地方。 6、测试角度 集成测试工作的开展更多的是站在测试工作人员的角度上。系统测试工作的开展更多的是站在用户的角度来进行。A产品子系统1子系统2硬件子系统1软件子系统1软件模块1软件模块2软件程序1软件程序2单元1单元2单元3单元4硬件子系统2软件子系统2软件模块3软件模块4（软件结构图）（软件模块结构）4-1 软件结构

43、图 三、集成测试与开发的关系三、集成测试与开发的关系 为了使读者更好的了解集成测试与开发的关系，图4-1给出了软件基本结构图。 四四、集成测试的重点集成测试的重点 1、各个模块连接起来后，穿过模块接口的数据是否会丢失，是否能够按期望值传递给另外一个模块； 2、各个模块连接起来后，需要判断是否仍然存在单元测试时所没发现的资源竞争问题； 3、分别通过单元测试的子功能模块集成到一起能否实现所期望的父功能； 4、兼容性，检查引入一个模块后，是否对其他与之相关的模块产生负面影响； 5、全局数据结构是否正确，是否被不正常的修改； 6、集成后，每个模块的误差是否会累计扩大，是否会达到了不可接受的程度； 五五

44、、集成测试的层次集成测试的层次 对于传统软件来说，按集成粒度不同，可以把集成测试分为3个层次，即：- 模块内集成测试- 子系统内集成测试- 子系统间集成测试 对于面向对象应用系统来说，按集成粒度不同，可以把集成测试分为2个层次：- 类内集成测试- 类间集成测试 4.4.2 4.4.2 集成测试任务集成测试任务 一、集成测试任务集成测试任务 在把各个模块连接起来时，穿越模块接口的数据是否会丢失； 各个子功能组合起来，是否能够达到预期要求的父功能； 一个模块的功能是否会对另一个模块的功能产生不利的影响； 全局数据结构是否有问题，会不会被异常修改； 单个模块的误差积累起来，是否会放大，从而达到不可接

45、受的程度； 二二、集成测试基础分析集成测试基础分析 1、体系结构分析 首先，跟踪需求分析，对要实现的系统划分出结构层次图。 其次，是对系统各个组件之间的依赖关系进行分析，然后据此确定集成测试的粒度，即集成模块的大小。2、模块分析 一般，可从以下几个角度进行模块分析： 1）确定本次要测试的模块；2） 找出与该模块相关的所有模块，并且按优先级对这 些模块进行排列；3）从优先级别最高的相关模块开始，把被测模 块与其集成到一起；4）然后依次集成其他模块。3、接口分析 接口的划分要以概要设计为基础，一般通过以下几个步骤来完成： (1)确定系统的边界、子系统的边界和模块的边界。 (2)确定模块内部的接口。

46、 (3)确定子系统内模块间接口。 (4)确定子系统间接口。 (5)确定系统与操作系统的接口。 (6)确定系统与硬件的接口。 (7)确定系统与第三方软件的接口。4、风险分析 风险通常被分为3种类型： 项目风险：包括项目管理和项目环境的风险。 商业风险：它和领域的相关概念及规则息息相关。 技术风险：这是针对应用程序的具体实现而言的，主要和代码级的测试有关。 风险分析是一个定义风险并且找出阻止潜在的问题变成现实的方法的过程。 通常把风险分析分为3个阶段：风险识别、风险评估和风险处理。 5、可测试性分析 必须尽可能早地分析接口的可测试性，提前为后续的测试工作做好准备。 6、集成测试策略分析 集成测试策

47、略分析的主要任务就是根据被测对象选择合适的集成测试策略。工程硕士89 基于功能分解的集成 大爆炸 自顶向下集成 自底向上集成 三明治集成 基于调用图的集成 成对集成 相邻集成 基于路径的集成 集成测试策略工程硕士90SATMSATM系统系统设备传感与控制设备传感与控制中央银行通信中央银行通信终端传感与控制终端传感与控制管理会话管理会话通道传感与控制通道传感与控制槽传感与控制槽传感与控制屏幕驱动器屏幕驱动器键盘传感器键盘传感器验证卡验证卡验证验证PINPIN取数字取数字管理事务管理事务结束会话结束会话集成测试功能分解图和调用图示例工程硕士911A10BC2511 12 13151416ED234

48、82621201822F17919242376527集成测试功能分解图工程硕士92123456789101112131415161718192021222324252627集成测试调用图示例工程硕士93 在完成单元测试后就立即将所有模块连接成一个整体进行测试是一个好方法。 Not always！集成测试策略大爆炸集成工程硕士94 从顶层开始，采用同设计顺序一样的思路对被测系统进行测试，一般集中于顶层的组件，然后逐步测试处于底层的组件，被上层单元调用的下层单元以桩出现； 自顶向下的集成方式可以采用深度优先和广度优先策略。集成测试策略自顶向下集成工程硕士95ABCDEFAS1S2S3AS4S2S3

49、BAS2S3BEAS3BECABECDS5ABECFD集成测试策略自顶向下集成示例 深度优先有一个程序的结构如下图所示，当采用自顶向下深度优先的策略进行集成测试时，请详细描述该程序的测试过程。ABCD自顶向下深度优先的策略进行集成测试的方法是：以先左后右的方式选择模块集成主线路径，主模块作为测试驱动，为主模块编制相应的桩基模块。 测试主模块A，编制桩基模块S1和S2来代替模块A实际调用的模块B和C，如图（a）所示。 用模块B代替桩基模块S1，编制桩基模块S3来代替模块B实际调用的模块D，对模块B进行测试，如图（b）所示。 用模块D代替桩基模块S3，对模块D进行测试，如图（c）所示。 用模块D代

50、替桩基模块S3，对模块C进行测试，如图（d）所示。 AS1S2ABS2S3ABS2DABCD （a） （b） （c） （d）工程硕士99ABCDEFAS1S2S3AS4S2S3BACS3BS4ABECDS5ABECFDADBS4CS5集成测试策略自顶向下集成示例 广度优先工程硕士100 从最底层组件开始，按照分解树的结构，逐层向上集成，调用下层单元的上层单元以驱动出现。 示例集成测试策略自底向上集成Ed1d3FCd2BEd4DFd5ABCDEFABCDEF工程硕士101 在分解树的子树上进行集成 优先模块优先集成集成测试策略三明治集成工程硕士102 成对集成 测试思想：依据调用图，测试调用图中

51、的每一对单元 测试会话的数量：调用图中的边的数目 相邻集成 测试思想：依据调用图，测试节点的邻居，节点的邻居是包括节点的所有直接前躯节点和所有直接后继节点 测试会话的数量： 邻居 = 节点 汇节点（有叶直接连到根节点） 邻居 = 节点 汇节点-源节点（没有叶直接连到根节点）集成测试策略成对集成&相邻集成工程硕士103123456789101112131415161718192021222324252627集成测试策略成对集成示例工程硕士104123456789101112131415161718192021222324252627集成测试策略相邻集成示例工程硕士105 测试思想:来源于

52、路径测试，集成的策略是测试从一个单元沿类似于控制的线索进入另一 个单元。 相关概念 源节点：程序执行开始时或重新开始处的语句片断（单元中的第一个可执行语句，紧接着转移控制到其他单元节点之后的节点）。 汇节点：程序执结束处的语句片断（单元中的最后一个可执行语句，转移控制到其他单元的节点）。 模块执行路径: 以源节点开始，以汇节点结束的一些列语句，中间没有插入汇节点。 消息：一种程序设计语言机制，通过这种机制一个单元将控制转移给另一个单元。集成测试策略基于路径的集成工程硕士106MM-路径是穿插出现模块执行路径和消息的序列;通过MM-路径可以描述包含在单独单元之间控制转移的模块执行路径序列1234

53、56123412345ABC MEP(A,1) = MEP(A,2) = MEP(A,3) = MEP(B,1) = MEP(B,2) = MEP(C,1) = MEP(C,2) = 集成测试策略基于路径的集成工程硕士107集成测试策略基于路径的集成 给定一组单元，其MM-路径图是一种有向图，其中的节点表示模块执行路径，边表示消息和单元之间的返回，实线表示消息，相应的返回由虚线表示 MM-路径有多长（深）？消息静止点和数据静止点 覆盖准则：至少遍历所有的消息工程硕士108123456123412345ABC MEP(A,1) = MEP(A,2) = MEP(A,3) = MEP(B,1) =

54、 MEP(B,2) = MEP(C,1) = MEP(C,2) = MEP(A,2)MEP(A,1)MEP(C,1)MEP(B,2)MEP(A,3)MEP(c,2)MEP(B,1)集成测试策略基于路径的集成示例工程硕士109硬件硬件环环境：境：尽尽可能的考可能的考虑实际环虑实际环境，境，实实在不可用使用模在不可用使用模拟环拟环境境 操作操作环环境：考境：考虑虑到不同机型的不同操作系到不同机型的不同操作系统统版本版本数数据据库环库环境境网络环网络环境境接口模拟器接口模拟器1驱动驱动已集成模块已集成模块新增模块新增模块桩桩桩桩桩桩驱动驱动已集成模块已集成模块新增模块新增模块桩桩桩桩桩桩接口模拟器接

55、口模拟器2测试控制中心测试控制中心测试数据库测试数据库测试规程库测试规程库TCP/IPTCP/IPTCP/IPTCP/IPTCP/IPPC机机PC机机PC机机PC机机小型机小型机集成测试环境工程硕士110 将已经集成好的软件系统，作为整个基于计算机系统的一个元素，与计算机硬件、外设、某些支持软件、数据和人员等其他系统元素结合在一起，在实际运行（使用）环境下，对计算机系统进行一系列的组装测试和确认测试。 测试任务： 发现与系统定义不符或矛盾的地方 系统各个部分是否可以协调工作4.5 4.5 系统测试系统测试过程技术过程技术工程硕士111 功能性测试 性能测试 压力测试 容量测试 协议一致性测试

56、安全性测试 恢复性测试 备份测试 GUI测试 健壮性测试 兼容性测试 可用性测试 可安装性测试 文档测试 在线帮助测试 数据转换测试系统测试内容工程硕士112系统测试功能性测试 测试思想：功能测试是系统测试中最基本的测试，根据产品的需求规格书和测试需求列表，验证产品的功能实现是否符合产品的需求规格。主要发现以下几类错误： 是否有不正确或遗漏了的功能？ 功能实现是否满足用户需求和系统设计的隐藏需求？ 是否能正常地接受输入？能否正确地输出结果？ 对测试设计者的要求：非常熟悉产品的规格说明、需求文档和产品业务功能，掌握测试用例的设计方法。工程硕士113 对每个明确的功能需求进行标号 对每个可能隐含的

57、功能需求进行标号 对于可能出现的功能异常进行分类，并进行标号 对于前三步获得的功能需求进行分级，确定关键功能和非关键功能 设计每个功能的测试用例（等价类，边界值，决策表，错误猜测等） 系统测试功能性测试（用例分析方法）工程硕士114系统测试功能性测试（用例设计方法） 规范导出法； 等价类划分； 边界分析； 因果图； 决策表； 基于风险的测试； 错误猜测法；工程硕士115 测试思想：软件的性能和效率目标描述为在特定负载和配置环境下程序的响应时间和吞吐率。性能测试的目的是设计测试用例来说明程序不能满足其性能目标，监控的关键性能指标（例如响应时间、CPU、内存、I/O使用情况、网络连接等） 。 例如

58、：应用程序能够以1000ms的最大响应时间处理750个同时发生的活跃用户；峰值时刻支持800个用户，响应时间下降7%。系统测试性能测试（以Web应用为例）工程硕士116系统测试性能测试（以Web应用为例） 性能度量指标： 响应时间的定义：对计算机系统的一个查询或请求结束和一个响应开始之间所逝去的时间，例如在指示一个查询结束和在用户终端上显示相应的第一个字符之间的时间长度。 事务时间：客户、网络和服务器完成一个事务所需要的时间总量。 等待时间：完成一个请求所需的时间，如网络延迟和服务器延迟。在Web应用中，相应时间可以度量为用户点击一个按钮或链接和浏览器开始显示导出的页面之间的时间。在Web应用

59、中，事务时间可以度量为用户点击一个按钮或链接和浏览器开始显示导出的页面之间的时间（包括客户端脚本、Java小程序等的执行）。工程硕士117系统测试性能测试（以Web应用为例）一个典型的Web事务范例 客户端用户输入URL或者在浏览器上点击链接，请求服务器提供某个文件。域名服务器将服务器的主机名转换成合适的IP地址。客户连接到Web服务器。客户向服务器发送一个超文本传输协议请求。在Internet上网络将数据从客户端传输到服务器端。在服务器端一旦请求到达服务器，数据在合适的通讯协议上被拆分；服务器对请求作出响应；服务器通过检索数据或者将数据写入数据库来处理请求，一旦处理完成，服务器向客户返回请求

60、文件或者结果信息。在Internet上回传（网络）网络从服务器端向客户端传输数据返回到客户端浏览器接受请求的数据，显示HTML内容并执行动态内容。工程硕士118系统测试性能测试（以Web应用为例） 性能测试的关键元素 工作负载：系统需要进行处理和通信管理的信息总量。 考虑的因素： 用户 应用 资源 通过对用户数量（和日常活动）、需要应用处理用户活动的命令、系统的资源需求的分析，计算出系统的工作负载。工程硕士119系统测试性能测试（以Web应用为例） 性能测试的关键元素 系统环境和可利用资源：客户端的浏览器、网络和服务器。 Web应用中涉及的环境资源包括： 网络访问量 人员变量 地域变量 ISP基础结构