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

2023-12-21 21:59:23

?自动化驱动模式

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

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

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

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

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

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

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

流量回放技术

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

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

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

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

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

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

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

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

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

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

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

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

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

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

文章来源:https://blog.csdn.net/2301_78843735/article/details/135133333
本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。