本文拟从以下 4 个方面来说说看 toB 业务的测试难点以及所能想到的解决思路和方案。
本文基于作者自己所做的业务，只代表作者自己的观点。欢迎大家一起探讨。
我这两年一直在做 toB 的业务。这些业务有一些共性特点，
低频高额
B 端业务不像 C 端，调用频率不那么高，我做过一个半年才有一单，一单就是几个 e 的业务，所以这就注定了 B 端业务，在性能方面的需求是偏弱的。对于 B 端业务，我们的压测诉求也没有那么强烈。我们会更加注重业务的稳定性，因为你不知道他什么时候来走一单。
上游以企业用户为主，下游以金融机构为主
所以我们的战地大部分在中游，对上暴露接口，对下调用接口（当然也会有给机构暴露回调接口）。那么这里的测试策略就以接口测试为主，辅以数据校验。
资损分析
无论是信息流还是资金流，会着重测试状态生命周期。
乍一看，测试策略很清晰，感觉上也很简单，那难点在哪里呢？
在 toB 业务里，测试数据的构造非常困难，特别是要一套能覆盖所有场景（正向和逆向）的数据，基本是不太可能。我遇到的数据主要有：
前面提到我们测试的策略是分层，在测试阶段，我们造数逻辑是外部靠 mock，内部靠调用 api 创建测试数据。为了方便内部造数，我们设计了造数工厂和 MockServer。
当推进到联调阶段的时候，这个时候客户系统和银行机构都已经开发完毕，对应的环境也都 ready。我们将全链路用例梳理完毕，然后由上游客户发起，经过我们的系统，再到银行机构。这个时候，理论上银行机构是可以提供各种类型的数据的，但是即便在测试环境，往往也很难造出很全的数据，特别是异常用例，比如各种各样的错误码。通常，在联调阶段我们会重点 cover 核心主链路。
到了预发或者线上的时候，这个时候的验证就更加困难了。我曾在朋友圈问过和银行合作的 toB 业务，如何做线上验证？所有的回复，都是使用真实账户来验证。但是对于技术人员来说，弄到企业账号的可能性几乎为 0，这个时候如果产品没有协助去拿到客户的真实账号，或者没有协调到客户来帮忙验证的话，这部分的工作很难开展。
这就是第一个难点，测试数据的缺失。虽然我们可以通过 mock 的手段，把自己的系统测试充分，但是全链路联调测试阶段和预发阶段都没有办法保证。这一点，其实还是非常影响发布信心的。
我们测试策略之所以分层的原因其实就是因为测试环境问题。在代码开发阶段，上下游都在开发，通常我们的合作方的效率都比我们慢（可能没我们加班多），所以我们开发编码完成之后，提测的时候，上下游还没有完成。这个时候就只能先测试自己的系统，所以我们做了 MockServer 来 mock 下游调用。这是测新的情况。对于老功能的回归，通常下游机构是没有义务配合你做回归测试的，所以他们更加不太可能有一个稳定的环境提供给你做回归测试。那测旧又该怎么办？这也是我们目前遇到的问题，没有一个稳定的测试环境，可以用来持续回归。
一般 toB 业务多了之后，往往就会有业务中台的诉求，将上层业务的通用能力往中台沉淀，比如账号会员体系，资金能力，机构对接能力。通过中台的建设，可以避免重复建设，统一数据模型，接口协议等等。本质上是让上层业务的研发进入了工业化的流水线。
中台的搭建很考验产品的抽象能力，也考验研发的架构能力，当然对测试的挑战也很大。当不断有新业务接入中台的时候，10 个，20 个，100 个。这个时候，你会发现中台的任何改动，都是牵一发动全身。
在最早上层业务不多的情况下，我们在中台系统其实都没有投入专职测试。当有改动的时候，中台同学发出邮件，把这次的改动点以及影响面描述下，然后上层业务根据情况自己回归。等各业务回归完了之后，中台再发布（通常会建一个表格来跟踪）。因为上层业务不多，所以测试周期不长，整体的发布节奏也还可控。然而随着上层业务和中台自己的发展，这种方式变得不可行，一来业务多，不是所有的业务线都能配合回归，而来中台自己也有了业务需求，需要快速迭代上线，等不及上层业务的回归。所以这个阶段，我们就提出了问题：是否每次都需要全业务全链路回归？基于此，我们将中台发布分成了独立发布，关联发布和全回归发布，对于独立发布主要适用于技改类型，和上层业务无关的中台自身业务等；关联发布就是某个上层业务向中台提出的需求，不会涉及到其他业务；全回归发布，就是通过评估确定上层业务都需要回归的改动。这三种类型的发布形式，在需求和排期阶段就定下了基调，后面就针对三种方式制定不同的测试策略。当然这个时候，也给中台投入了专职测试了，要把中台的质量最厚，测试策略也调整为：中台功能测试 + 中台回归测试 + 上层业务回归测试（可评估）。目前还在试验中，其实也不清楚是不是有效果。
抛砖引玉的提了这 4 点。也在和其他同事，其他公司讨论过，并没有太好的方式。扔到社区里，希望得到更多的讨论！
