🎉 🎂 🍰 TesterHome 创立 9 周年纪念日 🍰 🎂 🎉

品质管理 toB 业务的测试难点

恒温 · 2021年10月10日 · 最后由 余生 回复于 2021年10月15日 · 1812 次阅读

本文拟从以下 4 个方面来说说看 toB 业务的测试难点以及所能想到的解决思路和方案。

  1. 业务特点
  2. 测试数据
  3. 测试环境
  4. 业务中台

本文基于作者自己所做的业务,只代表作者自己的观点。欢迎大家一起探讨。

业务特点

我这两年一直在做 toB 的业务。这些业务有一些共性特点,

  1. 低频高额
  2. 上游以企业用户为主,下游以金融机构为主,包括银行、保险公司、支付机构
  3. 资损分析方面:部分业务以信息流为主,资金流在下游。部分业务信息流和资金流都有。

低频高额

B 端业务不像 C 端,调用频率不那么高,我做过一个半年才有一单,一单就是几个 e 的业务,所以这就注定了 B 端业务,在性能方面的需求是偏弱的。对于 B 端业务,我们的压测诉求也没有那么强烈。我们会更加注重业务的稳定性,因为你不知道他什么时候来走一单。

上游以企业用户为主,下游以金融机构为主

所以我们的战地大部分在中游,对上暴露接口,对下调用接口(当然也会有给机构暴露回调接口)。那么这里的测试策略就以接口测试为主,辅以数据校验。

资损分析

无论是信息流还是资金流,会着重测试状态生命周期。
乍一看,测试策略很清晰,感觉上也很简单,那难点在哪里呢?

测试数据

在 toB 业务里,测试数据的构造非常困难,特别是要一套能覆盖所有场景(正向和逆向)的数据,基本是不太可能。我遇到的数据主要有:

  1. 不同类型的企业用户的账号
  2. 金融机构,尤其是银行的账户
  3. 涉及第三方认证机构的数据
  4. 各种异常场景的数据,包括金融机构所有的异常码对应的异常数据,上游客户自己的异常数据。

前面提到我们测试的策略是分层,在测试阶段,我们造数逻辑是外部靠 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 同学,答复中没特别的信息,估计也是存在一样的问题。

共收到 27 条回复 时间 点赞

之前做医疗 toB 的业务基本上都是上千万、上亿的也有~

测试环境不稳定,下游业务不配合,这是个通病啊😭

负责下游业务测试,上游业务不配合

也是新入职到了一家负责金融业务相关的,感觉上下游都是爸爸,每天都是围绕着爸爸转圈圈,而且线上我们基本上不去验证的,所以线上发布这块只能完全看线上监控来给点安慰。每次发布都心惊胆战的。。。。

槽神 回复

那是 bd,我们技术还是喝不过。。

BigDel 回复

嗯,大额,但是很奇怪,他们对资损的容忍也挺高的,只要你给他恢复就没太大问题。

黄clown 回复

有没有办法?

残枫 回复

没有发布信心吧?我也是,挺吓人的。

恒温 回复

所以技术的价值就是给他们 bd 养胃啊,你们多做一点,他们就少喝一杯,让 bd 明白这个道理,然后他们就不敢对你们嚣张了,哈哈哈哈~

测试数据

这就是第一个难点,测试数据的缺失。虽然我们可以通过 mock 的手段,把自己的系统测试充分,但是全链路联调测试阶段和预发阶段都没有办法保证。这一点,其实还是非常影响发布信心的。

财经的 QA 会自己花钱在线上真实环境跑用例(转账、付款),最后再走退款流程把钱拿回来,也有在用流量回放、MockServer 等技术。

测试环境

对于老功能的回归,通常下游机构是没有义务配合你做回归测试的,所以他们更加不太可能有一个稳定的环境提供给你做回归测试。那测旧又该怎么办?这也是我们目前遇到的问题,没有一个稳定的测试环境,可以用来持续回归。

关于线上压测和回归,忘记之前从哪里听说的,银行那边会给个固定的压测 QPS 要求,如果超过这个 QPS 就算发压方(也就是我们)的事故。
吐槽一下,平时用个招行银行 app 转账还提示等待 10 秒,用支付宝和微信转账根本不存在这种等待,就是传统银行跟互联网的区别,背后就是新老技术架构、风险承担能力、成本结构的差异。

业务中台

当然这个时候,也给中台投入了专职测试了,要把中台的质量最厚,测试策略也调整为:中台功能测试 + 中台回归测试 + 上层业务回归测试(可评估)。目前还在试验中,其实也不清楚是不是有效果。

以前跟教育业务线的小伙伴交流过,他们比楼主更原始一些,部分教育线的业务中台甚至跟上层业务耦合在一起(也就是业务中台给不同业务做了一堆定制需求)。导致了但凡中台一改,很多业务都要跟着回归一遍,或者业务改了,中台要跟着改,互相坑。

