测试人员在工作中经常会听开发或者架构提到系统架构的微服务改造，是的，越来越多的企业级系统都在做这个改变，感觉都快变成一个流行的事情一样，自己不做的企业自己人都感觉系统会比较low。所以，对测试人员来讲，如何跟进，如何完整的测试微服务又是一件要去学习的事情了。今天就一起探讨下如何在微服务架构下开展测试。
当我们提到微服务的时候，我们想到些什么
微服务架构根据业务特点可将系统划分为粒度更小的服务，每一个颗粒的服务实现单一的功能业务，和其他颗粒的服务互不干扰，所以每个颗粒的服务可以由不同的团队来独立做，也加快了迭代的整体进度和减小问题的依赖。看过有文章这么形容，微服务就是像是一个星系的行星，各个行星在自己的该有的轨道中运行，又通过星球间的引力和其他行星以及恒星之间达到一种平衡并且紧紧联系。
微服务下的测试分层：
传统的面向服务SOA架构下测试一般分为界面层测试，接口层测试，单元测试层三层的测试结构，我们可以分别对这几个层级进行测试。
但是微服务给我们带来了更多服务间依赖的测试，各个服务由不同团队开发，保证每个服务本身的质量就尤为重要。所以，微服务测试重点主要是解决服务间的复杂依赖关系下的测试控制，但依然可以根据颗粒度完成以下测试步骤：
单元测试：单元测试的工具非常多，每个语言下都有不同的工具。比如unittest，pytest，testng，junit，Qunit都是常见的单元测试工具。单元测试往往是由开发人员来执行和维护的，但是测试人员需要尽可能的提供测试的数据和部署协助提高单元测试的覆盖率。单元测试做的好坏也是软件质量把控的关口。单元测试里面虽然要统计代码覆盖率，但是也有"黑盒"的概念，黑盒往往就指函数或者方法的内部，在微服务中，这些方法的输出往往依赖很多其他的服务，这个时候的mock就是很重要的了。在微服务中，如果剥离其他的依赖来测试，mock就尤为重要了。这里强调一点，单元测试其实最容易使用自动化来完成，构建-》执行-》断言-》清洗贯穿于整个过程。
集成测试：指的是把子模块集中再一次测试，检查各个模块间的通信以及数据交互是否存在问题，微服务中的集成测试一般重点关注服务中对外的模块与外部服务的通信和数据交互。
组件测试：组件也是服务本身，单独验证服务本身业务逻辑和异常逻辑。这里也是微服务测试的关键，往往方法就是依赖模拟。我们可以使用工具比如moco，Mountebank实现虚拟的api供服务来调用。这种方式好处是可以模拟复杂的微服务应用，但是实现起来复杂依赖关系比较麻烦一些。
契约测试：一种定义在Consumer与Provider之间的交互方式。微服务架构下，这种测试不需要深入测试服务的功能，需要检查请求的报文，响应，协议等是否通畅，并且可以使用模拟的服务测试来判断在依赖不可用的时候通讯的容错性。
端到端测试：从整个产品线上层ui来进行验证，判断系统并且包括多个服务运作的整体情况。
以上测试方法颗粒度由小到大，并且微服务的测试大大增加了测试人员的工作量，所以控制软件的质量更多的就依靠自动化来完成，上面的测试方式可以进一步实现流水线测试，我们可以借助Jenkins来建立持续集成/交付的自动化测试流程，并且分层测试，在每一个节点的完成之后对下一层进行测试。但是在测试的过程中，往往会遇到以下几个方面的问题：
1.怎么样能模拟真实场景的数据来建立高质量的mock提高测试用例的覆盖度？
往往测试用例的覆盖度是非常重要的，由于微服务的特殊性以及测试中mock的依赖往往更加高，测试中模拟数据很多时候都是基于测试人员的经验来的，所以很可能会遗漏，怎么样能够多场景的覆盖并且生成模拟数据尤为重要了
这里我给大家的解决方案是通过线上数据流量回放来达到，流量回放乍一看好像很高大上，其实是用生产环境的数据，log来作为数据依据，再通过整理清洗后作为测试的数据注入到测试系统中，所以这样的数据更加丰富，场景更多，也是现在很多大厂再进行回归测试以及压力测试的方法，也节约更多自己生成用例的时间，并且覆盖度更高。
2.微服务测试环境的不稳定
微服务因为服务拆分后并且有多个团队维护和开发，所以会造成 测试环境不稳定，用例失败高，所以选用合适的mock工具并且使 用数据注入，摆脱对底层服务的依赖。
3）输入流的判断
被测服务内部往往会调用其他服务，也会有复杂的业务逻辑判断， 所以对调用服务的输出流判断也是很重要的，我们测试的股哟成中 对输入输出的判断同等重要。
对于测试人员来讲，未来微服务测试会越来越近，我们不仅仅要知道微服务本身实现逻辑，也要不断的研究在新的架构下的测试方法，跟开发和架构配合，不断完善对系统的认知，才能更高质量的去完成测试。
公主耗：shenjitest回复666，领取最新一线大厂面试资料，面试题。以及整理最前沿的测试技术人员发展路线图和技能路线。
关注公主耗获取更多干货
