软件测试过程与方法(1)：单元测试，集成测试，确认测试

54 阅读 0 评论 36 点赞

我是靠谱客的博主轻松香氛，最近开发中收集的这篇文章主要介绍软件测试过程与方法(1)：单元测试，集成测试，确认测试，觉得挺不错的，现在分享给大家，希望可以做个参考。

概述

软件测试过程

软件测试从测试计划编写到测试实施，需要经过一系列的过程。这些测试按软件从编写到交付的各个阶段的先后顺序可分为以下5个阶段：
单元测试
集成测试
确认（有效性）测试
系统测试
验收（用户）测试

单元测试

单元测试的定义：
单元测试（Unit Testing）是对软件基本构成单元进行的测试。单元测试的对象是软件设计的最小单位——模块。作为一个最小的单元应该有明确的功能定义、性能定义和接口定义，而且可以清晰地与其他单元区分开来。一个菜单、一个显示界面或者能够独立完成的具体功能都可以是一个单元。
单元测试通常是开发者编写的一小段代码，用于检验被测代码的一个很小的、很明确的功能是否正确。通常而言，一个单元测试是用于判断某个特定条件（或者场景）下某个特定函数的行为。因此，单元测试通常是由程序员自己来完成的。

单元测试的目标：
单元测试的主要目标是确保各单元模块被正确的编码。单元测试除了保证测试代码的功能性，还需要保证代码在结构上具有可靠性和健全性，并且能够在所有的条件下做出正确的响应。进行全面的单元测试，可以减少应用级别所需的工作量，并且彻底减少系统产生错误的可能性。

单元测试的主要内容：
模块接口测试；局部数据结构测试；独立路径测试；出错处理测试；边界条件测试。这些测试都作用于模块，共同完成单元测试任务。
在这里插入图片描述

单元测试的步骤：
通常单元测试在编码阶段进行。当源程序代码编制完成，经过评审和验证，确认没有语法错误之后，就开始进行单元测试的测试用例设计。利用设计文档，设计可以验证程序功能、找出程序错误的多个测试用例。对于每一组输入，应有预期的正确结果。
由于模块接口测试中的被测模块并不是一个独立的程序，在考虑测试模块时，同时要考虑它和外界的联系，用一些辅助模块去模拟与被测模块相关联的其他模块。这些辅助模块可分为两种：

驱动模块（driver）：相当于被测模块的主程序，它接收测试数据，把这些数据传给被测模块，最后输出实测结果。
桩模块（stub）：
用以代替被测模块调用的子模块，桩模块可以做少量的数据操作，不需要把子模块所有功能都带进来，但不允许什么事情也不做。被测模块与被测模块相关的驱动模块及桩模块共同构成了一个“测试环境”，如下图所示。

集成测试

集成测试的定义：
集成测试（Integration Testing）是单元测试的扩展和延伸，是为了测试程序模块之间接口的规范性、一致性等，在测试时根据实际情况对程序模块采用适当的策略组装起来，对系统的接口及集成后的功能进行正确校验。
通常经过单元测试后的模块能够单独工作，能够达到设计要求，但在把模块集成后并不能保证各模块能够正常地协同工作。程序在某些局部反映不出来的问题，在全局上很有可能暴露出来，从而影响到软件功能的实现。因此，在各模块完成单元测试的基础上，还应将模块按设计要求组装成起来，针对程序整体结构进行集成测试。

在集成测试时需要考虑以下问题：
模块集成后，穿越模块接口的数据是否会丢失。
模块集成后，各模块的功能是否会相互抑制。
模块集成后的功能能否达到预期的要求。
各模块的接口是否一致、各模块间的数据流和控制流是否按照设计实现其功能。
全局及局部数据的作用域是否存在问题,是否会被非法修改。
单个模块的误差通过累积是否会放大到不能接受的程度。
单个模块的错误是否会导致数据库错误。

集成测试的层次
软件的开发过程是一个从需求到实现的自上而下，逐步细化的过程，而软件测试则是对开发过程的一个逆向求证、自下而上的验证。集成测试对于传统软件和面向对象的应用系统的测试是不同的，分别体现在以下两个方面：
对于传统软件的3个测试层次：

模块内集成测试。
子系统内集成测试。
子系统间集成测试。

对于面向对象的应用系统的两个测试阶段：

类内集成测试。
类间集成测试。

集成测试的模式
选择用何种方式把模块组装起来形成一个可运行的系统是软件集成测试中的策略体现，其重要性是明显的，集成的方式直接关系到模块测试用例的形式、所用测试工具的类型、模块编号的次序和测试的次序、生成测试用例的费用和调试的费用等，一般是根据软件的具体情况来决定采用哪种模式。通常，把模块组装成为系统的测试方式有两种：

1.一次性集成测试：一次性集成测试又称非增量式集成测试，先分别测试每个模块，再把所有模块按设计要求一次全部组装起来所要的系统，然后进行整体测试。在这里插入图片描述

2.增量式集成测试方式
在增量式集成测试模式中，程序一段一段地扩展，测试的范围一步一步地增大，具体做法是把下一个要测试的模块同已经测好的模块结合起来进行测试，测试完毕，再把下一个应该测试的模块结合进来继续进行测试。在组装的过程中边连接边测试，以发现连接过程中产生的错误。如果出现错误，则错误发生在新加入的模块中。增量式集成测试有3种方式：
①自顶向下增量测试方式（Top-down Integration）
自顶向下增量测试方式从主控模块开始，按照软件的控制层次结构，以深度优先或广度优先的策略，逐步把各个模块集成在一起。

