游戏测试Appium

想想自动化测试-开始(一)

2015-01-07  本文已影响1053人  乱步

自动化测试的开始

自动化测试,从一个大家陌生的概念,到现在越来越多的人在关注使用自动化测试。似乎自动化测试已经成了一个“高级"。但是其实很多人对自动化测试本身有很多误解,自动化测试不是银弹,不是瑞士军刀。自动化测试并不能代替测试本身。很多领导或者客户了解到自动化测试,就都会有用自动化测试覆盖测试的冲动。在这种冲动下,投入大量的人力财力,经常是无功而返的。自动化测试到底怎么了?

自动化测试并没有想象的那么完美

自动化测试到底都有哪些问题?我们为什么会经常感觉做不下去了?为什么投入那么多,效果总是那么一点点。
自动化测试本身有自动测试自己的问题,随着大量投入地去做自动化测试,这些问题会越来越明显,比方说:

我们拿自动化测试怎么办

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

最佳实践

说了这么多芝麻绿豆的,原则也好想法也好,是否有一套方法来支撑整个自动化测试呢,我想简单的说,我比较支持现在比较流行的说法分层测试。利用适宜的测试框架,按照分层测试的范围理论,结合较好的CI工具整合自动化测试。具体的做法我想在下面的章节一一解释说清。

上一篇下一篇

猜你喜欢

热点阅读