自动化工具 解决测试自动化问题:超自动化测试工具 -- 复测高手

复测高手 · 2022年08月02日 · 最后由 薄荷可乐 回复于 2022年08月10日 · 9503 次阅读

前言

在市场竞争越来越激烈的当下,系统的发布和迭代速度变得越来越快,两周一个迭代,甚至几天一个发布都早已是见怪不怪了。为了适应这种快速迭代开发模式,不得不在业务运营、产品需求和功能开发的原有工作节奏上进行调整,同时这也让质量测试的工作变得越来越富有挑战性。其中,一个关键问题就是,以往回归的成本很高,工作量占比较大,但有时候却没有很高的回报。因此往往只能在没有足够的资源的情况下妥协部分的回归内容,使得质量与效率问题变得不可调和。尤其在测试节奏紧张的情况下,这类问题会被放大。如何把整个测试工作变得更加高效,让测试人员可以仅仅把主要精力集中在新功能的验证上,而不再被老功能的验证所束缚?这个问题,已经成为测试领域又一迫在眉睫的问题。

目录

软件测试领域普遍的问题
新测试手段或将解决测试痛点
流量录制回放方案或将成为主流
自动化测试工具的趋势和未来
使用复测高手体验超自动化测试

软件测试领域普遍的问题

最早的测试工具都是纯手工进行,纯手工测试通过先理解需求再设计测试用例,随后在系统发布后执行测试用例,找到 bug 并在 bug 修复后再次进行回归测试。最后确保系统达到了质量标准后择日发布上线。
随着系统上线后,功能需要不断迭代,每次修改,即使只是很小的一部分,仍然需要投入较大的测试成本去执行相关用例,而里面需要执行的很多测试内容其实是重复的、机械的,为此大量的自动化测试工具应运而生。目前市场上存在大量的自动化测试工具,但很大部分的测试工具都是基于开源的工具来做二次开发和集成的,比如:selenium、postman、Jmeter、soapui 等等。

他们和其他商用的自动化测试工具都是通过下面方式实现自动化测试的

  • 脚本
  • 参数化变量
  • 数据源
  • 造数
  • 接口 Mock、挡板等

这些常见的工具之所以能实现自动化测试,是因为测试开发人员为这些工具编写了脚本、并在上下文的依赖参数化、通过数据源或者造数功能构建了测试数据,并使用挡板等方式绕开了执行不下去的步骤。
但在实际的过程中,即使有了这些自动化测试工具依然无法让整个测试完全自动化,也难以把测试成本降下来。因为这些工具只是能把测试执行的一部分动作自动化,但为了自动化工具能正常运行起来,需要新增测试开发人员,测试开发人员需要编写、调试相关的脚本。在使用初期,往往纯手工五分钟可以执行完成的工作,以自动化脚本执行则需要一个多小时才能编写、调试、参数化完毕,在达到一定的自动化用例规模后,效果才能够逐渐显现。而当系统变动时,部分脚本可能又不能正常工作了,之后不得不再次投入成本进行维护。就在这一轮又一轮如同噩梦般的循环下,使用这类自动化测试工具往往没有使测试成本下降多少,更多时候,反而让测试人员苦不堪言。

新测试手段或将解决测试痛点

以 Web 应用为例,系统在使用时会产生流量数据,比如,由用户操作产生的报文请求,由程序调用数据库时所返回的数据内容,由应用之间调用时所产生的交互数据。这些流量数据因自身携带着丰富的数据信息,可以满足测试时所需的相关数据要求。且生产上的流量更加真实丰富,更能代表用户真正行为,如果可以基于真实行为的数据进行测试,那么在许多场景下都可以替代基于经验撰写的用例。而自动化工具、脚本、参数化等动作,主要也是希望能够高效解决数据的准备及发送与服务器端的通讯请求。倘若这些工具需要使用的测试数据,都能由生产环境真实用户的操作所产生,利用这些数据进行系统的测试,是否有可能解决上述测试的痛点,实现更高效的自动化测试工具或平台?
目前,这种利用生产环境运行中产生的数据进行系统测试的模式,也已经被一些厂商所尝试,在前些年,阿里有已经对外分享过,如何使用线上流量进行全链路测试的思路。而在最近两年的时间里,更多知名互联网厂商也开始拥抱了这种方式,纷纷加入到这股浪潮中来,通过不断的实践与探索,近期也取得了非常好的成效。而这种新的测试手段,就是"流量录制与回放"方案,从结果来看,它为自动化测试的未来带来了新的曙光。

流量录制回放方案或将成为主流

“流量录制与回放” 可分为 “前端流量与回放” 和 “后端流量与回放”,但无论前端流量方案还是后端流量方案,都是基于录制用户或者用户的真实数据,并通过数据来演变出回归测试所需要的执行步骤、执行内容等依赖信息,都是推动自动化测试再向前迈进一大步的巨大助力。
目前探索过 “流量录制回放方案” 的厂商有阿里、腾讯、字节跳动、美团等。在这些探索尝试多发生在相对容易实现的后端流量部分。而在后端流量部分,实现 “流量录制与回放” 方案的方式又主要分为两大流派,其中,Java agent 流派占据了主流地位。

