干货 | 携程DARE回归测试实施二三鉴

作者简介

李艳秋，携程金融支付测试团队工具组负责人，专注于测试技术探索及测试工具研发。

正如我们所知，在整个项目的测试工作中，回归测试所占用的时间和资源消耗是整个测试周期的70%-80%。在开发不断做BUG修复时，在系统不断维护过程中，都是回归测试必须出场的节点。

携程与众多“历史悠久”的IT企业一样，计算机系统历史悠久，同样“深不可测”。需求版本的叠加，人员的流动，难免在“传承”的过程中有所遗漏。

再加上近年来携程改造项目的逐渐增多，如：去SP改造类项目、Dot Net转Java项目，对改善回归测试的技术或工具的研究探索是非常有必要的。

DARE平台的使用，我们将一个手工回归需要20人日的项目降低至5人日。5人日的工作中包含了对被测模块新旧版本的调研、配置、数据拉取和整理、环境搭建配置、测试执行、对比结果并完成报告。因为前面配置的可复用，后面的bug修复及多轮回归测试只需轻轻点一下按钮，即可等待最终的执行结果。发现的bug远比手工测试多。

在一个历史久远的通道上我们发现了一个特别出众的bug。原因是该通道的存在对于手工测试和开发同学几乎是印象模糊的。另外还有各种特殊交易类型的未支持。让线上无数条银行通道，每个通道平均10种的交易类型的繁琐验证变得不再烧脑费时。

什么是DARE平台

DARE策略是指利用生产上实际发生的用户请求，来完成新版本回归测试的软件测试方案。

为了DARE策略的落地使用，我们开发了DARE平台，用来自动拉取和整理数据，测试执行及结果验证过程。

DARE适应的场景即那些系统出参、入参及DB结构改变不多，且内部逻辑有变化的系统变更。完全适合技改项目，及日常系统迭代过程中的回归测试。

DARE平台的工作原理如下图：

在整个测试执行过程中，DARE平台帮我们获取生产环境用户访问产生的中间数据；对新旧版本之间数据差异进行处理；对生产环境与测试环境之间的数据差异进行处理；模拟上游动作重复请求测试环境部署完成的应用；模拟下游为该请求返回相应的返回报文，以便让整个应用程序能够将一去一回的场景覆盖全面。

如上图，执行过程中需要验证的几个点，DARE平台也同样设置了埋点。

首先，在这个模拟过程中，平台会保存B点向下请求的数据，以作为对A-B之间应用程序的验证数据。再次，平台会对D点向上返回的数据进行保存，以作为对C-D之间应用程序的验证。另外，应用程序运行过程中的数据存储我们也将保存并加以验证。

如何验证保存好的数据呢？为被测系统设置基准（基准版本+基准数据+基准DB），测试产生数据与基准做对比。

基准版本可以是生产正在运行的版本，整理好的生产数据，生产应用程序版本在测试环境执行后产生的数据。除此之外，也可以拿某个比较出色的测试版本在测试环境执行后所产生的数据作为基准数据。DARE平台可以直接将某个版本的执行结果设置成基准数据。

并且B点、D点以及数据存储之间的对比工作平台也是可以一键完成的。

两个项目

下面分享两个主要采用DARE策略和DARE平台完成测试实施过程的试点项目。

项目1

第一个是支付业务的Dot Net转Java项目。这个项目刚好符合出参、入参及DB结构变化不大的场景。

不过，出乎意料的是，这个项目的B点、C点不是我们希望的SOA1.0、SOA2.0、restful等等中的任何一种接口。它是一个队列，对的Rabbit MQ。当然这不是难题，我们增加了对Rabbit MQ的数据获取和抛入的支持。

前期的准备工作，首先了解老的系统架构，做新旧系统架构比较，确定系统回放的切入点。

过程中发现整个系统架构确实变化比较大的，切入点向外放大了一点点。这一点点对于整个测试来说，还是有差别的。不过差别仅在于需要增加应用程序部署的工作量，当链路中出现问题时，需要多验证几个节点。对测试结果没有任何影响。

与切入点同样重要的东西是每个切入点的日志记录及新旧版本之间的差异。分别与开发负责人沟通后，确认日志在clog里可以获取，并获取后确定了新旧日志间字段的转换规则。DARE平台里配置起来。

与此同时单独搭建一套干净独立隔离的测试环境。使用环境预先尝试若干条处理好的数据，并尝试小规模执行。以此来确保拉取和整理的配置无误，期间的反复周折一笔略过。

确保没有问题之后，大批量的数据拉取开始了，clog提供的API循环拉取7天的请求日志。拉取和整理的时间算下来每次大约12小时。验证对比出报告顺利搞定。

由此看出，创新改善工作。

项目2

当第二个项目走进DARE的时候，我们总结了前一个项目经验教训。召集了相关干系人来了一个启动会，会议中搞定切入点选择、日志获取方法、新旧请求之间的差异问题。减少配置过程中的反复周折所耗费的资源和时间。

根据上一次clog拉取耗时及数据量表现，与大数据团队报告进行对比之后发现数据有所遗漏。再次与clog团队沟通，获得的支持是从zeus平台直接导出hive DB的方式来获得clog中的原始数据。将12小时的处理时间降低至30分钟，并且保证了数据的全面。

改进了上面两点后，效率再一次提升了一大截。本来20人日的测试任务，最后在5人日内完成。

在效率提升的同时，DARE策略保证的场景回归的全面，发现手工回归很难发现的各种模糊问题。上线以来无事故。

通过第二次实践，可以看出：

第一，逐步的熟悉系统架构，可以更少的依赖开发同学。随着版本的推进，一些回归项目在DARE平台上的配置可以复用，更可以减少反复配置时间。

第二，环境搭建及应用的部署同样是一个占用时间资源的环节，有待解决。