自动化测试缺点的原则
Posted szl6
tags:
篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了自动化测试缺点的原则相关的知识,希望对你有一定的参考价值。
自动化测试并没有想象的那么完美
自动化测试到底都有哪些问题?我们为什么会经常感觉做不下去了?为什么投入那么多,效果总是那么一点点。
自动化测试本身有自动测试自己的问题,随着大量投入地去做自动化测试,这些问题会越来越明显,比方说:
- 编写维护自动化测试脚本成本太高了
- 天天在跑自动化测试,发现的缺陷数量怎么就那么少
- 自动化测试为什么就没有节约人力成本
- 自动化测试为什么就你们几个能用,那么多手工测试人员就不能用起来吗?
这些问题,其实本身不是自动化测试的问题,而是把自动化测试本身放错了位置。就像开篇说的,自动化测试其实不是这样的。
我们拿自动化测试怎么办
自动化测试一般都是需要编写脚本,通过脚本的执行来达到测试的目的,一般被测系统稳定的话,那么脚本是不需要怎么维护的,反之的话,就比较恐怖了。所以要进行自动化测试,就需要下工夫去开发维护脚本,而且工作量不小。由于他有这种特性,所以自动化测试,尤其是针对业务的功能测试中,最好不要去拼命地覆盖全业务,覆盖所有案例,而且抓住重点核心业务进行回归测试。这样可以减少开发维护工作量,还能尽量保证重点业务的测试质量,测试性价比是最高的。
原则1: 针对重点业务,进行回归的自动化测试
另外,尽量针对较为稳定的业务,或者较为稳定的测试方式进行自动化测试,这样人力的投入主要集中的初期脚本的编写,而之后由于较为稳定,那么脚本的维护工作量也不会太大。当然,这种投入不是越早越好,很多项目经理都觉得自动化测试及早投入,这样我们在项目研发中就可以及早用,及早的享受到自动化测试带来的便利。其实自动化测试,一般要做环境比较稳定的情况再投入开发,这样可以减少维护的成本,另外对于不稳定的环境,执行自动化测试也没有太好的效果,经常跑出的脚本一堆问题,分析来半天其实就是不能用,这样测试的意义就不大了。
原则2:针对稳定的业务(或接口),在环境比较稳定的情况,前期投入脚本开发,有利于减少后期维护成本
还有很多自动化测试,几乎每天都在跑,老是发现脚本错误,怎么就没有真正的缺陷呢,出缺陷的概率这么多,就盲目地增加校验点,结果还是一样。其实不用为了发现不了缺陷而烦恼,自动化一般都是保证主要功能完整可用,这些是他的核心价值,而不是发现多少缺陷。
原则3:自动化测试主要是为了保证主要功能完整可用,而不是为了多发现缺陷
当然,还有些人,做自动化就是为了节约手工测试人员的人力成本,做着做着,发现做了那么长时间自动化测试,为什么人力成本没有减少。不减少我为什么做自动化测试啊?这也是一个误区,自动化测试并不能减少测试的人力成本,而是为了加快测试反馈,提升测试质量。我建议自动化测试可以跟自动化部署工具绑定,在每日构建的时候,自动化执行,可以更早的发现产品的问题,自动地反馈开发人员,从而提升开发修复缺陷的效率。
原则4:自动化测试并不能减少测试的人力成本,而是为了加快测试反馈,提升测试质量
还有一个问题,这个问题在初期开始做自动化测试的人,会比较容易走上的误区----录制回放最好了。其实录制回放,并不好,录制的脚本很多时候是不能直接使用,而且业务或者系统发生变化,很有可能很难修改脚本需要重新录制恢复,这样的工作量也不小。而且还有很多人,自动化测试脚本应该跟业务能挂钩起来,让人一目了然我自动化测试脚本都做了些什么,脚本最好能做到"可视化"。其实这些看似的方便,都给脚本维护带来很多困难,业务和系统是在变化的,脚本是要不断维护,可视化和录制回放其实并不能提升效率,反而是为脚本维护增加工作量。建议如果有能力的话,对脚本本身进行管理即可,编写脚本不用录制回放,使用一些辅助工具,或者设计一些框架,编写脚本会更好。
原则5:不要对录制回放抱有幻想了,可视化也不是一个好的想法
最后一个问题,有很多人任务自动化测试执行这么方便,是否手工测试人员可以进行自动化测试啊?可以吗?很多人持不同观点,有的人任务测试其实要成为开发测试,有开发能力,去写自动化测试脚本;还有的人,觉得测试和自动化测试要分开,两个团队管理;还有的人任务,测试执行,测试数据编写等可以让手工人员参与。其实我觉得这都不是最好的想法。真正应该参与自动化测试的应该是开发。
原则6:开发参与自动化测试,让开发和测试融合在一起
作者:乱步
链接:https://www.jianshu.com/p/2473af93034b
來源:简书
以上是关于自动化测试缺点的原则的主要内容,如果未能解决你的问题,请参考以下文章