主题

群友 1 从口袋里掏出了主题抛了出来：群里做微架构（或者前后台分开测试）的欢迎来讨论下。
早上发生在第四届移动测试大会群提出了 1 个还是比较前沿得内容。
1.分层测试还是端到端测试为主吗？
a.如果端到端的测试，如何解决前端对于后台测试数据依赖的需求，以及测试效率的问题。
b.如果是分层测试，这个层怎么分，谁来保障端到端的质量。

2.如何管理各服务的接口定义，解决二义性问题和接口版本更新问题呢?
有没有做这块的探索，欢迎有类似问题的同学讨论下。

现场讨论

这里我做下搬运工，群友的名字下面有群友 1，群友 2…来替代，在下于这块理解回头会写在回复区域，保证不漏啊。

群友 2：早起的鸟儿有虫子吃
群友 3：一张图片
群友 4：这个问题社区发帖会有人参与讨论的。
群友 5：拇指这个问题好，搬小板凳等大牛解惑
群友 6：微服务建议分层测试，微服务可以理解为小应用，每个小应用都提供对外接口访问，这个接口是需要测试的，至于接口的构建与传统接口没区别
群友 6 继续发言：微服务需要测试前置，测试需要提前介入。
群友 7：第一个问题，我觉得是分阶段的，就如单元测试和集成测试一样，每一次微服务本身业务逻辑的验证完成后，还要保证集成之后，上下游接口依赖调用时候，数据格式啊异常情况等等是否正常。
群友 6：接口测试好后，至于前端调用也是需要的。既使有问题也容易修复了。
群友 6：关于接口效率问题，可以了解一下契约测试。
群友 6：既接口变化后，会有机制通知接口相关人员，保证大家信息同步。
群友 7：数据问题在初期都是 mock，后期真实数据吧
群友 6：不绝对哦
群友 7@ 群友 6：你们的同步怎么做的啊，我们经常会出现消息不同步的情况。
群友 6：这点我们就是用邮件。
群友 6：业界有相关工具
群友 8：通知不都是邮件或者 rtx 吗？
群友 7：有点意思。
群友 9：API 平台，涉及接口改动都通知到项目组成员，可以通过短信，邮件和微信
群友 6：微服务建议大家写写代码就明白了，可以试试 springboot 上手快
群友 9：接入企业公众号可以直接发微信
群友 8：再不行就写个运维 app
群友 7：我也有个问题，在项目周期非常短的时候，时候可以用端到端直接覆盖
群友 6：没时间，只能这样了。
群友 7：微服务应该有 1 个自检能力，每次启动的时候跑一次。
群友 10：接入自动化测试？
群友 7：我感觉还得看架构师的架构能力。首先拆系统能把业务边界裁干净就很不容易了。然后每个业务都做为一个微服务，有自己的完整生命周期和状态机，否则还是互相依赖的，挺尴尬的。
群友 11：这个问题贴到社区应该很多人感兴趣。
群友 12：接口扫描
群友 13：前后端分离，通过 swagge 管理接口。并进行契约测试保证前后接口一致避免二义性。先分层后，端到端测试。
群友 13 继续发言：分层保证每个微服务的正确性，端到端保证每个微服务整体业务的正确性。
群友 14：测试还是来点落地实在好，那些应该是开发架构师考虑了吧
群友 8：大拇指 *2
群友 11：目前我们只是弄了契约测试，开发同学一提交代码 commit 就触发跑下测试失败就邮件通知加 slack 通知该修改的服务端同学，我来观望看看大家有啥好的建议 2 个萌表情
群友 15：如果微服务架构，多个服务同时构建，相互有依赖关系。其中一个构建完成就开始测试就会大面试失败吧。
群友 6：测试哪些服务是需要沟通的
群友 6：服务的依赖要想清楚，以及有好的测试策略，测试一定要前期介入的
群友 6：微服务时代，我个人觉得测试和开发捏得更紧密了。
群友 6：双方得共同目录是高效得完成开发任务。
群友 6：并保证质量。
群友 16@ 群友 11：推荐用 gated checkin 在 merge request 卡点跑 build 和 test。跑失败了就 reject merge request.这样确保所有进主分支的 commit 都是可以通过 build 和 test 的。
群友 11@ 群友 16 表达感谢：多谢多谢这么好的建议。对于端到端全自动化大家有啥好的方案和建议呢？thank you
以下内容就是串到自动化了。