醒醒吧,这才叫自动化测试

1.《World Quality Report 2020-2021》要点解读 2. 类淘宝商城自动化测试实战 3. 测试学习方法分享 1.思考:大家知道为什么需要自动化测试或者自动化测试怎么来的吗?” 为了回答这个问题,...

1.《World Quality Report 2020-2021》要点解读

2. 类淘宝商城自动化测试实战

3. 测试学习方法分享

1.思考:大家知道为什么需要自动化测试或者自动化测试怎么来的吗?”

为了回答这个问题,我们可以回想一下软件测试的概念:软件测试是使用人工或自动的手段来运行或测定某个软件系统的过程,其目的在于检验它是否满足规定的需求或弄清预期结果与实际结果之间的差别。概念中就明确指出了传统人工测试和自动化测试,所以说自动化也是完成和验证客户需求的一种方式。为什么会有这种方式呢?

人力成本:当公司的项目足够多,或者公司的项目足够复杂、功能很多,那么需要的测试人员肯定会越来越多。时间成本:目前IT行业竞争激烈,企业对内对外都需要一个很快的节奏,而测试是保障软件产品的重要手段,如果太慢,即使质量好,也会失去市场。人工测试的弊端在于人在大量重复执行同一任务时,会形成固定思维,从而导致误测、漏测,影响产品质量。人工测试工作通常滞后于自动化测试,而测试的原则就是要尽早测试,所以自动化测试是必须的。

另外,根据《World Quality Report 2020-2021》(全球质量报告)

醒醒吧,这才叫自动化测试插图

有来自32个国家、10个行业的1750名QA/测试经理、首席信息管理和其他IT高管参与的调查结果表明,2020-2021年测试领域有6个主要趋势:其中也有一点:

自动化测试在整个QA生命周期中的比重不断上升,但自动化测试的优势并没有得到充分利用

其实我们很多同学都会或者已经做了自动化测试了,最大的问题就在于对自动化整个知识体系的理解还有所欠缺,会用会写,但是不知道怎么做才最好。那么今天来这里就对了,我今天就教大家怎么样将自动化做得清新脱俗。

2. 类淘宝商城自动化测试实战

这是淘宝App我想这个软件大家一定都用过,那假设我们在淘宝上班。现在项目组发布了一个新的版本,给的测试时间是2周。请问大家都是用什么方法来解决的呢?

好的,我已经看到公屏上有很多种答案了啊。

我们一个个来看看。

首先是手工测试的传统办法,这是典型的4K薪资水平的做法…….

我们再来看看另外的做法,先测试接口吗?好的,这种思路基本可以拿到8K,其关键的目的在于测试的提前,可以更早的介入,更早的发行问题……

还有同学说用自动化。那一般的自动化怎么做的呢?为了方便起见,我们用一个类淘宝商城来替代,因为商用的线上环境会有很多限制….

这里我们先来写一段代码:

醒醒吧,这才叫自动化测试插图1

大家看出来什么问题没有?这是不是很多同学的做法?这样的代码能不能让自动化测试真正落地呢?

不能!那怎样才能让自动化代码变得清新脱俗?好,现在我教大家一步步地来完成这个任务。

实际上从上到下,我们可以简单地将脚本划成几个部分:

part1:头部

醒醒吧,这才叫自动化测试插图2

这里是需要引入的包。

part2:浏览器控制

醒醒吧,这才叫自动化测试插图3

这一块代码,主要作用就是实例化浏览器驱动,并且根据需要对浏览器进行相关操作,比如这里的最大化浏览器。

part3:具体的操作(测试用例)

醒醒吧,这才叫自动化测试插图4

这块代码比较长,主要做的是具体的操作,实际上这就是自动化测试用例。

part4:退出

醒醒吧,这才叫自动化测试插图5

最后一部分就是一行代码,非常简单,用于退出驱动。

思考:这样的脚本用于实际测试会产生什么样的问题?

代码非常死板,不适应环境运行用例不够完整,没有任何判断是否符合需求测试数据单一,覆盖面很小……

解决问题:脚本改造!

2.1 引入测试框架,让代码层次更加清晰

我们可以根据实际测试常见将脚本重新组合一下,比如我现在就想测试搜索功能,那么按照功能测试用例的写法,我们应该知道一条用例有前置条件,输入以及输出,所以我们可以将脚本改成:

醒醒吧,这才叫自动化测试插图6

但是实际测试过程中,根据之前的功能测试知识,严格上来说,一条测试用例只会对应一个测试结果,所以我们会把有多个结果的用例进行拆分。可以采用下面的方法进一步改造,为了更容易理解,我将之前的众多操作挑选登录作为实例:

醒醒吧,这才叫自动化测试插图7

完善测试用例,加入结果判断

我们都知道一条完整的测试必须有结果判断,用来验证实际结果是否符合预期结果,所以我们需要将测试用例中添加断言处理:(前面部分一样,这里只是测试用例部分代码)

醒醒吧,这才叫自动化测试插图8

使用参数化,让数据变活

从上面代码效果看来,层次比最开始确实清晰很多,但是还有存在不少问题。比如,代码里面有很多都是一样的代码,就是数据不一样,并且这些数据都是写“死”在里面,假设还需要搜索别的内容,又要多一截。怎么解决这个问题呢?可以使用参数化来处理,参数化正是解决这种逻辑相同数据不同的方法,我们来看解决办法:

醒醒吧,这才叫自动化测试插图9

使用外部文件管理数据,实现数据驱动(DDT)

虽然这样做可以减少后期一行行改代码的问题,但是实际上还不够“自动”。实际测试中,我们经常使用外部文件来实现数据管理,后期只用维护文件就行,这也就是数据驱动的基本思想。外部文件可以使用的格式有很多,比如yaml、csv、json等都可以,这里采用yaml来举例:

首先编辑yaml文件:

醒醒吧,这才叫自动化测试插图10

再改造代码:

醒醒吧,这才叫自动化测试插图11

我们的脚本逼格是不是越来越高了?实际上,都是围绕着解决自动化实际落地,能够真正让测试人员解放双手的目的地。后续我们根据需要继续将日志/测试报告/持续集成去实现起来,就达到了真正能落地的框架了。本文部分代码因为篇幅问题,不是很完全。最后,如果你对软件测试感兴趣,欢迎百度搜索“特斯汀软件测试腾讯课堂”或关注公众号“特斯汀软件测试”,里面涵盖很多精彩免费视频或干货知识。

联系我们

联系我们

0769-81627526

在线咨询: QQ交谈

邮箱: info@kingpo.hk

工作时间:周一至周五,9:00-17:30,节假日休息
关注微信
微信扫一扫关注我们

微信扫一扫关注我们

手机访问
手机扫一扫打开网站

手机扫一扫打开网站

返回顶部