软件测试之【单元测试、系统测试、集成测试】

一、单元测试的概念
单元测试（Unit Testing）是对软件基本组成单元进行的测试，如函数（function或procedure）或一个类的方法（method）。当然这里的基本单元不仅仅指的是一个函数或者方法，有可能对应多个程序文件中的一组函数。

单元也具有一些基本的属性。比如：明确的功能、规格定义，明确的与其他部分的接口定义等，可清晰地与同一程序的其他单元化分开来。

二、单元测试的目的
单元测试的目的在于发现各模块内部可能存在的各种错误，主要是基于白盒测试。（也就是说，在单元测试过程中，用的最多的是白盒测试方法，也可能会有灰盒或者黑盒。单元测试和白盒测试是不同的划分，不存在包含关系）。

在单元测试阶段对应的文档是详细设计文档（LLD）；对应的代码就是单元代码，因此单元测试的目的主要有3点：

1、验证代码是与设计相符合的；

2、发现设计和需求中存在的错误；

3、发现在编码过程中引入的错误。

三、单元的常见错误
单元的常见错误一般出现在以下五个方面，因此这五个方面是单元测试应该关注的重点。

1、单元接口。

2、局部数据结构。

3、独立路径。

4、出错处理。

5、边界条件。

四、如何进行单元测试
在单元测试时，由于单元本身不是一个独立的程序，一个完整的可运行的软件系统并没有构成，所以需要设置一些辅助测试单元，辅助测试单元有两种，一种是驱动单元，另外一种是桩单元。

1、驱动单元（Driver）:用来模拟被测单元的上层单元，相当于被测函数的主函数，如main函数。所以驱动单元主要完成以下4个步骤：

（1）接受测试数据，包含测试用例输入和预期输出；

（2）把测试用例输入传送给被测单元，驱动被测单元测试；

（3）将被测单元的实际输出和预期输出进行比较，得到测试结果；

（4）将测试结果输出到指定位置。

2、桩单元（Stub）：用来代替被测单元工作过程中调用的子单元。

桩单元模拟的单元可能是自定义函数：这些自定义函数可能尚未编写完成，为了测试被测单元，需要构造桩单元来代替它们，可能存在错误，会影响测试结果，所以需要构造正确无误的桩单元来达到隔离的目的。

驱动单元和桩单元都是额外的开销，虽然在单元测试的时候必须写，但是并不需要作为最终的产品提供给客户。

五、单元测试策略
一般的单元执行策略有三种：孤立的单元测试策略（Isolation Unit Testing），自顶向下的单元测试策略（Top Down Unit Testing）和自底向上的单元测试策略（Bottom Up Unit Testing）。需要注意的是：在集成测试中也有自顶向下和自底向上的测试策略，但是测试对象不同。

1、孤立的单元测试策略（Isolation Unit Testing）

方法：不考虑每个模块与其它模块之间的关系，为每个模块设计桩模块和驱动模块，每个模块进行独立的单元测试。
 
优点：这个方法比较简单，最容易操作，可以达到很高的结构覆盖率，可以并行开展，该方法是纯粹的单元测试。
 
缺点：桩函数和驱动函数工作量很大，效率低。

2、自顶向下的单元测试策略（Top Down Unit Testing）

方法：先对最顶层的单元进行测试，把顶层所调用的单元做成桩模块，其次对第二层进行测试，使用上面已经测试过的单元做驱动模块，以此类推，直到测试完所有模块。
 
优点：可以节省驱动函数的开发工作，效率高。
 
缺点：随着被测单元一个一个被加入，测试过程将变得越来越复杂，并且开发和维护的成本将增加。

3、自底向上的单元测试策略（Bottom Up Unit Testing）

方法：先对最底层的模块进行单元测试，将模拟调用该模块的模块设置为驱动模块，然后再对上面一层做单元测试，用下面已经测试好的模块做桩模块，以此类推，直到测试完所有模块。
 
优点：可以节省桩函数的开发工作量，测试效率较高。
 
缺点：不是纯粹的单元测试，底层函数的测试质量对上层函数的测试将产生很大影响。

