本文内容
两家供应商都说开发完成，软件该怎么验收？
顾客已经付了钱，却迟迟没收到买的东西。找客服一问，商家后台显示这笔款还没付。这样的工单接连涌进来，连运营这套软件的人都说不清钱和订单在哪一步对不上了。
这是我在访谈中谈到的一次支付故障。它也说明了我为什么会在交付会上追问一件事。即便两家供应商各自演示完了自己的部分，谁能用同一笔业务，从用户操作一直查到后台结果？Wavect 有时也是交付方之一，客户完全可以这样问我们。
验收前，业务负责人要先说清什么？
先把用户付出时间或金钱以后应该得到什么写下来。以电商为例，顾客付款成功，商家能找到这笔款对应的订单，仓库可以发货。这条验收条件给出了观察的位置，也能让业务负责人判断眼前的证据够不够。
再请两家供应商把合同范围对到这条路径上。谁发送支付结果？谁负责记账、更新订单？谁来组织联测？让两个团队各自举证，然后给出一次跨过交接点的完整演示。对于功能、权限和交付范围等常规项目，可以复用上线前软件 QA 检查清单。
为什么顾客付了款，后台却没有订单？
在开头那个案例里，支付成功后负责通知商家服务器的 webhook 没有配置好。应用沿用了“未支付”的状态。运营人员缺少监控，只能看到软件自己记录的结果。等到顾客来问，客服手里也没有足够的信息追查。
以公开的支付接口为例，Stripe 的履约文档说明了为什么付款后的跳转页面不足以触发可靠的交付。顾客可能在付款后关闭页面。Webhook 文档还介绍了事件重试和重复投递。这些资料解释了这类系统的工作方式。案例中的支付服务商未具名。
如果我来验收，会选用一笔能追踪的测试交易。请支付侧指出交易记录，请订单侧从同一笔业务找到可履约的订单。再请值班人演示，假如款项已经到账，订单仍未生成，他会从哪里得知异常，手上有什么信息可以处理。
Google SRE 的分布式系统监控指南区分了用户从外面能看到的现象和系统内部留下的线索。放到这里，一个问题是顾客的订单能否交付，另一个是事件究竟停在哪一端。要看支付场景的技术细节，可以参考支付成功而订单仍待处理的排查示例。
两家供应商应该共同留下哪些验收证据？
我会让双方在待发布版本上跑一次结果可复核的端到端测试。只把各自通过的测试项贴到一起，容易漏掉接口地址、订阅事件或环境配置上的差异。下面是可以直接拿到验收会上填写的记录示例。
| 验收项 | 两家供应商要展示什么 | 在验收记录中写什么 |
|---|---|---|
| 需求与范围 | 一笔已确认的付款只对应一笔可以履约的订单。 | 需求编号、双方待发布的版本和测试环境。 |
| 购买成功 | 用同一笔交易，从支付服务商的收款记录查到运营后台的订单。 | 测试交易编号、实际观察到的最终状态和证据链接。 |
| 流程中断 | 模拟通知延迟，展示谁会发现异常、如何补回漏单。 | 告警、负责人、恢复结果，以及是否产生重复订单。 |
| 决定与后续安排 | 说明尚未解决的风险，以及谁有权接受。 | 验收结论、负责人、待办事项和复测日期。 |
这份记录可以很短。下次更换供应商版本或回调配置时，接手的人要能据此找到应当重跑的路径，以及能判断结果的人。
怎样按风险复核，又给可靠的团队留足空间？
先估算一次失败的代价。有付款无订单的可能，就值得检查真实业务状态、告警与补救路径。若一个熟悉的团队只改了低风险文案，让负责人看改动和针对性的回归结果，可能已经够了。要求可靠的开发者反复解释每个小决定，会耗掉交付时间和信任。
流量也要问具体。月活用户分散在整个月，开售时一批人挤进结账页却发生在几分钟内。要不要为两家系统的接口加做负载测试，应看预计的并发量、峰值持续多久、出错后影响多少交易，以及团队现阶段承担得起多少测试成本。
对出错代价高的流程，可以让真人手动从头走一遍，再请另一位工程师检查两侧对状态的理解是否一致。AI 也可以对照需求与测试记录，专门找漏测的异常情形。模型指出的问题交给人复核，能复现的再纳入测试。引入外部团队时，外部 QA 首月的评估方法能帮你判断对方交付的证据是否有用。
在另一个公开项目中，Wavect 为多家供应商交付的七个微服务协调质量保障工作。Polity 的 QA 案例记录了团队怎样把各服务的检查和跨服务的用户流程关联起来。
签字前还需要确认谁负责什么？
请每家供应商说明测过什么、哪些条件仍靠假设，以及上线后谁接第一通故障电话。再核对交付约定，例如双方是否约定在验收后 30 天内免费修复特定缺陷，谁承担后续维护。30 天只是可能的条款，具体范围和期限以双方的约定为准。
交付验收和生产上线可以有不同的负责人。让前者确认交付是否满足约定，让后者明确何时放量、谁看告警、何时暂停。无论团队大小，我都会要求看一遍与本次风险相称的完整流程。剩下多少复核工作，要结合出错的后果和供应商以往的表现来定。
如果两家供应商都交了报告，最担心的业务仍缺一次联测，可以把现有证据带给 Wavect 的软件质量保障团队，或约一次交付验收讨论。