系统多,系统与系统之间的交互也多,比如有 ABCDEFG 共 7 个系统,这 7 个系统相互之间各种交互与缠绕
请教下大佬,如果只想测试 其中一个系统 D,那么上下游的依赖,是怎么隔离的? mock 还是直接就 强依赖?
如果是 mock 的话,那工作量肯定也不小,稍微一变动,维护的工作量也不小
目前我们的做法就是直接强依赖,就是把 ABCEFG 其它各个系统都搭建起来,再来测 D,总感觉受限太多,不知道社区大佬有什么好的想法和建议
从理论上来说,必须得 Mock 才能真的做到独立测试。至于 mock 的维护成本,有很多方法可以优化(比如由真实服务的提供团队来维护 mock,保障和真实服务版本内容一致;系统间契约改动保持着向下兼容,这样老的 mock 可以长期复用)
不过实际工作上,如果这 7 个系统的测试团队其实是同一个,甚至是同一个人,大概率还是会直接强依赖来测试,因为要花大精力保障的,是这 7 个系统集成起来的效果。只有这 7 个系统会分给不同团队或者小组来测试时,大家才会花成本投入到各个系统的独立测试中。
至于说这种场景下,想独立测试单个系统时会受限太多,这个信息比较有限,得具体问题具体分析。比如如果只是缺数据,可以考虑通过造数据解决;如果是要求返回异常以便触发某些异常处理机制,也可以考虑针对性构建少量的 mock。
我们的做法是直接在 k8s 上拉一套独立的周边系统(这个操作依赖于各个系统的容器化),这套测试环境就是这个团队独占的
其实 7 个系统不一定多,每个系统做的事情并不一定很复杂,只是按领域设计,拆分了多个服务而已。
如果每个系统都功能很复杂且频繁迭代,那测试团队也不大可能一个团队直接 hold 这么多个系统。
你们系统就你一个测试吗
相互纠缠的系统是架构没规划好,建议全启起来再测。
PS:代码都讲究高内聚低耦合,这系统间还纠缠起来了。。。
单测 mock,集成 mock,系统级测试参考 4 楼……不过 4 楼只说了应用层,金融系统 DB 有可能都是多应用共享的,这个更麻烦,对造数的能力要求比较高
具体怎么搞,其实还是要看你们的系统群的架构设计,包含系统间交互方式、数据管理方式、安全管控等等因素,给不了什么有价值的建议……
本来不想杠你的,但是我看还有人点赞,觉得有必要举个例子给你们琢磨一下:
不说银行,银行太复杂,就说保险吧,至少会包含这些最基本的模块:
……以上所有数据没操作一次都要可追溯,供稽核和监管审计,而且很多很多操作都会影响后续的操作,比如健康险理赔一次之后,第二次理赔,费率不一样了;车险理赔之后次年的保费也会不一样;分红险分红过后保单价值也会随之发生变化……
如果你来设计,是准备把这些服务独立,操作数据向其他服务去冗余呢?还是说放到一个服务里面,一旦服务不可用,所有的业务都不要开展了呢?
依据你给出的设计,你再思考楼主的问题,可能就更容易得出解决方案了,至少我没有勇气去考虑改变系统纠缠的问题
还是要保证功能,从接口、功能等角度去测试
也不叫杠哈,每个人看的角度不同,理解不同,有不同看法很正常。
金融行业的系统过于复杂,我没接触过,就不献丑了。
不过我还是坚持全启起来测。
综合楼上观点,分情况讨论可能是这个样子:
大多数情况下,大家可能都是按照 1 去操作,有些业务形态真的复杂,那就只能 2,这些工作省不了。
一般系统设计接口是稳定的,如果频繁变动接口(mock 轻易就 break),我觉得可以质疑研发的接口设计水平。所以不太需要考虑 mock 要经常维护的问题。如果你能预见这个接口它就是因为业务迭代肯定会频繁变动,好像也没更好办法,因为你的被测服务可能也要跟着变动,那时候你也要被叫过来测试。这种情况先和研发探讨一下再做决定