2. 软件开发生存周期中的测试

2.1.软件开发生存周期模型

2.1.1. 软件开发和软件测试

无论选择哪种软件开发生存周期模型，测试活动都应在生存周期的早期阶段开始，以符合测试

的尽早介入原则。

常见的软件开发生存周期模型，本大纲分类如下：

 顺序开发模型

 迭代和增量开发模型

顺序开发模型将软件开发过程描述为线性的、顺序的活动流。它是指开发过程中的任何阶段都

应该在完成前一阶段的基础上进行。从理论上讲，阶段之间没有重叠，但在实践中，都会受益于来

自下一阶段的早期反馈。

在瀑布模型中，开发活动（例如需求分析、设计、编码、测试）是一个接一个完成的。在该模型

中，只有在完成所有其他开发活动之后，才会进行测试活动。

与瀑布模型不同，V-模型将测试过程集成到了整个开发过程中，满足了尽早测试的原则。此外，

V-模型还包括与每个相应开发阶段相对应的测试级别，这进一步支持了尽早测试

2.1.2. 周境中的软件开发生存周期模型

软件开发模型必须适应项目和产品特性的原因可以是：

• 系统的产品风险不同（复杂或简单项目）
• 许多业务单元可以是项目或程序的一部分（顺序开发和敏捷开发的结合）
• 一个产品交付市场的时间短（合并测试级别和/或在测试级别中结合不同的测试类型）

2.2.测试级别

2.2.1. 组件测试

组件测试的目标

组件测试（也称为单元或模块测试）关注在可单独测试的组件。组件测试的目标包括：

 降低风险

 验证组件的功能和非功能行为是否符合设计和规定

 建立对组件质量的信心

 发现组件中的缺陷

 防止缺陷遗漏到更高的测试级别

测试依据

组件测试中可用作测试依据的典型工作产品包括：

 详细设计

 代码

 数据模型

 组件规格说明

测试对象

组件测试的典型测试对象包括：

 组件、单元或模块

 代码和数据结构

 类

 数据库模块

典型的缺陷和失效

组件测试发现的典型缺陷和失效包括：

 功能不正确（例如，不符合设计规格说明中的描述）

 数据流问题

 代码和逻辑不正确

组件测试通常没有进行正式的缺陷管理，缺陷通常在发现后立即修复。但是，当开发人员报告

缺陷时，这为根本原因分析和过程改进提供了重要信息。

特定的方法和职责

组件测试通常由编写代码的开发人员开展，组件测试是需要访问到被测软件的代码。开发人

员可以将组件开发与发现和修复缺陷交替进行。开发人员经常在编写组件代码后编写并执行测

试。但是，尤其在敏捷开发中，编写自动化组件测试用例可能先于编写应用程序代码。

例如，考虑测试驱动开发（TDD）。测试驱动开发是高度迭代的，基于开发自动化测试用例、

构建和集成小段代码，然后执行组件测试、纠正所有问题并重构代码的循环。该过程将持续到完

全构建好组件且通过了所有组件测试。测试驱动开发是测试优先方法的一个例子。虽然测试驱动

开发起源于极限编程（XP），但它已经扩展到其他形式的敏捷以及顺序生存周期（参见 ISTQB

CTFL-AT）

2.2.2. 集成测试

集成测试的目标

集成测试侧重于组件或系统之间的交互。集成测试的目标包括：

 减少风险

 验证接口的功能和非功能行为是否符合设计和规定

 建立对接口质量的信心

 发现缺陷（可能存在于接口本身，也可能存在于组件或系统内部）

 防止缺陷遗漏到更高的测试级别

与组件测试一样，在某些情况下，自动化集成的回归测试可以增强信心，因为即使产品有变更

也不会破坏已有的接口、组件或系统。

本大纲中描述了两种不同级别的集成测试，可以对不同大小的测试对象进行测试，如下所示：

 组件集成测试，侧重于集成组件之间的交互和接口。在组件测试之后执行组件集成测试，

并且组件集成测试通常是自动化的。在迭代和增量开发中，组件集成测试通常是持续集成

过程的一部分。

 系统集成测试，侧重于系统、软件包和微服务之间的交互和接口。系统集成测试还可以涵

盖与外部组织（例如，web 服务）的交互和接口。在这种情况下，开发组织无法控制外部接

口，这可能会给测试带来各种挑战（例如，外部组织代码中阻碍测试的缺陷得以解决、安

排测试环境等）。系统集成测试可以在系统测试之后进行，也可以和正在进行的系统测试活