他们的改进路线也比较明显,先让中台逐渐与上层业务解耦,解放测试人力,然后也是将部分 QA 挪到中台中做专项测试(其实很多业务线都是这样做,中台作为最核心的部分,不放人去做专项测试是不实际的,自己都方得都命)。

另一个点,正因为中台是通用且稳定的,意味着老逻辑改动频率低,所以中台更加适合做各种自动化回归(接口自动化、流量回放等),这个收益应该是比较显著的。


由于自己没怎么接触过这类 toB 业务,也就只能把一些道听途说的东西写上来。对于测试数据和测试环境,简单问了财经的 QA 同学,答复中没特别的信息,估计也是存在一样的问题。

恒温 #12 · 2021年10月11日 Author
王稀饭 回复

中台这边其实有一些可以做的,没在文中写,对于 api 和 spi 类型,测试策略还是挺多的。

恒温 回复

现在企业环境就是保障自己系统无问题,上游也好,下游也罢,不配合就找老大😢 ,沟通业务,需求去督促他们配合,不通过就不允许排版上线,总有上头大佬去给他们施压的

平时用个招行银行 app 转账还提示等待 10 秒,用支付宝和微信转账根本不存在这种等待,就是传统银行跟互联网的区别

我怎么觉得这是普通人对业务不了解而造成的偏见呢……
@siwen 司总给解释一下银行转帐和支付宝转帐的区别在哪里吧

恒温 #15 · 2021年10月11日 Author

😂

恒温 回复

你还别说,之前一个隐藏的 bug,一个月后对账才才发现。也就要求公司弥补损失....

恒温 #17 · 2021年10月11日 Author
BigDel 回复

是吧,如果是 c 端的故障,早就上纲上线,1 级故障了。

是的,不过 B 端的需求也是稀奇古怪,比如说为了应付检查要做一些乱起八糟的功能。

槽神 回复

我的理解是银行对资损防控上的谨慎,直觉上银行是直接管钱的,而互联网金融是间接操作钱(或许碰不到实际的钱,最终还是要去到银行?)。在用户体验上的评价是这样的,欢迎澄清一下区别

我们自己开发的中台、数据我们可以自己造、环境我们可以自己配、敌方的(上下游)环境我们可以模拟、突突突往上招呼就对了

恒温 #21 · 2021年10月12日 Author
秋林老祖 回复

银行的也可以么?

中台与业务层,是不是可以走契约测试。从而快速识别需要回归的上层业务。

恒温 #23 · 2021年10月13日 Author
重来看雨 回复

契约是需要研发的诚信和及时保鲜。从方法论上是可以的。

toB 业务也有对性能要求较高的时候,比如我这边是做视频智能安防的,
业务层来说,一个大省下面 100 多万用户,每个用户就是组织机构树下的叶子节点,父节点之间还有错综复杂的级联关系,哪怕是一个管理员用户上去做个查询或搜索类操作,性能压力不小,早期查询超时是家常便饭。压力不一定来自并发或高频,有可能来自业务特性决定的复杂数据结构或数据量。
能力层来说,如果某片地区出现停电或网络抖动,导致这一片十几万设备同时掉线离线,能力层网关或服务器就要面对每秒几万~十几万的请求压过来,时间虽短,但不做任何性能保护的策略,能力层网关很可能触发限流 or 服务器被降级。

“基于此,我们将中台发布分成了独立发布,关联发布和全回归发布,对于独立发布主要适用于技改类型,和上层业务无关的中台自身业务等;关联发布就是某个上层业务向中台提出的需求,不会涉及到其他业务;全回归发布,就是通过评估确定上层业务都需要回归的改动。这三种类型的发布形式,在需求和排期阶段就定下了基调” --- 俺们也一样

恒温 #26 · 2021年10月13日 Author
jinglebell 回复

嗯,我们的 toB 业务都完成了全链路压测改造

无论是账号还是环境,其实主要就是上下游(非内部)协调工作。我们产品是 toG 的,关系网络更复杂,除了 G 还是当地原有厂商,友商,各种兄弟部门,生态伙伴。。。
全链路测试也会有温大大同样的问题,能推动的一般都尽量自己去推,需要多打打关系。推不动的就找战时委员会(项目上的各个部门大佬组成)协调,有时候这些工作已经超出测试能力范畴了,需要委员会多次说明问题的严重性而且要跟进 G(非常强势)的进度。
至于测试问题,应该是各个链路上保障自己业务以及对下游的保障。这样责任就很清晰,测试策略和范围也好制定。但往往客户不会管具体是谁的问题,自己公司需承担全链路的质量保障,所有这就是一个大糅合的过程,摸索前进。没有正确答案,所以测试也比较难做。
最后就和槽神讲的一样,商务关系太重要了。一个好的商务会让研发事半功倍。

需要 登录 后方可回复, 如果你还没有账号请点击这里 注册