在这里插入图片描述
②自底向上增量测试方式（Bottom-up Integration）
自底向上增量测试是从软件结构最低层的模块开始向上一层层地组装测试。
③混合增量测试方式（ModifiedTop-downIntegration）
自顶向下增量的方式和自底向上增量的方式各有优缺点，此处不过多阐述。
因此，通常是把以上两种方式结合起来进行组装和测试：
1）改进的自顶向下增量测试：基本思想是强化对输入／输出模块和引入新算法模块的测试，并自底向上组装成为功能相当完整且相对独立的子系统，然后由主模块开始自顶向下进行增量测试。
2）自底向上－自顶向下的增量测试（混和法）：首先对含读操作的子系统自底向上直至根结点模块进行组装和测试，然后对含写操作的子系统做自顶向下的组装与测试。
3）回归测试：这种方式采取自顶向下的方式测试被修改的模块及其子模块，然后将这一部分视为子系统，再自底向上测试，以检查该子系统与其上级模块的接口是否适配。

一次性集成测试方式与增量式集成测试方式的比较：
增量式集成方式需要编写的软件较多，工作量较大，花费的时间较多，一次性集成方式的工作量较小。
增量式集成方式发现问题的时间比一次性集成方式早。
增量式集成方式比一次性集成方式更容易判断出问题的所在，因为出现的问题往往和最后加进来的模块有关。增量式集成方式测试得更为彻底。
使用一次性集成方式可以多个模块并行测试。

集成测试的组织和实施
集成测试要完成程序的组装及测试，还要进行组装成的功能模块的测试，因此必须精心计划，并与单元测试的完成时间协调起来。在制订测试计划时，应考虑如下因素：
采用何种系统组装方法来进行组装测试。
组装测试过程中连接各个模块的顺序。
模块代码编制和测试进度是否与组装测试的顺序一致。
测试过程中是否需要专门的硬件设备。

集成测试完成的标志
可以从以下几个方面来判定集成测试过程是否完成：
成功地执行了测试计划中规定的所有集成测试。
修正了所发现的错误。
测试结果通过了专门小组的评审。

采用集成测试的原因
不管采用什么模式开发软件，具体的开发工作总是从一个一个的软件单元做起，软件单元只有经过集成才能形成一个有机的整体。具体的集成过程可能是显性的也可能是隐性的。只要有集成，总是会出现一些常见问题，工程实践中，几乎不存在软件单元组装过程中不出任何问题的情况。

确认测试

确认测试的定义
经过集成测试，分散开发的模块被连接起来构成完整的程序，各模块间接口存在的种种问题都已消除。测试工作就可以进入确认测试（Validation Testing）阶段。确认测试又称为有效性测试或合格性测试（Qualification Testing），其目的是验证软件的功能和性能及其特性是否与客户的要求一致，是否满足软件需求规格说明书中的规定。确认测试阶段需要做的工作如下图所示。首先要进行有效性测试及软件配置审查，然后进行验收测试和安装测试，在通过了专家鉴定之后，才能成为可交付的软件。
在这里插入图片描述
确认测试是在模拟的环境（可能是就是开发的环境）下，通过一系列黑盒测试来验证所测试件是否满足需求规格说明书列出的需求。
确认测试同样需要制订测试计划和过程，测试计划应规定测试的种类和测试进度，测试过程则定义一些特殊的测试用例，旨在说明软件与需求是否一致。无论是计划还是过程，都应该着重考虑软件是否满足合同规定的所有功能和性能，文档资料是否完整、准确的人机界面和其他方面（例如，可移植性、兼容性、错误恢复能力和可维护性等）是否令用户满意。

确认测试的准则
若一个软件的功能、性能及限制条件达到了设计要求，则这个软件的开发是成功的。判断软件在功能、性能及限制条件上达到设计要求，就需要按照需求规格说明书进行功能确认测试。在测试前，要依据需求规格说明书制订更详细、更具体的测试规格说明书（Test Specification）。在测试规格说明书中应明确指出确认测试应测试哪些方面，并给出测试用例。除了考虑功能和性能以外，还需要检验软件其他方面的要求，如可移植性、兼容性、可维护性、人机接口及开发的文件资料等是否符合要求。经过确认测试，就可以为已开发的软件做出结论性评价。

确认测试的结果

在全部软件测试的测试用例运行完后，所有的测试结果可以分为两类：
1.测试结果与预期的结果相符。说明软件的这部分功能或性能特征与需求规格说明书相符合，用户可以接受。
2.测试结果与预期的结果不符，与需求说明书有相当大的偏离，不满足用户要求，用户无法接受。

确认测试应交付的文档有：确认测试分析报告、最终的用户手册和操作手册、项目开发总结报告。

软件配置审查
确认测试的另一个重要环节是配置复审。复审的目的在于保证软件配置齐全、分类有序，各方面的质量都符合要求，具备维护阶段所需的细节资料并且已经编排好分类的目录。除了按合同规定的内容和要求，由人工审查软件配置之外，在确认测试的过程中，还应当严格遵守用户手册和操作手册中规定的使用步骤，以便检查这些文档资料的完整性和正确性。必须仔细记录发现的遗漏和错误，并且适当地补充和改正。