微服务架构是近些年来比较流行的一种架构模式，它提倡将单一应用程序划分成一组小的服务，每个服务运行在其独立的进程中，服务间采用轻量级通信机制互相沟通。每个服务都围绕着具体的业务进行构建，并且能够被独立部署到生产环境、预生产环境。
微服务的它有如下好处：
- 每个服务可以独立开发
- 处理的单元粒度更细
- 单个服务支持独立部署和发布
- 更有利于业务的扩展
在微服务架构模式下，对于项目流程中的重要角色“测试”来讲，面临诸多新的挑战。以往单一应用的测试手段，不足以对微服务架构应用的质量进行全面保障，那么在微服务架构上，测试策略该如何制定呢？与以往单一应用的测试手段有哪些不同呢？
我们首先思考一下测试的目标是什么？
业务价值，各个软件系统通过给用户提供更优质的服务，同时为公司赢得更多的利润，软件测试是为达成业务价值而提供保障的一个重要环节，测试的工作也是围绕着这个目标展开的。
质量要求，对于各软件系统的功能完整性、正确性以及性能等方面的要求，各参与软件研发的不同角色会有不同的定义和衡量标准。对于内部系统，关注重心更多的是功能，而对于对外发布的系统，要求就会更高，甚至按钮的位置、文字的颜色都是测试的重点。
解决痛点，在软件测试过程中，需要挖掘软件生命周期各环节的痛点，并且有步骤的进行解决和优化，比如上线回归测试耗时较长，则需要考虑是否提高自动化测试的比例、降低测试回归的范围等。
根据微服务架构的特点，我们梳理出了三个软件测试的方向：
- 微服务框架自身的测试
- 服务与服务之间的测试
- 单一服务内部的测试
微服务框架的测试
1、服务的容错性和可用性
在系统负荷达到一定程度或者某个服务出现故障的时候，微服务架构有两种技术来确保系统的可用性：服务的熔断和降级。
1)服务的熔断是指当某个服务出现故障时，为了保证系统整体的可用性，会关闭掉出现故障的服务；
2)服务的降级则是当系统整体负荷过载的时候，考虑关闭某些外围服务来保证系统的整体可用性。
针对服务的容错和可用性，需要采用的测试手段包括性能测试、稳定性测试。
1) 熔断：从服务的性能角度，当系统负载达到某个熔断状态的时候，服务是否能正确熔断；同时，从功能角度验证熔断后系统的行为是否跟预期相符；
2)降级：从业务的稳定性角度，要能区分出核心业务和外围业务，在需要降级的时候不能影响核心业务；当某个服务降级后，从功能角度验证系统行为是否跟预期相符。
2、数据的最终一致性
数据一致性是微服务特别需要关注的。举个例子，在电商平台某个订单支付成功以后，需要更新订单状态、优惠券信息、积分信息，当订单服务、优惠券服务、积分服务其中有一个出现故障的时候，就会导致最终的数据不一致性。
测试这种情况，从业务的角度分析哪些服务会导致数据不一致性，制造对应的异常情况去测试数据的最终一致性。
3、独立部署
微服务的独立部署需要有CI、CD的支持，跟DevOps实践分不开。同时，更为关键的是需要契约测试来验证独立部署后服务行为的正确性。
服务与服务之间的测试
服务间的依赖和连贯性
在微服务框架下，各服务是独立开发的，如何保证服务与服务之间的依赖与连通性是关键所在。作为测试，在保证各独立服务自身的正确性以外，还需要对服务与服务之间的关联性进行验证，需要采用的测试手段包括探索性测试、Smoke测试、契约测试。
探索性测试（Exploratory Test）
各个服务连接在一起之后，系统中的各个功能是否能够稳定正确的运行，用户所能操作的路径是否能够稳定地提供反馈，这些都需要进行详细的测试验证。基于探索性测试的4种类型：自由式测试、基于场景的测试、基于策略的测试、基于反馈的测试，测试能够充分的对系统进行验证。
冒烟测试（Smoke Testing）
在系统软件的更新迭代过程中，每各需求可能都涉及系统中的某一个或者某几个服务，测试在针对需求进行详细测试后，还需要保证与该需求涉及到的其他关联服务的功能可用性，故通过建立冒烟测试，将系统各功能的主路径进行回归，用最少的用例，保证各服务之间的连通性与功能正确性。
契约测试（Contract Testing）
契约测试是一种用于验证外部服务调用与其API Provider endpoint之间契约的黑盒子。一般有两种契约测试：