测试管理 系统是如何独立测试的?

树叶 · 2023年06月25日 · 最后由 王稀饭 回复于 2023年06月26日 · 7669 次阅读

系统多,系统与系统之间的交互也多,比如有 ABCDEFG 共 7 个系统,这 7 个系统相互之间各种交互与缠绕

请教下大佬,如果只想测试 其中一个系统 D,那么上下游的依赖,是怎么隔离的? mock 还是直接就 强依赖?

如果是 mock 的话,那工作量肯定也不小,稍微一变动,维护的工作量也不小

目前我们的做法就是直接强依赖,就是把 ABCEFG 其它各个系统都搭建起来,再来测 D,总感觉受限太多,不知道社区大佬有什么好的想法和建议

共收到 17 条回复 时间 点赞

从理论上来说,必须得 Mock 才能真的做到独立测试。至于 mock 的维护成本,有很多方法可以优化(比如由真实服务的提供团队来维护 mock,保障和真实服务版本内容一致;系统间契约改动保持着向下兼容,这样老的 mock 可以长期复用)

不过实际工作上,如果这 7 个系统的测试团队其实是同一个,甚至是同一个人,大概率还是会直接强依赖来测试,因为要花大精力保障的,是这 7 个系统集成起来的效果。只有这 7 个系统会分给不同团队或者小组来测试时,大家才会花成本投入到各个系统的独立测试中。

至于说这种场景下,想独立测试单个系统时会受限太多,这个信息比较有限,得具体问题具体分析。比如如果只是缺数据,可以考虑通过造数据解决;如果是要求返回异常以便触发某些异常处理机制,也可以考虑针对性构建少量的 mock。

陈恒捷 回复

7 个系统组成的可能太多了。单系统做好测试,集成做好核心链路就可以了吧。利用 mock 把测试工作更多的左移和右移。

恒温 回复

金融类系统,十几甚至几十个都正常,7 个小场面😎

我们的做法是直接在 k8s 上拉一套独立的周边系统(这个操作依赖于各个系统的容器化),这套测试环境就是这个团队独占的

恒温 回复

其实 7 个系统不一定多,每个系统做的事情并不一定很复杂,只是按领域设计,拆分了多个服务而已。

如果每个系统都功能很复杂且频繁迭代,那测试团队也不大可能一个团队直接 hold 这么多个系统。

陈恒捷 回复

通过敏捷方式管理按特性划分

树叶 #10 · 2023年06月25日 Author
小狄子 回复

那就还是把 ABCEFG 全部启起来,然后再测 D, 和我们目前搞法差不多

恒温 回复

也想着 mock 来着。。就是工作量有点大(新写和维护 工作量都大

槽神 回复

槽大佬 是采用的什么方式呢 ?

你们系统就你一个测试吗

相互纠缠的系统是架构没规划好,建议全启起来再测。

PS:代码都讲究高内聚低耦合,这系统间还纠缠起来了。。。

树叶 回复

单测 mock,集成 mock,系统级测试参考 4 楼……不过 4 楼只说了应用层,金融系统 DB 有可能都是多应用共享的,这个更麻烦,对造数的能力要求比较高
具体怎么搞,其实还是要看你们的系统群的架构设计,包含系统间交互方式、数据管理方式、安全管控等等因素,给不了什么有价值的建议……

Ouroboros 回复

本来不想杠你的,但是我看还有人点赞,觉得有必要举个例子给你们琢磨一下:
不说银行,银行太复杂,就说保险吧,至少会包含这些最基本的模块:

  • 新契约签单,承保并且生效之后,保单、责任条款之类的数据持久化落库
  • 保全变更,比如受益人变更、联系方式变更、退保等等,操作的还是这批数据
  • 理赔,这个不用我解释大家都懂,操作的还是这批数据
  • 渠道佣金计提,字面意思,操作的还是这批数据
  • 财务,字面意思,操作的还是这批数据

……以上所有数据没操作一次都要可追溯,供稽核和监管审计,而且很多很多操作都会影响后续的操作,比如健康险理赔一次之后,第二次理赔,费率不一样了;车险理赔之后次年的保费也会不一样;分红险分红过后保单价值也会随之发生变化……

如果你来设计,是准备把这些服务独立,操作数据向其他服务去冗余呢?还是说放到一个服务里面,一旦服务不可用,所有的业务都不要开展了呢?
依据你给出的设计,你再思考楼主的问题,可能就更容易得出解决方案了,至少我没有勇气去考虑改变系统纠缠的问题

树叶 回复

对,但创建周边环境足够方便,运维也足够方便(通过配套平台支持),基本上一套周边环境(大概三四十个系统)可以在十分钟内准备完毕。

还是要保证功能,从接口、功能等角度去测试

18楼 已删除
槽神 回复

也不叫杠哈,每个人看的角度不同,理解不同,有不同看法很正常。

金融行业的系统过于复杂,我没接触过,就不献丑了。

不过我还是坚持全启起来测。

综合楼上观点,分情况讨论可能是这个样子:

  1. 如果你能确保上游服务稳定,如上游服务变更少,逻辑简单等,可以偷懒省去 mock 的环节直接测,我们默认上游没问题,在测试的时候一并观察上游返回是否符合预期即可 —— 相对来说,省了 mock 成本,但是在校验时有额外的心智负担
  2. 如果你无法确保上游服务稳定,如上有服务变更频繁,逻辑复杂,可能有更复杂的依赖,这种为了测试效率考虑还是走 mock,如果直接测,一旦出问题要排查半天是哪里的问题,长期来看效率可能是负向 —— 相对来说,有 mock 成本,mock 了之后就可以尽量去转化为接口自动化测试

大多数情况下,大家可能都是按照 1 去操作,有些业务形态真的复杂,那就只能 2,这些工作省不了。

一般系统设计接口是稳定的,如果频繁变动接口(mock 轻易就 break),我觉得可以质疑研发的接口设计水平。所以不太需要考虑 mock 要经常维护的问题。如果你能预见这个接口它就是因为业务迭代肯定会频繁变动,好像也没更好办法,因为你的被测服务可能也要跟着变动,那时候你也要被叫过来测试。这种情况先和研发探讨一下再做决定

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