动并行进行（不论是顺序开发还是迭代和增量开发）。

测试依据

集成测试中可用作测试依据的典型工作产品包括：

 软件和系统设计文档

 序列图

 接口和通信协议规范；

 用例

 组件或系统级别的架构

 工作流

 外部接口定义

测试对象

集成测试的典型测试对象包括：

 子系统

 数据库

 基础结构

 接口

 API

 微服务

典型的缺陷和失效

组件集成测试中典型缺陷和失效包括：

 数据不正确、数据丢失或数据编码不正确

 接口调用的顺序或时序不正确

 接口不匹配

 组件间通信失效

 组件间未处理或处理不当的通信失效

 关于组件间传递的数据含义、数据单位或数据边界的假设不正确

系统集成测试中典型缺陷和失效包括：

 系统间的消息结构不一致

 数据不正确、数据丢失或数据编码不正确

 接口不匹配

 系统间的通信失效

 系统间未处理或处理不当的通信失效

 关于系统间传递的数据定义、数据单元或数据边界的假设不正确

 未遵守强制性安全规定

组件集成测试通常由开发人员负责。系统集成测试通常由测试员负责。

2.2.3. 系统测试

测试依据

系统测试中，可以作为测试依据的典型工作产品包括：

 系统和软件需求规格说明（功能和非功能）

 风险分析报告

 用例

 史诗和用户故事

 系统行为模型

 状态图

 系统和用户手册

测试对象

系统测试的典型测试对象包括：

 应用程序

 硬件/软件系统

 操作系统

 被测系统（SUT）

 系统配置和配置数据

典型的缺陷和失效

系统测试的典型缺陷和失效包括：

 计算不正确

 不正确的或非预期的系统功能或非功能行为

 系统内的控制流和/或数据流不正确

 不能正确完整地开展端到端功能任务

 系统在系统环境中不能正常工作；

 系统不能按照系统和用户手册中的说明进行工作

2.2.4. 验收测试

验收测试的目标

与系统测试类似，验收测试通常侧重于整个系统或产品的行为和功能。验收测试的目标包括：

 建立对整个系统质量的信心

 确认系统是否完整且系统将按预期工作

 验证系统的功能和非功能行为符合规范

验收测试可以提供信息，用以评估系统是否可以部署并交付给客户（最终用户）使用。虽然在

验收测试期间可能会发现缺陷，但发现缺陷通常不是其目标。在验收测试过程中发现大量的缺陷，

在某些情况下可能会被认为是一个重要的项目风险。验收测试也可能是为了满足法律或法规要求或

标准。

验收测试的常见形式包括：

 用户验收测试

 运行验收测试

 合同和法规验收测试

 Alpha 和 beta 测试

Alpha 和 beta 测试

Alpha 和 beta 测试通常被商业现货（COTS）软件的开发人员所采用，他们希望在软件产品投放

市场之前从潜在或现有用户、客户和/或操作人员中获得反馈。Alpha 测试是在开发组织所在场地进行的测试，由潜在或现有客户、和/或操作人员或独立测试团队执行。Beta 测试是由潜在或现有的客户、和/或操作人员在他们本地执行。在完成 alpha 测试后，可以执行 Beta 测试，或之前没有执行过任何 alpha 测试的情况下执行 Beta 测试

测试依据

验收测试中，可以作为测试依据的典型工作产品包括：

 业务流程

 用户或业务要求

 法规、法律合同和标准

 用例和/或用户故事

 系统需求

 系统或用户文档

 安装规程

 风险分析报告

典型的测试对象

验收测试的典型测试对象包括：

 被测系统

 系统配置和配置数据

 完整集成系统的业务流程

 恢复系统和热站点（用于业务连续性和灾难恢复测试）

 操作和维护流程

 表格

 报告

 现有和转换的生产数据

典型的缺陷和失效

验收测试的典型缺陷包括：

 系统工作流程不符合业务或用户要求

 业务规则未正确实现

 系统不满足合同或法规要求

 非功能失效，例如安全漏洞、高负载下的性能效率不足或在被支持平台上的不正确操作

特定的方法和职责

验收测试通常是由客户、业务用户、产品负责人或系统操作员负责，也可能涉及其他利益相关

方。

验收测试通常作为顺序开发生存周期中的最后一个测试级别，但也可能在其他时间发生，例如：

 安装或集成商业现货（COTS）软件产品时，可能会对其进行验收测试；

 试在系统测试之前可能会对新功能增强进行验收测。

2.3.测试类型

2.3.1. 功能测试

