干货 | 质量保障新手段，携程回归测试平台实践

作者简介

 

Sedro，携程资深测试工程师，专注于测试技术探索及测试工具研发。

一、系统回归问题

回归测试是软件生命周期一个十分重要的环节，但项目在随着版本的逐步迭代，功能日益增多，系统愈加复杂，在测试过程中测试人员常常需要回归稳定版本的功能以保证不被待发布版本需求所影响。若要对系统进行全方位回归，这个测试的工作量将会非常庞大，而且可能几百上千用例中才会发现一个甚至是0个问题，测试投入产出不成比例。

而CPR则为上述问题提供了较好的解决方案。它通过基于稳定版本的输出，对待发布版本的输出进行比较，同时还将校验两个版本对下游请求的差异。根据比对结果评判待发布版本是否正确，可以大大降低回归的工作量。

二、CPR目标

• 大量真实流量确保覆盖率

• 将录制的流量作为用例管理起来进行自动化回归

• 流量回放支持子调用自动化mock，避免回放产生脏数据

• 流量回放支持子调用结果的验证

•  减少人力资源

三、目标实现基本过程

1）首先将部署了稳定代码的服务器作为流量采集源。测试人员在进行功能、接口测试时，实现测试执行过程中主调用以及子调用的入参和返回值的录制。通过功能和接口测试实现对应用功能的全量覆盖，使得应用中请求流量都会被录制到。

2）将录制到的请求流量复制到console平台，由测试人员分析有效的流量归纳为用例。后续即可采用这些有效用例来对待发布版本进行回放和差异比对。

3）回放完成告知到测试人员，由测试人员对回放的差异结果进行确认，快速发现被测系统bug并解决。

 

四、CPR原理及实现

4.1.  CPR录制的数据抓取点

       

如上图所示，CPR采集的数据主要为两方面：待测应用接收到的客户端请求及响应；待测应用接收请求后向外部服务的子调用请求及响应。CPR目前支持的请求类型如上图橙色框中所示；但CPR本身设计时对各类请求采用插件式设计，使其具有较好的扩展性，对于后续其他需要捕获的类型能很好的进行支持。当前CPR系统支持的报文协议为JSON和PB(ProtoBuf)。

4.2.  CPR结构简介

CPR分为两大组件：

1）CPR (CtripPaymentRepeater) 组件，该组件基于开源的jvm-sandbox开发，用于录制和回放流量。此组件核心为两部分：

• CPRRecord：目标是在稳定代码环境中录制请求调用的入参和返回值，并上送到存储服务。使得CPR Replay具备回放流量的数据。

• CPRReplay：功能为接收回放服务提供的回放流量，在待测代码环境中进行回放，并将回放结果上送至对比服务，让其实现正常系统和待测系统返回结果比对差异的能力。

2）CPRConsole组件，该组件主要录制/回放的配置管理；数据存储/数据对比等具备多种能力。主要包含三部分：

• 存储服务：对接收到的录制流量数据，将其持久化保存，待后续用户筛选有效流量。

• 回放服务：功能为将录制流量进行还原，然后对入口调用做一次流量的发起,使得CPR Replay。

• 对比服务：对接收到的回放数据与录制数据进行差异比对。

4.3 CPR处理流