微服务的灾难：端到端测试的痛苦
大家好，我是煎鱼。
小咸鱼经过前文所提到的折磨人的 “微服务拆分、微服务环境” 问题后，终于顺顺利利的上到了测试环境进行测试。
这时候开发、测试同学又闹新的头疼了，测了一轮下来。发现好好的。结果发现一上生产就有一些地方有问题，发现没测到。
这到底是为什么呢？
背景
在以往，小咸鱼他们团队都是传统的大单体应用。也就是一体化应用，包含了前端、后端等模块，具备天然的协调性：
- 测试同学能够很方便的就直接测到前后端接口。
- 测试能够直接对系统本身进行集成测试。
但现在，做了微服务化（雏形）后，小咸鱼他们就翻车了，为什么呢？
因为考虑到微服务，微服务就是向往单拎一个服务出来，都可以独立修改，独立发布。于是小咸鱼提交了一个迭代的几个服务变更，想着实现一把 “敏捷” 发布。
结果一上线就炸了，一大堆的 BUG，光荣加班到晚上 12 点。
这实质上是缺乏端到端测试的一个问题，单服务，无法明确系统正在正常运行。
端到端测试
在测试的质量保障上，我们要站在用户视角去验证这个系统，保障整体的系统可用性，而不是单纯的前端 BFF，又或是后端 Server 的某些接口能够正常运行。
在定义上端到端测试（End-to-end Test）是一种用于测试整个应用程序的流程是否符合预期的测试技术。测试同学会模拟用户真实的使用场景，通过用户界面测试应用程序。
如下图：
与小咸鱼团队那种单纯只测接口的方式不同，端到端测试是面向业务的。
其目的是验证应用程序系统整体上是否符合业务诉求，主要通过 GUI 测试，也会有人称其为集成测试、系统测试，黑盒测试。不少公司会将这几种混在一起。
实则在细节定义上各有不同：
本文不是测试方向文章，因此不深究。
问题症结
那么小咸鱼他们团队主要是缺乏端到端的这类集成测试的校验。直接在迭代中，把几个微服务一改，接口跑几下，以为就是合理通过的了。
真实情况：
- 一上到生产，发现压根不是这么回事。因为多个变更结合在一起，很有可能会导致系统原有的行为发生改变。
- 即使是你单个服务接口没违背，也不一定能保证其他在同个时段上的服务没问题。
- 在业内执行情况来看，业务迭代的非常快，接口自动化大多比较缺乏。又或是以请外包人员的方式来做，大多是面向存量补接口。
我们可以知道单纯验证接口，不走端到端类别的集成测试，是非常风骚的。设身处地的想想如下场景：
有没有见过一些开发，他在本地测好接口后，一和前端集成上到测试环境。测试人员，一点一个报错，正向流程压根跑不通。测试同学苦不堪言，开发同学一下身背数十 BUG，齐齐加班。
但开发同学大呼我在本地的接口测试的完全没问题。归根结底，小咸鱼团队的问题，还是因为缺乏端到端测试，缺乏齐全的接口自动化用例导致的。
解决思路
在每个迭代中，实际上每个团队都会专注于系统中所使用的所有服务中的某个服务。
系统中存在的大量微服务和子系统的功能和较窄的测试空间，有可能会导致没有发现系统或服务中存在的隐患。
这样测试，问题的出现，甚至是必然的。
在解决思路上常见于：
- 新增预发布环境，做类似端到端测试的集成测试，确保系统集成后会是可用的。
- 尝试更高覆盖率的接口自动化测试，大多数公司会针对新的，做增量或存量的自动化测试用例的补全。
- 借助线上、线下数据在 CI/CD 时进行自动化测试，实现更全面真实的测试用例。
业内基本是数种思路齐头并进，最常见的是第一种方式。最有效，但开销也是最大的，并且会导致预发布环境的一定阻塞。
随后第二第三种大多都会紧接着跟进，具体程度会根据公司的软硬实力（例如：行政手段、基础设施等）不同而做的深度不同。
甚至前几天听小咸鱼说，面试时还听到不少公司延伸了外包岗位专门做一块的内容。
总结
虽说这个问题并不是 “微服务” 架构所独有的。但是显然微服务化后放大了测试的深坑问题。
很多公司的流程和措施都是为了保障一些东西，像小咸鱼团队这样，被网上布道师例举的优点遮蔽了双眼，后面又被迫把端到端测试加回来的不在少数。
你们的团队又是如何高效解决这个问题的呢，欢迎在评论区留言和交流！
