流量复制与回放与压测平台化

背景

软件测试是软件质量保障工作中重要的一个环节，如何通过测试的手段确保京东APP购物流程的平稳运行以及绝佳的购物体验，是我们测试团队永恒的话题。

作为一名测试工程师，相信您一定曾经遇到过类似这样的场景：已经按照评审过的测试用例完成所有的测试，并且也包含了异常逻辑的测试覆盖，但是版本发布，或者服务上线后可能还是出现了各种问题，导致不得不回退版本或者紧急上线修复。一旦发生这种事情不仅会对业务正常运营造成严重的影响，测试人员甚至会对自己的测试能力产生怀疑，形成恶性循环。究其根本原因，还是在于没有能够全部覆盖到用户的各种场景，越是功能复杂的软件越容易发生类似问题；为了减少这种影响，京东APP在发版、上线之前会按照用户的场景进行全量和增量的一致性数据比对测试，确保软件的平稳运行；但是如果遇到对业务还不是特别熟悉的测试人员，仍然可能存在类似的风险。

每逢618、11.11大促，都需要提前对系统进行压力测试，尽早评估系统的各项运行指标，全面做好备战。如果要准确的模拟用户的场景进行压力测试，就需要庞大体量的用户数据支持，比如要对搜索的接口进行大规模压测，就需要大批量的搜索词来模拟接口的实际调用，而且这些搜索词最好是与用户实际购物过程中所使用的一致，这样才能对系统产生有效的压力。那么这些搜索词从何而来，怎么产生，最直接有效的方式就是使用前台输入的内容。为了达到这个效果，我们跟研发人员合作，在某几台服务器上开启操作跟踪日志，记录不同时刻的搜索词并进行存储，在实际进行压力测试的时候，读取这些搜索词，输入到接口中，完成相关的压力测试；但是收集这些搜索词，对其进行二次处理，拼接可以实际调用的接口，都需要消耗大量的时间和成本。

流量复制与回放

针对上面提到的测试需求，我们实际使用了提取用户输入数据，线上服务与待发布服务进行比对测试等方法进行满足外，同时也在积极探索另外一种高效的测试模式-流量复制与回放。

什么是流量复制？

我们把用户访问系统造成的数据传输定义为流量，那么在用户访问系统的过程中，我们可以把进入和流出的数据复制下来，进行保存，待后续使用，即离线模式，或者转发到一个新的服务器，立即使用，即在线模式。

什么是流量回放？

获取到复制下来的流量以后，我们按照接收的时间顺序，将它们一条一条的传输到待测试的服务中，让测试服务产生相应的响应；相当于实际用户帮助我们进行测试。

通常有以下几种回放测试的情景：

（1）    复制下来什么内容就回放什么内容，即全量回放；

（2）    复制下来的内容进行一些预设规则的过滤，或者特殊的处理后，再进行回放，即选择性回放；

（3）    复制下来的内容，对其进行处理从中获取必须的数据项，比如上文中提到的搜索词，即关键词回放。

TCPCOPY是比较常用，极其优秀的流量复制回放工具，但是其对组网的要求较高，对于网络不熟悉的同学入门比较难，而且扩展起来也有些难度，为了便于测试人员方便使用，最好是能够通过页面进行简单的设置后就可以达到理想的效果，我们尝试开发了一款流量复制回放的平台-狙击手测试平台。

平台化

3.1 平台特性

狙击手测试平台是能够进行HTTP协议的流量复制与回放的平台，它充分结合日常工作需要，具备尽量少的用户主动操作，尽量准确的测试以及自助式的接入策略等特点，平台具体特性如下：

功能多样：狙击手测试平台能够完成对特定系统服务（通过域名区分）进行线上流量复制，并利用这些流量完成单机的性能调优测试，常态化压测，以及对比性回归测试等；

方便快捷：平台接入非常简单，用户仅需要填写服务的域名，并选择域名下需要进行压测或者比对的接口名，即可进行周期性的常态化压测和对比测试；

数据安全：狙击手测试平台复制的数据对用户是完全透明、无感知的，平台在设计之初就充分考虑了用户数据的安全性，不会存在数据泄露的问题；

可追溯性：每次测试结果均会进行持久化操作，方便测试人员、开发人员进行数据查询以及问题复现，并能够形成某段周期内的趋势性数据；

可扩展性：流量复制服务，流量回放服务都是分布式实现，并统一进行调度管理，非常易于扩展。

3.2 平台基础架构

狙击手测试平台主要由流量控制和管理中心、流量复制服务、流量处理服务、流量回放服务以及流量跟踪和数据持久化中心5大核心模块组成。

• 流量控制和管理中心：主要负责流量的调度和管理，包括从哪个线上服务去抓取实时流量，离线流量保存到哪里，从哪里获取，流量需要回放到哪里等相关的任务。