六、系统测试的概念
系统测试（System Testing）的定义：将已经集成好的软件系统，作为整个基于计算机系统的一个元素，与计算机硬件、外设、某些支持软件、数据和人员等其他系统元素结合在一起，在实际运行（使用）的环境下，对计算机系统进行一系列的组装测试和确认测试。

系统测试的对象：软硬件集合在一起的系统，集成后的产品，不应是独立的软件与硬件环境。不仅仅包括需测试的软件，还要包含软件所依赖的硬件、外设，甚至包括某些数据、某些支持软件的系统等。

目的：通过与系统的需求定义做比较，发现软件与系统定义不符合或与之矛盾的地方，以验证软件的功能和性能等满足其规约所指定的要求。

常见的系统分类：

纯软件：QQ.................

软件和硬件：手机，PSP，空调，电梯

软件硬件和维护人员：大型系统

七、系统测试的环境
真实环境：直接将整个系统和其交联的物理设备真实的建立链接，进行测试

优点：可以发现某些只能在真实环境下出现的问题

缺点：构建这样一个环境需要高昂的费用，它的测试运行也需要高昂的费用

仿真环境：它能够逼真的模拟被测试软件运行所需的真实物理环境的输入与输出，并且能够组织被测软件的输入，来驱动被测软件运行，同时接收被测软件的输出结果。

优点：仿真环境和真实环境的软件依赖是一样的，并且它能够保证测试的可重复性、完整性、可扩展性

Example 1：某系统环境搭建的要求

硬件环境：

CPU：主频2GHZ以上，4核及以上

内存：4GB及以上

硬盘：可用空间10G以上

软件环境：

平台要求：Windows XP/2003标准版+Apache2.2.X+Mysql5.0及以上版本

目录权限：目录/Attachment，/Cache及文件需要写的权限

推荐平台：推荐使用XAMPP作为安装介质

选用测试工具应考虑的因素：

1.测试工具与被测软件系统的匹配程度

2.测试工具提供的主要功能和辅助机制

3.测试工具的服务和技术支持

4.测试工具的价格

测试数据：

特点：

1.数据可以以消息、事物、记录、文件等形式存在

2.数据来源很多

3.真实数据最好，但在很多情况下不易或者不能得到

来源：

1.产品数据

2.手工构造数据

3.生成数据（一般由工具设备构造）

4.捕获数据（少用，与捕获数据源有关，允许手工修改）

5.随机数据（系统测试少用，它易于获得，不够真实，性能测试常用）

产品数据

1.最具真实性

2.不能覆盖所需所有场景

3.数据敏感，很难保证正确性

4.随时间变化

5.可能数据量太大（从而降低测试执行速度）

手工构造数据

1.费时间、枯燥

2.如果对系统的功能缺乏了解，数据不真实

3.有时是获得特定测试用例所需独特数据的唯一手段

生成数据

1.一般由工具或设备构造

2.数据取决于工具的完善程度和测试人员的关于如何构造数据的规格说明

捕获数据

1.与捕获数据源无关

2.允许手工修改

随机数据

1.易于获得，不够真实

2.对强度或负载测试是非常有用的

八、系统测试的类型
常见的测试类型：

功能测试（配置测试、恢复性测试、备份测试）

性能测试（压力测试、稳定性测试、容量测试）

GUI测试（可用性测试）

兼容性测试

安全性测试（网络测试）

安装性测试

文档测试

功能测试

概念：根据SRS和 需求列表，验证产品的功能实现是否符合产品的需求规格

目标:

1.是否有不正确或者遗漏了的功能（做错或少做）

2.功能实现是否满足用户需求和系统设计的隐藏需求

3.能否正确的接受输入，能否正确的输出结果

功能测试步骤：

1.对每个明确的功能需求进行标号

2.对每个隐含的功能需求进行标号

3.对可能出现的功能异常进行分类分析并且标号

4.把功能划分为关键功能和非关键功能

5.对每个功能进行测试分析，分析其是否可测，如何测试，可能的输入、输出

6.脚本化和自动化

性能测试

概念：用来测试软件在集成系统中的运行性能

目标: 度量系统各项指标，确认系统有无各种性能瓶颈

特点：混合白盒测试和黑盒测试的方法

性能测试考虑的两个方面:

1.验证系统实现的性能是否与性能需求完全一致

2.检测系统实现的具体性能到底怎样

