场景一:
最近听到越来越多的功能测试朋友向我抱怨:功能测试工作很没有前途,固定的系统、按部就班的测试流程,偶尔有点新的需求,写用例、排计划、执行用例,探索性测试,完事上线。
每每听到这样的抱怨,我都会和他们说可以选择另一种方式从事测试工作。
如学习性能和自动化测试,通过自己的学习,搭建一套适合自己被测试系统的自动化框架,实现简单固定工作的自动化,使自己在编码方面有所突破,并且获得更多的时间去学习感兴趣的其他知识。
那么,问题又来了:我想学自动化测试,是不是找个老司机带带我啊?
于是,找了自动化测试比较牛的朋友,“老王,给我好好讲讲自动化吧!”
“没工夫,呵呵…”
大家都这么忙,与其依赖别人,不如自己摸索。
场景二:
我长期从事一线的接口测试工作,第一次测试接口的时候,领导着重的交代我,一定要把每个接口的最大并发量试一试。
我答应了一声,然后就想,这个我该怎么去做啊,我知道 Postman 实现的只是一个请求,手速快点?人工触发?要不请求多人和我一起点击?
现在想想,当时的方法多么的可笑......
多么简单的实践,运用 Thread、同时并发多个线程、将请求进行封装,每请求一次,记录一下结果,写个循环,按基数并发即可。
当时为什么没有这样的处理思维?因为自己的编码知识薄弱,也没有自动化的思想。
所以说你以为自动化是简单的解放功能测试?其实是为了在你学习自动化的过程中,接触积累越来越多的代码知识,最后窥探到测试最深的地方——代码层。
场景三:
许多的测试人员应该都有跳槽的想法,但是一些招聘网站上大部分的招聘要求是测试人员需掌握自动化。
会自动化往往意味着自己更有资本,向用人单位索要薪酬,如果说若不懂自动化,也没有实施过自动化,则价值一定会大大的打折扣。
场景四:
双十一前夕一天上午领导下达任务了,需测试网站的购物流程,包含的功能有如下几个方面:
(1)注册用户
(2)用注册的用户进行登录
(3)登录后进行物品选择
(4)加入购物车
(5)进行结算
(6)支付
这样的功能,对于网购的用户并不陌生,那么功能测试的思维是怎样的呢?写测试用例,然后去执行这个功能,手工注册、登录。
不过测试 Web 的时候有一个不可逾越的问题,必须考虑浏览器的兼容性。
按照主流浏览器 Google、Firefox、IE、Microsoft edge、360 等,每一个浏览器不考虑具体版本的情况下,至少要执行四次(OK,可以接受)。
如果要考虑几个版本的浏览器的话,要测试的远不止10个浏览器了(What?难以接受)。
此时如果我们采用自动化的思维,只需启动不同的浏览器,对其进行分布式并发测试,那么上面的流程就变得非常简单了。
执行脚本,采集结果即可。跑流程的事情交给自动化,结算、支付涉及金钱非常重要,着重人工测试,这样一定会事半功倍。
没错,测试行业发展到今天,我们无法忽略功能测试的作用。
但是不得不面对的现实是越来越多的公司要求员工要掌握自动化测试,越来越多的公司招聘测试人才的时候,把自动化技能放在首要位置。
然而,合格的自动化人才却像是大海捞针一样寥寥无几,自动化在 IT 行业已经产生了巨大的人才缺口。
OK,既然这样,我再花个万把块去培训一下吧?如果有钱任性,那就去吧。
或许,你可以看看关于 「Selenium 自动化测试」的内容:
注重自动化实践,同时讲解一些基础的自动化测试理念,以及常用的 Java 思维,以便快速理解并掌握自动化测试体系、自动化测试核心内容,以及自动化框架的整合实现。
「阅读原文」了解更多 Selenium 自动化测试