• 流量复制服务：主要负责从线上服务中复制流量，做到随用随复制，不需要的时候保持静默，不损耗系统资源。

• 流量处理服务：主要负责对线上复制的流量进行处理，这里包括离线处理和实时处理两大类，主要是过滤掉不需要进行回放的接口，比如写库类型的接口，如果直接回放到测试服务中，也会进行对应的写库操作，如果正好共用同一套数据库，就会造成大量脏数据，甚至对整体的业务流程产生影响。

• 流量回放服务：接收处理过的流量，进行回放，支持并行产生大量并发的流量，达到压测的目的。

• 流量跟踪和数据持久化中心：从流量复制到流量回放，整个过程跟踪，以及产生的请求和响应数据，比如压测的实际效果，QPS、CPU等数据，均需要进行持久化保存，进行分析，及时发现问题。

3.3 平台功能

常态化压测

常态化压测是以一定的频率对系统的单机服务进行压测，通常是以固定的请求量或者固定的CPU使用率进行，经过周期性积累，可以发现单机服务性能的变更情况（由于服务经常会进行上线操作，为防止性能的衰减，对系统服务进行常态化压测就显得尤为重要）。一次正常的常态化压测会经历如图所示的五个过程：

• 环境检测：由于常态化压测是对线上服务进行的跟踪压测，我们会提前从线上服务中摘除一台机器作为被测试服务，环境检测主要是检测被测服务是否存在实际的流量，回放服务是否处于空闲状态等，确保后续过程顺利执行；

• 流量抓取：环境检测通过后，控制中心会下达流量抓取的任务，系统服务的流量将实时传送到流量处理服务中，进行二次处理；

• 预热压测：没有服务运行的机器，如果大量的流量突然打到某个服务上，会引起大量线程的创建，从而消耗更多的CPU资源，甚至有可能造成机器被压挂，为防止这种问题的发生，我们在正式压测之前首先进行小流量的预热压测，让服务提前处于正常的运行状态；

• 正式压测：系统会按照指定的QPS发送等量的请求到被测服务中，同时进行TPS的实时监控、CPU的实时采集等工作；

• 测试完成：压测结束后，系统将根据QPS、CPU等指标进行实时计算，找出对应关系，做好数据持久化。

常态化压测与传统压测平台的主要区别在于：传统压测平台通常需要用户提供测试报文链接，提供可用的测试数据，编写测试脚本等工作；常态化压测是全自动方式执行，不需要人工干预，也不需要用户组织请求报文，提取测试数据等较为复杂的行为；在一定程度上可以作为传统压测平台的有效补充。

动态回归

动态回归测试是流量复制与回放的另一个典型应用，将线上服务的流量复制后，经过流量处理，实时回放到被测服务中，被测服务可能是包含了新的功能点即将上线的服务。这个过程中一边复制一边回放，一边同步进行返回值的结果对比，经过以上对比测试后，能够提升服务上线的成功率。

效果及不足

4.1  应用接入

平台的接入非常简单，业务仅需提供接入的域名，并提供一台部署了服务但已摘除流量的机器作为被测服务，在平台上设定好目标QPS以及自动执行的时间，即完成接入过程。

4.2 运营结果

以上是某个业务一段时间累计的常态化压测结果趋势数据，图中可以看到QPS、CPU在这段时间的变化趋势，根据这个变化的趋势，我们可以去查看详细数据，并分析降低的原因是什么，以及后续升高的原因又是什么，是不是因为某次上线引起了相应的变化。

目前平台已经对30个左右的核心服务进行了常态化压测的跟踪，对于系统单机容量的评估起到了非常重要的参考作用。

4.3 平台不足

协议支持：由于业务大部分处于前台，而且基本都是HTTP接口，所以平台设计之初就仅仅支持HTTP协议的复制与回放，后续我们也将根据实际需求，尝试对公司内部JSF协议接口的零门槛复制与回放；

常态化压测：目前常态化是周期性开展，后续也将尝试与持续交付平台、穹天平台对接，做到事件触发，有变更就压测，就比对，让每一次压测和比对都能产生有效结果；

写接口：由于回放后对写接口的操作，可能会产生脏数据，这些还依赖于业务侧进行相应的脏数据过滤，或者对写接口的回放操作进行必要的转发，鉴于以上问题的风险，写接口的回放操作平台还不能很好的支持，这也是后续我们需要持续改进的地方。

总结

狙击手测试平台充分利用线上已有的流量数据，经过平台加工处理后回放到指定的服务中，完成自动化的常态化压力测试，回归比对测试等，从很大程度上减轻了测试人员编写脚本，收集测试数据等重复性且耗时的工作。但是平台也只是众多测试方法中的冰山一角，在测试的技术发展上仍然任重而道远，我们也期望测试人员都能成为这个发展道路上的狙击手，进行精准测试，成为产品质量的忠实守护者。