2.3.2. 非功能测试

2.3.3. 白盒测试

2.3.4. 与变更相关的测试

 确认测试：修复缺陷后，应该在软件的最新版本上，重新执行之前因该缺陷而导致失败的

测试用例。为了覆盖修复缺陷所需的变化，也可以使用新的测试来测试软件。至少必须在

新的软件版本上重新执行这些由缺陷引起失效的步骤。确认测试的目的是确认是否已成功

修复原来的缺陷。

 回归测试：部分代码所做的变更，无论是修复代码，还是其他类型的更改，都可能会意外

地影响到除更改代码外的其他部分代码的行为，不管是在同一组件内，还是在同一系统的

其他组件中，甚至在其他系统中。变更也可能包括环境的变化，例如操作系统或数据库管

理系统的新版本。这种意外的副作用被称为回归。回归测试包括运行测试来检测这些意外

的副作用。

2.3.5. 测试类型和测试级别

可以在任何测试级别开展上述提到的任何测试类型。下面以银行应用程序为例，介绍功能测试、

非功能测试、白盒测试以及与变更相关的测试在所有测试级别中的应用，从功能测试开始：

 对于组件测试，根据组件是如何计算利息来进行测试设计。

 对于组件集成测试，测试设计是基于如何将在用户界面捕获的账户信息传递到业务逻辑中。

 对于系统测试，测试设计是基于帐户持有人如何在他们的支票帐户上申请信用额度。

 对于系统集成测试，测试设计是基于系统如何使用外部微服务来检查帐户持有者的信用评

分。

 对于验收测试，测试设计是基于银行是如何处理批准或拒绝信贷申请。

以下是非功能测试的示例：

 对于组件测试，性能测试的设计是为了评估开展复杂的总利息计算所需的 CPU 周期数。

 对于组件集成测试，安全性测试的设计是针对从用户界面传到业务逻辑的数据所产生的缓

冲区溢出漏洞。

 对于系统测试，可移植性测试的设计是为了检查表示层是否在所有支持的浏览器和移动设

备上工作。

 对于系统集成测试，可靠性测试的设计是为了在信用评分微服务无法响应时，评估系统的

健壮性。

 对于验收测试，易用性测试的设计是为了评估银行信贷处理界面对残疾人的无障碍性。

以下是白盒测试的示例：

 对于组件测试，测试的设计是为了对所有进行财务设计的组件实现完全的语句和判定覆盖

（参见第 4.3 节）。

 对于组件集成测试，测试的设计是为了测试浏览器界面中的每个屏幕如何将数据传递到下

一个屏幕和业务逻辑。

 对于系统测试，测试的设计是为了覆盖信用额度应用期间可能发生的网页序列。

 对于系统集成测试，测试的设计是为了检查所有可能发送到信用评分微服务的查询类型。

 对于验收测试，测试的设计是为了覆盖所有支持的财务数据文件结构和银行间转账的价值

范围。

最后，以下是与变更相关的测试示例：

 对于组件测试，为每个组件构建自动回归测试，并将其归入在持续集成框架内。

 对于组件集成测试，测试的设计是为了确认当修复的代码已经集成到代码库时，与接口相

关的缺陷已得到修复。

 对于系统测试，如果工作流上的任何屏幕发生更改，则会重新执行指定的工作流的所有测

试。

 对于系统集成测试，每天重新执行与信用评分微服务交互的应用程序的测试，作为该微服

务的持续部署的一部分。

 对于验收测试，在验收测试中修复发现的缺陷后，将重新执行所有先前失败的测试。

2.4.维护测试

2.4.1. 维护的触发因素

维护的触发因素分类如下：

 修改，例如计划的特性改善（例如，基于发布）、纠正和紧急变更，操作环境的更改（例如

计划的操作系统或数据库升级）、商业现货（COTS）软件的升级以及缺陷和漏洞的补丁；

 迁移，例如从一个平台到另一个平台，这可能需要对新环境以及更改的软件进行运行测试，

或者当来自另一个应用程序的数据将迁移到正在维护的系统时进行数据转换测试；

 退役，例如当应用程序的使用周期结束时。

o 当应用程序或系统退役时，如果需要较长的数据保留期，可能需要测试数据迁移或归

档。

o 在长期保留归档之后，还可能需要测试保存/恢复规程。

o 可能需要进行回归测试，以确保在使用中的任何功能仍然有效。

2.4.2. 维护的影响分析

若本文有帮助到阅读本文的同学，欢迎点赞、关注、收藏，互相学习交流。