不同流派的技术优劣对比

根据上图所示,之所以 Java agent 会成为厂商里最多使用的技术原因主要有以下几个判断:
1.流量转发流派,难以扩展运行程序的逻辑,不能应对写操作,回放时会对存储介质造成污染
2.java agent 对于被测系统的扩展性好,在不修改程序代码的情况下,就能扩展出录制与回放功能
3.java agent 可以有效应对不同存储介质的写操作,也可以 mock 远程调用的返回值

从近期调研结果来看,使用 java agent 作为流量录制回放方案的技术手段,从落地后实际业务场景的满足程度上来说,其效果也比光使用流量转发流派要好。

自动化测试工具的趋势和未来

在实际的落地过程中,如何使得技术手段,变成一个系统或平台,从而更有效地进行系统化管理?如何以此为撬点,大量降低测试过程中机械式的体力活?这些问题,光是有一些可以支持理论的技术出现是远远不够的。只有把工具变成平台,把实际的自动化测试工具中存在的问题解决的足够彻底后,超越以往的自动化测试新体验才能够到来。
回顾一下以往自动化测试过程中,使用门槛较高和使用维护成本较高的一大原因就是使用这些自动化测试工具不得不通过测试开发人员编写和调试下面内容:

  • 脚本
  • 参数化变量
  • 数据源
  • 造数
  • 接口 Mock、挡板等

自动化测试工具的未来肯定要去把这部分的痛点消除的,而能去除这些痛点的新一代的超越目前的自动化测试工具的产品才能被叫做超自动化测试工具。而也只有新一代的超自动化测试工具才会使得测试过程的效率得到极大幅度提升。随后才能腾出更多测试人员的精力放在新功能或更有意义的事情上。
超自动化测试工具不但应该消除上述痛点,还应具有学习能力和大幅提高测试效率的能力,可通过录制的流量数据,默默学习并具备初步的智能学习能力、决策能力、探索能力。因此超自动化测试工具应具备以下特性:

  • 无脚本、无参数化
  • 可学习人的操作行为
  • 可自我判断是否是 bug
  • 可自我判断是否是阻塞性 bug
  • 可自行绕开非阻塞性 bug 继续执行
  • 可通过机器人高速测试

使用复测高手体验超自动化测试

超自动化测试平台基本出发点看起来很美好,但真正落地时,其背后的架构、运维、部署、接入、功能及技术等多方面因素背后潜藏着高昂的成本,这让没有经历过这些实际问题的团队难以让这一理念轻松有效地落地。

复测高手是一款目标实现超自动化测试平台的产品,并在公开的版本中已支持了大部分超自动化测试的一阶段目标。借用无人驾驶的理念来说,超自动化的水平达到 L3 级别以上。

超自动化测试平台/工具应该不需要手动用例,也不需要编写自动化测试用例,更不需要手动执行测试用例,即可实现自动化测试。从操作上来讲,这几乎是零成的本回归测试了。而且复测高手在使用过程中,除了可以免除以往自动化测试过程中,最令人烦躁的那几个动作以外,还尽可能的降低使用和运维门槛,比如以下几个特点:

  • 让系统搭接入变得容易,实测 5 分钟内完成
  • 使用门槛低,玩两遍就会了
  • 易用的跨环境复测
  • 流量可以乱序并发回放
  • 维护成本低
  • 多人一起测试,不会再造成测试结果的混乱
  • 易于辨认真正的 bug
  • 易于定位 bug 根因

以下是复测高手的一些更具体的功能介绍:
拥有链路自动感知、调用链路识别、请求自动统计等功能,方便测试、开发确认现在系统的运行关系,也为后续的链路筛选提供了自动提示和查询做了准备。


自动感知的系统调用关系图

对于无论是测试人员还是真实用户,只需要操作一次,流量数据就有了,随后任意回放,也不再需要准备脚本,从而解决了目前的自动化测试工具的大量编写脚本、调试脚本所需要的高级测开人员和脚本开发时间等问题。

常见的自动化测试工具之所以要参数化和调试很大的一个原因是它们需要消除不同环境里面的数据、状态、集成环境的差异。复测高手通过录制的数据和智能算法自动仿真,可以实现跨环境回归测试。


跨环境回放概要示意图

通过与自动化工具集成,每次发布,都可以自动生成一份与之对应的测试结果报告,每次发布的变化都能够看得清。


接入持续集成示意图

复测高手集成第三方测试管理工具,可以在里面进行项目管理以及 bug 用例管理,测试人员在执行测试用例的过程中,如发现实际结果与预期结果不一致, 则意味着可能出现 Bug 的情况。当测试人员发现 Bug 之后,可以快速确认或推送到原本自己习惯的 bug 管理平台进行统一管理。


可以与更多的第三方质量平台打通

复测时,可以进行无数据库依赖的测试动作,也可以基于影子库的真实访问(以应对特殊场景时),同时可以屏蔽掉真实写入的操作,以免污染数据源。


无数据库模式与影子数据库模式的回放策略示意图

