当我对“完成”的 MERN 技术栈 Zerodha 克隆版运行 Specmatic 合约测试时，该工具标记出了五个我的手动检查从未发现的真实缺陷。在生成的 178 个测试用例中，该测试套件以可能影响真实用户的方式破坏了 API——包括无效的数据类型、格式错误的凭据导致崩溃、静默数据损坏、非幂等的注册流程，以及一个导致 CI 门禁（CI gate）立即停止运行的破坏性合约变更。
为什么这些 Bug 会在手动测试中溜掉
该项目结合了 Node.js 后端、React 前端、MongoDB 存储以及用于支付的 Razorpay。我手动走通了注册和支付流程，一切看起来都运行正常。然而，手动测试只能覆盖“快乐路径”（happy path）：它只能确认当用户遵循预期步骤时代码的行为。它无法证明服务能够应对格式错误的请求或意外的客户端行为。
当我将 Specmatic 指向现有代码时，合约（即对每个端点请求和响应结构的明确描述）充当了事实来源（source of truth）。随后，该工具自动生成了一个包含大量正向和负向场景的矩阵，其中许多场景是人工测试人员根本不会想到去编写的。
发现的五个缺陷
- 输入验证漏洞 –
/newOrder端点接受quantity字段的十进制数字和字符串，尽管合约要求其为整数。发送错误类型的生成测试导致 API 行为异常。 - 未处理的登录错误 – 向身份验证路由提供格式错误的凭据触发了运行时异常，因为代码缺乏类型检查。
- 静默支付数据损坏 –
/verify-payment端点允许amount字段使用布尔值。当一个true传入时，数据库记录了一笔金额为零的成功支付，从而在不知不觉中虚增了营收数据。 - 缺失幂等性 – 在测试套件中第二次运行注册流程时失败了，因为端点试图重新创建现有用户，而不是优雅地处理重复请求。
- 捕获破坏性合约变更 – 我故意修改了合约中的一个数据类型。CI 流水线立即拒绝了该变更，防止了破坏性的发布。
为什么合约测试对 CI 流水线至关重要
- 大规模负向测试 – 178 个用例中的大多数都是边界情况输入。手动编写这些用例将极其耗时。
- 为第三方客户端提供安全性 – 合约定义了服务向外部消费者提供的承诺。如果实现发生偏差，合约测试就会失败，从而保护下游应用。
- 快速反馈循环 – CI 门禁在破坏性变更被合并之前将其拦截，从而避免了团队面临代价高昂的回滚。
- 提高代码质量 – 添加 actuator 端点并使注册流程具备幂等性是使合约可测试的必要步骤，这反过来也增强了服务的健壮性。
开发者需要权衡的利弊
合约测试会增加维护开销。规范必须与代码保持同步，且测试生成过程可能会延长构建时间。团队需要决定增加的安全性是否值得投入额外的精力，特别是对于那些觉得手动测试已经足够的较小项目。
未来值得关注的方向
- 更广泛的 CI 应用 – 随着越来越多的团队将合约套件集成到其流水线中，相关工具可能会变得更快且更具可配置性。
- 标准化的合约格式 – 新兴的规范可能会使跨服务和跨团队共享合约变得更加容易。
- 规范更新自动化 – 从代码变更中推断合约的工具可能会减轻手动维护的负担。
如果你仅仅因为 UI 运行流畅就认为你的 API 是稳固的，那么运行一次合约测试可能会揭示手动检查所遗漏的隐藏故障。在你的 CI 流水线中添加可执行合约，可以将“看起来不错”转变为“经证明安全”。