软件测试 - 概述

什么是软件测试？

软件测试是评估软件应用程序或系统，以确定其是否满足指定的需求并识别任何缺陷（差距、错误或缺失功能）的过程。它涉及在受控条件下执行软件，以验证其行为、性能、安全性以及其他质量属性。最终目标是向利益相关者提供有关产品质量和发布风险的信息。

根据 ANSI/IEEE 1059 标准，测试定义为：“一个分析软件项以检测现有条件与所需条件之间差异（即缺陷/错误/ bug）并评估软件项特性的过程。” 现代测试还强调通过在生命周期早期让测试人员参与来预防缺陷。

谁执行测试？

测试并非完全由专门的测试团队负责。在现代软件开发中，质量是共同的责任。各种角色都对测试做出贡献：

Software Developers（软件开发人员）: 执行 unit testing（单元测试），并经常参与 integration testing（集成测试）和组件测试。在 DevOps 文化中，开发人员对测试自己的代码承担更多责任。
Software Testers / QA Engineers（软件测试人员 / 质量保证工程师）: 在各个级别（集成测试、系统测试、验收测试）设计和执行测试，制定测试计划，报告缺陷，并经常管理测试自动化。
Software Development Engineers in Test (SDET): 将开发和测试技能相结合的专业工程师，通常专注于构建测试自动化框架和工具。
Test Leads / Test Managers（测试负责人 / 测试经理）: 计划、管理和协调测试工作，定义测试策略，并报告质量状况。
Product Owners / Business Analysts（产品负责人 / 业务分析师）: 参与 acceptance testing（验收测试），确保软件满足业务需求和用户需求。
End Users（最终用户）: 参与 User Acceptance Testing (UAT，用户验收测试）、Beta 测试，并提供真实世界的使用反馈。

在敏捷方法学中，“全团队质量方法”非常普遍，其中每个人都为交付高质量产品做出贡献。

何时开始测试？

‘Shift Left’ 原则提倡在软件开发生命周期 (SDLC) 中尽早开始测试活动。早期测试有助于在缺陷更容易修复且成本更低时检测到它们。测试活动可以在每个阶段进行：

Requirements Phase（需求阶段）: 评审和分析需求的清晰性、完整性和可测试性。
Design Phase（设计阶段）: 评审架构设计和详细设计，以识别潜在缺陷。
Development (Coding) Phase（开发/编码阶段）: 开发人员执行单元测试。静态分析工具可以检查代码质量。
Testing Phase (Dedicated)（专门测试阶段）: 正式执行集成测试、系统测试和验收测试。
Maintenance Phase（维护阶段）: 修改或 bug 修复后的回归测试。

在像 Agile 这样的迭代模型中，测试是每个迭代或 sprint 中的持续活动，确保持续的反馈和质量。

何时停止测试？

决定何时停止测试是一个关键且往往具有挑战性的决策，因为穷尽测试通常是不可能的。该决定通常基于多种因素的组合：

Project Deadlines and Budget Constraints（项目截止日期和预算限制）: 时间和资源的实际限制。
Test Case Completion（测试用例完成度）: 执行所有计划的测试用例或达到预定义的比例。
Coverage Goals（覆盖率目标）: 达到需求覆盖率、代码覆盖率或风险覆盖率的目标水平。
Defect Metrics（缺陷指标）: 当发现新缺陷的速度低于某个阈值，并且没有关键或高优先级的缺陷悬而未决时。
Risk Assessment（风险评估）: 当软件发布的剩余风险被利益相关者认为可以接受时。
Business Value（业务价值）: 当进一步测试的成本超过潜在收益或未发现缺陷的风险时。
Management Decision（管理层决策）: 最终基于所有可用信息和项目背景的决策。

Verification 与 Validation

Verification 和 Validation (V&V，验证与确认) 是质量管理中两个基本概念，它们常常被混淆但有所区别：

方面	Verification（验证）	Validation（确认）
回答的问题	“我们是否正确地构建了产品？”	“我们是否构建了正确的产品？”
关注点	检查软件是否符合其设计和规格。确保内部正确性。	检查软件是否满足用户的需求和预期用途。确保是否符合目的。
时机	通常在整个开发过程中进行，通常在 validation 之前。	通常在开发过程接近尾声时进行，对构建好的产品进行。
活动	静态活动，如对文档（需求、设计、代码）的评审、检查、走查。也包括一些动态检查，如验证特定逻辑的单元测试。	动态活动，如系统测试、验收测试，执行软件以查看其在用户环境中是否按预期工作。
示例	评审设计文档以确保其符合架构标准。单元测试检查函数是否根据其规格正确计算值。	最终用户使用软件执行真实任务的 User Acceptance Testing。系统测试以确保所有功能协同工作，符合用户的使用流程。
性质	更客观，对照文档化的标准和规格进行检查。	更主观，从用户的角度评估产品是否适合其预期用途。

指导原则：测试金字塔和持续测试

测试金字塔（The Test Pyramid）是一个被广泛采用的模型，用于说明不同测试级别的推荐比例。它建议拥有大量快速、廉价的 Unit Tests（单元测试）基础，上面是规模较小的 Integration Tests（集成测试）层，再上面是更小、更慢、更昂贵的 End-to-End (UI) Tests（端到端/UI 测试）层。这种结构促进了更快的反馈和更稳定的测试套件。欲了解更多信息，请搜索“Mike Cohn Test Pyramid”。

Continuous Testing（持续测试）是 DevOps 中的一种实践，测试在整个软件交付管道中持续进行。自动化测试集成到 CI/CD 流程中，为每一次变更提供快速反馈，从而实现更快、更可靠的发布。