常用方法：探针，测试驱动

常用工具：Loadrunner,WebLoad,SilkPerformer

GUI测试

概念：针对软件系统界面进行的测试

目标：1.测试界面实现与界面设计的吻合情况 2.确认界面处理的正确性

关注点：界面层与功能接口层上（GUI系统分为三个层次：界面层、界面与功能的接口层、功能层）

常用工具：QTP，QARun

兼容性测试

概念：考虑被测试软件在其他软件（例如操作系统）或硬件设备下的运行情况。

目标：1.与辅助软件的结合情况（操作系统，其他应用程序，测试软件，监控软件，浏览器等）； 2.与硬件设计的结合情况（由于兼容性测试对硬件要求较多，一般无特殊要求都只会针对软件要求做测试）。

安全性测试

概念：验证集成在系统内的保护机制是否能够在实际中保护系统不受非法的侵入，用来保护数据本身的完整性和保密性。广义的还包括物理安全和业务安全。

范围：主要从几个方面考虑：系统登录，用户管理，防火墙，系统数据，WEB安全，数据库安全，内部通讯，系统防毒测试等。

保护测试是安全测试中的一种常见的测试，主要用于测试系统的信息保护机制

安装性测试

概念：主要依据软件的测试特征列表、软件安装、配置文档、设计安装过程的测试用例，发现软件在安装过程中的错误。

目标：找出软件安装的错误，安装手册的错误。

安装测试前所要做的检查工作：

1.安装文档是否齐全

2.安装软件的程序文件是否齐全

3.被测试的安装文件是否齐全

4.软件的文件格式是否与安装指导中的要求的文件格式相符

常用自动化安装测试软件：Total Uninstall:它能够监视软件安装的所有过程，记录下它对系统所做的任何改变FileRiver:可以自动监视和准确记录下多个文件夹中的文件以及子文件的细微变化。

文档测试

概念：主要针对软件需求说明书，安装手册，配置指南等文档，测试内容主要是编写规范，内容正确性，无歧义性，完整性。

目标：验证用户文档是正确的并且保证操作手册的过程能够正确工作。

九、系统测试的过程
测试阶段的划分

系统测试计划阶段：完成系统测试计划（规划和步骤）

系统测试设计阶段：完成系统测试方案

系统测试实现阶段：完成系统测试用例，系统测试规程，系统测试预测试（冒烟测试）项

系统测试执行阶段：执行系统测试预测试，系统测试用例，开展回归测试，校验已修复的问题，提交系统预测试报告，系统测试报告，缺陷报告

过程：软件需求分析、设计（概要）、系统测试（执行）

系统测试中的角色及职责

开发代表：解决资源需求，对系统测试结果进行监督

QA：系统测试过程质量保证，参与相关评审，对过程进行审计

配置管理组：对系统测试文档，及测试代码等相关配置进行配置管理

软件开发组：

1.系统测试计划阶段，提供软件开发计划SDP，参与系统测试计划的评审

2.系统测试设计和实现阶段，提供SRS，需求分析，测试建议，响应系统测试需求，参与软件系统测试方案的评审

3.系统测试执行阶段，跟踪解决软件测试项目组的缺陷问题报告单，参与系统测试报告的评审

软件测试组：

1.系统测试计划阶段，制定系统测试计划并组织评审

2.系统测试设计和实现阶段，制定软件测试方案并组织评审，按照软件系统测试方案，实现测试用例，测试代码和测试工具等设计，编写测试规程

3.系统测试执行阶段，执行系统测试，反馈并跟踪缺陷问题报告单，完成系统测试报告并组织评审，输出测试案例、总结等经验文档

系统分析组：

1.提出系统测试需求

2.进行测试需求跟踪

3.进行软件系统可测性分析，确定系统测试的对象、范围和方法

系统测试计划的要点

1.明确系统测试的被测对象

2.完成系统测试的需求跟踪

3.明确系统的通过或失败标准

4.系统测试的挂起标准及恢复的必要条件

5.明确系统测试工作任务分配

6.系统测试结束后应交付的工作产品

系统测试设计的要点

1.测试环境和测试数据的准备

2.测试工具的开发/场景设计

3.系统测试用例设计

4.测试策略的选择（如：测试几轮）

