自动化测试之流量录制回放

?自动化驱动模式

相信大家对“关键字驱动”和“数据驱动”这两个名词都已经很熟悉了，但是还有一些小伙伴其实对怎么定义它们还有些误解。比如前面讲的，我们把测试脚本中的数据参数化出来，放在一个文件里，是否就代表它是数据驱动了？并不是。

我们说“X 驱动”，就是以“X”作为输入，控制测试流的走向，获得对应输出的意思。比如一台播放机，放入不同的 CD，就会播放不同歌曲，那么我们就称这个播放机是“CD”驱动的。再比如我们做定格动画，把不同的物体状态拍摄下来，连在一起成为影片，就称这个动画是“物态”驱动的。

以上两个例子分别对应数据驱动和关键字驱动的概念，CD 就是播放机的数据，物态就是动画的关键字。如果把播放机的 CD 读取模块改成一块不可替换的独立存储芯片（类比数据参数化到文件），这时播放机的输入和输出是固定的，那么我们就不能说它是芯片“驱动”的，即便它是提取出来的一个单独模块。

严格上说数据驱动的方式会更早一点（关键字驱动模式从 QTP 之后才被明确化），早期的测试脚本都比较简单，也比较分散，在进行自动化测试的时候，往被测试脚本中注入不同的数据即可。注意重点是通过“不同”的数据测试“相同”的脚本，数据放在什么位置并不重要，并不是一定要用 Excel 之类的工具，哪怕内置在代码中也行。

随着软件架构的复杂化，单个脚本的代码量越来越多，给自动化维护工作带来了很大的麻烦。于是关键字驱动模式应运而生，将不同的行为封装成“动作”，再通过各种“动作”组装形成测试。这里也要注意，重点是“动作”的封装和调用，粒度上是可大可小的，比如往大可以是一个模块的流程，往小可以是一个点击的动作。

不论是数据驱动还是关键字驱动，本质上就是为了代码复用，只不过复用的对象不同而已。所以重新理解上面说的：数据驱动即是使用不同的数据集，复用相同的测试过程；关键字驱动即是使用不同的关键字组合，复用相同的测试动作。

实际上，现在一般都是采用混合驱动的模式。比如我们的测试过程由“登录->查看->下单->评价”组成，登录部分可以是普通账号或会员账号，查看下单的可以是折扣商品或非折扣商品，评价可以是一星或五星，混合驱动模式即可提供“关键字 x 数据”的全用例组合测试。

流量回放技术

开篇的时候有提到，流量回放技术是自动化测试领域一项重要进步。传统的自动化测试方法一直有着“覆盖率”的问题：即我们的自动化测试需要覆盖到什么程度才算足够？并且生产环境的用户数据格式很难预估，导致有很多缺陷是由于对某些特定数据形式的不兼容引起。

流量回放技术很好地解决了这个问题，它基于生产环境的真实流量和请求参数（用户数据），来验证测试（或预发）环境的待发布代码，在真实性、准确度和覆盖率方面都有着极为优秀的保证。流量回放技术本身并不复杂，总的来说可以分成：采集->记录->回放这三个过程。

流量采集的位置一般有两种：网络层和应用层。网络层的采集通过数据包的复制来实现（无代码侵入），应用层的采集通过类似 AOP 的方式来实现（少量代码侵入）。网络层更适用于性能方面的验证（限制或放大流量），应用层更适用于功能方面的验证（真实用户请求）。因此基于本文自动化测试的主题，我们主要来说下应用层。

应用层的采集点通常位于控制器层（Controller），通过拦截器（Intercepter）记录请求地址、请求头，请求参数、返回结果等信息，经过脱敏后写入 DB （或者中间加个 MQ 做二次处理后再写入）做持久化处理。

在录制的时候，可以以适当的比率截取，以减轻录制侧的压力，对线上访问的性能表现也不会产生过多干扰。

上面过程有一个问题是：对于写入型的流量要怎么处理。因为很多时候回放环境和录制环境用的是同一个数据库，如果在回放环境调用写接口，会导致生产环境脏数据的产生，这是不可接受的。即便是使用不同的数据库，也会有需要重复写的情况，来保证测试的幂等性。因此，写入处理是录制回放技术必定会面临的一个难点。

为了解决这个问题，我们同样可以将一些中间件的请求和返回做录制和回放。

比如 DB，可以对 DAO 层的结果进行拦截和记录，作为请求的上下文一并持久化。这样在回放的时候，就不用去 DB 里操作，只要从存储的上下文中读取即可。这个方法其实也是在做 Mock，只不过对业务代码的侵入较少。

录制回放的过程可以是实时的，也可以是离线的。实时指的是一边录制一边回放，中间不一定要经过 DB，通过 MQ 来传递即可。离线指的是录制和回放过程是独立的，因此中间需要有个持久化的步骤，录制下来的流量，可以在任意时候进行单次或多次回放，灵活度较实时回放更高。

前面提到的流程回放技术，大多用于接口层的测试，利用类似的思路，我们其实可以在其他层面复用这套逻辑，比如代码层测试和界面层测试。它们的技术原理与接口层相差不大，只不过录制和回放点有所区别。

代码测试（这里特指单元测试）的采集点位于方法层，采集的是方法的入参和返回值，可以利用反射机制做统一处理。界面测试的采集点位于前端层，采集的是用户的操作，可以使用埋点上报的方式处理。其它诸如 Mock 之类的机制，与接口层的处理是类似的，直接复用就行。

通过这种方式，我们就能够将流量回放技术用于单元测试和 UI 层自动化测试，给自动化测试带来更多的可能性。由此可见，当我们在了解一项技术的原理之后，不妨做一些发散性的思考，或许就能获得一些创新的方法。

最后感谢每一个认真阅读我文章的人，礼尚往来总是要有的，虽然不是什么很值钱的东西，如果你用得到的话可以直接拿走：

这些资料，对于【软件测试】的朋友来说应该是最全面最完整的备战仓库，这个仓库也陪伴上万个测试工程师们走过最艰难的路程，希望也能帮助到你！