本文拟从以下 4 个方面来说说看 toB 业务的测试难点以及所能想到的解决思路和方案。
- 业务特点
- 测试数据
- 测试环境
- 业务中台
本文基于作者自己所做的业务，只代表作者自己的观点。欢迎大家一起探讨。
业务特点
我这两年一直在做 toB 的业务。这些业务有一些共性特点，
- 低频高额
- 上游以企业用户为主，下游以金融机构为主，包括银行、保险公司、支付机构
- 资损分析方面：部分业务以信息流为主，资金流在下游。部分业务信息流和资金流都有。
低频高额
B 端业务不像 C 端，调用频率不那么高，我做过一个半年才有一单，一单就是几个 e 的业务，所以这就注定了 B 端业务，在性能方面的需求是偏弱的。对于 B 端业务，我们的压测诉求也没有那么强烈。我们会更加注重业务的稳定性，因为你不知道他什么时候来走一单。
上游以企业用户为主，下游以金融机构为主
所以我们的战地大部分在中游，对上暴露接口，对下调用接口（当然也会有给机构暴露回调接口）。那么这里的测试策略就以接口测试为主，辅以数据校验。
资损分析
无论是信息流还是资金流，会着重测试状态生命周期。
乍一看，测试策略很清晰，感觉上也很简单，那难点在哪里呢？
测试数据
在 toB 业务里，测试数据的构造非常困难，特别是要一套能覆盖所有场景（正向和逆向）的数据，基本是不太可能。我遇到的数据主要有：
- 不同类型的企业用户的账号
- 金融机构，尤其是银行的账户
- 涉及第三方认证机构的数据
- 各种异常场景的数据，包括金融机构所有的异常码对应的异常数据，上游客户自己的异常数据。
前面提到我们测试的策略是分层，在测试阶段，我们造数逻辑是外部靠 mock，内部靠调用 api 创建测试数据。为了方便内部造数，我们设计了造数工厂和 MockServer。
当推进到联调阶段的时候，这个时候客户系统和银行机构都已经开发完毕，对应的环境也都 ready。我们将全链路用例梳理完毕，然后由上游客户发起，经过我们的系统，再到银行机构。这个时候，理论上银行机构是可以提供各种类型的数据的，但是即便在测试环境，往往也很难造出很全的数据，特别是异常用例，比如各种各样的错误码。通常，在联调阶段我们会重点 cover 核心主链路。
到了预发或者线上的时候，这个时候的验证就更加困难了。我曾在朋友圈问过和银行合作的 toB 业务，如何做线上验证？所有的回复，都是使用真实账户来验证。但是对于技术人员来说，弄到企业账号的可能性几乎为 0，这个时候如果产品没有协助去拿到客户的真实账号，或者没有协调到客户来帮忙验证的话，这部分的工作很难开展。
这就是第一个难点，测试数据的缺失。虽然我们可以通过 mock 的手段，把自己的系统测试充分，但是全链路联调测试阶段和预发阶段都没有办法保证。这一点，其实还是非常影响发布信心的。
测试环境
我们测试策略之所以分层的原因其实就是因为测试环境问题。在代码开发阶段，上下游都在开发，通常我们的合作方的效率都比我们慢（可能没我们加班多），所以我们开发编码完成之后，提测的时候，上下游还没有完成。这个时候就只能先测试自己的系统，所以我们做了 MockServer 来 mock 下游调用。这是测新的情况。对于老功能的回归，通常下游机构是没有义务配合你做回归测试的，所以他们更加不太可能有一个稳定的环境提供给你做回归测试。那测旧又该怎么办？这也是我们目前遇到的问题，没有一个稳定的测试环境，可以用来持续回归。
业务中台
一般 toB 业务多了之后，往往就会有业务中台的诉求，将上层业务的通用能力往中台沉淀，比如账号会员体系，资金能力，机构对接能力。通过中台的建设，可以避免重复建设，统一数据模型，接口协议等等。本质上是让上层业务的研发进入了工业化的流水线。
中台的搭建很考验产品的抽象能力，也考验研发的架构能力，当然对测试的挑战也很大。当不断有新业务接入中台的时候，10 个，20 个，100 个。这个时候，你会发现中台的任何改动，都是牵一发动全身。
在最早上层业务不多的情况下，我们在中台系统其实都没有投入专职测试。当有改动的时候，中台同学发出邮件，把这次的改动点以及影响面描述下，然后上层业务根据情况自己回归。等各业务回归完了之后，中台再发布（通常会建一个表格来跟踪）。因为上层业务不多，所以测试周期不长，整体的发布节奏也还可控。然而随着上层业务和中台自己的发展，这种方式变得不可行，一来业务多，不是所有的业务线都能配合回归，而来中台自己也有了业务需求，需要快速迭代上线，等不及上层业务的回归。所以这个阶段，我们就提出了问题：是否每次都需要全业务全链路回归？基于此，我们将中台发布分成了独立发布，关联发布和全回归发布，对于独立发布主要适用于技改类型，和上层业务无关的中台自身业务等；关联发布就是某个上层业务向中台提出的需求，不会涉及到其他业务；全回归发布，就是通过评估确定上层业务都需要回归的改动。这三种类型的发布形式，在需求和排期阶段就定下了基调，后面就针对三种方式制定不同的测试策略。当然这个时候，也给中台投入了专职测试了，要把中台的质量最厚，测试策略也调整为：中台功能测试 + 中台回归测试 + 上层业务回归测试（可评估）。目前还在试验中，其实也不清楚是不是有效果。
总结
抛砖引玉的提了这 4 点。也在和其他同事，其他公司讨论过，并没有太好的方式。扔到社区里，希望得到更多的讨论！
测试数据
这就是第一个难点，测试数据的缺失。虽然我们可以通过 mock 的手段，把自己的系统测试充分，但是全链路联调测试阶段和预发阶段都没有办法保证。这一点，其实还是非常影响发布信心的。
财经的 QA 会自己花钱在线上真实环境跑用例（转账、付款），最后再走退款流程把钱拿回来，也有在用流量回放、MockServer 等技术。
测试环境
对于老功能的回归，通常下游机构是没有义务配合你做回归测试的，所以他们更加不太可能有一个稳定的环境提供给你做回归测试。那测旧又该怎么办？这也是我们目前遇到的问题，没有一个稳定的测试环境，可以用来持续回归。
关于线上压测和回归，忘记之前从哪里听说的，银行那边会给个固定的压测 QPS 要求，如果超过这个 QPS 就算发压方（也就是我们）的事故。
吐槽一下，平时用个招行银行 app 转账还提示等待 10 秒，用支付宝和微信转账根本不存在这种等待，就是传统银行跟互联网的区别，背后就是新老技术架构、风险承担能力、成本结构的差异。
业务中台
当然这个时候，也给中台投入了专职测试了，要把中台的质量最厚，测试策略也调整为：中台功能测试 + 中台回归测试 + 上层业务回归测试（可评估）。目前还在试验中，其实也不清楚是不是有效果。
以前跟教育业务线的小伙伴交流过，他们比楼主更原始一些，部分教育线的业务中台甚至跟上层业务耦合在一起（也就是业务中台给不同业务做了一堆定制需求）。导致了但凡中台一改，很多业务都要跟着回归一遍，或者业务改了，中台要跟着改，互相坑。
他们的改进路线也比较明显，先让中台逐渐与上层业务解耦，解放测试人力，然后也是将部分 QA 挪到中台中做专项测试（其实很多业务线都是这样做，中台作为最核心的部分，不放人去做专项测试是不实际的，自己都方得都命）。
另一个点，正因为中台是通用且稳定的，意味着老逻辑改动频率低，所以中台更加适合做各种自动化回归（接口自动化、流量回放等），这个收益应该是比较显著的。
由于自己没怎么接触过这类 toB 业务，也就只能把一些道听途说的东西写上来。对于测试数据和测试环境，简单问了财经的 QA 同学，答复中没特别的信息，估计也是存在一样的问题。
无论是账号还是环境，其实主要就是上下游（非内部）协调工作。我们产品是 toG 的，关系网络更复杂，除了 G 还是当地原有厂商，友商，各种兄弟部门，生态伙伴。。。
全链路测试也会有温大大同样的问题，能推动的一般都尽量自己去推，需要多打打关系。推不动的就找战时委员会（项目上的各个部门大佬组成）协调，有时候这些工作已经超出测试能力范畴了，需要委员会多次说明问题的严重性而且要跟进 G（非常强势）的进度。
至于测试问题，应该是各个链路上保障自己业务以及对下游的保障。这样责任就很清晰，测试策略和范围也好制定。但往往客户不会管具体是谁的问题，自己公司需承担全链路的质量保障，所有这就是一个大糅合的过程，摸索前进。没有正确答案，所以测试也比较难做。
最后就和槽神讲的一样，商务关系太重要了。一个好的商务会让研发事半功倍。
“基于此，我们将中台发布分成了独立发布，关联发布和全回归发布，对于独立发布主要适用于技改类型，和上层业务无关的中台自身业务等；关联发布就是某个上层业务向中台提出的需求，不会涉及到其他业务；全回归发布，就是通过评估确定上层业务都需要回归的改动。这三种类型的发布形式，在需求和排期阶段就定下了基调” --- 俺们也一样
toB 业务也有对性能要求较高的时候，比如我这边是做视频智能安防的，
业务层来说，一个大省下面 100 多万用户，每个用户就是组织机构树下的叶子节点，父节点之间还有错综复杂的级联关系，哪怕是一个管理员用户上去做个查询或搜索类操作，性能压力不小，早期查询超时是家常便饭。压力不一定来自并发或高频，有可能来自业务特性决定的复杂数据结构或数据量。
能力层来说，如果某片地区出现停电或网络抖动，导致这一片十几万设备同时掉线离线，能力层网关或服务器就要面对每秒几万~十几万的请求压过来，时间虽短，但不做任何性能保护的策略，能力层网关很可能触发限流 or 服务器被降级。
中台与业务层，是不是可以走契约测试。从而快速识别需要回归的上层业务。
我们自己开发的中台、数据我们可以自己造、环境我们可以自己配、敌方的（上下游）环境我们可以模拟、突突突往上招呼就对了
槽神
回复
我的理解是银行对资损防控上的谨慎，直觉上银行是直接管钱的，而互联网金融是间接操作钱（或许碰不到实际的钱，最终还是要去到银行？）。在用户体验上的评价是这样的，欢迎澄清一下区别
是的，不过 B 端的需求也是稀奇古怪，比如说为了应付检查要做一些乱起八糟的功能。
平时用个招行银行 app 转账还提示等待 10 秒，用支付宝和微信转账根本不存在这种等待，就是传统银行跟互联网的区别
我怎么觉得这是普通人对业务不了解而造成的偏见呢……
@siwen 司总给解释一下银行转帐和支付宝转帐的区别在哪里吧
恒温
回复
现在企业环境就是保障自己系统无问题，上游也好，下游也罢，不配合就找老大
，沟通业务，需求去督促他们配合，不通过就不允许排版上线，总有上头大佬去给他们施压的
测试数据
这就是第一个难点，测试数据的缺失。虽然我们可以通过 mock 的手段，把自己的系统测试充分，但是全链路联调测试阶段和预发阶段都没有办法保证。这一点，其实还是非常影响发布信心的。
财经的 QA 会自己花钱在线上真实环境跑用例（转账、付款），最后再走退款流程把钱拿回来，也有在用流量回放、MockServer 等技术。
测试环境
对于老功能的回归，通常下游机构是没有义务配合你做回归测试的，所以他们更加不太可能有一个稳定的环境提供给你做回归测试。那测旧又该怎么办？这也是我们目前遇到的问题，没有一个稳定的测试环境，可以用来持续回归。
关于线上压测和回归，忘记之前从哪里听说的，银行那边会给个固定的压测 QPS 要求，如果超过这个 QPS 就算发压方（也就是我们）的事故。
吐槽一下，平时用个招行银行 app 转账还提示等待 10 秒，用支付宝和微信转账根本不存在这种等待，就是传统银行跟互联网的区别，背后就是新老技术架构、风险承担能力、成本结构的差异。
业务中台
当然这个时候，也给中台投入了专职测试了，要把中台的质量最厚，测试策略也调整为：中台功能测试 + 中台回归测试 + 上层业务回归测试（可评估）。目前还在试验中，其实也不清楚是不是有效果。
以前跟教育业务线的小伙伴交流过，他们比楼主更原始一些，部分教育线的业务中台甚至跟上层业务耦合在一起（也就是业务中台给不同业务做了一堆定制需求）。导致了但凡中台一改，很多业务都要跟着回归一遍，或者业务改了，中台要跟着改，互相坑。
他们的改进路线也比较明显，先让中台逐渐与上层业务解耦，解放测试人力，然后也是将部分 QA 挪到中台中做专项测试（其实很多业务线都是这样做，中台作为最核心的部分，不放人去做专项测试是不实际的，自己都方得都命）。
另一个点，正因为中台是通用且稳定的，意味着老逻辑改动频率低，所以中台更加适合做各种自动化回归（接口自动化、流量回放等），这个收益应该是比较显著的。
由于自己没怎么接触过这类 toB 业务，也就只能把一些道听途说的东西写上来。对于测试数据和测试环境，简单问了财经的 QA 同学，答复中没特别的信息，估计也是存在一样的问题。
也是新入职到了一家负责金融业务相关的，感觉上下游都是爸爸，每天都是围绕着爸爸转圈圈，而且线上我们基本上不去验证的，所以线上发布这块只能完全看线上监控来给点安慰。每次发布都心惊胆战的。。。。
负责下游业务测试，上游业务不配合
测试环境不稳定，下游业务不配合，这是个通病啊
之前做医疗 toB 的业务基本上都是上千万、上亿的也有~
土比业务，酒桌上见真章，技术是次要的