前言

  一直以来,测试团队都面临一个迫在眉睫的问题:自动化测试收效甚微,甚至被认为是”为了实现自动化而自动化“。之前写过一篇博客自动化测试的评价维度,其实自动化的评价不乏有其他的评价指标。但这里想说的一点是,自动化方案产出低的一个重要原因是自动化整体方案的不合理。
  下面根据自己的经验,做下总结,个人之见,不免有不足之处,欢迎补充交流?。?!
  自动化整体方案不合理的证据
  1、自动化发现bug率太低/甚至很长一段时间没有发现过bug
  可能你会说自动化本来就不如手工测试容易暴露问题,况且有些业务本来bug就不多。但注意了,这里强调的是自动化发现bug的占比,如果这个比例趋向于0,那自动化实现的价值还有多少呢
  2、没有减少手工成本/或时间成本
  自动化虽然也不断暴露问题,但自动化测试一次,与手工测试一次相比,并没有节省多少 人工成本和时间成本(例如,执行过程中还需要人工参与等),甚至反而增加了自动化的维护成本。那么这样算起来,自动化可能成为了一种”摆设“。
  这种情况流行的一种说法是:”为了自动化而自动化“。将不适合做自动化的地方,强行自动化实现后,是得不偿失的。
  3、自动化运行失败, 极大概率并不能说明真的bug存在
  这在实际业务中,是大多数实现自动化的测试同学比较痛心疾首的情况了。日常的工作就是不断调试自动化,确保运行时不再那么频繁失败了。很早之前,自己也曾经历过这样的痛苦。
  这种情况除了白白浪费很多时间精力外,还会让参与自动化建设的同学丧失继续实现自动化的信心。 说白了,自动化实现的目标是帮测试同学干活的,如果失去这个作用,还不如果断放弃自动化。
  4、自动化执行后仍然需要重复投入手工测试
  这种自动化运行类似于”空跑“一样,并没有起到什么作用,其实这种情况也是”为了自动化而自动化“的一种证明了。目前很多团队评价自动化好坏的重要指标就是自动化case数量、运行稳定性/成功率,其实这两个指标对评价自动化并没有那么的有说服力。
  自动化整体方案不合理的几个原因
  根本原因是自动化整体方案与实施不合理,具体说来,有几点值得注意:
  1、自动化方案与手工测试流程千差万别
  不会做手工测试的同学,真心很难做好自动化测试(当然了,这里的自动化排除掉压测)。不敢想象,如果自动化方案与手工测试流程完全不在一个维度上,自动化怎么能像手工测试一样大量暴露问题呢?。?!
  2、实现的自动化只能”一条腿走路“
  这里说的”一条腿走路“是说,只实现了半自动化,并没有实现100%的自动化,运行前/中/后需要人为参与。 半自动化的例子,在实际的业务中,还是挺多见的。比如,自动化执行前输入人为输入一些参数、或自动运行前需要人为准备一些数据、或自动化运行后需要人为check一些东西。
  3、试图将一切自动化
  所谓过犹不及,试图将一切自动化的后果是自动化变得臃肿不堪,要么常常失败,要么成了摆设。
  4、没有根据业务实现特点进行自动化
  各个公司/团队的业务、实现千差万别,哪怕是不同产品线都会因为团队合作、迭代、架构设计的不同,导致自动化方案的千差万别,进而自动化使用的工具、平台都会有很大不同。因而,在别的业务上运行完美的自动化,拿过来直接用,很可能会产生”水土不服“。
  如果自动化目前用的不顺手,或者没有达到效果预期,那么不妨评估一下,你的自动化方案是不是也正在”水土不服“呢
  写在最后
  自动化实现的方法论:
  1、承认不是所有的东西都适合自动化;
  2、自动化测试的前提是强大地进行手工测试;手工测试是自动化测试的必要条件。自动化测试应该尽可能模拟手工测试的流程
  ps: 这里的手工测试,当然是完美、大神级别的了, 并不是仅仅是说点点点的功能级别测试
  3、自动化实现之前,不妨先列一些自动化实现最为核心的目标。
  在频繁的迭代上线过程中,如果遗漏到线上的问题太明显,太多,这是测试技能问题;但如果线上无遗留,测试技能没有问题,只能说明自动化整体方案可能有很大的提升空间。