微服务测试

微服务的定义

相比较传统服务，微服务是将一个单体应用拆分成多个模块，每一个服务都只负责一小块儿具体的业务能力，可以独立的部署到环境中去，服务的边界清晰。相互间通过轻量级的接口调用或者消息列队进行通信，为用户提供最终价值。

微服务的优缺点

优点：

• 日常研发阶段： 可以构建持续集成的环境，因为体量小，所以变异速度快
• 发布方面：如果某一个微服务有问题，那么不会影响到整个应用，增加了系统的可靠性
• 例如扩容只需要针对某个服务扩容，可以节约资源
• 微服务可以使用不同的语言，架构，环境来构建微服务模块

缺点：

• 软件架构的复杂度变高：划分的粒度问题，有的太细，就是滥用
• 测试的难度加大: 验证成本高（搭建测试环境的成本，因为它需要的依赖关系多，团队需要等待测试环境进行完整的搭建和配置，才可以开始联调，测试和实验)，反馈周期长（有的问题排查需要用到链路调用分析，逐步排查，那么成本就提高了），测试的环境如何维护，测试结果（由于会出现网络延迟，超时，带宽等因素，就会造成不稳定的测试结果，例如可靠性（隔离机制），数据一致性（存储不一致），关联性（依赖））
• 团队间的协作能力加大：更改接口时，需要把用到这个微服务的都要进行更改；一个微服务的更新，不能破坏掉对它进行调用的一方；因为微服务众多，所以需要运维投入更多的人力物力，

微服务的测试策略

1. 选取合适的测试策略模型，确保测试活动的全面性，有效性，根据项目的不同，测试策略应该调整为符合当前项目的

[1]  测试分层，根据每一层测试的粒度不同

（1） Toby Clemson提出的微服务下的测试策略：（由底向上的，比重逐渐降低）
探索测试(Exploratory)
端到端测试(End-to-End)
组件测试(Component)
集成测试(Integration)
单元测试(Unit)
（2）测试蜂巢
端到端测试
集成测试(占比高)
单元测试
（3）钻石型（由上到下，比重逐渐降低，安全&性能测试和契约测试比例几乎一样）
安全&性能测试
契约测试
进程外组件测试
进程内组件测试
单元测试

[2] 全面性：
微服务下，需要关注服务的内部的完整性，也要关注服务间的交互，才能提高覆盖率和全面性
单元测试：方法，类级别的错误
集成测试：当前模块和外部模块的通信方式或者交互是否有问题，测试出接口问题
组件测试：将测试樊伟限定在被测范围的一部分
契约测试：验证当前服务与外部服务之间的交互，已表明它符合消费者的契约
端到端测试：从用户角度来来验证是否符合用户所需要的预期

[3]有效性
需要考虑资源的 投入产出比，基于现实情况来选取

 2. 建立质量保障体系，使之成为一种规范

质量保障体系：通过一定的流程规范，测试技术，方法，CI/CD 等活动的结合，形成系统化，标准化和规范化的保障。

组件测试

方法1： 使用测试替身隔离掉单个微服务依赖的其他微服务和数据存储，避免受其他微服务的影响而阻塞

• 好处：1.使环境可控； 2. 执行速度快；3.利于定位问题

-进程内组件测试：将测试替身注入到所测试服务所在进程中，不需要网络，降低了不确定因素和测试的复杂度，需要侵入到源码

• 进程外测试：将测试替身置身于被测服务的进程之外，需要通过世纪网络调用模拟的外部服务进行交互。例如：事先准备好的静态数据，调用动态的API。
  工具：wiremock

	优点	缺点
进程内	测试设计简单；运行速度快	未测试到服务的部署情况，仿真性弱
进程外	更具有集成性和仿真性，测试覆盖度高	测试设计复杂度高，跨网络，运行环境不确定

选择：实际项目中，首选组件内，除非是复杂的集成，持久性活启动逻辑，需要进程外。