群友 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
以下内容就是串到自动化了。