系统测试方案和系统测试计划的区别

系统测试计划：对系统测试全过程的组织、资源、原则等进行规定和约束，并制定系统测试全过程各个阶段的任务以及时间进度安排，并提出对各项任务的评估、风险分析和管理需求。

系统测试方案：描述系统需要测试的特性，测试的方法，测试环境的规划，测试工具的设计和选择，测试用例的设计方法，测试代码的设计方案。（设计测试方法的细节文档）

注：案需要在系统测试计划的指导下进行，系统测试计划提出做什么，而系统测试方案明确提出“如何做”

系统测试执行概述

1.按一定的系统测试计划，依据系统测试用例，完成测试的各项操作任务

2.根据系统测试方案，搭建系统测试环境是系统测试执行的一个重要步骤，测试环境时候与否会严重影响测试结果的真实性和正确性

3.系统测试执行阶段应完成：环境准备、测试操作、测试记录、测试报告

4.执行的时间安排：在集成测试执行完成之后进行系统测试的执行

系统测试预测试

目的：验证软件系统基本功能或预测主要的系统功能，以确保其后的系统测试执行能够顺利进行。

时间安排：系统预测试应在开发项目组提出软件版本转系统测试申请后进行，主要是完成转系统测试评审需要输入的《软件系统与测试报告》。

人员安排：执行验证软件基本功能活动的主体可以是软件开发项目组也可以是软件测试项目组或联合的组织。

转系统测试评审

1.评审责任的主体为软件项目测试组，需要完成软件转系统测试评审表

2.软件版本转系统测试通过后，才能启动执行系统测试过程

3.启动执行系统测试过程后，系统预测试相关的软件版本，测试代码，文档，环境等均应在配置管理中基线化

系统测试报告写作和评审

1.依据系统测试计划的测试通过准责，结束系统测试后，撰写系统测试报告

2.系统测试报告需要通过评审，责任人为软件测试项目组，由软件开发项目组，配置管理小组和QA参与

3.评审不通过，系统测试报告退回。在评审不符合项和问题解决后再提交评审申请，或重新启动系统测试过程

4.评审通过后，系统测试相关文档、代码、工具等均需跟随软件代码，开发文档一起完成配置基线化，系统测试过程结束

系统测试日报的写作目的

1.测试人员总结每天的测试工作，便于了解自己的测试进度和测试情况，用以调整下一天的工作计划

2.测试人员对被测对象每天给出评估结果，用以调整后续工作的测试策略

3.测试人员向测试经理反映测试中的困难，保证测试的顺利进行

4.测试经理通过测试日报，了解每个工作人员的测试进度，把握测试的整体进度，发现进度上的风险及时调整计划

5.测试经理通过测试日报，了解各模块缺陷发展的趋势，判断测试是否可以退出

6.开发经理可以通过软件测试日报了解当前软件的质量情况，并可以调整缺陷修改的人力资源、

7.如果软件有多个测试组并行测试，测试日报可以提供彼此测试交流的手段

系统测试步骤

需求分析 -> 计划、方案 -> 用例设计 -> 环境搭建 -> 执行 -> 测试报告

需求分类： 1. 项目需求（用户自己提需求） 2．产品需求（产品人员进行调查撰写）

基线：第一种说法：软件版本相对稳定 第二种说法：文档经过多次评审修改之后封存起来，任何人需求修改都要提出申请。

十、集成测试概念

    1.集成测试也叫组装测试、联合测试、子系统测试或部件测试。
    2.集成测试是在单元测试的基础上，将所有模块按照概要设计要求（如根据结构图）组装成为子系统或系统，进行集成测试。

十一、集成测试的目的

    1.找出模块接口以及整体体系结构上的问题；
    
    2.确保各组件组合在一起后能够按照既定意图协作运行，并确保增量的行为正确；
    
    3.集成测试属于灰盒测试；
    
            1)验证接口是否与设计相符合；
            
            2)发现设计和需求中存在的错误。

十二、集成测试关注的重点

一些模块虽可以单独正常工作，但不能保证连接起来也能正常工作，程序在某些局部反映不出来的问题，在全局上就很有可能暴露出来，影响功能的实现。

因此，集成测试应当考虑一下两个问题：

