微服务的流程自动化测试设计 | 叶婉婷

大家好，我是来自普元的叶婉婷。今天由我来和中生代技术的朋友分享一下流程微服务的自动化测试。 首先，我给大家分享一下普元多年实践的自动化测试过程与方法； 阐述一下我们的测试理念：测试一切、测试驱动开发、测试自动化； 1）测试一切文档、配置、环境、发布包，一切皆代码，这个很好理解，我不再赘述； 2）测试驱动开发测试提前，敏捷协作，测试用例同步开发； 3）测试自动化多种测试技术能力、组件化开发、统一管理，不间断测试执行；为了实现测试驱动开发、测试自动化，我们认为需要以下四个要素： 1）敏捷协作的过程； 2）测试设计方法； 3）全栈测试团队； 4）自动化测试服务；
普元多年来在产品研发过程中，一直践行敏捷协作的RDT过程，在新一代云平台项目中，我们分为若干RDT小团队，每个团队负责一个或多个领域系统，以实现不同的用户场景；在每个RDT小团队中，采用需求、开发、测试协同并行工作模式；随着产品需要在公有云上部署运维，我们做了一些改进，运维组参与分析用户场景、需求设计测试评审、反馈运维遇到的问题，而且，运维组自身也作为RDT团队直接负责统一监控中心的需求定义和设计开发； 那么为什么在敏捷协作的过程中，就能将测试尽量提前呢？从上面过程中我们可以看到，在计划阶段，每个RDT团队对用户场景都有了统一认识，那么在接下来的每个迭代开发中，定义需求规格、设计概念模型/原型界面/API定义/数据模型的同时，测试可以并行进行测试对象分析、测试点分析、测试数据和测试组件设计，并且强调RDT的相互评审；基于这些成果，开发进行编码的同时，测试就可以并行进行测试用例的开发，并且测试用例开始不间断的执行，自动化测试相比传统开发过程大大提前，通过测试尽量提前达到测试驱动开发的目标； 自动化测试毕竟不同于手工用例，我们从四个方面定义了自动化测试的设计原则与方法： 1）易管理性统一规划、统一版本控制的规范要求； 2）易实现性采用分层设计，测试基础服务层、测试能力支撑层、测试组件层、测试用例 层，支持多种技术的测试能力，测试组件复用，用例专注业务逻辑； 3）易维护性组件与用例分离、区分变化与不变、测试用例原则上不互相依赖、测试数据 容易维护； 4）易定位性测试用例独立、低复杂度、要求断言信息的准确性； 自动化测试分层设计对测试团队提出了更高的要求，也就是要求我们必须成为全栈测试团队，具备各层的能力：测试架构师负责总体设计、测试基础服务层，提供统一管理、统一调度的能力；领域技术专家负责测试能力支撑层，对各领域测试技术进行分析和选型，提供测试服务能力以及基础的技术组件；测试专家负责指导测试开发工程师进行测试方案设计、测试组件和用例的实现； 除了过程、方法、团队，自动化测试的落地最终还是需要依赖各种自动化测试服务的实现，我们也一直在做这方面的努力，并形成了产品化的自动化测试服务能力；除测试基础服务以外，我们没有选择从零开始，而是评估并引入好的开源技术和公司内部其他产品的可用技术，按照我们的自动化测试设计原则和方法进行相应的改造；比如WebUI测试服务，我们选用了Selenium，为了适应我们的用例开发规范和易用性，我们对其接口进行了重新封装，形成我们的WebUI基础组件库；比如CI工具Jenkins1.x，由于我们产品多、每个产品版本也多，使用时间久了之后其任务管理界面简直就是灾难，任务的调用关系也非常不直观、难以维护，所以我们扩展实现了持续集成项目管理、图形化的持续集成任务流管理，以适应我们的需要；另外，像用例开发/调试，除了支持Java以外，我们还复用了普元的逻辑流图形化开发能力、组件库可视化管理能力，用例开发效率更高、更易维护； 在企业级应用中，流程服务的测试一直面临诸多的问题，诸如：— 系统内部任何一个微小的变化，要上线测试；— 外部关联系统变化，引起的业务验证测试；— 如果流程作为一个公共的服务，一旦服务升级，所有业务系统都会有影响，所有业务系统全部都要验证。这些都会给测试造成巨大的工作量，不仅消耗过多的时间，还无法很好的保证质量。当这些问题投射到云环境与分布式架构中，所面临的复杂度与解决难度的升级不言而喻。 如图所示，在基于微服务架构的数字化企业云平台中，流程是一类重要的微服务。我们正在尝试将流程微服务的测试自动化，并由DevOps平台高效的验证微服务的改变是否影响原先的业务，从而提供高质量的上线保障，让测试人员告别那些让人生无可恋的重复性操作。 基于微服务的自动化测试的本质是通过数据的录制记录既有的测试过程，并通过案例固化过程中的全部测试数据，最终通过对案例的调用回放完成流程微服务测试的自动化。 流程微服务的自动化测试并非完全脱离手工测试，这里的自动化是建立初次手工测试的基础上的。第一次手工测试会在数据库中记录下所有的测试信息，我们将收集这些信息录制形成测试数据文件，根据每条流程实例录制一个测试数据文件。每个文件中包含：该流程实例运行过程中的所有相应请求/相应报文，该流程实例运行过程中的上下文变化，该流程实例的流转路径（活动+连线），该流程实例包含的子流程实例。 在流程微服务的自动化测试里，我们会根据实际的接口调用来设计多个组件，这些组件放置于一个测试组件微服务中提供给测试人员使用，每个简单的组件都对应一个接口的请求报文。这就犹如搭积木，每个积木是一个简单的接口报文，多个积木搭在一起形成一个房子，即多个接口报文固定调用形成一个复杂组件。多个房子、花坛、汽车形成一个小镇，即多个简单组件和复杂组件结合在一起生成的最终一个“流程实例的自动化测试”案例。有了之前收集的数据文件，就是根据每个数据文件，选择积木的问题了，再根据数据文件给每个组件添加必要的参数，这样就形成了测试案例。在案例生成的过程中测试人员不需要编写任何代码！ 我们将统一测试平台门户设计为一类领域系统，可以上传我们的测试案例部署，选择案例点击执行即可。每个案例的运行其实就是相应手工测试的一次回放。案例执行完成会形成详细的测试报告，包含了成功、错误、异常的详细信息，案例统计图，以及案例执行时间。清晰明了地达成便捷测试。
流程微服务有时也会和其他微服务之间通信，往往测试环境中无法与其他微服务直接交互，这时候我们为了模拟流程微服务引擎与其他微服务交互过程，提供了一个服务挡板功能，服务挡板也是设计中的数字化企业云平台的一类领域系统，由api mock提供挡板能力，即用服务挡板替代生产上的微服务。（未来我们会详细介绍api mock相对于传统mock的优势） 当自动化测试进行到其他微服务交互时，流程微服务引擎向挡板发起请求，挡板响应请求，并动态拼写回调报文，当所有的回调报文完成之后，挡板通知测试引擎，测试引擎向流程引擎发送回调报文。
对于测试案例，不仅需要模拟流程流转的服务接口过程，还需要验证流转过程中的参数正确性，所以需要验证组件来完成参数的确认。

• - 对比服务接口返回报文信息是否一致；
• - 一个活动完成后循环等待后继活动是否激活；
• - 一个活动完成后对比当前后继活动与历史测试数据中后继活动是否一致；
• - 一个活动激活后对比当前活动产生的连线是否与历史测试数据中连线信息一致；
• - 每当一个可能引起上下文改变的服务接口完成后，对比当前流程实例与历史测试数据中的上下文是否一致。