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

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

软件开发生存周期（SDLC）模型是对软件开发过程的抽象、概要表述。SDLC 模型定义了软件开发过程中不同开发阶段和活动类型之间的逻辑和时间关系。SDLC 模型的示例包括：顺序开发模型（例如瀑布模型、V 模型）、迭代开发模型（例如螺旋模型、原型模型）和增量开发模型（例如统一软件开发过程）。

软件开发过程中的活动也可以通过更详细的软件开发方法和敏捷实践来描述。例如：验收测试驱动开发（ATDD）、行为驱动开发（BDD）、领域驱动设计（DDD）、极限编程（XP）、特征驱动开发（FDD）、看板、精益管理、Scrum 和测试驱动开发（TDD）。

2.1.1 软件开发生存周期对测试的影响

测试必须适应软件开发生存周期才能成功。软件开发生存周期的选择会对以下几个方面产生影响：

• 测试活动的范围和时间安排（例如测试级别和测试类型）

• 测试文档的详细程度

• 测试技术和测试方法的选择

• 测试自动化程度

• 测试人员的角色和职责

在顺序开发模型中，测试人员通常在软件开发的初期阶段参与需求评审、测试分析和测试设计。可执行代码通常在后期阶段创建，因此通常无法在软件开发生存周期早期进行动态测试。

在某些迭代和增量开发模型中，每次迭代都会提供供可工作的增量原型或产品。也就是说在每个迭代中，静态和动态测试都可以在所有测试级别上执行。频繁的增量交付需要快速反馈和全面回归测试。

敏捷软件开发假定在项目过程中都可能发生变化。因此，在敏捷项目中，更倾向于轻量级的工作产品文档和全面测试自动化，以便更容易进行回归测试。此外，大部分人工测试往往使用基于经验的测试技术，不需要事前进行大量的测试分析和设计。

2.1.2 软件开发生存周期与良好的测试实践

无论选择哪种软件开发生存周期模型，良好的测试实践包括以下内容：

• 每个软件开发活动，都有相应的测试活动，以便对所有开发活动进行质量控制

• 不同测试级别具有特定且不同的测试目标，可以确保测试既全面又避免冗余

• 给定测试级别的测试分析和设计始于相应的软件开发生存周期开发阶段，以便测试能够遵循早期测试的原则

• 相关文档的初稿完成时，测试人员立即参与评审工作产品，以便早期测试和缺陷检测，从而支持测试左移方法

2.1.3 测试是软件开发的驱动力

测试驱动开发（TDD）、验收测试驱动开发（ATDD）和行为驱动开发（BDD）是类似的开发方法，将测试定义为指导开发的手段。这些方法都实现了早期测试的原则并遵循左移方法，因为测试在编写代码之前定义。它们支持迭代开发模型。这些方法的具体特点如下：

测试驱动开发（TDD）：

• 通过测试用例来指导编码（而不是详尽的软件设计）。

• 先编写测试，后编写代码以满足测试，最后对测试和代码进行重构。

验收测试驱动开发（ATDD）：

• 作为系统设计过程的一部分，从验收准则中导出测试。

• 在部分应用程序开发前，编写测试，以满足测试的要求。

行为驱动开发（BDD）：

• 用简化的自然语言编写测试用例来表达应用程序的期望行为，利益相关方容易理解，通常使用Given/When/Then 格式。

• 自动将测试用例转化为可执行的测试。

对于上述所有方法，通常应用自动化测试，以确保将来改写或重构的代码质量。

2.1.4 DevOps 与测试

DevOps 是一种组织方法，旨在通过使开发（包括测试）和运维部门共同努力，实现一系列通用目标，从而实现协同效应。DevOps 要求组织内部进行文化转变，将开发和运维的职能同等看待，以弥合开发（包括测试）和运维之间的差距。DevOps 倡团队的自主权、快速反馈、集成工具链以及持续集成CI）和持续交付（CD）等技术实践。通过 DevOps 交付流水线，软件团队可以更快地构建、测试和发布高质量的代码。

从测试的角度来看，DevOps 的好处包括：

• 代码质量的快速反馈，并判断变更是否对现有代码产生不利影响。

• 持续集成（CI）通过鼓励开发人员交高质量的代码，并辅以组件测试和静态分析，在测试中实现左移方法。

• 促进 CI/CD 自动化过程，有助于建立稳定的测试环境。

• 更加关注非功能性质量特性（例如性能、可靠性）。

• 交付流水线的自动化，减少人工重复测试的需求。

• 由于自动化回归测试的规模和范围，降低了回归风险。

然而，DevOps 也面临着某些风险和挑战，包括：

• 必须定义和建立 DevOps 交付流水线。

• 必须引入和维护 CI/CD 工具。

• 测试自动化需要额外资源，这些资源可能难以建立和维护。

尽管 DevOps 供了高度自动化测试，但从用户的角度来说，仍然需要人工测试。

2.1.5 左移的方法

测试早期介入的原则有时被称为“左移”，这是软件开发生存周期中较早进行测试的方法。左移建议测试应该早期进行（例如，代码实现或组件集成前开始测试），但不能因此忽视软件开发生存周期的后期测试。

许多良好的实践可以说明如何实现测试 “左移”，包括：

• 从测试的角度评审规格说明。对规格说明进行评审通常可以发现潜在的缺陷，例如规格说明表述模糊、不完整和不一致。

• 编码之前编写测试用例，在代码实现过程中通过测试用具（test harness）运行代码。

• 使用持续集成（CI）和持续交付（CD），供快速反馈和自动化组件测试，可以在代码提交到代码库时运行源代码测试。

• 在动态测试之前或作为自动化过程的一部分对源代码进行静态分析。

• 在可能的情况下，从组件测试级别开始进行非功能性测试。这是左移形式之一，因为非功能性

测试类型通常在系统完整且代表性的测试环境就绪后，在软件开发生存周期的后期执行。左移方法可能会在过程早期增加培训、工作量和成本，但可以节省过程后期的工作量和成本。对于左移，重要的是让利益相关方相信并接受此种方法。

2.1.6 回顾与过程改进

回顾会议（也称为“项目总结会议/post-project meetings”和项目回顾）作为发布的里程碑，通常在项目或迭代结束后，按需召开。回顾会议的时间和组织方式取决于所采用的特定软件开发生存周期模型。回顾会议上，参与者（不仅限于测试人员，还包括开发人员、架构师、产品负责人、业务分析师等）讨论以下内容：

• 哪些工作是成功的，应予以保留？

• 哪些工作没成功，可以改进？

• 如何整合改进并保持未来成功？

应记录结果，通常作为测试完成报告的一部分。回顾对于成功实施持续改进至关重要，对任何建议的改进都要进行跟踪。

测试的典型收益包括：

• 增加测试的有效性/效率（例如，实施过程改进的建议）。

• 高测试件的质量（例如，联合评审测试过程）。

• 团队凝聚力和学习能力（例如，出问题，列出改进点）。

• 高测试依据的质量（例如，处理和解决需求范围和质量方面的缺陷）。

• 改善开发和测试之间的合作（例如，定期评审和优化协作）。