--- title: "多供应商软件验收：买方签字前该怎么测？" canonical: https://wavect.io/zh/blog/multi-vendor-software-acceptance-testing/ language: zh description: "两家供应商分别交付后，谁来证明整条用户流程可用？从付款成功却没有订单的真实案例，了解买方如何记录端到端测试证据，按业务风险复核，并确认上线后的维护责任。" image: "https://wavect.io/img/blog/headers/header_multi-vendor-software-acceptance-testing.png" author: ["Kevin Riedl"] published: "2026-11-11" updated: "2026-11-11" reviewed: "2026-11-11" --- # 两家供应商都说开发完成，软件该怎么验收？ [**返回**](/zh/blog/overview/) [![Kevin Riedl](/img/team/kevin.webp)](/zh/team/kevin-riedl/) [Kevin Riedl](/zh/team/kevin-riedl/) https://linkedin.com/in/wsdt 5 分钟 阅读 · 2026年11月11日 最近审核 2026年11月11日 [**下一篇**](/zh/blog/external-qa-benchmark-first-30-days/) 要点速览 签字前，让两家供应商用待发布版本完成同一笔业务，并展示两端可以核对的结果。以付款为例，从支付记录追到可履约订单，还要知道通知失败后谁会发现、如何恢复。额外的人工复核和负载测试应根据潜在损失、预计并发量和供应商以往的可靠程度决定。验收记录要写明剩余风险、责任人和修复约定。 顾客已经付了钱，却迟迟没收到买的东西。找客服一问，商家后台显示这笔款还没付。这样的工单接连涌进来，连运营这套软件的人都说不清钱和订单在哪一步对不上了。 这是我在访谈中谈到的一次支付故障。它也说明了我为什么会在交付会上追问一件事。即便两家供应商各自演示完了自己的部分，谁能用同一笔业务，从用户操作一直查到后台结果？Wavect 有时也是交付方之一，客户完全可以这样问我们。 ## 验收前，业务负责人要先说清什么？ 先把用户付出时间或金钱以后应该得到什么写下来。以电商为例，顾客付款成功，商家能找到这笔款对应的订单，仓库可以发货。这条验收条件给出了观察的位置，也能让业务负责人判断眼前的证据够不够。 再请两家供应商把合同范围对到这条路径上。谁发送支付结果？谁负责记账、更新订单？谁来组织联测？让两个团队各自举证，然后给出一次跨过交接点的完整演示。对于功能、权限和交付范围等常规项目，可以复用 [上线前软件 QA 检查清单](/zh/software-development-guide/software-qa-checklist-before-launch/) 。 ## 为什么顾客付了款，后台却没有订单？ 在开头那个案例里，支付成功后负责通知商家服务器的 webhook 没有配置好。应用沿用了“未支付”的状态。运营人员缺少监控，只能看到软件自己记录的结果。等到顾客来问，客服手里也没有足够的信息追查。 以公开的支付接口为例， [Stripe 的履约文档](https://docs.stripe.com/checkout/fulfillment) 说明了为什么付款后的跳转页面不足以触发可靠的交付。顾客可能在付款后关闭页面。 [Webhook 文档](https://docs.stripe.com/webhooks) 还介绍了事件重试和重复投递。这些资料解释了这类系统的工作方式。案例中的支付服务商未具名。 如果我来验收，会选用一笔能追踪的测试交易。请支付侧指出交易记录，请订单侧从同一笔业务找到可履约的订单。再请值班人演示，假如款项已经到账，订单仍未生成，他会从哪里得知异常，手上有什么信息可以处理。 Google SRE 的 [分布式系统监控指南](https://sre.google/sre-book/monitoring-distributed-systems/) 区分了用户从外面能看到的现象和系统内部留下的线索。放到这里，一个问题是顾客的订单能否交付，另一个是事件究竟停在哪一端。要看支付场景的技术细节，可以参考 [支付成功而订单仍待处理的排查示例](/zh/videos/stripe-payment-succeeded-order-pending-webhook/) 。 ## 两家供应商应该共同留下哪些验收证据？ 我会让双方在待发布版本上跑一次结果可复核的端到端测试。只把各自通过的测试项贴到一起，容易漏掉接口地址、订阅事件或环境配置上的差异。下面是可以直接拿到验收会上填写的记录示例。 | 验收项 | 两家供应商要展示什么 | 在验收记录中写什么 | | --- | --- | --- | | 需求与范围 | 一笔已确认的付款只对应一笔可以履约的订单。 | 需求编号、双方待发布的版本和测试环境。 | | 购买成功 | 用同一笔交易，从支付服务商的收款记录查到运营后台的订单。 | 测试交易编号、实际观察到的最终状态和证据链接。 | | 流程中断 | 模拟通知延迟，展示谁会发现异常、如何补回漏单。 | 告警、负责人、恢复结果，以及是否产生重复订单。 | | 决定与后续安排 | 说明尚未解决的风险，以及谁有权接受。 | 验收结论、负责人、待办事项和复测日期。 | 这份记录可以很短。下次更换供应商版本或回调配置时，接手的人要能据此找到应当重跑的路径，以及能判断结果的人。 ## 怎样按风险复核，又给可靠的团队留足空间？ 先估算一次失败的代价。有付款无订单的可能，就值得检查真实业务状态、告警与补救路径。若一个熟悉的团队只改了低风险文案，让负责人看改动和针对性的回归结果，可能已经够了。要求可靠的开发者反复解释每个小决定，会耗掉交付时间和信任。 流量也要问具体。月活用户分散在整个月，开售时一批人挤进结账页却发生在几分钟内。要不要为两家系统的接口加做负载测试，应看预计的并发量、峰值持续多久、出错后影响多少交易，以及团队现阶段承担得起多少测试成本。 对出错代价高的流程，可以让真人手动从头走一遍，再请另一位工程师检查两侧对状态的理解是否一致。AI 也可以对照需求与测试记录，专门找漏测的异常情形。模型指出的问题交给人复核，能复现的再纳入测试。引入外部团队时， [外部 QA 首月的评估方法](/zh/blog/external-qa-benchmark-first-30-days/) 能帮你判断对方交付的证据是否有用。 在另一个公开项目中，Wavect 为多家供应商交付的七个微服务协调质量保障工作。 [Polity 的 QA 案例](/zh/case-studies/polity/) 记录了团队怎样把各服务的检查和跨服务的用户流程关联起来。 ## 签字前还需要确认谁负责什么？ 请每家供应商说明测过什么、哪些条件仍靠假设，以及上线后谁接第一通故障电话。再核对交付约定，例如双方是否约定在验收后 30 天内免费修复特定缺陷，谁承担后续维护。30 天只是可能的条款，具体范围和期限以双方的约定为准。 交付验收和生产上线可以有不同的负责人。让前者确认交付是否满足约定，让后者明确何时放量、谁看告警、何时暂停。无论团队大小，我都会要求看一遍与本次风险相称的完整流程。剩下多少复核工作，要结合出错的后果和供应商以往的表现来定。 如果两家供应商都交了报告，最担心的业务仍缺一次联测，可以把现有证据带给 Wavect 的 [软件质量保障团队](/zh/services/software-quality-assurance/) ，或 [约一次交付验收讨论](/zh/contact/?intent=qa) 。 ## 关于多供应商软件验收的常见问题 ### 两家供应商各给一张截图，可以作为验收证据吗？ 可以作为佐证，前提是两张图对应同一笔交易、同一组待发布版本和同一环境。请双方给出可关联的编号，再核对运营人员能看到的订单是否已达到约定状态。 ### 验收时必须使用真实顾客的付款吗？ 先在共用的测试环境核对待发布版本及支付配置。如果生产配置有差异，事先同运营方约定一次受控的上线检查，明确谁负责、怎样对账，再开放真实订单。 ### 一家供应商更新组件后，要重跑哪些测试？ 保留上一轮验收记录，列出依赖这次变更的业务结果。用双方实际准备发布的版本重新跑受影响的流程，让新的结论对应本次交付的软件。 ### 有缺陷修复期，就足以批准支付流程上线吗？ 书面约定说明出问题后谁负责、哪些修复在范围内。已付款却拿不到商品的顾客仍要等待，客服也得追查。签字前，应把修复承诺与实际联测结果一起审阅。 ### 早期项目可以在哪些地方减少验收工作？ 影响小且容易撤回的变更，可以沿用团队平时的复核方式。把额外的测试时间留给涉及资金、会在高峰期影响大量用户，或出错后客服难以察觉和补救的操作。 QA 与生产就绪 ## 接下来读什么 可靠生产软件所需的测试、审计、维护与加固。 [从这里开始**AI 生成代码的 QA**](/zh/blog/qa-for-ai-generated-code/) - [README ZIP 恶意软件：审查 AI 工具的实际安装内容](/zh/blog/readme-zip-malware-install-review/) - [AI 生成的 Odoo 模块：先审业务规则，再谈上线](/zh/blog/ai-generated-odoo-module-audit/) - [Odoo 迁移验收：逐条核对业务记录与余额](/zh/blog/odoo-migration-acceptance-reconciliation/) - [Odoo AI 智能体测试：验收实际保存的活动记录](/zh/blog/odoo-ai-agent-business-state-tests/) - [Odoo 20 权限迁移：如何验收多公司隔离？](/zh/blog/odoo-20-company-access-migration-tests/) [下一篇文章**README ZIP 恶意软件：审查 AI 工具的实际安装内容**](/zh/blog/readme-zip-malware-install-review/) [**返回**](/zh/blog/overview/) [![Kevin Riedl](/img/team/kevin.webp)](/zh/team/kevin-riedl/) [Kevin Riedl](/zh/team/kevin-riedl/) https://linkedin.com/in/wsdt 5 分钟 阅读 · 2026年11月11日 最近审核 2026年11月11日 [**下一篇**](/zh/blog/external-qa-benchmark-first-30-days/)