1.模块间的接口（需要考虑的有两点）

        1)在把各个模块连接起来的时候，穿越模块接口的数据是否会丢失；
            
        2)全局数据结构是否有问题，会不会被异常修改。

2.集成后的功能（需要考虑三点）

        1)各个子功能组合起来，能否达到预期要求的父功能；
            
        2)一个模块的功能是否会对另一个模块的功能产生不利的影响；
            
        3)单个模块的误差积累起来，是否会放大，从而达到不可接受的程度。

十三、集成测试的层次
一个产品的开发过程包括了一个分层的设计和逐步细化的过程，从最初的产品到最小的单元可以划分为：产品——>子系统——>硬件子系统、软件子系统——>软件模块——软件程序——>单元。

一般单元测试针对最小的单元结构，系统测试对应于产品级，而当中的所有各层测试都需要通过集成测试来完成，由于集成的力度不同，因此将集成测试划分为3个级别：

    1.模块内集成测试（单元测试完成后）
        
    2.子系统内集成测试，即模块间集成测试
    
    3.子系统间集成测试

十四、集成测试策略

集成测试策略是在测试对象分析的基础上，描述软件模块集成（组装）的方式、方法，分类如下：

1.大爆炸集成（Big Bang Integration）

是属于非增值式集成（Non-Incremental Integration）的一种方法，也叫一次性组装或整体拼装。该集成把所有系统组件一次性集合到被测系统中，不考虑组件之间的相互依赖性或者可能存在的风险。应用一个系统范围内的测试包来证明系统最低限度的可操作性。
 
    1)方法(策略)
        a.在这种集成方式中，首先对每个模块分别进行单元测试
        b.然后再把所有单元组装在一起进行测试        
        c.最后得到要求的软件系统
            
    2)目的
        在最短时间内把系统组装出来，并且通过最少的测试来验证整个系统
            
    3)优点
        a.在有利的情况下，大爆炸集成可以迅速完成集成测试，并且只要极少数的驱动和桩模块设计（如果需要的话）;
        b.它需要的测试用例也是很少的;
        c.该方法比较简单；
        d.多个测试人员可以并行工作，对人力，物力资源利用率较高。
 
    4)缺点
        a.这种一次性组装方式试图在辅助模块的协助下，在模块单元测试的基础上，将所测模块连接起来进行测试，但是由于程序中不可避免地存在模块间接口、全局数据结构等方面的问题，所以一次试运行成功的可能性并不很大;
        b.在发现错误的时候，其问题定位和修改都比较困难;
        c.即使被测系统能够被一次性集成，但还是会有很多接口错误很容易的躲过测试而进入到系统范围测试内。
 
    5)适用范围
        a.维护型项目（或功能增强型项目），其以前的产品已经很稳定，并且新增的项目只有少数几个组件被增加和修改；
        b.被测系统比较小，并且它的每个组件都经过了充分的单元测试；
        c.产品使用了严格的净室软件工程过程，并且每个开发阶段的质量和单元测试质量都非常高。

2.自顶向下的集成策略（Top-Down Integration）

采用了和设计一样的顺序对系统进行测试，在第一时间内对系统的控制接口进行了验证。
 
    1)方法（策略）
         a. 以主模块为所测模块兼驱动模块，所有直属于主模块的下属模块全部用桩模块替换，对主模块进行测试；
         b.采用深度优先（Depth-First）或者宽度优先（Breath-First）的策略，用实际模块替换相应桩模块，再用桩替代它们的直接下属模块，与已测试的模块或子系统组装成新的子系统；
            c.进行回归测试，排除组装过程中引起的错误的可能；
         d.判断所有的模块是否都已组装到系统中?如果是，则结束测试，否则转到b步骤去执行。
            
    2）目的
        从顶层控制开始，采用同设计顺序一样的思路对被测系统进行测试，以验证系统的接口稳定性。
            
    3）优点
        a.自顶向下的增殖方式在测试过程中较早的验证了主要的控制和判断点;
        b.功能可行性较早得到证实，还能够给开发者和用户带来成功的信心;
        c.最多只需要一个驱动模块，减少了驱动器开发的费用；
        d.由于和设计顺序的一致性，可以和设计并行进行，如果目标环境可能存在改变，该方法可以灵活的适应；
        e.支持故障隔离。
 
    4）缺点
        a.桩的开发和维护是本策略的最大成本，随着桩数目增加，成本急剧上升;
        b.底层组件中一个无法预计的需求可能会导致许多顶层组件的修改，这破坏了部分先前构造的测试包;
        c.底层组件行为的验证被推迟；
        d.随着底层模块的不断增加，整个系统越来越复杂。
 
    5）适用范围
        适用于大部分采用结构化编程方法的软件产品，且产品的结构相对比较简单，对于具有以下属性的产品，可以优先考虑该策略：
        a.产品控制结构比较清晰和稳定；
        b.产品的高层接口变化比较小；
        c.产品底层接口未定义或经常可能被修改；
        d.产品控制模块具有较大的技术风险，需要尽早被验证；
        e.希望尽早可以看到产品的系统功能行为；
        f.在极端编程（Extreme Program）中使用探索式开发风格时，其集成策略可以采用自顶向下。

