码迷,mamicode.com
首页 > 其他好文 > 详细

自动化测试实现优劣

时间:2020-05-10 17:36:16      阅读:75      评论:0      收藏:0      [点我收藏+]

标签:image   package   增删改   逻辑   http   朋友   迭代   补充   针对   

目前互联网测试中,几乎所有团队、所有测试人员都在做自动化测试。但要评价自动化测试实现的优劣,就需要拿具体的数据来说话了。究竟自动化测试的效果如何呢?自动化测试有没有真正发挥出来其作用,又如何来评价一个团队自动化测试工作做得好坏呢?以下就跟大家分析一下自动化测试实现的优劣。

 一、背景

  从自动化测试方法论层面来说,之所以要实现自动化测试,大致有以下几个方面的原因:

  1、提升测试效率

  2、提升测试覆盖度,包括深度和广度

  3、提升测试发现问题后的解决效率

  4、补充手动测试无法覆盖/不易覆盖的场景

  以上是一些实现自动化测试方向性的指导原则,但要评价自动化测试实现的优劣,就需要拿具体的数据来说话了。下面就自己的一点经验,来说说自己对自动化测试优劣的一些体会,不足之处,欢迎大家交流指正。

技术图片
 

二、评价自动化测试优劣的常见指标

  互联网公司中,由于绝大多数团队都在重点攻克自动化测试,因而每个团队都指定了相应的评价指标。虽然各个公司,各个团队对指标的侧重不同,但几乎都会关注如下指标。

  1、自动化运行通过率/成功率

  这里排除了代码bug导致的失败。为了避免自动化运行经常失败,大部分团队都会将自动化运行通过率作为一项重要指标,来评判不同模块/业务线自动化实现的好坏。还将这个指标设置一定的阈值,例如,经历过的有个团队要求自动化运行成功率要大于90%+,最好能100%运行成功。

  这个指标是几乎所有团队都会强调的一个指标了,因为自动化运行通过率/成功率是自动化发挥作用的前提条件。但看这个指标,其实也无法评估自动化实现效果,只能说明自动化运行的比较稳定。

  2、自动化执行频率

  这里的执行频率,排除业务测试,特指每天定时的自动执行。不同团队,根据实际情况不同,有不同的要求。例如,有的团队要求早晚至少各一次,有的团队则要求每天至少执行一次,但无论哪一种,几乎都会形成这样一种现象:各个团队为了让定时自动执行时都通过,每天都要花费一定时间来维护自动化代码。

  这个指标其实也是一种评估自动化运行是否稳定的指标。执行的频率越高,加上执行的通过率/成功率越高,说明自动化运行的越稳定。

  3、自动化case数量/覆盖场景数

  这个指标不同业务线之间,其实没有太大的可比性。但同一个业务线上,还是可以作为参考指标的。自动化case多、覆盖的场景多,至少一定程度上说明了自动化的覆盖范围。这个指标可以一定程度上来评估自动化测试的广度、深度。

  4、自动化发现bug比例

  如果说自动化运行通过率/成功率、自动化执行频率、自动化case数量/覆盖场景数还是评价自动化优劣的过程指标,那么自动化发现bug比例就是最有力的结果性指标了。试想一种极端情况,如果一个自动化项目,跑了N久后,还没有发现过bug,那么这个自动化的价值是不是要打一个大大的问号呢?

  自己经历的团队,以及曾经接触过的团队,其实对自动化发现bug比例的侧重反而不是那么高。

  这个指标可以说是众多指标中,最能立竿见影的说明自动化实现效果的指标了。自动化发现bug的比例越高,说明自动化在实际的项目中发挥的作用越大。甚至可以用自动化发现bug率是100%,来作为自动化测试的终极目标。

技术图片
 

如果对软件测试、接口测试、自动化测试、面试经验交流。感兴趣可以加软件测试交流:1085991341,还会有同行一起技术交流。

三、评价自动化测试优劣的隐性指标

  关于评价自动化测试的优劣,除了上述常见指标外,还有一些不太容易拿数据说话的指标,这里叫做隐性指标。

  隐性指标主要包括:自动化的维护成本、自动化的运行成本

  1、自动化的维护成本

  针对同一个业务,不同的自动化测试实现方案,对应的维护成本可能天壤之别。诚然,自动化的维护成本,受业务成熟度、迭代速度、项目规范程度影响,但不妨考虑以下情况下,你的维护成本如何:

  新增了一些逻辑(如,接口/服务/应用),对新增部分维护自动化,你需要多长时间;

  删除了一些逻辑(如,接口/服务/应用),对删除部分维护自动化,你需要多长时间;

  修改了一些逻辑(如,接口/服务/应用),对修改部分维护自动化,你需要多长时间;

  在项目迭代速度加快时,并伴有增删改逻辑时,你的自动化脚本还能跟得上吗?其实,这是不少团队都会面临的严峻考验。 一个正处于快速发展的业务,每次业务测试、回归时,可能都会想放弃自动化测试,转而来手工执行测试。因为,自动化测试还要不断调试自动化代码,大概率来不及这次的测试,还不如直接手动测试的效率高。

  2、自动化运行成本

  这里的自动化运行成本是说,从想执行自动化 ~?执行结束 需要符合的人力&时间成本。一般的自动化运行过程大致如下:

  1)创造一些自动化执行条件。比如,找运行数据,设置运行环境等等,这一步如果没有被自动化掉,需要花费人力&时间;

  例如,实现的自动化只能”一条腿走路“,即只实现了半自动化,并没有实现100%的自动化,运行前/中/后可能需要人为参与。

  2)执行自动化。这里主要是自动化运行所需时间,时间越长,导致的等待时间越长。可能你会说,自动化执行的时候,你可以去干别的事情啊,没必要一直等待执行结束。但既然执行了自动化,肯定想像手工测试一样,”马上“看到执行结果,得到及时反馈,才能避免在不同工作间来回切换。

  3)验证自动化结果。一般结果的验证都包含在上一个步骤里面了,但不排除有些验证仍然需要人工来check的情况。这种情况,其实也属于半自动化的一种实现形式。

  4)自动化失败问题排查。各种各样的原因,都会导致自动化运行失败了,比如,数据问题、环境问题、自动化维护不及时、第三方问题等等。自动化失败后,能否比较清晰的给出失败原因,甚至能根据自动化失败结果,直接定位到失败原因,这些做到位了,会让你对自动化爱不释手。

以上内容希望对你有帮助,有被帮助到的朋友欢迎点赞,评论。

自动化测试实现优劣

标签:image   package   增删改   逻辑   http   朋友   迭代   补充   针对   

原文地址:https://www.cnblogs.com/Chaqian/p/12863679.html

(0)
(0)
   
举报
评论 一句话评论(0
登录后才能评论!
© 2014 mamicode.com 版权所有  联系我们:gaon5@hotmail.com
迷上了代码!