近年来，随着大数据、云计算等新兴软件技术的高速发展，应用软件系统也变得愈来越复杂，这种软件系统的高复杂性引入了许多新的问题，而微服务架构正成为解决这处软件应用复杂性的新武器。
微服务架构是一种将单应用程序作为一套小型服务开发的方法，每种应用程序都在自己的进程中运行，采用一组服务的方式来构建一个应用，服务独立部署在不同的进程中，不同服务通过一些轻量级交互机制来通信的架构思路。
微服务架构下的测试是以不变应万变，还是要随机应变，是一个问题。本文将介绍微服务架构下的测试策略，并结合在业务中台项目的测试实践，分享测试策略的选择以及测试实践过程中的体会。
第一部分：构建测试模型
业务中台为近些年来客户大型项目，是CRM系统相关内外能力进行微服务化解耦重构，并完成与内外部系统的集成改造。项目的重要性和复杂性为近年来难得一见。
微服务化改造对测试带来了许多挑战：
1、CRM系统各种业务能力进行了微服务化的拆分重整，使服务数量大幅增加，测试对象体量增大，常规的测试手段无法解决大量的测试对象与固定的项目周期之间的矛盾。
2、服务/模块之间的关系变得更加复杂，微服务架构中，每个服务都是独立的业务单元，服务之间主要通过接口进行交互，如何保证这些依赖的正常及微服务化后不影响现有业务模式，是测试人员面临的主要挑战。
3、每个服务的开发进度可能不同，使传统的端到端测试进度不理想。CRM系统本就有业务关联复杂的特点，传统的多服务的端到端测试会因为某一个服务的微小改动而经常出错。系统的整个业务功能是否符合预期成为了测试难点。
基于以上挑战，考虑尽可能的完整测试覆盖，同时考虑项目周期等因素，根据分层测试的思想，对策略模型与工程实践规划的适配定制，结合金字塔模型和钻石模型，业务中台的微服务测试形成了新的模型：越往上，越接近业务/最终用户；越往上，测试成本越高，越耗时，失败时的信息越模糊，越难跟踪。
在项目实践过程中实现的自动化测试是分层实现的：
底层：单元测试，由开发人员在每个工程模块中编写测试代码实现；
中间：API测试（类似于金字塔模型里的组件测试）；
上层：部分契约测试和端到端测试来保证服务间的契约和集成；
除此之外，考虑中台为全新的环境，增加性能测试和生产测试，其中包括针对微服务特点进行的测试。这部分由测试人员通过自动化工具实现测试。
①单元测试：针对代码单元进行测试，通过执行代码文件里的类方法或函数来验证。
②服务独立测试：针对服务接口进行测试，测试重点为验证功能、数据检查、性能。
③服务一致性测试：验证测试微服务业务功能与解耦前的服务业务功能相一致性，微服务化后性能相当或优于解耦前的服务性。一般通过比对测试完成。
④系统集成测试：验证微服务与外部模块的交互是否正常。通过调用服务的外部接口来验证业务逻辑验证服务功能。
⑤端到端测试：覆盖整个系统，模拟实际业务场景，一般可分为UI层面端到端和接口层面的端到端测试。
⑥性能与生产系统测试：考虑测试环境与生产环境的不对等，根据交易热度的覆盖，选用了特定的业务，在生产环境也行了性能测试验证及部分的业务功能验证测试。
第二部分：实践三把斧
除了符合策略模型的自动化测试之外，我们还紧跟项目持续交付节奏，践行DevOps实践，同时关注生产环境的重点测试（API连通测试，重点业务的功能验证，性能测试等），把测试活动适度延伸到生产环境。
API&服务测试
API测试主要包括以下三大步骤：
1、准备测试数据；
2、通过自动化测试工具发起对被测API的请求；
3、验证返回结果。
微服务改造，产生了大量的新的API，通过定制化的自动测试工具LYAUTO实现快速的API测试验证。LYAUTO包含API功能测试及数据查验测试、比对测试，并能生成详细报告，满足每次迭代的API快速全覆盖测试。
API&服务测试要求：
1. 所有涉及的测试由自动化平台完成；
2. 测试覆盖率要求达到90%以上；
3. 至少进行一轮自动化回归测试。
测试过程如下：
对于服务的测试，更多关注比较测试，涉及上线的所有微服务，每个微服务进行全面的测试，对服务进行新旧比对验证，验证新旧返回关键信息，数据结果的一致性。
在业务中台的实践过程中，比对测试主要有三种应用形式：
1、同一环境，相同的预置数据和业务请求，同时向新服务和旧服务发送请求，比较服务返回结果的一致性，多于用于测试验证查询类服务，关注重点业务要素。
2、同一环境，相同的预置数据和业务请求，相同的预置数据和业务请求，先后请求新服务和旧服务，比较服务返回结果的一致性，并重点关注业务结果数据的一致性。主要用于测试受理类业务。
3、不同环境，相同的环境要素，相同的预置数据和业务请求，同时向新服务和旧服务请求，比较服务返回结果的一致性和数据结果的一致性。这种方式需要新增相同或相类似的环境，代价不小。
端到端测试
端到端测试，主要是涉及到微服务改造的业务场景及关联的TOP业务场景（以生产近3个月交易排行为准），采用现有的自动化平台已有的用例场景+日常新业务泛关联测试，持续运行，保证测试质量。
UI层面的端到端，由自动化平台完成常规用例和TOP业务测试。
接口层面的端到端，由自动化平台组织实施，根据业务场景的服务调用情形，把不同的服务用例组织为自动化场景。
端到端测试优先关注最终结果，且关注关键或核心环节/节点的测试结果。
总体的实施过程：
1、梳理TOP交易服务，梳理关联的业务场景；
2、分析场景，关注重点业务和热点业务，获取现有平台的自动化用例编排场景及任务；
性能&生产测试
做为模型的顶端，在业务中台项目实现中，性能测试和生产测试并非是一个高频或日常的测试内容，是按需执行测试。
性能测试，主要是为了验证新服务的稳定性，为项目提供数据参考，以交易TOP，热点业务，被测系统的性能焦点业务，作为业务选型依据。
目前性能测试主要包含核心业务的容量测试及核心链路稳定测试，采用分布式测试，尽可能接近生产实际情况。
性能测试指标参考依据为既有系统的交易峰值吞吐量，并以此为依据评价了微服务化后新系统对应的参考指标。
核心业务的容器测试选择了TOP10的业务，压测处理流程图如下所示：
核心链路稳定测试，选择了关键链路上的关键业务进行了常规的性能压测试，检查新系统的业务链路性能与既有系统的性能数据比较是否存在差异。
生产测试，做为测试活动右移的重要实践之一，也是基于“谨慎、安全”的前提下，为了验证生产服务的健康度，选择典型的服务&API，进行生产环境的自动化测试，进一步巩固测试质量。
生产测试主要结果关注：服务&API的应答是否符合预期，服务&API产生的数据结果是否正确。
生产测试需要考虑生产验证产生的数据影响（如产生脏数据，影响用户数据等）。在测试过程中，需要授权及使用专用的测试号码规避影响。主要的实践过程如下：
实践成果
业务中台一期CRM-3中心，目前共完成多轮次测试和生产测试，完成API测试800+，90%API&服务由自动化测试覆盖完成，日均执行测试用例260+。总体检错率25%左右，缺陷数（500+）/测试用例（2000+）。同时，根据项目需要，完成多轮性能和生产测试。
测试用例和测试报告及不同时期的测试结果，如图所示
第三部分：日常运营阶段自动化测试流程
在业务中台上线之后，我们持续将项目实施中定制的自动化用例归集到NL自动测试平台的专题场景，每日运行，形成常态自动化测试工作进程。
工作流程
需求自动化测试
1、自动化需求分析：筛选涉及新增、修复更新的服务&API部分需求，将接口部分纳入自动化测试流程，由自动化测试完成。
2、新增、更新自动化测试用例、场景、定时任务。
3、分时频繁自动测试，每间隔1-2小时滚动执行专项任务。
4、跟踪执行结果反馈，根据执行结果反馈问题或调优用例。
5、需要上线后，调整任务，转换为日常每日测试。
6、根据需要，调整准备生产测试脚本，执行生产测试。
自动化日常维护
1、日常维护更新任务分发至责任人。
2、新增或更新自动化测试用例、场景、定时任务。
3、跟踪任务执行反馈，根据需要反馈问题或调优用例。
工作成果
目前已在新大陆研发云平台每日运行的API情况如下，已完成部分每日运行的日均成功率稳定在95%。
第四部分：测试实践心得体会
微服务架构下多个服务的整合是最具有挑战的，对此最重要的是契约测试。业界契约测试说的最多的是基于消费者的契约测试，有效保证服务间的契约关系不被破坏，确保服务的连通性，有助于实现真正的独立部署和独立交付。
基于消费者契约的测试，在业务中台项目的工程实践中，由于各种原因无法直接做到以消费者提供的契约为入口，而采用了契约测试变形验证。
1、从平台导入共同契约。
2、 根据契约配置Mock机制，为消费者提供模拟的提供者以及期望的响应。
3、模拟消费者发送的请求向Mock机制请求， Mock机制根据契约返回响应。
4、 Mock机制集成测试，模拟消费者，根据契约生成请求，向真正的提供者发送请求。
5、 验证提供者提供的应答是否和之前导入的契约记录一致。
关于生产测试
微服务架构引入带来了不确定性，同时在业务中台接入灰度系统，使生产测试变成了可能。项目实践证明，尽管存在各种约束，生产环境下的测试是必须的，通过自动化验证手段，快速测试，提前发现问题，增强系统的健康度。
测试策略的影响因素
测试策略的影响因素不是唯一的，技术架构并不是最关键的因素。微服务架构下的测试策略跟其他架构下的没有本质的区别。
业务价值始终是我们的终极目标，在这个终极目标的驱动下，整个软件系统/项目构建过程中的测试策略要根据资源、进度、数据、工具等因素综合考虑，不断的取舍、改进，逐渐演进。
END
