微服务下分层测试及端到端测试的讨论，基于群讨论整理：
原始问题：
早上好，群里做微服务架构（或者前后台分开测试）下的测试大侠，有 2 点困惑能否来指点指点 [抱拳]
1.分层测试还是端到端测试为主呢？
a.如果端到端测试，如何解决前端对后台测试数据的依赖需求，及测试效率问题。
b.如果是分层测试，这个层怎么分，谁来保障端到端的质量。
2.如何管理各服务的接口定义，解决二义性问题和接口版本更新问题呢？
以下是大家的回复整理，供有类似问题的同学参考，欢迎补充。
收集大家整体的建议主要有以下两点：
1、微服务模式下，测试前置，建议分层测试，可以使用契约测试模式来进行
2、先分层，再端到端测试。
下面是原聊天记录，里面有一些具体的实施建议。
李老师 08:04
微服务建议分层测试，微服务可以理解为小应用，每个小应用都提供对外接口访问，这个接口是需要测试的，至于接口的构建与传统接口测试没区别
李老师 08:05
微服务需要测试前置，测试需要提前介入了
恒老师 08:05
第一个问题，我觉得是分阶段的，就如单元测试和集成测试一样。每一个微服务本身业务逻辑的验证完成后，还要保证集成之后，上下游接口依赖调用时候，数据格式啊，异常啊等等是否正常。
李老师 08:05
接口测试好后，至于前端调用也是需要的，即使有问题也容易修复了
李老师 08:06
关于接口效率问题，可以了解一下契约测试
李老师 08:07
即接口变化后，会有机制通知接口相关人员，保证大家信息同步
恒老师 08:07
数据问题在初期都是 mock，后期真实数据吧
李老师 08:08
不绝对哦
恒老师 08:08
@ 李老师?你们同步怎么做的？我们经常会出现信息不同步的情况
李老师 08:09
这点我们比较
low，就是邮件
李老师 08:09
业界有
相关工具
叶老师 08:10
通知不都是邮箱或者 rtx 吗？
恒老师 08:10
有点意思。
斟老师 08:10
API 平台，涉及接口改动都通知到项目组成员，可以通过短信、邮件和微信
李老师 08:11
微服务，建议大家自己写写代码就明白了，可以试试 soringboot，上手快
斟老师 08:11
接入企业公众号可以直接发微信
李老师 08:11
springboot
叶老师 08:11
再不行就写个运维 app
恒老师 08:12
我也有个问题，在项目周期非常短的时候，是否可以用端到端直接复盖
李老师 08:13
没时间，只能这样了
恒老师 08:16
微服务应该有个自检能力，每次启动的时候，跑一下。
Ken 老师 08:16
接入自动化测试？
恒老师 08:19
我感觉还是得看架构师的架构能力。首先拆系统能把业务边界窄干净，就很不容易了。然后每个业务都做为一个微服务，有自己的完整生命周期和状态机，否则还是互相依赖的话，挺尴尬的。
Ti 老师 08:43
前后端分离，通过 swagge 管理接口，并进行契约测试保证前后接口的一致，避免二义性。先分层后端到端测试
Ti 老师 08:44
分层保证每个微服务的正确性，端到端保证各个微服务整体业务的正确性
李老师 08:45
测试还是来点能落地实在的好，那些应该是开发架构师考虑了吧
Li 老师 08:51
目前我们只是弄了契约测试，开发同学一提交代码 commit 就触发跑下测试失败就邮件通知加 slack 通知 该修改的服务同学。我来观望看看大家有啥好的建议 [耶][耶]
夏老师 08:53
如果微服务架构，多个服务同时构建，相互有依赖关系。其中一个构建完成就开始测试就会大面积失败吧
李老师 08:54
测试哪些服务是需要沟通的
李老师 08:55
服务的依赖性要想搞清楚，以及有好的测试策略，测试一定是要前期介入的
李老师 08:56
微服务时代，我个人觉得测试和开发捏的更紧密了
李老师 08:56
双方的共同目标是高效的完成开发任务
李老师 08:57
并保证质量
郑老师 08:59
@Li老师?推荐用 gated checkin，在 merge request 卡点跑 build 和 test，跑败了就 reject merge request。这样确保所有进主分支的 commit 都是可以通过 build 和 test 的。
Li 老师 09:02
@ 郑老师 (蚂蚁金服资深测试总监)?多谢多谢这么好的建议。对于端到端全自动化大家有啥好的方案和建议呢？thank you
李老师 09:03
全自动化啊，大厂都有自己的平台
李老师 09:03
我们自己玩可以，各种工具通过 jenkins 串起来
李老师 09:04
大厂就是把这个流程封装了
李老师 09:05
构建完成跑白盒，白盒通过跑接口，接口通过 run ui
李老师 09:05
jenkins 控制各个节点串联，各个节点使用不同的工具
李老师 09:06
当然细节有很多，但是思路就是这个了