软件测试是软件质量保障工作中重要的一个环节，如何通过测试的手段确保京东APP购物流程的平稳运行以及绝佳的购物体验，是我们测试团队永恒的话题。
作为一名测试工程师，相信您一定曾经遇到过类似这样的场景：已经按照评审过的测试用例完成所有的测试，并且也包含了异常逻辑的测试覆盖，但是版本发布，或者服务上线后可能还是出现了各种问题，导致不得不回退版本或者紧急上线修复。一旦发生这种事情不仅会对业务正常运营造成严重的影响，测试人员甚至会对自己的测试能力产生怀疑，形成恶性循环。究其根本原因，还是在于没有能够全部覆盖到用户的各种场景，越是功能复杂的软件越容易发生类似问题；为了减少这种影响，京东APP在发版、上线之前会按照用户的场景进行全量和增量的一致性数据比对测试，确保软件的平稳运行；但是如果遇到对业务还不是特别熟悉的测试人员，仍然可能存在类似的风险。
每逢618、11.11大促，都需要提前对系统进行压力测试，尽早评估系统的各项运行指标，全面做好备战。如果要准确的模拟用户的场景进行压力测试，就需要庞大体量的用户数据支持，比如要对搜索的接口进行大规模压测，就需要大批量的搜索词来模拟接口的实际调用，而且这些搜索词最好是与用户实际购物过程中所使用的一致，这样才能对系统产生有效的压力。那么这些搜索词从何而来，怎么产生，最直接有效的方式就是使用前台输入的内容。为了达到这个效果，我们跟研发人员合作，在某几台服务器上开启操作跟踪日志，记录不同时刻的搜索词并进行存储，在实际进行压力测试的时候，读取这些搜索词，输入到接口中，完成相关的压力测试；但是收集这些搜索词，对其进行二次处理，拼接可以实际调用的接口，都需要消耗大量的时间和成本。
针对上面提到的测试需求，我们实际使用了提取用户输入数据，线上服务与待发布服务进行比对测试等方法进行满足外，同时也在积极探索另外一种高效的测试模式-流量复制与回放。
什么是流量复制？
我们把用户访问系统造成的数据传输定义为流量，那么在用户访问系统的过程中，我们可以把进入和流出的数据复制下来，进行保存，待后续使用，即离线模式，或者转发到一个新的服务器，立即使用，即在线模式。
什么是流量回放？
获取到复制下来的流量以后，我们按照接收的时间顺序，将它们一条一条的传输到待测试的服务中，让测试服务产生相应的响应；相当于实际用户帮助我们进行测试。
通常有以下几种回放测试的情景：
（1）
复制下来什么内容就回放什么内容，即全量回放；
（2）
复制下来的内容进行一些预设规则的过滤，或者特殊的处理后，再进行回放，即选择性回放；
（3）
复制下来的内容，对其进行处理从中获取必须的数据项，比如上文中提到的搜索词，即关键词回放。
TCPCOPY是比较常用，极其优秀的流量复制回放工具，但是其对组网的要求较高，对于网络不熟悉的同学入门比较难，而且扩展起来也有些难度，为了便于测试人员方便使用，最好是能够通过页面进行简单的设置后就可以达到理想的效果，我们尝试开发了一款流量复制回放的平台-狙击手测试平台。
狙击手测试平台是能
够进行HTTP协议的流量复制与回放的平台，它充分结合日常工作需要，具备尽量少的用户主动操作，尽量准确的测试以及自助式的接入策略等特点，平台具体特性如下：
功能多样：
狙击手测试平台能够完成对特定系统服务（通过域名区分）进行线上流量复制，并利用这些流量完成单机的性能调优测试，常态化压测，以及对比性回归测试等；
方便快捷：
平台接入非常简单，用户仅需要填写服务的域名，并选择域名下需要进行压测或者比对的接口名，即可进行周期性的常态化压测和对比测试；
数据安全：
狙击手测试平台复制的数据对用户是完全透明、无感知的，平台在设计之初就充分考虑了用户数据的安全性，不会存在数据泄露的问题；
可追溯性：
每次测试结果均会进行持久化操作，方便测试人员、开发人员进行数据查询以及问题复现，并能够形成某段周期内的趋势性数据；
可扩展性：
流量复制服务，流量回放服务都是分布式实现，并统一进行调度管理，非常易于扩展。
狙击手测试平台主要由流量控制和管理中心、流量复制服务、流量处理服务、流量回放服务以及流量跟踪和数据持久化中心5大核心模块组成。
-
流量控制和管理中心：主要负责流量的调度和管理，包括从哪个线上服务去抓取实时流量，离线流量保存到哪里，从哪里获取，流量需要回放到哪里等相关的任务。
-
流量复制服务：主要负责从线上服务中复制流量，做到随用随复制，不需要的时候保持静默，不损耗系统资源。
-
流量处理服务：主要负责对线上复制的流量进行处理，这里包括离线处理和实时处理两大类，主要是过滤掉不需要进行回放的接口，比如写库类型的接口，如果直接回放到测试服务中，也会进行对应的写库操作，如果正好共用同一套数据库，就会造成大量脏数据，甚至对整体的业务流程产生影响。
-
流量回放服务：接收处理过的流量，进行回放，支持并行产生大量并发的流量，达到压测的目的。
-
流量跟踪和数据持久化中心：从流量复制到流量回放，整个过程跟踪，以及产生的请求和响应数据，比如压测的实际效果，QPS、CPU等数据，均需要进行持久化保存，进行分析，及时发现问题。
常态化压测
常态化压测是以一定的频率对系统的单机服务进行压测，通常是以固定的请求量或者固定的CPU使用率进行，经过周期性积累，可以发现单机服务性能的变更情况（由于服务经常会进行上线操作，为防止性能的衰减，对系统服务进行常态化压测就显得尤为重要）。一次正常的常态化压测会经历如图所示的五个过程：
-
环境检测：由于常态化压测是对线上服务进行的跟踪压测，我们会提前从线上服务中摘除一台机器作为被测试服务，环境检测主要是检测被测服务是否存在实际的流量，回放服务是否处于空闲状态等，确保后续过程顺利执行；
-
流量抓取：环境检测通过后，控制中心会下达流量抓取的任务，系统服务的流量将实时传送到流量处理服务中，进行二次处理；
-
预热压测：没有服务运行的机器，如果大量的流量突然打到某个服务上，会引起大量线程的创建，从而消耗更多的CPU资源，甚至有可能造成机器被压挂，为防止这种问题的发生，我们在正式压测之前首先进行小流量的预热压测，让服务提前处于正常的运行状态；
-
正式压测：系统会按照指定的QPS发送等量的请求到被测服务中，同时进行TPS的实时监控、CPU的实时采集等工作；
-
测试完成：压测结束后，系统将根据QPS、CPU等指标进行实时计算，找出对应关系，做好数据持久化。
常态化压测与传统压测平台的主要区别在于：
传统压测平台通常需要用户提供测试报文链接，提供可用的测试数据，编写测试脚本等工作；常态化压测是全自动方式执行，不需要人工干预，也不需要用户组织请求报文，提取测试数据等较为复杂的行为；在一定程度上可以作为传统压测平台的有效补充。
动态回归
动态回归测试是流量复制与回放的另一个典型应用，将线上服务的流量复制后，经过流量处理，实时回放到被测服务中，被测服务可能是包含了新的功能点即将上线的服务。这个过程中一边复制一边回放，一边同步进行返回值的结果对比，经过以上对比测试后，能够提升服务上线的成功率。