复测高手会对某些敏感信息从源头上彻底脱敏,实现敏感隐私数据的可靠保护。在涉及客户安全数据或者一些性敏感数据的情况下,对真实数据进行改造并提供测试使用。


脱敏后的数据展示

可以进行单个链路请求的重测,重测过程中,也不会对数据造成污染,不再需要 PostMan 带入参数后验证。


单次重测的示意图


复测高手的报告展示
点击了解更多功能

复测高手首页地址:https://www.fucegaoshou.com

最佳回复

复测高手的亮点:
1、利用生产端用户真实环境生成的数据造数,
2、录制生产端用户行为回放
3、理念不错

对原来自动化测试(脚本化功能测试用例)是一个改进,但也存在以下问题:
1、真实环境下的数据收集需要时间,及用户量,回归测试此时才开展是否有些晚(因为版本已上线)
2、不太可能代替原来经验设计的用例,因为生产端的用户场景也只能是一部分(重要的一部分)
3、复测高手假定的被测对像需要比较稳定或长久性产品

建议:
1、复测高手除了收集生产数据、用户行为,是否可进行用户大数据分析,导推需求测试,及需求挖掘。
2、是否有成功应用的业务领域,分享一下

共收到 10 条回复 时间 点赞

额,没个链接,搞推销?

Bruce 回复

您好,复测高手的官网地址是: https://www.fucegaoshou.com
您也可以点击二维码上方的 “点击了解更多功能” 跳转过去

要是能够给一个真实的项目的案例就好了,比如自家公司产品测试 视频😂

说这么多,反而一头雾水,这个到底是个什么东西.能做什么

复测高手的亮点:
1、利用生产端用户真实环境生成的数据造数,
2、录制生产端用户行为回放
3、理念不错

对原来自动化测试(脚本化功能测试用例)是一个改进,但也存在以下问题:
1、真实环境下的数据收集需要时间,及用户量,回归测试此时才开展是否有些晚(因为版本已上线)
2、不太可能代替原来经验设计的用例,因为生产端的用户场景也只能是一部分(重要的一部分)
3、复测高手假定的被测对像需要比较稳定或长久性产品

建议:
1、复测高手除了收集生产数据、用户行为,是否可进行用户大数据分析,导推需求测试,及需求挖掘。
2、是否有成功应用的业务领域,分享一下

简一 回复

感谢您的建议和提出的建设性的问题,通过复测高手在以往的实践情况来看,试图回答一下您提出的几个点
1、真实环境下的数据收集需要时间,及用户量,回归测试此时才开展是否有些晚(因为版本已上线)
回复:在请求录制的时候,数据沉淀需要一定的时间,比如 1 周左右,具体看实际用户量、用户操作、系统复杂度、测试要求等实际因素,可略有调整,一般都是当前版本沉淀,下个版本使用,初次录制的数据在使用上会有一定滞后性。(这部分可以由其它现有功能弥补)

2、不太可能代替原来经验设计的用例,因为生产端的用户场景也只能是一部分(重要的一部分)
回复:是的,比如在新版本迭代时出现的新功能,由于用户没有操作,因此无法从生产环境中沉淀这部分新内容。所以需要在更早的测试环境中被人工验证,也可以把人工验证的动作录制下来,放到复测流量中后续使用,这样其实也可以解决一些测试成本,比如,一次录制多次回放,不再需要造数等动作。
而基于经验设计的用例,这一点在部分客户使用的过程中,也有明确要求希望保留,因此我们也开发了带有用例助手功能的小复机器人,可以在小复机器人(注册后可下载)中进行用例维度的操作,与传统用例类似,用例步骤中的操作请求内容会被记录下来,也可以免去造数等用例执行过程前的准备动作。

3、复测高手假定的被测对像需要比较稳定或长久性产品
回复:如果是流量录制的话,那在初期的第一个版本,需要提前沉淀一下,当然,复测高手有用例助手,可以按照用例步骤来录制流量。这两种方式其实更多的是看重发布的节奏。当然如果产品比较稳定,能够长久性的在生产运行那样会更好,这更有助于线上流量的沉淀

感谢您的建议,您可以扫描二维码或者进入官网获取更多方案咨讯。

流量回放和录制用例在几年前就提出的概念,经过各大公司多个业务实践过,理论和现实差距很大的。综合考评,投入产出比严重失衡,也可以说价值不够大,这也是这方面的技术后续没有大的发展的原因。文章介绍的工具思路很好,不过无法使用到真实的环境中,一是,不同公司的产品会因为技术,架构,实现方案等原因,造成千差万别,无法统一化;二是,由于安全限制,产品特点等,无法让你获取到相应的流量的;三,收益得不到认可,搞过很多次相关技术专项,业务相关同事只是拿来做参考,不会重视,慢慢的就没有人投入精力去使用了。个人的一些经验,讨论一下。

这个是来打广告的吗,为什么试用注册后,还得等对方电话?这是变相宣传吗??

爱偷懒的QA 回复

你说的几点也是我们碰到的,然后后来就没有后来了。。。

安全限制是致命的,很多不可能让你去抓生产流量的,客户信息,财务信息等都是保密的

需要 登录 后方可回复, 如果你还没有账号请点击这里 注册