简短的回答：软件测试与质量保证不是交付前的最后一个阶段——它们决定了系统在上线之后要花掉您多少成本。预算完全相同的两个系统，会在一个点上分道扬镳：它是否在构建时就具备能在客户之前发现缺陷的测试覆盖，还是说您的客户就是测试套件？在前一种情况下，您只在开发期间为质量付一次钱。在后一种情况下，您每个月都要以故障、紧急修复和不断流失的信任来买单。

质量保证不是"交付前有人随便点一点"

企业主中普遍的印象是，质量就是在项目最后一周由一个人打开各个页面、点击各个按钮。这只是其中很小的一部分——而且是效果最差的一部分。真正的质量保证是一个从第一天就开始运转的体系：需求写得足够精确，以便能够被测试；代码由每次变更都会运行的自动化测试覆盖；有一个与生产环境一致的预发布（staging）环境；还有一条部署路径，任何变更在通过这些关卡之前都无法进入生产环境。

实际差别很简单：在第一种机制下，缺陷在被写出几分钟后就会暴露；在第二种机制下，您的客户会在一个月后发现它，而那时您已经在同一个错误之上构建了其他功能。

作为决策者，您需要关注的测试层级

没有人要求您了解技术细节，但您应当知道自己在为什么付钱。以下是任何一份严肃的技术方案都应当列明的层级：

  • 单元测试：独立地验证最小的逻辑单元。它们最快、成本最低，正是它们防止一个小改动破坏发票总额、折扣或税额计算。
  • 集成测试：验证各部分之间以及与外部系统之间的通信是否正确——支付网关、物流、开票平台、消息服务。现实中的大多数故障都出现在这里，而不是代码本身内部。
  • 端到端测试：从头到尾模拟完整的用户旅程，从打开页面到确认订单再到收到通知。
  • 性能与负载测试：回答一个其他任何测试都无法回答的问题——如果同一分钟内涌入的是一千名用户而不是十名，会发生什么？这正是团队常常跳过的一层，结果系统就在您最大规模营销活动的当天崩溃。
  • 安全测试：在别人发现之前扫描常见漏洞。实用的参考是 OWASP Top 10 关键 Web 应用风险清单；在测试计划中看到它被提及，是成熟度的明确信号。
  • 用户验收测试：您和您的团队按照真实的业务场景运行系统，而不是按照开发人员准备的理想脚本。这一阶段由您负责，在它完成之前不应进行任何签收。

为什么缺陷发现得越晚，代价越高

任何管理过软件项目的人都知道这条规律：在编写需求时发现的缺陷，修改一句话就能解决。同样的缺陷如果在上线后才发现，就需要诊断、修复、重新测试、重新部署——通常还要修复过程中被损坏的数据，并向受影响的客户道歉。问题在于，这种差距从不会出现在报价单上，因此把测试从工作范围中砍掉的供应商看起来更便宜。实际上，他们只是把账单推迟了，而且还让它变得更大。

自动化测试与手动测试：何时用哪一种

手动测试对于评估用户体验、边界情况以及一切需要人类判断的事项是不可或缺的。但它无法充当永久的安全网，因为没有人会在每次小改动之后手动重新检查两百个页面。正是自动化测试让持续开发成为可能：测试只需编写一次，就能运行数千次，并在几分钟内告诉您今天的改动是否破坏了团队一年前构建的某项功能。实用原则是：凡是重复性的、涉及资金或数据的事项都应自动化；凡是涉及产品使用感受的事项，都交给人的判断。

注意您的测试数据

有一个问题被许多团队忽略而未加审视：为了让开发人员能够进行测试，把生产数据库复制到预发布环境中。这意味着您客户的姓名、电话号码和地址如今存放在一个访问范围更广、保护更弱的环境里。由沙特数据与人工智能管理局（SDAIA）监管的沙特阿拉伯《个人数据保护法》，对个人数据的处理进行规范，无论您如何称呼存放这些数据的环境。解决办法简单且广为人知：使用合成生成的数据，或在复制之前对敏感字段进行脱敏处理的真实数据。

签约前应向供应商提出的要求

  • 工作范围内的书面测试计划，而不是"系统会经过测试"的口头承诺。
  • 通过持续集成流水线在每次变更时自动运行测试，并在测试失败时阻止部署。
  • 一个与面向客户的环境相分离的预发布环境，并清楚说明其数据来源。
  • 定期的覆盖率报告，既看百分比也看趋势：随着系统增长，覆盖率是在上升还是在下降？
  • 上线后的质保期，明确界定哪些属于免费修复的缺陷，哪些属于新的开发需求。

项目中质量被忽视的迹象

您不需要技术背景就能发现这些迹象：每次修复都会弄坏别的东西；每次部署之前团队都明显紧张；没有人敢碰旧模块，"因为它能用，我们也不知道改动会影响什么"；故障是由您的客户而不是您的监控系统报告的。这些并不是彼此孤立的问题——它们都是缺少测试网的症状，而这张网本可以让团队放心地进行修改。

在 Origami，我们把测试覆盖视为产品的一部分，而不是一项支持费用：一个在两年后无法被安全修改的系统，无论交付当天看起来多么出色，都不是一个成功的系统。

资料来源