系统多，系统与系统之间的交互也多，比如有 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 有可能都是多应用共享的，这个更麻烦，对造数的能力要求比较高
具体怎么搞，其实还是要看你们的系统群的架构设计，包含系统间交互方式、数据管理方式、安全管控等等因素，给不了什么有价值的建议……
Ouroboros
回复
本来不想杠你的，但是我看还有人点赞，觉得有必要举个例子给你们琢磨一下：
不说银行，银行太复杂，就说保险吧，至少会包含这些最基本的模块：
- 新契约签单，承保并且生效之后，保单、责任条款之类的数据持久化落库
- 保全变更，比如受益人变更、联系方式变更、退保等等，操作的还是这批数据
- 理赔，这个不用我解释大家都懂，操作的还是这批数据
- 渠道佣金计提，字面意思，操作的还是这批数据
- 财务，字面意思，操作的还是这批数据
……以上所有数据没操作一次都要可追溯，供稽核和监管审计，而且很多很多操作都会影响后续的操作，比如健康险理赔一次之后，第二次理赔，费率不一样了；车险理赔之后次年的保费也会不一样；分红险分红过后保单价值也会随之发生变化……
如果你来设计，是准备把这些服务独立，操作数据向其他服务去冗余呢？还是说放到一个服务里面，一旦服务不可用，所有的业务都不要开展了呢？
依据你给出的设计，你再思考楼主的问题，可能就更容易得出解决方案了，至少我没有勇气去考虑改变系统纠缠的问题
还是要保证功能，从接口、功能等角度去测试
槽神
回复
也不叫杠哈，每个人看的角度不同，理解不同，有不同看法很正常。
金融行业的系统过于复杂，我没接触过，就不献丑了。
不过我还是坚持全启起来测。
综合楼上观点，分情况讨论可能是这个样子：
- 如果你能确保上游服务稳定，如上游服务变更少，逻辑简单等，可以偷懒省去 mock 的环节直接测，我们默认上游没问题，在测试的时候一并观察上游返回是否符合预期即可 —— 相对来说，省了 mock 成本，但是在校验时有额外的心智负担
- 如果你无法确保上游服务稳定，如上有服务变更频繁，逻辑复杂，可能有更复杂的依赖，这种为了测试效率考虑还是走 mock，如果直接测，一旦出问题要排查半天是哪里的问题，长期来看效率可能是负向 —— 相对来说，有 mock 成本，mock 了之后就可以尽量去转化为接口自动化测试
大多数情况下，大家可能都是按照 1 去操作，有些业务形态真的复杂，那就只能 2，这些工作省不了。
一般系统设计接口是稳定的，如果频繁变动接口（mock 轻易就 break），我觉得可以质疑研发的接口设计水平。所以不太需要考虑 mock 要经常维护的问题。如果你能预见这个接口它就是因为业务迭代肯定会频繁变动，好像也没更好办法，因为你的被测服务可能也要跟着变动，那时候你也要被叫过来测试。这种情况先和研发探讨一下再做决定