当错误到达生产环境时，原因通常不是有人忘记运行测试。问题在于，需求从未受到质疑，测试数据是错误的，或者没有人同意“完成”的含义。 软件测试生命周期通过为测试提供从第一个需求到最终报告的清晰结构来解决这些问题。

本指南解释了每个阶段，然后遵循所有阶段的一个说明性功能：登录页面在五次失败尝试后锁定帐户。消息来源对于阶段数量并不完全一致。您会看到有七个或八个模型，但它们大多以不同的方式分配相同的工作。我们使用广泛教授的六阶段版本。

什么是 STLC？

STLC 是一系列定义的测试活动，旨在确认软件满足其要求。每个阶段都有一个目标、输入和输出，因此测试是有计划和可追踪的，而不是最后临时凑合的。

好处是实用的。测试人员尽早参与，此时修复缺陷的成本较低。努力去承担最高的风险。当经理问“我们准备好发布了吗？”时，团队可以用证据来回答。

STLC 的六个阶段一览

进入标准是阶段开始之前必须满足的条件。 退出条件是结束之前必须满足的条件。例如，它们可以阻止团队在损坏的构建上运行测试并浪费一天的时间。

第一阶段：需求分析

测试人员研究需求以找出哪些内容可以测试以及哪些内容尚不清楚。这通常是防止错误最便宜的地方，因为问题的成本远远低于生产修复的成本。

• 条目： 已提供需求文档或用户故事。
• 活动： 识别功能性和非功能性需求，提出问题，评估风险并决定哪些内容可以自动化。
• 退出： 回答开放性问题并启动需求可追溯性矩阵 (RTM)。
• 可交付成果： 可测试需求列表和 RTM。

登录示例。故事说“五次尝试失败后锁定帐户”。一个好的测试人员会问：五个在哪个时期？它是如何解锁的？成功登录会重置计数吗？显示什么消息？每个答案都成为可测试的东西。

第 2 阶段：测试计划

团队决定范围、方法、人员、工具、时间表和风险。测试负责人通常负责此阶段。

• 条目：分析了需求并进行了初步风险评估。
• 活动： 定义范围、估计工作量、选择工具、分配角色并为后续阶段设置退出标准。
• 退出：测试计划审核通过。
• 可交付成果： 测试计划和工作量估计。

登录示例。范围：网络和移动设备上的锁定规则、重置和错误消息。超出范围：单点登录，由另一个团队处理。最大的风险是锁定真正的用户，因此受到最多的关注。如果您不确定计划与策略有何不同，请阅读测试计划与测试策略。

第 3 阶段：测试用例开发

这是测试人员编写详细测试用例、自动化脚本和测试数据的地方。

• 条目： 批准的测试计划和稳定的要求。
• 活动：编写和审查测试用例、准备数据、编写自动检查脚本并更新 RTM。
• 退出：测试用例和数据已审核并准备就绪。
• 可交付成果： 测试用例、脚本和测试数据。

请注意，TC-01 和 TC-02 测试极限的任一侧，该极限直接来自边界值分析。有关编写这些测试用例的更多信息，请参阅如何编写测试用例。

第 4 阶段：测试环境设置

测试需要在现实的地方运行：正确的服务器、数据、帐户、浏览器和网络访问。此阶段通常与第 3 阶段并行运行，并且可能由开发人员或 DevOps 团队处理。

• 条目：测试计划、架构概述和环境要求。
• 活动： 设置硬件或容器、加载数据、配置访问并安装构建。
• 退出：环境已准备好并且烟雾测试通过。
• 交付成果：工作环境和烟雾测试结果。

登录示例。 登台获取处于已知状态的测试帐户，以及缩短的锁定计时器，因此测试人员无需等待。快速冒烟测试确认在完整运行开始之前登录已加载。容器有助于保持环境的一致性，如我们的 Docker Compose 教程 所示。

第五阶段：测试执行

测试人员运行计划的测试，比较实际结果和预期结果并报告缺陷。已修复的错误将被重新测试，相关区域将接受回归测试。

• 条目： 测试用例已准备就绪，环境正常运行并且构建已交付。
• 活动：运行测试、记录结果、记录缺陷、重新测试修复并更新 RTM。
• 退出： 运行计划的测试，修复或正式接受缺陷。
• 可交付成果： 测试结果和缺陷报告。

登录示例。 TC-04 失败：使用两个浏览器，计数器仅达到 4。测试人员用清晰的步骤和证据记录错误，如如何编写错误报告中所述。修复后，TC-04 将重新运行，相关登录检查将通过回归检查表。

第 6 阶段：测试结束

这个阶段通常被跳过，这是一种耻辱，因为这是团队改进的方式。团队评估周期、归档其工作并记录所学到的知识。

• 条目：执行已完成并且缺陷状态已知。
• 活动：检查退出标准，分析缺陷趋势，归档测试资产并进行回顾。
• 退出： 结案报告已签署。
• 可交付成果： 结束报告和经验教训。

登录示例。报告显示，一次修复后，所有五个案例都通过了。教训是，并发性只是在后期才进行测试，因此未来带有计数器的功能会在设计过程中添加该场景。

STLC 与 SDLC

SDLC（软件开发生命周期）涵盖了整个产品的构建。 STLC 是专注于测试的部分，并与其一起运行。

SDLC 中的需求分析为 STLC 中的需求分析提供支持，而开发则将构建交付到测试执行中。测试不必等到编码结束。早开始就是人们所说的“左移”。

敏捷和 DevOps 中的 STLC

这些阶段听起来像是一个漫长的、单向的过程，但事实并非如此。在敏捷中，相同的活动会在每个冲刺中缩小并重复，通常需要几个小时而不是几周：

• 需求分析通过对用户故事的问题进行待办事项细化。
• 规划发生在冲刺规划中，用轻量级的注释代替长文档。
• 测试设计与编码同时进行，通常作为验收标准和自动化测试。
• 环境设置通过容器和基础设施即代码实现自动化。
• 执行在CI/CD管道中连续运行。
• 结束成为冲刺审查和回顾的一部分。

保留有用的内容，并根据风险调整文书工作。小型内部工具可能需要简短的清单，而银行系统出于监管原因可能需要正式签字。

常见错误

• 测试人员迟到。 在需求中发现的错误比发布后发现的错误要便宜得多。
• 模糊的退出标准。如果没有这些标准，最后期限就会为你做出决定。
• 在恶劣的环境中进行测试。 由于错误的数据或配置而导致的失败会浪费时间并削弱信任。
• 跳过关闭。团队然后在下一个周期中重复相同的错误。
• 过于严格地遵循它。 STLC 是一个指南。厚重的文档并不自动意味着更好的质量。

最后的话

软件测试生命周期只是对六个问题的严格回答：我们测试什么、如何测试、使用哪些案例、在哪里、发生了什么以及我们学到了什么？查看您的下一个功能，并检查您的团队通常会跳过哪些问题。弥补这一差距可能会给你带来最大的收获。

常见问题

继续学习