微服务测试策略制定

微服务架构是近些年来比较流行的一种架构模式，它提倡将单一应用程序划分成一组小的服务，每个服务运行在其独立的进程中，服务间采用轻量级通信机制互相沟通。每个服务都围绕着具体的业务进行构建，并且能够被独立部署到生产环境、预生产环境。 微服务的它有如下好处：

• 每个服务可以独立开发
• 处理的单元粒度更细
• 单个服务支持独立部署和发布
• 更有利于业务的扩展

在微服务架构模式下，对于项目流程中的重要角色“测试”来讲，面临诸多新的挑战。以往单一应用的测试手段，不足以对微服务架构应用的质量进行全面保障，那么在微服务架构上，测试策略该如何制定呢？与以往单一应用的测试手段有哪些不同呢？

我们首先思考一下测试的目标是什么？

1. 业务价值，各个软件系统通过给用户提供更优质的服务，同时为公司赢得更多的利润，软件测试是为达成业务价值而提供保障的一个重要环节，测试的工作也是围绕着这个目标展开的。
2. 质量要求，对于各软件系统的功能完整性、正确性以及性能等方面的要求，各参与软件研发的不同角色会有不同的定义和衡量标准。对于内部系统，关注重心更多的是功能，而对于对外发布的系统，要求就会更高，甚至按钮的位置、文字的颜色都是测试的重点。
3. 解决痛点，在软件测试过程中，需要挖掘软件生命周期各环节的痛点，并且有步骤的进行解决和优化，比如上线回归测试耗时较长，则需要考虑是否提高自动化测试的比例、降低测试回归的范围等。

根据微服务架构的特点，我们梳理出了三个软件测试的方向：

1. 微服务框架自身的测试
2. 服务与服务之间的测试
3. 单一服务内部的测试

微服务框架的测试

1. 服务的容错性和可用性 在系统负荷达到一定程度或者某个服务出现故障的时候，微服务架构有两种技术来确保系统的可用性：服务的熔断和降级。 1). 服务的熔断是指当某个服务出现故障时，为了保证系统整体的可用性，会关闭掉出现故障的服务； 2). 服务的降级则是当系统整体负荷过载的时候，考虑关闭某些外围服务来保证系统的整体可用性。 针对服务的容错和可用性，需要采用的测试手段包括性能测试、稳定性测试。 1). 熔断：从服务的性能角度，当系统负载达到某个熔断状态的时候，服务是否能正确熔断；同时，从功能角度验证熔断后系统的行为是否跟预期相符； 2). 降级：从业务的稳定性角度，要能区分出核心业务和外围业务，在需要降级的时候不能影响核心业务；当某个服务降级后，从功能角度验证系统行为是否跟预期相符。
2. 数据的最终一致性

数据一致性是微服务特别需要关注的。举个例子，在电商平台某个订单支付成功以后，需要更新订单状态、优惠券信息、积分信息，当订单服务、优惠券服务、积分服务其中有一个出现故障的时候，就会导致最终的数据不一致性。 测试这种情况，从业务的角度分析哪些服务会导致数据不一致性，制造对应的异常情况去测试数据的最终一致性。

1. 独立部署 微服务的独立部署需要有CI、CD的支持，跟DevOps实践分不开。同时，更为关键的是需要契约测试来验证独立部署后服务行为的正确性。

服务与服务之间的测试

1. 务间的依赖和连贯性 在微服务框架下，各服务是独立开发的，如何保证服务与服务之间的依赖与连通性是关键所在。作为测试，在保证各独立服务自身的正确性以外，还需要对服务与服务之间的关联性进行验证，需要采用的测试手段包括探索性测试、Smoke测试、契约测试。
2. 探索性测试（Exploratory Test） 各个服务连接在一起之后，系统中的各个功能是否能够稳定正确的运行，用户所能操作的路径是否能够稳定地提供反馈，这些都需要进行详细的测试验证。基于探索性测试的4种类型：自由式测试、基于场景的测试、基于策略的测试、基于反馈的测试，测试能够充分的对系统进行验证。
3. 冒烟测试（Smoke Testing） 在系统软件的更新迭代过程中，每各需求可能都涉及系统中的某一个或者某几个服务，测试在针对需求进行详细测试后，还需要保证与该需求涉及到的其他关联服务的功能可用性，故通过建立冒烟测试，将系统各功能的主路径进行回归，用最少的用例，保证各服务之间的连通性与功能正确性。
4. 契约测试（Contract Testing） 契约测试是一种用于验证外部服务调用与其API Provider endpoint之间契约的黑盒子。一般有两种契约测试： a. 集成契约测试： 在集成契约测试中，每个组件都需要独立调用，并且必须满足消费服务（consumer）预期的契约协议。解决这个问题的最佳方法是对double进行测试。另一方面，定期运行一组单独的测试以确认测试double没有变化至关重要。不过，一旦出现测试失败，会降低部署管道的速度并破坏IT基础架构或分布式系统的功能。处理间歇性测试失败的最佳方法之一是更新测试double，同时可能也需要更新代码，以便可以使其恢复到与外部服务一致的状态。 b. 消费者驱动（consumer-driven）契约测试： 在消费者驱动的契约测试中，消费者将描述他们想要使用服务的方式。消费者契约可以在生产者和消费者之间以相互同意的语言和模式进行。服务提供商将针对各个契约的副本测试服务，然后对该特定服务进行更改，而不会影响其他服务的性质。

单服务自身的测试

系统被拆分成独立的服务，每个服务都是一个完整的小系统，此方面的测试与单一应用的测试手段基本一致，主要是保证服务自身的业务功能正确性。所采用的测试手段主要为：API接口测试、单元测试。

1. API接口测试 API包括对外提供的用于与其他服务之间相互通信的接口，以及对内提供用于各函数之间相互调用的接口，与单一应用不同，微服务架构依赖于进程间通信（IPC）机制来正常运行，这就是为什么必须验证服务之间的交互。测试一般会采用自动化的方式开展测试工作，以通过与外部服务和数据存储的集成来映射成功或错误的情况。
2. 单元测试（Unit Testing） 服务细分之后从某种意义上让单元测试更加易于编写，可以借助Mock来屏蔽掉对其他服务依赖。单元测试的范围可以是一组服务，也可以是单独的一个服务。被测试的单元粒度越小，就越容易确定模块的行为，越容易在源头发现产品质量上的问题。

在针对具体项目的测试策略制定时，需要根据具体实际情况灵活调整，在后续的文章中，我们会将实践中的更多成果与大家分享。