3.自底向上的集成策略（Bottom-Up Integration）

是从程序模块结构的最底层的模块开始组装和测试，因为模块是自底向上进行组装，对于一个给定层次的模块，它的子模块（包括子模块下属所有模块）已经组装并测试完成，所有不在需要桩模块。在模块的测试过程中需要从子模块得到的信息可以通过直接运行子模块得到。

4.三明治集成（Sandwich Integration）

也称为混合式集成，集合了自顶向下和自底向上两种策略的优点，它将系统划分为3层，中间一层为目标层，测试的时候，对目标层上面的一层使用自顶向下的集成策略，对目标层下面的一层使用自底向上的集成策略，最后测试在目标层会合。

5.基干集成（Backbone Integration）

在很多系统中，尤其是嵌入式系统，一般划分为两个部分：内和部分（基干部分）和外围应用部分，这两部分经常被不同的项目组并行开发，该策略首先要识别应用的控制组件部分，基干部分和应用子系统部分，然后进行测试。
结合自顶向下，自底向上和大爆炸集成的元素，验证紧密耦合的子系统之间的互操作性。

6.分层集成（Layers Integration）

分层集成是针对分层模型使用的一种策略。
通过增量式集成的方法验证一个具有层次体系结构的应用系统的稳定性和可互操作性。

7.基于功能的集成（Function-Based Integration）

是从功能角度出发，按照功能的关键程度对模块的集成顺序进行组织。
采用增值的方法，尽早的验证系统关键功能。

8.基于进度的集成（Schedule-Based Integration）

考虑了项目的进度压力，兼顾进度和质量，在两者之间寻找均衡点进行测试，该集成的最基本策略是把最早可获得的代码拿来立即进行集成，必要的时候开发桩模块和驱动模块，在最大程度上保持与开发的并行性，从而缩短了项目集成的时间。

9.基于风险的集成（Risk-Based Integration）

是基于假设：系统风险最高的模块间的集成往往是错误集中的地方，因此尽早的验证这些接口有助于加速系统的稳定。所以该集成需在第一时间内验证高危模块间的接口，保证系统的稳定性。

10.基于事件（消息）的集成（Event/Message-Based Integration）

针对基于状态机的系统（工作原理是基于状态变迁，内部模块间的接口主要通过消息来完成），因此该集成是从验证消息路径的正确性角度出发，渐增式的把系统集成到一起，从而验证系统的稳定性。

11.基于使用的集成（Use-Based Integration）

针对面向对象的系统，从分析类之间的依赖关系出发，通过从最小依赖关系的类开始集成，逐步扩大，最后集成到整个系统，通过该集成方法，可以验证类之间接口的正确性。

12.分布式集成（Distributed Services Integration）

针对可以有许多并发运行、没有专门控制轨迹的组件、以及没有专门服务器层的分布式系统。
验证松散耦合的同级组件之间交互的稳定性。

13.客户/服务器的集成（Client/Server Integration）

对于和单独的服务器组件进行松散耦合的客户端组件，可以使用客户/服务器集成来完成。
验证客户和服务器之间交互的稳定性。

14.高频集成（High-frequency Integration）

快速迭代式开发和增量式开发可能会导致系统功能的遗漏和冲突，该集成主要是为了避免以上问题，同时控制可能出现的基线偏差。