这个文章是写给没有接触过自动化测试,包括刚学自动化测试或者项目管理人员。 在工作中常常会有这种人,项目刚开始才出设计稿就要求先将自动化测试用例写出来;既然有自动化测试,那么就不要手工测试了,全部使用自动化。 一、有自动化测试就不需要手工测试 最常出现的误解,既然有自动化测试就不需要手工测试。我在世界排名前几位的公司项目文档上看到过这样的字眼“?GOAL:?NO Manual Testing”,目标没有手工测试,我认为这是个笑话。 自动化测试是否能够替代手工测试? 我们先来了解手工测试与自动化测试的概念。 手工测试是测试人员根据用例描述的测试步骤和方法,手工地一个一个执行,然后观察结果,看被测程序是否存在异常。手工测试与自动化测试相比较,手工测试能实时观察各个测试功能运行,但它的工作量大、繁琐、低效,并且出现bug需要重复的测试。 自动化测试是在预设条件下运行程序,评估运行结果,预先条件应包括正常条件和异常条件。它是把以人为驱动的测试行为转化为机器执行的一种过程,自动化测试执行速度比手工测试高很多,他的测试的准确性也相对较高。 从上面的描述能看出,自动化测试是在预设条件下运行程序,评估运行结果,它是设定固定路径来运行程序,这就造成它呆板。当运行结果出现预设条件之外异常,自动化程序就无法识别就会直接放行通过。 以现在的技术条件,程序还无法达到人的观察力,所以对于新功能,新需求无法使用自动化测试。 自动化测试仅仅是某些条件下手工测试的一种补充,它无法全面取代手工测试。 二、自动化测试需要发现大量的bug 自动化测试用例,天天在执行应该会发现大量的bug。 这个也是对前面自动化测试的概念没有理解透彻,自动化测试在预设条件下运行程序,评估运行结果。证明你在编写自动化测试脚本的时候这个功能已经正常,而你要在执行过程中发现大量的bug,这有可能吗?除非每个版本质量太差,开发每次都创造老功能的新bug。 自动化测试测试的真正用途不是用来找bug,而是解放有经验的测试工程师的生产力,让其从事新的测试方法和测试手段的研究。让测试人员的时间和精力来花费在找到更多、更深层次的新bug上,将产品质量再提高一个档次。 自动化化测试它无法发现新问题,它只适合用于回归测试。 三、自动化测试的工作量比手工测试少 自动化测试的人员投入不一定比手工测试少,前期的脚本编写与调试,后期的用例更新与维护,这些都是需要人力投入。尤其是前期自动化测试脚本开发耗时最多,而且自动化测试远比手工测试脆弱,后期用例维护成本也很高; 自动化测试用例的开发工作远大于单次的手工测试,产出价值往往在于长期的回归测试,短期内发挥的作用可能不明显。 实行自动化测试的初期,用例开发效率通常都很低,并且有很大概率后期在功能没有的变化的情况下需要重构用例。 自动化测试的效率很大程度上依赖用例的设计以及脚本实现质量,不稳定的自动化测试用例比没有自动化更糟糕。 自动化测试的投入成本与需求的变更频率相关,产品需求频繁变更,自动化测试工作量的投入也就相应提高。 四、自动化能提供百分百的测试覆盖 并非所有内容都可以被自动化地测试到。不可能覆盖所有功能,有很多功能不适合使用自动化测试。如有些App的扫描二维码或条形码功能,就很难实现自动化测试。 也不是所有的测试用例和测试步骤都可以转化为自动化测试。在自动化测试投入较多的行业,领先企业的自动化测试率有的能达到80%左右,但仍有20%左右的测试用例还是需要手工来进行。在国外,通常从开发第一版测试用例时,就同步进行自动化测试脚本的开发,所以自动化测试率普遍比中国企业高。 自动化测试是为了增加手工测试的广度和深度,它无法达到100%的测试覆盖,因为没有足够的时间或资源,它的投入与收入不能成正比。 五、只有性能测试和功能测试才需要自动化 自动化测试不光只能进行性能测试和功能测试,接口测试也会采用自动化测试。由于功能测试的覆盖率无法达到100%,所以现在能多企业将自动化测试瞄向了接口,接口测试的自动化能实现100%覆盖。 六、测试自动化就是录制和回放 录制得到的脚本不是有效的脚本。 很多人仍然把自动化测试等同于自动化测试工具的录制和回放。而事实上,录制的脚本通常是不可重复使用的脚本,脚本中充满了不可变动的输入值,这些值应该被参数化,否则脚本仅仅适用于当前测试情况,脚本中还需要加入条件判断、循环结构等,以便增强测试脚本的灵活性。 录制的脚本维护成本高,它前期投入可能相对较少,但后期的更新与维护很高。
|