软件测试基础教程杜文洁 景秀丽 主编中国水利水电出版社第三章 软件测试流程第三章 软件测试流程
3.1 软件测试的复杂性与经济性分析
3.2 软件测试的流程
3.3 单元测试
3.4 集成测试
3.5 确认测试
3.6 系统测试
3.7 验收测试习题本章概要第三章 软件测试流程
软件测试的复杂性和经济性
软件测试的相关流程：单元测试、集成测试、确认测试、系统测试和验收测试等基本测试阶段。
3.1 软件测试的复杂性与经济性分析第三章 软件测试流程人们在对软件工程开发的常规认识中，认为开发程序是一个复杂而困难的过程，需要花费大量的人力、物力和时间，而测试一个程序则比较容易，不需要花费太多的精力。这其实是人们对软件工程开发过程理解上的一个误区。在实际的软件开发过程中，
作为现代软件开发工业一个非常重要的组成部分，软件测试正扮演着越来越重要的角色。随着软件规模的不断扩大，如何在有限的条件下对被开发软件进行有效的测试正成为软件工程中一个非常关键的课题。
3.1.1 软件测试的复杂性第三章 软件测试流程设计测试用例是一项细致并且需要具备高度技巧的工作，稍有不慎就会顾此失彼，发生不应有的疏漏。下面分析了容易出现问题的根源。
(1) 完全测试是不现实的在实际的软件测试工作中，不论采用什么方法，由于软件测试情况数量极其巨大，都不可能进行完全彻底的测试。所谓彻底测试，
就是让被测程序在一切可能的输入情况下全部执行一遍。通常也称这种测试为“穷举测试”。
穷举测试会引起以下几种问题：
输入量太大；
输出结果太多；
软件执行路径太多；
说明书存在主观性。
3.1.1 软件测试的复杂性第三章 软件测试流程
E.W.Dijkstra的一句名言对测试的不彻底性作了很好的注解：“程序测试只能证明错误的存在，但不能证明错误的不存在”。由于穷举测试工作量太大，实践上行不通，这就注定了一切实际测试都是不彻底的，也就不能够保证被测试程序在理论上不存在遗留的错误。
3.1.1 软件测试的复杂性第三章 软件测试流程
(2) 软件测试是有风险的穷举测试的不可行性使得大多数软件在进行测试的时候只能采取非穷举测试，这又意味着一种冒险。比如在使用 Microsoft Office工具中的 Word时，可以作这样的一个测试：①新建一个 Word文档；②
在文档中输入汉字,胡”；③设置其字体属性为“隶书”，字号为初号，效果为,空心”；④将页面的显示比例设为,500%”。这时在“胡”字的内部会出现“胡万进印”四个字。类似问题在实际测试中如果不使用穷举测试是很难发现的，而如果在软件投入市场时才发现则修复代价就会非常高。这就会产生一个矛盾：软件测试员不能做到完全的测试，不完全测试又不能证明软件的百分之百的可靠。那么如何在这两者的矛盾中找到一个相对的平衡点呢？
3.1.1 软件测试的复杂性第三章 软件测试流程如图 3-1所示的最优测试量示意图可以观察到，当软件缺陷降低到某一数值后，随着测试从量的不断上升软件缺陷并没有明显地下降。这是软件测试工作中需要注意的重要问题。如何把测试数据量巨大的软件测试减少到可以控制的范围，如何针对风险做出最明智的选择是软件测试人员必须能够把握的关键问题。
图 3-1的最优测试量示意图说明了发现软件缺陷数量和测试量之间的关系，
随着测试量的增加，测试成本将呈几何数级上升，而软件缺陷降低到某一数值之后将没有明显的变化，最优测量值就是这两条曲线的交点。
3.1.1 软件测试的复杂性第三章 软件测试流程图 3-1 最优测试量示意图
3.1.1 软件测试的复杂性第三章 软件测试流程
(3) 杀虫剂现象
1990年,Boris Beizer在其编著的,Software Testing Techniques》
（第二版）中提到了“杀虫剂怪事”一词，同一种测试工具或方法用于测试同一类软件越多，则被测试软件对测试的免疫力就越强。
这与农药杀虫是一样的，老用一种农药，则害虫就有了免疫力，农药就失去了作用。
由于软件开发人员在开发过程中可能碰见各种各样的主客观因素，
再加上不可预见的突发性事件，所以再优秀的软件测试员采用一种测试方法或者工具也不可能检测出所有的缺陷。为了克服被测试软件的免疫力，软件测试员必须不断编写新的测试程序，对程序的各个部分进行不断地测试，以避免被测试软件对单一的测试程序具有免疫力而使软件缺陷不被发现。这就对软件测试人员的素质提出了很高的要求。
3.1.1 软件测试的复杂性第三章 软件测试流程
(4) 缺陷的不确定性在软件测试中还有一个让人不容易判断的现象是缺陷的不确定性。即并不是所有的软件缺陷都需要被修复。对于究竟什么才算是软件缺陷是一个很难把握的标准，在任何一本软件测试的书中都只能给出一个笼统的定义。实际测试中需要把这一定义根据具体的被测对象明确化。即使这样，具体的测试人员对软件系统的理解不同，
还是会出现不同的标准。
3.1.2 软件测试的经济性第三章 软件测试流程软件测试的经济性有两方面体现：
一是体现在测试工作在整个项目开发过程中的重要地位；
二是体现在应该按照什么样的原则进行测试，以实现测试成本与测试效果的统一。
软件工程的总目标是充分利用有限的人力和物力资源，高效率、
高质量地完成测试。结合 3.1.1节关于穷举测试具有不可行性，就可以理解为什么要在测试量与测试成本的曲线中选取最优测试点。
3.1.3 软件测试的充分性准则第三章 软件测试流程软件测试的充分性准则有以下几点：
对任何软件都存在有限的充分测试集合；
当一个测试的数据集合对于一个被测的软件系统的测试是充分的，那么再多增加一些测试数据仍然是充分的。这一特性称为软件测试的单调性；
即使对软件所有成分都进行了充分的测试，也并不意味着整个软件的测试已经充分了。这一特性称为软件测试的非复合性；
即使对一个软件系统整体的测试是充分的，也并不意味着软件系统中各个成分都已经充分地得到了测试。这个特性称为软件测试的非分解性；
软件测试的充分性与软件的需求、软件的实现都相关；
软件测试的数据量正比于软件的复杂度。这一特性称为软件测试的复杂性；
随着测试次数的增加，检查出软件缺陷的几率随之不断减少。软件测试具有回报递减率。
3.1.4 软件测试的误区第三章 软件测试流程随着软件产业工业化、模块化地发展，在软件开发组中软件测试人员的重要性也不断地突出。在国外，很多著名企业早已对软件测试工作十分重视。比如著名的微软公司，其软件测试人员与开发人员的比例已经达到 2:1。可见软件测试对于一个软件开发项目的成功与否具有十分重要的意义。但是在实际的项目开发与管理中仍然存在很多管理上或者技术上的误区：
(1) 期望用测试自动化代替大部分人工劳动
(2) 忽视需求阶段的参与
(3) 软件测试是技术要求不高的岗位
3.2 软件测试的流程第三章 软件测试流程
1,软件开发的 V模型软件测试是有阶段性的，而软件测试的流程与软件设计周期究竟是什么样的关系呢？关于软件开发流程的 V模型是一个广为人知的模型,如图 3-2所示
。在 V模型中，从左到右描述了基本的开发过程和测试行为，为软件的开发人员和测试管理者提供了一个极为简单的框架。 V模型的价值在于它非常明确地标明了测试过程中存在的不同级别，并且清楚地描述了这些测试阶段和开发过程期间各阶段的对应关系。
在 V模型中各个测试阶段的执行流程是：单元测试是基于代码的测试，最初由开发人员执行，以验证其可执行程序代码的各个部分是否已达到了预期的功能要求；集成测试验证了两个或多个单元之间的集成是否正确，并且有针对性地对详细设计中所定义的各单元之间的接口进行检查；在单元测试和集成测试完成之后，系统测试开始用客户环境模拟系统的运行，以验证系统是否达到了在概要设计中所定义的功能和性能；最后，当技术部门完成了所有测试工作，由业务专家或用户进行验收测试，以确保产品能真正符合用户业务上的需要。 图 3-2描绘出了各个测试环节在整个软件测试工作中的相互联系与制约关系。
3.2 软件测试的流程第三章 软件测试流程图 3-2 V模型示意图
3.2 软件测试的流程第三章 软件测试流程
2．软件测试过程软件测试过程按各测试阶段的先后顺序可分为单元测试、集成测试、确认（有效性）测试、系统测试和验收（用户）测试 5个阶段，如图 3-3所示。
(1) 单元测试：测试执行的开始阶段。测试对象是每个单元。测试目的是保证每个模块或组件能正常工作。单元测试主要采用白盒测试方法，检测程序的内部结构。
(2) 集成测试：也称组装测试。在单元测试基础上，对已测试过的模块进行组装，
进行集成测试。测试目的是检验与接口有关的模块之间的问题。集成测试主要采用黑盒测试方法。
(3) 确认测试：也称有效性测试。在完成集成测试后，验证软件的功能和性能及其他特性是否符合用户要求。测试目的是保证系统能够按照用户预定的要求工作。
确认测试通常采用黑盒测试方法。
(4) 系统测试：在完成确认测试后，为了检验它能否与实际环境（如软硬件平台、
数据和人员等）协调工作，还需要进行系统测试。可以说，系统测试之后，软件产品基本满足开发要求。
(5) 验收测试：测试过程的最后一个阶段。验收测试主要突出用户的作用，同时软件开发人员也应该参与进去。
3.2 软件测试的流程第三章 软件测试流程软件测试阶段的输入信息包括两类：
软件配置：指测试对象。通常包括需求说明书、设计说明书和被测试的源程序等；
测试配置：通常包括测试计划、测试步骤、测试用例以及具体实施测试的测试程序、测试工具等。
对测试结果与预期的结果进行比较以后，即可判断是否存在错误，
决定是否进入排错阶段，进行调试任务。对修改以后的程序要进行重新测试，因为修改可能会带来新的问题。
通常根据出错的情况得到出错率来预估被测软件的可靠性，这将对软件运行后的维护工作有重要价值。
3.2 软件测试的流程第三章 软件测试流程图 3-3 测试各阶段示意图
3.3 单元测试第三章 软件测试流程
1．单元测试的定义单元测试（ Unit Testing）是对软件基本组成单元进行的测试。单元测试的对象是软件设计的最小单位 —— 模块。很多人将单元的概念误解为一个具体函数或一个类的方法，这种理解并不准确。作为一个最小的单元应该有明确的功能定义、性能定义和接口定义，而且可以清晰地与其他单元区分开来。一个菜单、一个显示界面或者能够独立完成的具体功能都可以是一个单元。从某种意义上单元的概念已经扩展为组件（ component）。
3.3 单元测试第三章 软件测试流程
2．单元测试的目标单元测试的主要目标是确保各单元模块被正确地编码。单元测试除了保证测试代码的功能性，还需要保证代码在结构上具有可靠性和健全性，并且能够在所有条件下正确响应。进行全面的单元测试，
可以减少应用级别所需的工作量，并且彻底减少系统产生错误的可能性。如果手动执行，单元测试可能需要大量的工作，自动化测试会提高测试效率。
3.3 单元测试第三章 软件测试流程
3．单元测试的内容单元测试的主要内容有：
模块接口测试；
局部数据结构测试；
独立路径测试；
错误处理测试；
边界条件测试。
如图 3-4所示，这些测试都作用于模块，共同完成单元测试任务。
模块接口测试：对通过被测模块的数据流进行测试。为此，对模块接口，包括参数表、调用子模块的参数、全程数据、文件输入 /输出操作都必须检查。
3.3 单元测试第三章 软件测试流程局部数据结构测试：设计测试用例检查数据类型说明、初始化、默认值等方面的问题，还要查清全程数据对模块的影响。
独立路径测试：选择适当的测试用例，对模块中重要的执行路径进行测试。
基本路径测试和循环测试可以发现大量的路径错误，是最常用且最有效的测试技术。
错误处理测试：检查模块的错误处理功能是否包含有错误或缺陷。例如，
是否拒绝不合理的输入；出错的描述是否难以理解、是否对错误定位有误、
是否出错原因报告有误、是否对错误条件的处理不正确；在对错误处理之前错误条件是否已经引起系统的干预等。
边界条件测试：要特别注意数据流、控制流中刚好等于、大于或小于确定的比较值时出错的可能性。对这些地方要仔细地选择测试用例，认真加以测试。此外，如果对模块运行时间有要求的话，还要专门进行关键路径测试，以确定最坏情况下和平均意义下影响模块运行时间的因素。这类信息对进行性能评价是十分有用的。
3.3 单元测试第三章 软件测试流程
4．单元测试的步骤通常单元测试在编码阶段进行。当源程序代码编制完成，经过评审和验证，确认没有语法错误之后，就开始进行单元测试的测试用例设计。利用设计文档，设计可以验证程序功能、找出程序错误的多个测试用例。对于每一组输入，应有预期的正确结果。
模块接口测试中的被测模块并不是一个独立的程序，在考虑测试模块时，同时要考虑它和外界的联系，用一些辅助模块去模拟与被测模块相关联的模块。这些辅助模块可分为两种：
(1) 驱动模块（ driver）：相当于被测模块的主程序。它接收测试数据，把这些数据传送给被测模块，最后输出实测结果。
(2) 桩模块（ stub）：用以代替被测模块调用的子模块。桩模块可以做少量的数据操作，不需要把子模块所有功能都带进来，但不允许什么事情也不做。
3.3 单元测试第三章 软件测试流程被测模块、与它相关的驱动模块以及桩模块共同构成了一个“测试环境”，如图 3-5所示。
如果一个模块要完成多种功能，并且以程序包或对象类的形式出现，例如 Ada中的包,MODULA中的模块,C++中的类，这时可以将模块看成由几个小程序组成。对其中的每个小程序先进行单元测试要做的工作，对关键模块还要做性能测试。对支持某些标准规程的程序，更要着手进行互联测试。有人把这种情况特别称为模块测试，以区别单元测试。
3.3 单元测试第三章 软件测试流程图 3-4 单元测试任务
3.3 单元测试第三章 软件测试流程
5．采用单元测试的原因程序员编写代码时，一定会反复调试保证其能够编译通过。如果是编译没有通过的代码，没有任何人会愿意交付给自己的老板。但代码通过编译，只是说明了它的语法正确，程序员却无法保证它的语义也一定正确。没有任何人可以轻易承诺这段代码的行为一定是正确的。单元测试这时会为此做出保证。编写单元测试就是用来验证这段代码的行为是否与软件开发人员期望的一致。有了单元测试，
程序员可以自信的交付自己的代码，而没有任何的后顾之忧。
3.3 单元测试第三章 软件测试流程图 3-5 单元测试环境
3.3 单元测试第三章 软件测试流程通过单元测试，测试人员可以验证开发人员所编写的代码是按照先前设想的方式进行的，输出结果符合预期值，这就实现了单元测试的目的。与后面的测试相比，单元测试创建简单，维护容易，
并且可以更方便的进行重复。,实用软件度量,（ Capers Jones，
McGraw-Hill 1991）列出了准备测试、执行测试和修改缺陷所花费的时间（以一个功能点为基准），这些测试显示出了单元测试的成本效率大约是集成测试的两倍、系统测试的三倍，如图 3-6所示。术语域测试是指软件在投入使用后，针对某个领域所作的所有测试活动。
3.3 单元测试第三章 软件测试流程图 3-6 各测试阶段发现缺陷的耗时
3.4 集成测试第三章 软件测试流程
1．集成测试的定义在完成单元测试的基础上，需要将所有模块按照设计要求组装成为系统。这时需要考虑以下问题：
在把各个模块连接起来的时候，穿越模块接口的数据是否会丢失；
一个模块的功能是否会对另一个模块的功能产生不利的影响；
各个子功能组合起来，能否达到预期要求的父功能；
全局数据结构是否有问题；
单个模块的误差累积起来，是否会放大，从而达到不能接受的程度；
单个模块的错误是否会导致数据库错误。
3.4 集成测试第三章 软件测试流程集成测试（ Integration Testing）是介于单元测试和系统测试之间的过渡阶段，与软件开发计划中的软件概要设计阶段相对应，是单元测试的扩展和延伸。
集成测试的定义是根据实际情况对程序模块采用适当的集成测试策略组装起来，对系统的接口以及集成后的功能进行正确校验的测试工作。
3.4 集成测试第三章 软件测试流程
2．集成测试的层次软件的开发过程是一个从需求分析到概要设计、详细设计以及编码实现的逐步细化的过程，那么单元测试到集成测试再到系统测试就是一个逆向求证的过程。集成测试内部对于传统软件和面向对象的应用系统有两种层次的划分。
对于传统软件来讲，可以把集成测试划分为三个层次：
模块内集成测试；
子系统内集成测试；
子系统间集成测试。
对于面向对象的应用系统来说，可以把集成测试分为两个阶段：
类内集成测试；
类间集成测试。
3.4 集成测试第三章 软件测试流程
3．集成测试的模式选择什么方式把模块组装起来形成一个可运行的系统，直接影响到模块测试用例的形式、所用测试工具的类型、模块编号的次序和测试的次序、生成测试用例的费用和调试的费用。集成测试模式是软件集成测试中的策略体现，其重要性是明显的，直接关系到软件测试的效率、结果等，一般是根据软件的具体情况来决定采用哪种模式。通常，把模块组装成为系统的测试方式有两种：
⑴一次性集成测试方式（ No-Incremental Integration）
一次性集成测试方式也称作非增值式集成测试。先分别测试每个模块，再把所有模块按设计要求放在一起结合成所需要实现的程序。
3.4 集成测试第三章 软件测试流程如图 3-7是所示按照一次性集成测试方式的实例。如图 3-7（ a）所示表示的是整个系统结构，共包含 6个模块。具体测试过程如下：
如图 3-7（ b）所示，为模块 B配备驱动模块 D1，来模拟模块 A对 B的调用
。为模块 B配备桩模块 S1，来模拟模块 E被 B调用。对模块 B进行单元测试；
如图 3-7（ d）所示，为模块 D配备驱动模块 D3，来模拟模块 A对 D的调用
。为模块 D配备桩模块 S2，来模拟模块 F被 D调用。对模块 D进行单元测试；
如图 3-7（ c）、图 3-7（ e）、图 3-7（ f）所示，为模块 C,E,F分别配备驱动模块 D2,D4,D5。对模块 C,E,F分别进行单元测试；
如图 3-7（ g）表示，为主模块 A配备三个桩模块 S3,S4,S5。对模块 A进行单元测试；
在将模块 A,B,C,D,E分别进行了单元测试之后，再一次性进行集成测试；
测试结束。
3.4 集成测试第三章 软件测试流程图 3-7 一次性集成测试方式
3.4 集成测试第三章 软件测试流程
⑵ 增值式集成测试方式把下一个要测试的模块同已经测好的模块结合起来进行测试，测试完毕，再把下一个应该测试的模块结合进来继续进行测试。在组装的过程中边连接边测试，以发现连接过程中产生的问题。通过增值逐步组装成为预先要求的软件系统。增值式集成测试方式有三种：
自顶向下增值测试方式（ Top-down Integration）
主控模块作为测试驱动，所有与主控模块直接相连的模块作为桩模块；根据集成的方式（深度或广度），每次用一个模块把从属的桩模块替换成真正的模块；在每个模块被集成时，都必须已经进行了单元测试；进行回归测试以确定集成新模块后没有引入错误。这种组装方式将模块按系统程序结构，沿着控制层次自顶向下进行组装。自顶向下的增值方式在测试过程中较早地验证了主要的控制和判断点。选用按深度方向组装的方式，可以首先实现和验证一个完整的软件功能。
如图 3-8所示表示的是按照深度优先方式遍历的自顶向下增值的集成测试实例。具体测试过程如下：
在树状结构图中，按照先左后右的顺序确定模块集成路线；
如图 3-8（ a）所示，先对顶层的主模块 A进行单元测试。就是对模块 A配以桩模块 S1、
S2和 S3，用来模拟它所实际调用的模块 B,C,D，然后进行测试；
如图 3-8（ b）所示，用实际模块 B替换掉桩模块 S1，与模块 A连接，再对模块 B配以桩模块 S4，用来模拟模块 B对 E的调用，然后进行测试；
图 3-8（ c）是将模块 E替换掉桩模块 S4并与模块 B相连，然后进行测试；
判断模块 E没有叶子结点，也就是说以 A为根结点的树状结构图中的最左侧分支深度遍历结束。转向下一个分支；
图 3-8（ d）所示，模块 C替换掉桩模块 S2，连到模块 A上，然后进行测试；
判断模块 C没有桩模块，转到树状结构图的最后一个分支；
如图 3-8（ e）所示,模块 D替换掉桩模块 S3，连到模块 A上，同时给模块 D配以桩模块
S5，来模拟其对模块 F的调用。然后进行测试；
如图 3-8（ f）所示，去掉桩模块 S5，替换成实际模块 F连接到模块 D上，然后进行测试；
对树状结构图进行了完全测试，测试结束。
3.4 集成测试第三章 软件测试流程
3.4 集成测试第三章 软件测试流程图 3-8 自顶向下增值测试方式
3.4 集成测试第三章 软件测试流程
② 自底向上增值测试方式（ Bottom-up Integration）
组装从最底层的模块开始，组合成一个构件，用以完成指定的软件子功能。编制驱动程序，协调测试用例的输入与输出；测试集成后的构件；按程序结构向上组装测试后的构件，同时除掉驱动程序。这种组装的方式是从程序模块结构的最底层的模块开始组装和测试。因为模块是自底向上进行组装，对于一个给定层次的模块，它的子模块（包括子模块的所有下属模块）已经组装并测试完成，所以不再需要桩模块。在模块的测试过程中如果需要从子模块得到信息时可以直接运行子模块获得。
如图 3-9表示的是按照自底向上增值的集成测试例子。首先，对处于树状结构图中叶子结点位置的模块 E,C,F进行单元测试，如图 3-9（ a）、图 3-
9（ b）和图 3-9（ c）所示，分别配以驱动模块 D1,D2和 D3，用来模拟模块
B、模块 A和模块 D对它们的调用。然后，如图 3-9（ d）和图 3-9（ e）所示，
去掉驱动模块 D1和 D3，替换成模块 B和 D分别与模块 E和 F相连，并且设立驱动模块 D4和 D5进行局部集成测试。最后，如图 3-9（ f）所示，对整个系统结构进行集成测试。
3.4 集成测试第三章 软件测试流程图 3-9 自底向上增值测试方式
3.4 集成测试第三章 软件测试流程
③ 混合增值测试方式（ Modified Top-down Integration）
自顶向下增值的方式和自底向上增值的方式各有优缺点。
自顶向下增值方式的缺点是需要建立桩模块。要使桩模块能够模拟实际子模块的功能是十分困难的，同时涉及复杂算法。真正输入／输出的模块处在底层，它们是最容易出问题的模块，并且直到组装和测试的后期才遇到这些模块，一旦发现问题，会导致过多的回归测试。
自顶向下增值方式的优点是能够较早地发现在主要控制方面存在问题。
自底向上增值方式的缺点是“程序一直未能作为一个实体存在，直到最后一个模块加上去后才形成一个实体”。就是说，在自底向上组装和测试的过程中，对主要的控制直到最后才接触到。
自底向上增值方式的优点是不需要桩模块，建立驱动模块一般比建立桩模块容易，同时由于涉及到复杂算法和真正输入／输出的模块最先得到组装和测试，可以把最容易出问题的部分在早期解决。此外自底向上增值的方式可以实施多个模块的并行测试。
3.4 集成测试第三章 软件测试流程有鉴于此，通常是把以上两种方式结合起来进行组装和测试。
改进的自顶向下增值测试：基本思想是强化对输入／输出模块和引入新算法模块的测试，并自底向上组装成为功能相当完整且相对独立的子系统，然后由主模块开始自顶向下进行增值测试；
自底向上 — 自顶向下的增值测试（混和法）：首先对含读操作的子系统自底向上直至根结点模块进行组装和测试，然后对含写操作的子系统做自顶向下的组装与测试；
回归测试：这种方式采取自顶向下的方式测试被修改的模块及其子模块，然后将这一部分视为子系统，再自底向上测试，以检查该子系统与其上级模块的接口是否适配。
3.4 集成测试第三章 软件测试流程
⑶ 一次性集成测试方式与增值式集成测试方式的比较
增值式集成方式需要编写的软件较多，工作量较大，花费的时间较多。一次性集成方式的工作量较小；
增值式集成方式发现问题的时间比一次性集成方式早；
增值式集成方式比一次性集成方式更容易判断出问题的所在，因为出现的问题往往和最后加进来的模块有关；
增值式集成方式测试的更为彻底；
使用一次性集成方式可以多个模块并行测试。
这两种模式各有利弊，在时间条件允许的情况下采用增值式集成测试方式有一定的优势。
3.4 集成测试第三章 软件测试流程
⑷ 集成测试的组织和实施
集成测试是一种正规测试过程，必须精心计划，并与单元测试的完成时间协调起来。在制定测试计划时，应考虑如下因素：
是采用何种系统组装方法来进行组装测试；
组装测试过程中连接各个模块的顺序；
模块代码编制和测试进度是否与组装测试的顺序一致；
测试过程中是否需要专门的硬件设备。
（ 5）集成测试完成的标志判定集成测试过程是否完成，可按以下几个方面检查：
成功地执行了测试计划中规定的所有集成测试；
修正了所发现的错误；
测试结果通过了专门小组的评审。
3.4 集成测试第三章 软件测试流程
（ 6）采用集成测试的原因所有的软件项目都不能摆脱系统集成这个阶段。不管采用什么开发模式，具体的开发工作总得从一个一个的软件单元做起，软件单元只有经过集成才能形成一个有机的整体。
3.5 确认测试第三章 软件测试流程
1．确认测试的定义确认测试最简明、最严格的解释是检验所开发的软件是否能按用户提出的要求运行。若能达到这一要求，则认为开发的软件是合格的。因而有的软件开发部门把确认测试称为合格性测试 (Qualification Testing)。
确认测试又称为有效性测试。它的任务是验证软件的功能和性能及其特性是否与客户的要求一致。对软件的功能和性能要求在软件需求规格说明中已经明确规定。
确认测试阶段工作如图 3-10所示：
3.5 确认测试第三章 软件测试流程图 3-10 确认测试阶段的工作
3.5 确认测试第三章 软件测试流程
2．确认测试的准则经过确认测试，应该为已开发的软件做出结论性评价。这不外乎是以下两种情况之一：
经过检验的软件功能、性能及其他要求均已满足需求规格说明书的规定，
因而可被接受，视为是合格的软件；
经过检验发现与需求说明书有相当的偏离，得到一个各项缺陷的清单。
对于第二种情况，往往很难在交付期以前把发现的问题纠正过来。这就需要开发部门和客户进行协商，找出解决的办法。
3.5 确认测试第三章 软件测试流程
3．进行确认测试确认测试是在模拟的环境（可能是就是开发的环境）下，运用黑盒测试的方法，验证所测试件是否满足需求规格说明书列出的需求。
4．确认测试的结果在全部软件测试的测试用例运行完后，所有的测试结果可以分为两类：
测试结果与预期的结果相符。说明软件的这部分功能或性能特征与需求规格说明书相符合，从而这部分程序被接受；
测试结果与预期的结果不符。说明软件的这部分功能或性能特征与需求规格说明不一致，因此要为它提交一份问题报告。
通过与用户的协商，解决所发现的缺陷和错误。确认测试应交付的文档有：确认测试分析报告、最终的用户手册和操作手册、项目开发总结报告。
3.5 确认测试第三章 软件测试流程
5．软件配置审查软件配置审查是确认测试过程的重要环节。其的目的是保证软件配置的所有成分都齐全，各方面的质量都符合要求，具备维护阶段所必需的细资料并且已经编排好分类的目录。除了按合同规定的内容和要求，由工人审查软件配置之外，在确认测试的过程，
应当严格遵守用户手册和操作手册中规定的使用步骤，以便检查这些文档资料的完整性和正确性。必须仔细记录发现的遗漏和错误，并且适当地补充和改正。
3.6 系统测试第三章 软件测试流程
1．系统测试的定义在软件的各类测试中，系统测试是最接近于人们的日常测试实践。
它是将已经集成好的软件系统，作为整个计算机系统的一个元素，
与计算机硬件、外设、某些支持软件、数据和人员等其他系统元素结合在一起，在实际运行环境下，对计算机系统进行一系列的组装测试和确认测试。
3.6 系统测试第三章 软件测试流程
2．系统测试的流程系统测试流程如图 3-11所示。由于系统测试的目的是验证最终软件系统是否满足产品需求并且遵循系统设计，所以在完成产品需求和系统设计文档之后，系统测试小组就可以提前开始制定测试计划和设计测试用例，不必等到集成测试阶段结束。这样可以提高系统测试的效率。
3.6 系统测试第三章 软件测试流程图 3-11 系统测试流程
3.6 系统测试第三章 软件测试流程
3．系统测试的目标确保系统测试的活动是按计划进行的；
验证软件产品是否与系统需求用例不相符合或与之矛盾；
建立完善的系统测试缺陷记录跟踪库；
确保软件系统测试活动及其结果及时通知相关小组和个人。
3.6 系统测试第三章 软件测试流程
4．系统测试的方针为项目指定一个测试工程师负责贯彻和执行系统测试活动；
测试组向各事业部总经理 /项目经理报告系统测试的执行状况；
系统测试活动遵循文档化的标准和过程；
向外部用户提供经系统测试验收通过的项目；
建立相应项目的（ BUG）缺陷库，用于系统测试阶段项目不同生命周期的缺陷记录和缺陷状态跟踪；
定期对系统测试活动及结果进行评估，向各事业部经理 /项目办总监 /项目经理汇报项目的产品质量信息及数据。
3.6 系统测试第三章 软件测试流程
5．系统测试的设计为了保证系统测试质量，必须在测试设计阶段就对系统进行严密的测试设计。这就需要在测试设计中，从多方面考虑系统规格的实现情况。通常需要从以下几个层次来进行设计：用户层、
应用层、功能层、子系统层、协议层。
3.6 系统测试第三章 软件测试流程
6．几种常见的系统测试方法
(1) 恢复测试也叫容错测试，用来检查系统的容错能力。通常若计算机系统出现错误，就必须在一定时间内从错误中恢复过来，修正错误并重新启动系统。
恢复测试是通过各种手段，让软件强制性地出错，使其不能正常工作，从而检验系统的恢复能力。对于自动恢复系统，即由系统自身完成恢复工作，则应该检验重新初始化、检查点、数据恢复和重新启动等机制的正确性。对于人工干预恢复系统，要评估平均修复时间是否在可接受的范围。
(2) 安全测试安全测试的目的在于检查系统对外界非法入侵的防范能力。在安全测试过程中，
测试者扮演着非法入侵者，采用各种手段试图突破防线，攻击系统。例如，测试者可以尝试通过外部的手段来破译系统的密码，或者可以有目的地引发系统错误，
试图在系统恢复过程中侵入系统等。
系统的安全测试要设置一些测试用例试图突破系统的安全保密防线，用来查找系统的安全保密的漏洞。
系统安全测试的准则是让非法侵入者攻击系统的代价大于保护系统安全的价值。
3.6 系统测试第三章 软件测试流程
(3) 强度测试也称压力测试、负载测试。强度测试是要破坏程序，检测非正常的情况系统的负载能力。
强度测试模拟实际情况下的软硬件环境和用户使用过程的系统负荷，长时间或超负荷地运行测试软件来测试系统，以检验系统能力的最高限度，从而了解系统的可靠性、
稳定性等。例如，将输入的数据值提高一个或几个数量级来测试输入功能的响应等。
实际上，强度测试就是在一些特定情况下所做的敏感测试。比如数学算法中，在一个有效的数据范围内定义一个极小范围的数据区间，这个数据区间中的数据本应该是合理的，但往往又可能会引发异常的状况或是引起错误的运行，导致程序的不稳定性。
敏感测试就是为了发现这种在有效的输入数据区域内可能会引发不稳定性或者引起错误运行的数据集合和组合。
(4) 性能测试性能测试用来测试软件在系统运行时的性能表现，比如运行速度、系统资源占有或响应时间等情况。对于实时系统或嵌入式系统，若只能满足功能需求而不能满足性能需求，是不能被接受的。
性能测试可以在测试过程的任意阶段进行，例如，在单元层，一个独立的模块也可以运用白盒测试方法进行性能评估。但是，只有当一个系统的所有部分都集成后，才能检测此系统的真正性能。
3.6 系统测试第三章 软件测试流程
(5) 容量测试容量测试是指在系统正常运行的范围内测定系统能够处理的数据容量，测试系统承受超额数据容量的能力。系统容量必须满足用户需求，如果不能满足实际要求，
必须努力改进，寻求解决办法。暂时无法解决的需要在产品说明书中给予说明。
(6) 正确性测试正确性测试是为了检测软件的各项功能是否符合产品规格说明的要求。软件的正确性与否关系着软件的质量好坏，所以非常重要。
正确性测试的总体思路是设计一些逻辑正确的输入值，检查运行结果是不是期望值。
正确性测试主要有两种方法，一个是枚举法，另一个是边界值法。
3.6 系统测试第三章 软件测试流程
(7) 可靠性测试可靠性测试是从验证的角度出发，检验系统的可靠性是否达到预期的目标，同时给出当前系统可能的可靠性增长情况。可靠性测试需要从用户角度出发，模拟用户实际使用系统的情况，设计出系统的可操作视图。
(8) 兼容性测试现今，客户对各个开发商和各种软件之间相互兼容、共享数据的能力要求越来越高，所以对于软件兼容性的测试就非常重要。
软件兼容性测试是检测各软件之间能否正常地交互、共享信息，能否正确地和软件合作完成数据处理。从而保障软件能够按照客户期望的标准进行交互，多个软件共同完成指定的任务。
3.6 系统测试第三章 软件测试流程
(9) Web网站测试
Web网站测试是面向因特网 Web页面的测试。众所周知，因特网网页是由文字、图形、声音、视频和超级链接等组成的文档。
网络客户端用户通过在浏览器中的操作，搜索浏览所需要的信息资源。
针对 Web网站这一特定类型软件的测试，包含了许多测试技术，
如功能测试、压力 /负载测试、配置测试、兼容性测试、安全性测试等。黑盒测试、白盒测试、静态测试和动态测试都有可能被采用。
3.7 验收测试第三章 软件测试流程
1．验收测试的定义验收测试（ Acceptance Testing）是向未来的用户表明系统能够像预定要求的那样工作。
通过综合测试之后，软件已完全组装起来，接口方面的错误也已排除，软件测试的最后一步 —— 验收测试即可开始。
验收测试的目的是确保软件准备就绪，并且可以让最终用户将其用于执行软件的既定功能和任务。验收测试是检验软件产品质量的最后一道工序。验收测试通常更突出客户的作用，同时软件开发人员也有一定的参与。如何组织好验收测试并不是一件容易的事。以下对验收测试的任务、目标以及验收测试的组织管理给出详细介绍。
3.7 验收测试第三章 软件测试流程
2．验收测试的内容软件验收测试应完成的工作内容如下：要明确验收项目，规定验收测试通过的标准；确定测试方法；决定验收测试的组织机构和可利用的资源；选定测试结果分析方法；指定验收测试计划并进行评审；设计验收测试所用的测试用例；审查验收测试的准备工作；执行验收测试；分析测试结果；
做出验收结论，明确通过验收或不通过验收，给出测试结果。
3.7 验收测试第三章 软件测试流程
3．验收测试的标准实现软件确认要通过一系列黑盒测试。验收测试同样需要制订测试计划和过程，测试计划应规定测试的种类和测试进度，测试过程则定义一些特殊的测试用例，旨在说明软件与需求是否一致。无论是计划还是过程，都应该着重考虑软件是否满足合同规定的所有功能和性能
，文档资料是否完整、准确，人机界面和其他方面（例如，可移植性
、兼容性、错误恢复能力和可维护性等）是否令用户满意。
验收测试的结果有两种可能，一种是功能和性能指标满足软件需求说明的要求，用户可以接受；另一种是软件不满足软件需求说明的要求，用户无法接受。如果项目进行到这个阶段才发现有严重错误和偏差一般很难在预定的工期内改正，因此必须与用户协商，寻求一个妥善解决问题的方法。
3.7 验收测试第三章 软件测试流程
4．验收测试的常用策略选择的验收测试的策略通常建立在合同需求、组织和公司标准以及应用领域的基础上。实施验收测试的常用策略有三种，它们分别是：
(1) 正式验收测试：正式验收测试是一项管理严格的过程，它通常是系统测试的延续。计划和设计这些测试的周密和详细程度不亚于系统测试。选择的测试用例应该是系统测试中所执行测试用例的子集。
不要偏离所选择的测试用例方向，这一点很重要。在很多组织中，正式验收测试是完全自动执行的。对于系统测试，活动和工件是一样的
。在某些组织中，开发组织（或其独立的测试小组）与最终用户组织的代表一起执行验收测试。在其他组织中，验收测试则完全由最终用户组织执行，或者由最终用户组织选择人员组成一个客观公正的小组来执行。
3.7 验收测试第三章 软件测试流程
(2) 非正式验收或 Alpha 测试：在非正式验收测试中，执行测试过程的限定不像正式验收测试中那样严格。在此测试中，确定并记录要研究的功能和业务任务，但没有可以遵循的特定测试用例。测试内容由各测试员决定。
这种验收测试方法不像正式验收测试那样组织有序，而且更为主观。大多数情况下，非正式验收测试是由最终用户组织执行的。
(3) Beta 测试：与以上两种验收测试策略相比,Beta 测试需要的控制是最少的。在 Beta 测试中，采用的细节多少、数据和方法完全由各测试员决定。
各测试员负责创建自己的环境、选择数据，并决定要研究的功能、特性或任务。各测试员负责确定自己对于系统当前状态的接受标准。 Beta 测试由最终用户实施，通常开发组织对其的管理很少或不进行管理。 Beta 测试是所有验收测试策略中最主观的。
3.7 验收测试第三章 软件测试流程
3.7 验收测试第三章 软件测试流程图 3-12 验收测试的工作流程
5．验收测试的过程验收测试的工作流程如图 3-12所示 。
3.7 验收测试第三章 软件测试流程
6．验收测试的总体思路用户验收测试是软件开发结束后，用户对软件产品投入实际应用以前进行的最后一次质量检验活动。它要回答开发的软件产品是否符合预期的各项要求，以及用户能否接受的问题。由于它不只是检验软件某个方面的质量，而是要进行全面的质量检验，并且要决定软件是否合格，因此验收测试是一项严格的正式测试活动。
用户验收测试可以分为两个大的部分：软件配置审核和可执行程序测试，其大致顺序可分为：文档审核、源代码审核、配置脚本审核、测试程序或脚本审核、可执行程序测试。
习题第三章 软件测试流程
1,简述软件测试的复杂性。
2,对软件的经济性进行总结分析。
3,阐述软件测试的充分性准则。
4,如何描述测试流程整体框架。
5,简述单元测试的目标。
6,解释驱动模块和桩模块概念。
7,简述集成测试的层次划分。
8,归纳确认测试阶段的工作。
9,简述系统测试的流程。
10,归纳验收测试常用的策略。
11,简述验收测试的流程。
3.1 软件测试的复杂性与经济性分析
3.2 软件测试的流程
3.3 单元测试
3.4 集成测试
3.5 确认测试
3.6 系统测试
3.7 验收测试习题本章概要第三章 软件测试流程
软件测试的复杂性和经济性
软件测试的相关流程：单元测试、集成测试、确认测试、系统测试和验收测试等基本测试阶段。
3.1 软件测试的复杂性与经济性分析第三章 软件测试流程人们在对软件工程开发的常规认识中，认为开发程序是一个复杂而困难的过程，需要花费大量的人力、物力和时间，而测试一个程序则比较容易，不需要花费太多的精力。这其实是人们对软件工程开发过程理解上的一个误区。在实际的软件开发过程中，
作为现代软件开发工业一个非常重要的组成部分，软件测试正扮演着越来越重要的角色。随着软件规模的不断扩大，如何在有限的条件下对被开发软件进行有效的测试正成为软件工程中一个非常关键的课题。
3.1.1 软件测试的复杂性第三章 软件测试流程设计测试用例是一项细致并且需要具备高度技巧的工作，稍有不慎就会顾此失彼，发生不应有的疏漏。下面分析了容易出现问题的根源。
(1) 完全测试是不现实的在实际的软件测试工作中，不论采用什么方法，由于软件测试情况数量极其巨大，都不可能进行完全彻底的测试。所谓彻底测试，
就是让被测程序在一切可能的输入情况下全部执行一遍。通常也称这种测试为“穷举测试”。
穷举测试会引起以下几种问题：
输入量太大；
输出结果太多；
软件执行路径太多；
说明书存在主观性。
3.1.1 软件测试的复杂性第三章 软件测试流程
E.W.Dijkstra的一句名言对测试的不彻底性作了很好的注解：“程序测试只能证明错误的存在，但不能证明错误的不存在”。由于穷举测试工作量太大，实践上行不通，这就注定了一切实际测试都是不彻底的，也就不能够保证被测试程序在理论上不存在遗留的错误。
3.1.1 软件测试的复杂性第三章 软件测试流程
(2) 软件测试是有风险的穷举测试的不可行性使得大多数软件在进行测试的时候只能采取非穷举测试，这又意味着一种冒险。比如在使用 Microsoft Office工具中的 Word时，可以作这样的一个测试：①新建一个 Word文档；②
在文档中输入汉字,胡”；③设置其字体属性为“隶书”，字号为初号，效果为,空心”；④将页面的显示比例设为,500%”。这时在“胡”字的内部会出现“胡万进印”四个字。类似问题在实际测试中如果不使用穷举测试是很难发现的，而如果在软件投入市场时才发现则修复代价就会非常高。这就会产生一个矛盾：软件测试员不能做到完全的测试，不完全测试又不能证明软件的百分之百的可靠。那么如何在这两者的矛盾中找到一个相对的平衡点呢？
3.1.1 软件测试的复杂性第三章 软件测试流程如图 3-1所示的最优测试量示意图可以观察到，当软件缺陷降低到某一数值后，随着测试从量的不断上升软件缺陷并没有明显地下降。这是软件测试工作中需要注意的重要问题。如何把测试数据量巨大的软件测试减少到可以控制的范围，如何针对风险做出最明智的选择是软件测试人员必须能够把握的关键问题。
图 3-1的最优测试量示意图说明了发现软件缺陷数量和测试量之间的关系，
随着测试量的增加，测试成本将呈几何数级上升，而软件缺陷降低到某一数值之后将没有明显的变化，最优测量值就是这两条曲线的交点。
3.1.1 软件测试的复杂性第三章 软件测试流程图 3-1 最优测试量示意图
3.1.1 软件测试的复杂性第三章 软件测试流程
(3) 杀虫剂现象
1990年,Boris Beizer在其编著的,Software Testing Techniques》
（第二版）中提到了“杀虫剂怪事”一词，同一种测试工具或方法用于测试同一类软件越多，则被测试软件对测试的免疫力就越强。
这与农药杀虫是一样的，老用一种农药，则害虫就有了免疫力，农药就失去了作用。
由于软件开发人员在开发过程中可能碰见各种各样的主客观因素，
再加上不可预见的突发性事件，所以再优秀的软件测试员采用一种测试方法或者工具也不可能检测出所有的缺陷。为了克服被测试软件的免疫力，软件测试员必须不断编写新的测试程序，对程序的各个部分进行不断地测试，以避免被测试软件对单一的测试程序具有免疫力而使软件缺陷不被发现。这就对软件测试人员的素质提出了很高的要求。
3.1.1 软件测试的复杂性第三章 软件测试流程
(4) 缺陷的不确定性在软件测试中还有一个让人不容易判断的现象是缺陷的不确定性。即并不是所有的软件缺陷都需要被修复。对于究竟什么才算是软件缺陷是一个很难把握的标准，在任何一本软件测试的书中都只能给出一个笼统的定义。实际测试中需要把这一定义根据具体的被测对象明确化。即使这样，具体的测试人员对软件系统的理解不同，
还是会出现不同的标准。
3.1.2 软件测试的经济性第三章 软件测试流程软件测试的经济性有两方面体现：
一是体现在测试工作在整个项目开发过程中的重要地位；
二是体现在应该按照什么样的原则进行测试，以实现测试成本与测试效果的统一。
软件工程的总目标是充分利用有限的人力和物力资源，高效率、
高质量地完成测试。结合 3.1.1节关于穷举测试具有不可行性，就可以理解为什么要在测试量与测试成本的曲线中选取最优测试点。
3.1.3 软件测试的充分性准则第三章 软件测试流程软件测试的充分性准则有以下几点：
对任何软件都存在有限的充分测试集合；
当一个测试的数据集合对于一个被测的软件系统的测试是充分的，那么再多增加一些测试数据仍然是充分的。这一特性称为软件测试的单调性；
即使对软件所有成分都进行了充分的测试，也并不意味着整个软件的测试已经充分了。这一特性称为软件测试的非复合性；
即使对一个软件系统整体的测试是充分的，也并不意味着软件系统中各个成分都已经充分地得到了测试。这个特性称为软件测试的非分解性；
软件测试的充分性与软件的需求、软件的实现都相关；
软件测试的数据量正比于软件的复杂度。这一特性称为软件测试的复杂性；
随着测试次数的增加，检查出软件缺陷的几率随之不断减少。软件测试具有回报递减率。
3.1.4 软件测试的误区第三章 软件测试流程随着软件产业工业化、模块化地发展，在软件开发组中软件测试人员的重要性也不断地突出。在国外，很多著名企业早已对软件测试工作十分重视。比如著名的微软公司，其软件测试人员与开发人员的比例已经达到 2:1。可见软件测试对于一个软件开发项目的成功与否具有十分重要的意义。但是在实际的项目开发与管理中仍然存在很多管理上或者技术上的误区：
(1) 期望用测试自动化代替大部分人工劳动
(2) 忽视需求阶段的参与
(3) 软件测试是技术要求不高的岗位
3.2 软件测试的流程第三章 软件测试流程
1,软件开发的 V模型软件测试是有阶段性的，而软件测试的流程与软件设计周期究竟是什么样的关系呢？关于软件开发流程的 V模型是一个广为人知的模型,如图 3-2所示
。在 V模型中，从左到右描述了基本的开发过程和测试行为，为软件的开发人员和测试管理者提供了一个极为简单的框架。 V模型的价值在于它非常明确地标明了测试过程中存在的不同级别，并且清楚地描述了这些测试阶段和开发过程期间各阶段的对应关系。
在 V模型中各个测试阶段的执行流程是：单元测试是基于代码的测试，最初由开发人员执行，以验证其可执行程序代码的各个部分是否已达到了预期的功能要求；集成测试验证了两个或多个单元之间的集成是否正确，并且有针对性地对详细设计中所定义的各单元之间的接口进行检查；在单元测试和集成测试完成之后，系统测试开始用客户环境模拟系统的运行，以验证系统是否达到了在概要设计中所定义的功能和性能；最后，当技术部门完成了所有测试工作，由业务专家或用户进行验收测试，以确保产品能真正符合用户业务上的需要。 图 3-2描绘出了各个测试环节在整个软件测试工作中的相互联系与制约关系。
3.2 软件测试的流程第三章 软件测试流程图 3-2 V模型示意图
3.2 软件测试的流程第三章 软件测试流程
2．软件测试过程软件测试过程按各测试阶段的先后顺序可分为单元测试、集成测试、确认（有效性）测试、系统测试和验收（用户）测试 5个阶段，如图 3-3所示。
(1) 单元测试：测试执行的开始阶段。测试对象是每个单元。测试目的是保证每个模块或组件能正常工作。单元测试主要采用白盒测试方法，检测程序的内部结构。
(2) 集成测试：也称组装测试。在单元测试基础上，对已测试过的模块进行组装，
进行集成测试。测试目的是检验与接口有关的模块之间的问题。集成测试主要采用黑盒测试方法。
(3) 确认测试：也称有效性测试。在完成集成测试后，验证软件的功能和性能及其他特性是否符合用户要求。测试目的是保证系统能够按照用户预定的要求工作。
确认测试通常采用黑盒测试方法。
(4) 系统测试：在完成确认测试后，为了检验它能否与实际环境（如软硬件平台、
数据和人员等）协调工作，还需要进行系统测试。可以说，系统测试之后，软件产品基本满足开发要求。
(5) 验收测试：测试过程的最后一个阶段。验收测试主要突出用户的作用，同时软件开发人员也应该参与进去。
3.2 软件测试的流程第三章 软件测试流程软件测试阶段的输入信息包括两类：
软件配置：指测试对象。通常包括需求说明书、设计说明书和被测试的源程序等；
测试配置：通常包括测试计划、测试步骤、测试用例以及具体实施测试的测试程序、测试工具等。
对测试结果与预期的结果进行比较以后，即可判断是否存在错误，
决定是否进入排错阶段，进行调试任务。对修改以后的程序要进行重新测试，因为修改可能会带来新的问题。
通常根据出错的情况得到出错率来预估被测软件的可靠性，这将对软件运行后的维护工作有重要价值。
3.2 软件测试的流程第三章 软件测试流程图 3-3 测试各阶段示意图
3.3 单元测试第三章 软件测试流程
1．单元测试的定义单元测试（ Unit Testing）是对软件基本组成单元进行的测试。单元测试的对象是软件设计的最小单位 —— 模块。很多人将单元的概念误解为一个具体函数或一个类的方法，这种理解并不准确。作为一个最小的单元应该有明确的功能定义、性能定义和接口定义，而且可以清晰地与其他单元区分开来。一个菜单、一个显示界面或者能够独立完成的具体功能都可以是一个单元。从某种意义上单元的概念已经扩展为组件（ component）。
3.3 单元测试第三章 软件测试流程
2．单元测试的目标单元测试的主要目标是确保各单元模块被正确地编码。单元测试除了保证测试代码的功能性，还需要保证代码在结构上具有可靠性和健全性，并且能够在所有条件下正确响应。进行全面的单元测试，
可以减少应用级别所需的工作量，并且彻底减少系统产生错误的可能性。如果手动执行，单元测试可能需要大量的工作，自动化测试会提高测试效率。
3.3 单元测试第三章 软件测试流程
3．单元测试的内容单元测试的主要内容有：
模块接口测试；
局部数据结构测试；
独立路径测试；
错误处理测试；
边界条件测试。
如图 3-4所示，这些测试都作用于模块，共同完成单元测试任务。
模块接口测试：对通过被测模块的数据流进行测试。为此，对模块接口，包括参数表、调用子模块的参数、全程数据、文件输入 /输出操作都必须检查。
3.3 单元测试第三章 软件测试流程局部数据结构测试：设计测试用例检查数据类型说明、初始化、默认值等方面的问题，还要查清全程数据对模块的影响。
独立路径测试：选择适当的测试用例，对模块中重要的执行路径进行测试。
基本路径测试和循环测试可以发现大量的路径错误，是最常用且最有效的测试技术。
错误处理测试：检查模块的错误处理功能是否包含有错误或缺陷。例如，
是否拒绝不合理的输入；出错的描述是否难以理解、是否对错误定位有误、
是否出错原因报告有误、是否对错误条件的处理不正确；在对错误处理之前错误条件是否已经引起系统的干预等。
边界条件测试：要特别注意数据流、控制流中刚好等于、大于或小于确定的比较值时出错的可能性。对这些地方要仔细地选择测试用例，认真加以测试。此外，如果对模块运行时间有要求的话，还要专门进行关键路径测试，以确定最坏情况下和平均意义下影响模块运行时间的因素。这类信息对进行性能评价是十分有用的。
3.3 单元测试第三章 软件测试流程
4．单元测试的步骤通常单元测试在编码阶段进行。当源程序代码编制完成，经过评审和验证，确认没有语法错误之后，就开始进行单元测试的测试用例设计。利用设计文档，设计可以验证程序功能、找出程序错误的多个测试用例。对于每一组输入，应有预期的正确结果。
模块接口测试中的被测模块并不是一个独立的程序，在考虑测试模块时，同时要考虑它和外界的联系，用一些辅助模块去模拟与被测模块相关联的模块。这些辅助模块可分为两种：
(1) 驱动模块（ driver）：相当于被测模块的主程序。它接收测试数据，把这些数据传送给被测模块，最后输出实测结果。
(2) 桩模块（ stub）：用以代替被测模块调用的子模块。桩模块可以做少量的数据操作，不需要把子模块所有功能都带进来，但不允许什么事情也不做。
3.3 单元测试第三章 软件测试流程被测模块、与它相关的驱动模块以及桩模块共同构成了一个“测试环境”，如图 3-5所示。
如果一个模块要完成多种功能，并且以程序包或对象类的形式出现，例如 Ada中的包,MODULA中的模块,C++中的类，这时可以将模块看成由几个小程序组成。对其中的每个小程序先进行单元测试要做的工作，对关键模块还要做性能测试。对支持某些标准规程的程序，更要着手进行互联测试。有人把这种情况特别称为模块测试，以区别单元测试。
3.3 单元测试第三章 软件测试流程图 3-4 单元测试任务
3.3 单元测试第三章 软件测试流程
5．采用单元测试的原因程序员编写代码时，一定会反复调试保证其能够编译通过。如果是编译没有通过的代码，没有任何人会愿意交付给自己的老板。但代码通过编译，只是说明了它的语法正确，程序员却无法保证它的语义也一定正确。没有任何人可以轻易承诺这段代码的行为一定是正确的。单元测试这时会为此做出保证。编写单元测试就是用来验证这段代码的行为是否与软件开发人员期望的一致。有了单元测试，
程序员可以自信的交付自己的代码，而没有任何的后顾之忧。
3.3 单元测试第三章 软件测试流程图 3-5 单元测试环境
3.3 单元测试第三章 软件测试流程通过单元测试，测试人员可以验证开发人员所编写的代码是按照先前设想的方式进行的，输出结果符合预期值，这就实现了单元测试的目的。与后面的测试相比，单元测试创建简单，维护容易，
并且可以更方便的进行重复。,实用软件度量,（ Capers Jones，
McGraw-Hill 1991）列出了准备测试、执行测试和修改缺陷所花费的时间（以一个功能点为基准），这些测试显示出了单元测试的成本效率大约是集成测试的两倍、系统测试的三倍，如图 3-6所示。术语域测试是指软件在投入使用后，针对某个领域所作的所有测试活动。
3.3 单元测试第三章 软件测试流程图 3-6 各测试阶段发现缺陷的耗时
3.4 集成测试第三章 软件测试流程
1．集成测试的定义在完成单元测试的基础上，需要将所有模块按照设计要求组装成为系统。这时需要考虑以下问题：
在把各个模块连接起来的时候，穿越模块接口的数据是否会丢失；
一个模块的功能是否会对另一个模块的功能产生不利的影响；
各个子功能组合起来，能否达到预期要求的父功能；
全局数据结构是否有问题；
单个模块的误差累积起来，是否会放大，从而达到不能接受的程度；
单个模块的错误是否会导致数据库错误。
3.4 集成测试第三章 软件测试流程集成测试（ Integration Testing）是介于单元测试和系统测试之间的过渡阶段，与软件开发计划中的软件概要设计阶段相对应，是单元测试的扩展和延伸。
集成测试的定义是根据实际情况对程序模块采用适当的集成测试策略组装起来，对系统的接口以及集成后的功能进行正确校验的测试工作。
3.4 集成测试第三章 软件测试流程
2．集成测试的层次软件的开发过程是一个从需求分析到概要设计、详细设计以及编码实现的逐步细化的过程，那么单元测试到集成测试再到系统测试就是一个逆向求证的过程。集成测试内部对于传统软件和面向对象的应用系统有两种层次的划分。
对于传统软件来讲，可以把集成测试划分为三个层次：
模块内集成测试；
子系统内集成测试；
子系统间集成测试。
对于面向对象的应用系统来说，可以把集成测试分为两个阶段：
类内集成测试；
类间集成测试。
3.4 集成测试第三章 软件测试流程
3．集成测试的模式选择什么方式把模块组装起来形成一个可运行的系统，直接影响到模块测试用例的形式、所用测试工具的类型、模块编号的次序和测试的次序、生成测试用例的费用和调试的费用。集成测试模式是软件集成测试中的策略体现，其重要性是明显的，直接关系到软件测试的效率、结果等，一般是根据软件的具体情况来决定采用哪种模式。通常，把模块组装成为系统的测试方式有两种：
⑴一次性集成测试方式（ No-Incremental Integration）
一次性集成测试方式也称作非增值式集成测试。先分别测试每个模块，再把所有模块按设计要求放在一起结合成所需要实现的程序。
3.4 集成测试第三章 软件测试流程如图 3-7是所示按照一次性集成测试方式的实例。如图 3-7（ a）所示表示的是整个系统结构，共包含 6个模块。具体测试过程如下：
如图 3-7（ b）所示，为模块 B配备驱动模块 D1，来模拟模块 A对 B的调用
。为模块 B配备桩模块 S1，来模拟模块 E被 B调用。对模块 B进行单元测试；
如图 3-7（ d）所示，为模块 D配备驱动模块 D3，来模拟模块 A对 D的调用
。为模块 D配备桩模块 S2，来模拟模块 F被 D调用。对模块 D进行单元测试；
如图 3-7（ c）、图 3-7（ e）、图 3-7（ f）所示，为模块 C,E,F分别配备驱动模块 D2,D4,D5。对模块 C,E,F分别进行单元测试；
如图 3-7（ g）表示，为主模块 A配备三个桩模块 S3,S4,S5。对模块 A进行单元测试；
在将模块 A,B,C,D,E分别进行了单元测试之后，再一次性进行集成测试；
测试结束。
3.4 集成测试第三章 软件测试流程图 3-7 一次性集成测试方式
3.4 集成测试第三章 软件测试流程
⑵ 增值式集成测试方式把下一个要测试的模块同已经测好的模块结合起来进行测试，测试完毕，再把下一个应该测试的模块结合进来继续进行测试。在组装的过程中边连接边测试，以发现连接过程中产生的问题。通过增值逐步组装成为预先要求的软件系统。增值式集成测试方式有三种：
自顶向下增值测试方式（ Top-down Integration）
主控模块作为测试驱动，所有与主控模块直接相连的模块作为桩模块；根据集成的方式（深度或广度），每次用一个模块把从属的桩模块替换成真正的模块；在每个模块被集成时，都必须已经进行了单元测试；进行回归测试以确定集成新模块后没有引入错误。这种组装方式将模块按系统程序结构，沿着控制层次自顶向下进行组装。自顶向下的增值方式在测试过程中较早地验证了主要的控制和判断点。选用按深度方向组装的方式，可以首先实现和验证一个完整的软件功能。
如图 3-8所示表示的是按照深度优先方式遍历的自顶向下增值的集成测试实例。具体测试过程如下：
在树状结构图中，按照先左后右的顺序确定模块集成路线；
如图 3-8（ a）所示，先对顶层的主模块 A进行单元测试。就是对模块 A配以桩模块 S1、
S2和 S3，用来模拟它所实际调用的模块 B,C,D，然后进行测试；
如图 3-8（ b）所示，用实际模块 B替换掉桩模块 S1，与模块 A连接，再对模块 B配以桩模块 S4，用来模拟模块 B对 E的调用，然后进行测试；
图 3-8（ c）是将模块 E替换掉桩模块 S4并与模块 B相连，然后进行测试；
判断模块 E没有叶子结点，也就是说以 A为根结点的树状结构图中的最左侧分支深度遍历结束。转向下一个分支；
图 3-8（ d）所示，模块 C替换掉桩模块 S2，连到模块 A上，然后进行测试；
判断模块 C没有桩模块，转到树状结构图的最后一个分支；
如图 3-8（ e）所示,模块 D替换掉桩模块 S3，连到模块 A上，同时给模块 D配以桩模块
S5，来模拟其对模块 F的调用。然后进行测试；
如图 3-8（ f）所示，去掉桩模块 S5，替换成实际模块 F连接到模块 D上，然后进行测试；
对树状结构图进行了完全测试，测试结束。
3.4 集成测试第三章 软件测试流程
3.4 集成测试第三章 软件测试流程图 3-8 自顶向下增值测试方式
3.4 集成测试第三章 软件测试流程
② 自底向上增值测试方式（ Bottom-up Integration）
组装从最底层的模块开始，组合成一个构件，用以完成指定的软件子功能。编制驱动程序，协调测试用例的输入与输出；测试集成后的构件；按程序结构向上组装测试后的构件，同时除掉驱动程序。这种组装的方式是从程序模块结构的最底层的模块开始组装和测试。因为模块是自底向上进行组装，对于一个给定层次的模块，它的子模块（包括子模块的所有下属模块）已经组装并测试完成，所以不再需要桩模块。在模块的测试过程中如果需要从子模块得到信息时可以直接运行子模块获得。
如图 3-9表示的是按照自底向上增值的集成测试例子。首先，对处于树状结构图中叶子结点位置的模块 E,C,F进行单元测试，如图 3-9（ a）、图 3-
9（ b）和图 3-9（ c）所示，分别配以驱动模块 D1,D2和 D3，用来模拟模块
B、模块 A和模块 D对它们的调用。然后，如图 3-9（ d）和图 3-9（ e）所示，
去掉驱动模块 D1和 D3，替换成模块 B和 D分别与模块 E和 F相连，并且设立驱动模块 D4和 D5进行局部集成测试。最后，如图 3-9（ f）所示，对整个系统结构进行集成测试。
3.4 集成测试第三章 软件测试流程图 3-9 自底向上增值测试方式
3.4 集成测试第三章 软件测试流程
③ 混合增值测试方式（ Modified Top-down Integration）
自顶向下增值的方式和自底向上增值的方式各有优缺点。
自顶向下增值方式的缺点是需要建立桩模块。要使桩模块能够模拟实际子模块的功能是十分困难的，同时涉及复杂算法。真正输入／输出的模块处在底层，它们是最容易出问题的模块，并且直到组装和测试的后期才遇到这些模块，一旦发现问题，会导致过多的回归测试。
自顶向下增值方式的优点是能够较早地发现在主要控制方面存在问题。
自底向上增值方式的缺点是“程序一直未能作为一个实体存在，直到最后一个模块加上去后才形成一个实体”。就是说，在自底向上组装和测试的过程中，对主要的控制直到最后才接触到。
自底向上增值方式的优点是不需要桩模块，建立驱动模块一般比建立桩模块容易，同时由于涉及到复杂算法和真正输入／输出的模块最先得到组装和测试，可以把最容易出问题的部分在早期解决。此外自底向上增值的方式可以实施多个模块的并行测试。
3.4 集成测试第三章 软件测试流程有鉴于此，通常是把以上两种方式结合起来进行组装和测试。
改进的自顶向下增值测试：基本思想是强化对输入／输出模块和引入新算法模块的测试，并自底向上组装成为功能相当完整且相对独立的子系统，然后由主模块开始自顶向下进行增值测试；
自底向上 — 自顶向下的增值测试（混和法）：首先对含读操作的子系统自底向上直至根结点模块进行组装和测试，然后对含写操作的子系统做自顶向下的组装与测试；
回归测试：这种方式采取自顶向下的方式测试被修改的模块及其子模块，然后将这一部分视为子系统，再自底向上测试，以检查该子系统与其上级模块的接口是否适配。
3.4 集成测试第三章 软件测试流程
⑶ 一次性集成测试方式与增值式集成测试方式的比较
增值式集成方式需要编写的软件较多，工作量较大，花费的时间较多。一次性集成方式的工作量较小；
增值式集成方式发现问题的时间比一次性集成方式早；
增值式集成方式比一次性集成方式更容易判断出问题的所在，因为出现的问题往往和最后加进来的模块有关；
增值式集成方式测试的更为彻底；
使用一次性集成方式可以多个模块并行测试。
这两种模式各有利弊，在时间条件允许的情况下采用增值式集成测试方式有一定的优势。
3.4 集成测试第三章 软件测试流程
⑷ 集成测试的组织和实施
集成测试是一种正规测试过程，必须精心计划，并与单元测试的完成时间协调起来。在制定测试计划时，应考虑如下因素：
是采用何种系统组装方法来进行组装测试；
组装测试过程中连接各个模块的顺序；
模块代码编制和测试进度是否与组装测试的顺序一致；
测试过程中是否需要专门的硬件设备。
（ 5）集成测试完成的标志判定集成测试过程是否完成，可按以下几个方面检查：
成功地执行了测试计划中规定的所有集成测试；
修正了所发现的错误；
测试结果通过了专门小组的评审。
3.4 集成测试第三章 软件测试流程
（ 6）采用集成测试的原因所有的软件项目都不能摆脱系统集成这个阶段。不管采用什么开发模式，具体的开发工作总得从一个一个的软件单元做起，软件单元只有经过集成才能形成一个有机的整体。
3.5 确认测试第三章 软件测试流程
1．确认测试的定义确认测试最简明、最严格的解释是检验所开发的软件是否能按用户提出的要求运行。若能达到这一要求，则认为开发的软件是合格的。因而有的软件开发部门把确认测试称为合格性测试 (Qualification Testing)。
确认测试又称为有效性测试。它的任务是验证软件的功能和性能及其特性是否与客户的要求一致。对软件的功能和性能要求在软件需求规格说明中已经明确规定。
确认测试阶段工作如图 3-10所示：
3.5 确认测试第三章 软件测试流程图 3-10 确认测试阶段的工作
3.5 确认测试第三章 软件测试流程
2．确认测试的准则经过确认测试，应该为已开发的软件做出结论性评价。这不外乎是以下两种情况之一：
经过检验的软件功能、性能及其他要求均已满足需求规格说明书的规定，
因而可被接受，视为是合格的软件；
经过检验发现与需求说明书有相当的偏离，得到一个各项缺陷的清单。
对于第二种情况，往往很难在交付期以前把发现的问题纠正过来。这就需要开发部门和客户进行协商，找出解决的办法。
3.5 确认测试第三章 软件测试流程
3．进行确认测试确认测试是在模拟的环境（可能是就是开发的环境）下，运用黑盒测试的方法，验证所测试件是否满足需求规格说明书列出的需求。
4．确认测试的结果在全部软件测试的测试用例运行完后，所有的测试结果可以分为两类：
测试结果与预期的结果相符。说明软件的这部分功能或性能特征与需求规格说明书相符合，从而这部分程序被接受；
测试结果与预期的结果不符。说明软件的这部分功能或性能特征与需求规格说明不一致，因此要为它提交一份问题报告。
通过与用户的协商，解决所发现的缺陷和错误。确认测试应交付的文档有：确认测试分析报告、最终的用户手册和操作手册、项目开发总结报告。
3.5 确认测试第三章 软件测试流程
5．软件配置审查软件配置审查是确认测试过程的重要环节。其的目的是保证软件配置的所有成分都齐全，各方面的质量都符合要求，具备维护阶段所必需的细资料并且已经编排好分类的目录。除了按合同规定的内容和要求，由工人审查软件配置之外，在确认测试的过程，
应当严格遵守用户手册和操作手册中规定的使用步骤，以便检查这些文档资料的完整性和正确性。必须仔细记录发现的遗漏和错误，并且适当地补充和改正。
3.6 系统测试第三章 软件测试流程
1．系统测试的定义在软件的各类测试中，系统测试是最接近于人们的日常测试实践。
它是将已经集成好的软件系统，作为整个计算机系统的一个元素，
与计算机硬件、外设、某些支持软件、数据和人员等其他系统元素结合在一起，在实际运行环境下，对计算机系统进行一系列的组装测试和确认测试。
3.6 系统测试第三章 软件测试流程
2．系统测试的流程系统测试流程如图 3-11所示。由于系统测试的目的是验证最终软件系统是否满足产品需求并且遵循系统设计，所以在完成产品需求和系统设计文档之后，系统测试小组就可以提前开始制定测试计划和设计测试用例，不必等到集成测试阶段结束。这样可以提高系统测试的效率。
3.6 系统测试第三章 软件测试流程图 3-11 系统测试流程
3.6 系统测试第三章 软件测试流程
3．系统测试的目标确保系统测试的活动是按计划进行的；
验证软件产品是否与系统需求用例不相符合或与之矛盾；
建立完善的系统测试缺陷记录跟踪库；
确保软件系统测试活动及其结果及时通知相关小组和个人。
3.6 系统测试第三章 软件测试流程
4．系统测试的方针为项目指定一个测试工程师负责贯彻和执行系统测试活动；
测试组向各事业部总经理 /项目经理报告系统测试的执行状况；
系统测试活动遵循文档化的标准和过程；
向外部用户提供经系统测试验收通过的项目；
建立相应项目的（ BUG）缺陷库，用于系统测试阶段项目不同生命周期的缺陷记录和缺陷状态跟踪；
定期对系统测试活动及结果进行评估，向各事业部经理 /项目办总监 /项目经理汇报项目的产品质量信息及数据。
3.6 系统测试第三章 软件测试流程
5．系统测试的设计为了保证系统测试质量，必须在测试设计阶段就对系统进行严密的测试设计。这就需要在测试设计中，从多方面考虑系统规格的实现情况。通常需要从以下几个层次来进行设计：用户层、
应用层、功能层、子系统层、协议层。
3.6 系统测试第三章 软件测试流程
6．几种常见的系统测试方法
(1) 恢复测试也叫容错测试，用来检查系统的容错能力。通常若计算机系统出现错误，就必须在一定时间内从错误中恢复过来，修正错误并重新启动系统。
恢复测试是通过各种手段，让软件强制性地出错，使其不能正常工作，从而检验系统的恢复能力。对于自动恢复系统，即由系统自身完成恢复工作，则应该检验重新初始化、检查点、数据恢复和重新启动等机制的正确性。对于人工干预恢复系统，要评估平均修复时间是否在可接受的范围。
(2) 安全测试安全测试的目的在于检查系统对外界非法入侵的防范能力。在安全测试过程中，
测试者扮演着非法入侵者，采用各种手段试图突破防线，攻击系统。例如，测试者可以尝试通过外部的手段来破译系统的密码，或者可以有目的地引发系统错误，
试图在系统恢复过程中侵入系统等。
系统的安全测试要设置一些测试用例试图突破系统的安全保密防线，用来查找系统的安全保密的漏洞。
系统安全测试的准则是让非法侵入者攻击系统的代价大于保护系统安全的价值。
3.6 系统测试第三章 软件测试流程
(3) 强度测试也称压力测试、负载测试。强度测试是要破坏程序，检测非正常的情况系统的负载能力。
强度测试模拟实际情况下的软硬件环境和用户使用过程的系统负荷，长时间或超负荷地运行测试软件来测试系统，以检验系统能力的最高限度，从而了解系统的可靠性、
稳定性等。例如，将输入的数据值提高一个或几个数量级来测试输入功能的响应等。
实际上，强度测试就是在一些特定情况下所做的敏感测试。比如数学算法中，在一个有效的数据范围内定义一个极小范围的数据区间，这个数据区间中的数据本应该是合理的，但往往又可能会引发异常的状况或是引起错误的运行，导致程序的不稳定性。
敏感测试就是为了发现这种在有效的输入数据区域内可能会引发不稳定性或者引起错误运行的数据集合和组合。
(4) 性能测试性能测试用来测试软件在系统运行时的性能表现，比如运行速度、系统资源占有或响应时间等情况。对于实时系统或嵌入式系统，若只能满足功能需求而不能满足性能需求，是不能被接受的。
性能测试可以在测试过程的任意阶段进行，例如，在单元层，一个独立的模块也可以运用白盒测试方法进行性能评估。但是，只有当一个系统的所有部分都集成后，才能检测此系统的真正性能。
3.6 系统测试第三章 软件测试流程
(5) 容量测试容量测试是指在系统正常运行的范围内测定系统能够处理的数据容量，测试系统承受超额数据容量的能力。系统容量必须满足用户需求，如果不能满足实际要求，
必须努力改进，寻求解决办法。暂时无法解决的需要在产品说明书中给予说明。
(6) 正确性测试正确性测试是为了检测软件的各项功能是否符合产品规格说明的要求。软件的正确性与否关系着软件的质量好坏，所以非常重要。
正确性测试的总体思路是设计一些逻辑正确的输入值，检查运行结果是不是期望值。
正确性测试主要有两种方法，一个是枚举法，另一个是边界值法。
3.6 系统测试第三章 软件测试流程
(7) 可靠性测试可靠性测试是从验证的角度出发，检验系统的可靠性是否达到预期的目标，同时给出当前系统可能的可靠性增长情况。可靠性测试需要从用户角度出发，模拟用户实际使用系统的情况，设计出系统的可操作视图。
(8) 兼容性测试现今，客户对各个开发商和各种软件之间相互兼容、共享数据的能力要求越来越高，所以对于软件兼容性的测试就非常重要。
软件兼容性测试是检测各软件之间能否正常地交互、共享信息，能否正确地和软件合作完成数据处理。从而保障软件能够按照客户期望的标准进行交互，多个软件共同完成指定的任务。
3.6 系统测试第三章 软件测试流程
(9) Web网站测试
Web网站测试是面向因特网 Web页面的测试。众所周知，因特网网页是由文字、图形、声音、视频和超级链接等组成的文档。
网络客户端用户通过在浏览器中的操作，搜索浏览所需要的信息资源。
针对 Web网站这一特定类型软件的测试，包含了许多测试技术，
如功能测试、压力 /负载测试、配置测试、兼容性测试、安全性测试等。黑盒测试、白盒测试、静态测试和动态测试都有可能被采用。
3.7 验收测试第三章 软件测试流程
1．验收测试的定义验收测试（ Acceptance Testing）是向未来的用户表明系统能够像预定要求的那样工作。
通过综合测试之后，软件已完全组装起来，接口方面的错误也已排除，软件测试的最后一步 —— 验收测试即可开始。
验收测试的目的是确保软件准备就绪，并且可以让最终用户将其用于执行软件的既定功能和任务。验收测试是检验软件产品质量的最后一道工序。验收测试通常更突出客户的作用，同时软件开发人员也有一定的参与。如何组织好验收测试并不是一件容易的事。以下对验收测试的任务、目标以及验收测试的组织管理给出详细介绍。
3.7 验收测试第三章 软件测试流程
2．验收测试的内容软件验收测试应完成的工作内容如下：要明确验收项目，规定验收测试通过的标准；确定测试方法；决定验收测试的组织机构和可利用的资源；选定测试结果分析方法；指定验收测试计划并进行评审；设计验收测试所用的测试用例；审查验收测试的准备工作；执行验收测试；分析测试结果；
做出验收结论，明确通过验收或不通过验收，给出测试结果。
3.7 验收测试第三章 软件测试流程
3．验收测试的标准实现软件确认要通过一系列黑盒测试。验收测试同样需要制订测试计划和过程，测试计划应规定测试的种类和测试进度，测试过程则定义一些特殊的测试用例，旨在说明软件与需求是否一致。无论是计划还是过程，都应该着重考虑软件是否满足合同规定的所有功能和性能
，文档资料是否完整、准确，人机界面和其他方面（例如，可移植性
、兼容性、错误恢复能力和可维护性等）是否令用户满意。
验收测试的结果有两种可能，一种是功能和性能指标满足软件需求说明的要求，用户可以接受；另一种是软件不满足软件需求说明的要求，用户无法接受。如果项目进行到这个阶段才发现有严重错误和偏差一般很难在预定的工期内改正，因此必须与用户协商，寻求一个妥善解决问题的方法。
3.7 验收测试第三章 软件测试流程
4．验收测试的常用策略选择的验收测试的策略通常建立在合同需求、组织和公司标准以及应用领域的基础上。实施验收测试的常用策略有三种，它们分别是：
(1) 正式验收测试：正式验收测试是一项管理严格的过程，它通常是系统测试的延续。计划和设计这些测试的周密和详细程度不亚于系统测试。选择的测试用例应该是系统测试中所执行测试用例的子集。
不要偏离所选择的测试用例方向，这一点很重要。在很多组织中，正式验收测试是完全自动执行的。对于系统测试，活动和工件是一样的
。在某些组织中，开发组织（或其独立的测试小组）与最终用户组织的代表一起执行验收测试。在其他组织中，验收测试则完全由最终用户组织执行，或者由最终用户组织选择人员组成一个客观公正的小组来执行。
3.7 验收测试第三章 软件测试流程
(2) 非正式验收或 Alpha 测试：在非正式验收测试中，执行测试过程的限定不像正式验收测试中那样严格。在此测试中，确定并记录要研究的功能和业务任务，但没有可以遵循的特定测试用例。测试内容由各测试员决定。
这种验收测试方法不像正式验收测试那样组织有序，而且更为主观。大多数情况下，非正式验收测试是由最终用户组织执行的。
(3) Beta 测试：与以上两种验收测试策略相比,Beta 测试需要的控制是最少的。在 Beta 测试中，采用的细节多少、数据和方法完全由各测试员决定。
各测试员负责创建自己的环境、选择数据，并决定要研究的功能、特性或任务。各测试员负责确定自己对于系统当前状态的接受标准。 Beta 测试由最终用户实施，通常开发组织对其的管理很少或不进行管理。 Beta 测试是所有验收测试策略中最主观的。
3.7 验收测试第三章 软件测试流程
3.7 验收测试第三章 软件测试流程图 3-12 验收测试的工作流程
5．验收测试的过程验收测试的工作流程如图 3-12所示 。
3.7 验收测试第三章 软件测试流程
6．验收测试的总体思路用户验收测试是软件开发结束后，用户对软件产品投入实际应用以前进行的最后一次质量检验活动。它要回答开发的软件产品是否符合预期的各项要求，以及用户能否接受的问题。由于它不只是检验软件某个方面的质量，而是要进行全面的质量检验，并且要决定软件是否合格，因此验收测试是一项严格的正式测试活动。
用户验收测试可以分为两个大的部分：软件配置审核和可执行程序测试，其大致顺序可分为：文档审核、源代码审核、配置脚本审核、测试程序或脚本审核、可执行程序测试。
习题第三章 软件测试流程
1,简述软件测试的复杂性。
2,对软件的经济性进行总结分析。
3,阐述软件测试的充分性准则。
4,如何描述测试流程整体框架。
5,简述单元测试的目标。
6,解释驱动模块和桩模块概念。
7,简述集成测试的层次划分。
8,归纳确认测试阶段的工作。
9,简述系统测试的流程。
10,归纳验收测试常用的策略。
11,简述验收测试的流程。
