Unit4 软件的测试过程,,概述,4.1 概述,,测试生命周期称为软件测试过程模型（POCERM），其内容如下所示 （1）拟定软件测试计划 (Plans) （2）编制软件测试大纲 (Outlines) （3）设计和生成测试用例 (test Case generation) （4）实施测试 (Execution) （5）生成软件测试报告 (software testing Reports),4.2 测试计划,IEEE829－1998软件测试文档编制标准 软件测试计划文档模板 目录 1．测试计划标识符 2．介绍 3．测试项 4．需要测试的功能 5．方法（策略） 6．不需要测试的功能 7．测试项通过/失败的标准 8．测试中断和恢复的规定 9．测试完成所提交的材料 10．测试任务 11．环境需求 12．测试人员的工作职责 13．人员安排与培训需求 14．进度表 15．潜在的问题和风险 16．审批,4.3 测试设计,测试设计目的是为每一个测试需求确定测试用例集，并且确定执行测试用例的测试过程测试设计具体如下： （1）对每一个测试需求，确定其需要的测试用例 （2）对每一个测试用例，确定其输入及预期结果。
（3）确定测试用例的测试环境配置、需要的驱动程序 （4）编写测试用例文档 （5）对测试用例进行同行评审,4.4 测试实施过程,软件测试实施一般经历如下3个阶段： （1）初测期 ——测试主要功能和关键的执行路径，排除主要障碍 （2）细测期 ——依据测试计划和测试大纲、测试用例，逐一测试大大小小的功能、方方面面的特性、性能、用户界面、兼容性、可用性等等；预期可发现大量不同性质、不同严重程度的错误和问题 （3）回归测试期 ——系统已达到稳定，在一轮测试中发现的错误已十分有限；复查已知错误的纠正情况，确认未引发任何新的错误时，终结回归测试三个测试期阶段图示,,软件测试执行过程按以下步骤进行，即单元测试、集成测试、确认测试、系统测试、验收测试和回归测试4.4.1 单元测试,什么是单元测试？ 单元测试是对软件基本组成单元进行测试，主要是为了发现单元内部可能存在的各种错误和不足 主要工作分为两个步骤：人工静态检查和动态执行跟踪,,什么是单元？ 一个函数或几个函数的集合 类或类内成员函数 一个菜单、一个显示界面或者能够独立完成的具体的功能等单元测试的目的 验证代码能否达到详细设计的预期要求 发现代码中不符合编码规范的地方。
准确定位发现的错误，以便排除错误单元测试环境 由于一个模块或一个方法（Method）并不是一个独立的程序，在考虑测试它时要同时考虑它和外界的联系，因此要用到一些辅助模块，来模拟与所测模块相联系的其他模块一般把这些辅助模块分为两种： 1、驱动模块（driver）:相当于所测模块的主程序 2、桩模块（stub）:用于代替所测模块调用的子模块 那么，所测模块和与它相关的驱动模块及桩模块共同构成了一个“测试环境”单元测试的主要任务,1.模块接口测试 （1）调用所测模块时的输入参数与模块的形式参数在个数、属性、顺序上是否匹配； （2）所测模块调用子模块时，它输入给子模块的参数与子模块中的形式参数在个数、属性、顺序上是否匹配； （3）是否修改了只做输入用的形式参数； （4）调用标准函数的参数在个数、属性、顺序上是否正确； （5）全局变量的定义在各模块中是否一致注：主要关注单元中的输入和输出,2.局部数据结构测试 （1）数据类型说明是否正确 （2）是否使用了尚未赋值或尚未初始化的变量 （3）是否使用了错误的初始值或错误的默认值 （4）错误的变量名，如拼写错误或书写错误注：主要关注与被测单元内部相关的数据的类型,3.路径测试 （1）运算的优先次序不正确。
（2）错误的初始化；精度不够等 （3）进行比较的两数类型不同 （4）循环次数“差1错” （5）循环终止条件错 （6）对循环变量的修改不恰当等等不正确的计算,,不正确的比较和控制流,注：主要关注程序的逻辑分支问题,4.错误处理测试 （1）对运行发生的错误描述难以理解 （2）所报告的错误与实际遇到的错误不一致 （3）出错后，在错误处理之前就引起系统的干预 （4）提供的错误信息不足，以至于无法找到错误的原因总之，一个好的设计应能预见各种出错条件，并进行适当的出错处理注：主要针对于程序中的错误提示问题5.边界条件,单元测试误区 1、单元测试是一种浪费时间的工作，现在要赶进度，时间来不及了，随便做做应付领导 2、我是个很棒的程序员， 我是不是可以不进行单元测试？,注：主要针对于单元测试中的边界问题,砌墙,4.4.2 集成测试,什么是集成测试 集成测试是在单元测试的基础上，将所有模块按照概要设计要求组装成为子系统或系统所进行的测试 集成测试关注的重点 模块接口的数据交换 各子功能组合起来能否达到预期要求的父功能 模块间是否有不利影响 全局数据结构 单个模块的误差是否会累积放大,集成方法 大爆炸集成Big bang integration (all module together) 自顶向下集成Top down integration (from higher levels no test drivers are needed) 自底向上集成Bottom up integration (from lower levels No test stubs necessary) 三明治集成Sandwich testing (combination of bottom-up and top-down),大爆炸集成 1. 目的 尽可能缩短测试时间，使用最少的测试用例验证系统。
2. 定义 大爆炸集成也称为一次性组装或整体拼装，这种集成测试策略的做法就是把所有通过单元测试的模块一次性集成到一起进行测试，不考虑组件之间的互相依赖性及可能存在的风险3. 具体方法 举例来说，假设要对某个系统的部分功能进行测试，其功能分解如图：,自顶向下集成 自顶向下的集成测试就是按照系统层次结构图，以主程序模块为中心，从顶层控制（主控模块）开始，自上而下按照深度优先或者广度优先策略，对各个模块一边组装一边进行测试自顶向下集成测试的步骤： 以主模块为被测试模块，主模块的直接下属模块则用桩模块来代替 采用深度优先或宽度优先策略，用实际模块替换相应的桩模块（每次仅替换1个或少量几个），它们的直接下属模块则用桩模块来代替，与已测试的模块或子系统集成为新的子系统 对新形成的子系统进行测试 若所有的模块都已集成到系统中，则结束集成，否则转步骤2自底向上集成 自底向上集成是从系统层次结构图的最底层模块开始按照层次结构图，逐层向上进行组装和集成测试的方式自底向上集成测试的步骤： 为最底层模块开发驱动模块，对最底层模块进行测试； 用实际模块替换驱动模块，与其直属子模块集成为一个子系统； 为新形成的子系统开发驱动模块，对该子系统进行测试； 若该子系统已对应为主控模块，则结束集成，否则转步骤2；,三明治集成（混合集成） 1.目的 综合利用自顶向下和自底向上两种集成测试策略的优点 2.定义 三明治集成是一种混合增殖式测试策略，综合了自顶向下和自底向上两种集成方法，把系统划分成三层，中间一层为目标层，目标层上采用自顶向下集成，目标层下采用自底向上集成。
其他集成方法 核心系统先集成 高频集成方式 集成测试小结,集成测试过程中的两个重要里程碑 在集成测试过程中的两个重要的里程碑是功能冻结和代码冻结的确定这两个里程碑界定出回归测试期的起止界限 功能冻结(Function/Feature Freeze) ——经过测试，符合设计要求，确认系统功能和其他特性均不再做任何改变 代码冻结(Code Freeze) ——理论上，在无错误时冻结程序代码，但实际上，代码冻结只标志系统的当前版本的质量已达到预期的要求，冻结程序的源代码，不再对其做任何修改这个里程碑是设置在软件通过最终回归测试之后单元测试与集成测试区别 测试对象：单元测试对象是实现具体功能的单元，一般对应详细设计中所描述的设计单元集成测试是针对概要设计所包含的模块以及模块组合进行的测试 测试方法：单元测试所使用的主要测试方法是基于代码的白盒测试而集成测试所使用的主要测试方法是基于功能的黑盒测试 测试时间：集成测试要晚于单元测试，所以单元测试的好坏直接影响着集成测试 测试内容：单元测试主要包括模块内程序的逻辑等方面，集成测试主要是验证各个接口、接口之间的数据传递关系、模块组合后能否达到预期效果。
4.4.3 确认测试,什么是确认测试 确认测试（Validation Testing）的任务是验证软件的功能、性能及其他特性是否达到需求规格说明书的要求确认测试一般包括有效性测试和软件配置复查 1）有效性测试 有效性测试是在模拟的环境下，通过执行黑盒测试，验证被测软件是否满足需求规格说明书中的需求 2）软件配置复查 软件配置复查的目的是保证软件配置（在软件工程过程中产生的所有信息项，如文档、报告、程序、表格、数据等，称为软件配置）的所有成分齐全，各成分的质量都符合要求，具有维护阶段所必需的细节，且已编排好分类的目录确认测试的标准 所有的功能需求都得到了满足 所有性能需求都达到了 文档是正确且合理的 其他的需求 可移植性 兼容性 错误恢复 可维护性,4.4.4 系统测试,什么是系统测试 系统测试是将通过确认测试的软件，作为整个基于计算机系统的一个元素，与计算机硬件、外设、支持软件、数据等其它系统元素结合在一起，在实际运行（使用）环境下所进行的一系列测试活动 系统测试的目的 通过与系统的需求定义比较，检查软件是否存在与系统定义不符合或与之矛盾的地方，以验证软件系统的功能和性能等满足其规约所指定的要求。
4.4.5 验收测试,Acceptance testing（验收测试），系统开发生命周期方法论的一个阶段，这时相关的用户和／或独立测试人员根据测试计划和结果对系统进行测试和接收它让系统用户决定是否接收系统它是一项确定产品是否能够满足合同或用户所规定需求的测试验收测试的常用策略 Alpha 测试 Beta 测试,α测试是由一个用户在开发环境下进行的测试,也可以是公司内部的用户在模拟实际操作环境下进行的测试. α测试的目的是评价软件产品的FLURPS(即功能,局域化,可使用性,可靠性,性能和支持).尤其注重产品的界面和特色. α测试可以从软件产品编码结束之时开始,或在模块(子系统)测试完成之后开始,也可以在确认测试过程中产品达到一定的稳定和可靠程度之后再开始.,β测试是由软件的多个用户在实际使用环境下进行的测试.这些用户返回有关错误信息给开发者. 测试时,开发者通常不在测试现场.因而,β测试是在开发者无法控制的环境下进行的软件现场应用. 在β测试中,由用户记下遇到的所有问题,包括真实的以及主观认定的,定期向开发者报告. β测试主要着重于产品的支持性,包括文档,客户培训和支持产品生产能力.,4.4.6 回归测试,回归测试 在软件生命周期中的任何一个阶段，只要软件发生了改变，就可能给该软件带来问题。
每当软件发生变化时，就必须进行回归测试，重新测试原有的功能，以便确定修改是否达到了预期的目的，检查修改是否损害了原有的正常功能回归测试的使用时机,(a) 改错后进行回归测试,(b) 加入新代码后进行回归测试,冒烟测试（smoke test）的来历： 从电路板测试得来的因为当电路板做好以后，首先会加电测试，如果板子没有冒烟再进行其它测试，否则就必须重新来过类似的如果冒烟测试没有通过，那么这个build也会返回给开发队伍进行修正，测试人员测试的版本必须首先通过冒烟测试的考验 就象生产汽车一样，汽车生产出来以后，首先发动汽车，看汽车能否冒烟，如果能，证明汽车最起码可以开动了说明完成了最基本的功能其它测试类型介绍,4.5 评估测试,软件测试的主要评测方。