微服务的灾难：测试越来越痛苦...

大家好，我是煎鱼。

小咸鱼经过前文所提到的折磨人的 “微服务拆分、微服务环境” 问题后，终于顺顺利利的上到了测试环境进行测试。

这时候开发、测试同学又闹新的头疼了，测了一轮下来。发现好好的。结果发现一上生产就有一些地方有问题，发现没测到。

这到底是为什么呢？

背景

在以往，小咸鱼他们团队都是传统的大单体应用。也就是一体化应用，包含了前端、后端等模块，具备天然的协调性：

• 测试同学能够很方便的就直接测到前后端接口。
• 测试能够直接对系统本身进行集成测试。

但现在，做了微服务化（雏形）后，小咸鱼他们就翻车了，为什么呢？

因为考虑到微服务，微服务就是向往单拎一个服务出来，都可以独立修改，独立发布。于是小咸鱼提交了一个迭代的几个服务变更，想着实现一把 “敏捷” 发布。

结果一上线就炸了，一大堆的 BUG，光荣加班到晚上 12 点。

这实质上是缺乏端到端测试的一个问题，单服务，无法明确系统正在正常运行。

端到端测试

在测试的质量保障上，我们要站在用户视角去验证这个系统，保障整体的系统可用性，而不是单纯的前端 BFF，又或是后端 Server 的某些接口能够正常运行。

在定义上端到端测试（End-to-end Test）是一种用于测试整个应用程序的流程是否符合预期的测试技术。测试同学会模拟用户真实的使用场景，通过用户界面测试应用程序。

如下图：

与小咸鱼团队那种单纯只测接口的方式不同，端到端测试是面向业务的。

其目的是验证应用程序系统整体上是否符合业务诉求，主要通过 GUI 测试，也会有人称其为集成测试、系统测试，黑盒测试。不少公司会将这几种混在一起。

实则在细节定义上各有不同：

本文不是测试方向文章，因此不深究。

问题症结

那么小咸鱼他们团队主要是缺乏端到端的这类集成测试的校验。直接在迭代中，把几个微服务一改，接口跑几下，以为就是合理通过的了。

真实情况：

• 一上到生产，发现压根不是这么回事。因为多个变更结合在一起，很有可能会导致系统原有的行为发生改变。
• 即使是你单个服务接口没违背，也不一定能保证其他在同个时段上的服务没问题。
• 在业内执行情况来看，业务迭代的非常快，接口自动化大多比较缺乏。又或是以请外包人员的方式来做，大多是面向存量补接口。

我们可以知道单纯验证接口，不走端到端类别的集成测试，是非常风骚的。设身处地的想想如下场景：

有没有见过一些开发，他在本地测好接口后，一和前端集成上到测试环境。测试人员，一点一个报错，正向流程压根跑不通。测试同学苦不堪言，开发同学一下身背数十 BUG，齐齐加班。

但开发同学大呼我在本地的接口测试的完全没问题。归根结底，小咸鱼团队的问题，还是因为缺乏端到端测试，缺乏齐全的接口自动化用例导致的。

解决思路

在每个迭代中，实际上每个团队都会专注于系统中所使用的所有服务中的某个服务。

系统中存在的大量微服务和子系统的功能和较窄的测试空间，有可能会导致没有发现系统或服务中存在的隐患。

这样测试，问题的出现，甚至是必然的。

在解决思路上常见于：

1. 新增预发布环境，做类似端到端测试的集成测试，确保系统集成后会是可用的。
2. 尝试更高覆盖率的接口自动化测试，大多数公司会针对新的，做增量或存量的自动化测试用例的补全。
3. 借助线上、线下数据在 CI/CD 时进行自动化测试，实现更全面真实的测试用例。

业内基本是数种思路齐头并进，最常见的是第一种方式。最有效，但开销也是最大的，并且会导致预发布环境的一定阻塞。

随后第二第三种大多都会紧接着跟进，具体程度会根据公司的软硬实力（例如：行政手段、基础设施等）不同而做的深度不同。

甚至前几天听小咸鱼说，面试时还听到不少公司延伸了外包岗位专门做一块的内容。

总结

虽说这个问题并不是 “微服务” 架构所独有的。但是显然微服务化后放大了测试的深坑问题。

很多公司的流程和措施都是为了保障一些东西，像小咸鱼团队这样，被网上布道师例举的优点遮蔽了双眼，后面又被迫把端到端测试加回来的不在少数。

你们的团队又是如何高效解决这个问题的呢，欢迎在评论区留言和交流！

你好，我是煎鱼。高一折腾过前端，参加过国赛拿了奖，大学搞过 PHP。现在整 Go，在公司负责微服务架构等相关工作推进和研发。

从大学开始靠自己赚生活费和学费，到出版 Go 畅销书《Go 语言编程之旅》，再到获得 GOP（Go 领域最有观点专家）荣誉，点击蓝字查看我的出书之路。

日常分享高质量文章，输出 Go 面试、工作经验、架构设计，加微信拉读者交流群，记得点赞！