在我有限的软件测试经历里,一段专职的自动化测试经验总结

开发 测试
最近的一两年,我有时会想到自动化测试是什么?自动化测试本来是为提高测试效率而生,有时候使用不得当,却成为测试活动中的累赘。

在我有限的软件测试经历里,曾有一段专职的自动化测试经历。

接触自动化

那时第一次上手自动化测试,团队里用的是Python,接口自动化测试的框架是requests+Excel+Jenkins,APP自动化测试的框架是Appium。

整个公司当时有一款已有的APP,因此在试用期内,我的任务是完成对已有APP的自动化脚本编写和调试。

记得当时刚开始去,很没有经验,在跟功能测试同学了解了业务之后,只顾埋着头部署环境,突然有一天,测试主管问我,是否要输出一份自动化测试用例。我恍然大悟,于是把功能测试的用例拿来参考了一下,对用例做了一次筛选,输出了一份自动化测试用例(现在回过头看,当时的做法真的很草率,既没有一个自动化测试计划,也没有对自动化用例做评审,只知道功能测试同学的痛点就是迭代太快,回归来不及做)。

用例输出后,大概花了一个月的时间,完成了环境部署和基本用例脚本的编写,那时候大概实现了四五十个场景,并且完成了自动发送测试报告。剩下的两个月,我就一步一步的将场景扩充为二百多个。

其间也遇到了一些问题,比如登录图形验证码的获取,不过使用OCR图形识别很快就得到了解决,同事也有使用云打码一类的平台。

最大的一个问题是,当APP版本更新迭代后,固定页面所有的id、class等属性都会变化,因为这些都是写死在代码里的,如果要更改意味着每个page都要更改,工作量非常之大,而且获取这些属性还需要借助一些工具,如UI AuTomatorviewer 、Appium自带的Inspector。

在忙碌了一段时间后,先找到一个安卓开发,跟他排查了一下,他也找不到问题所在,后面又找了另一个开发,他排查之后发现是安卓混淆打包的问题,他给我出了一个不做混淆打包的APP,这才解决了这一问题。

另外一个比较大的问题是,APP自动化测试的运行时间非常久,我们两三百条用例,如果加上失败重试,大概要跑四五个小时,而且还会出现中间脚本出错运行停止的问题。

记得一个印象比较深的事情是,我们第二天要发版了,头一天下班前我开始跑脚本,等到晚上我一直没有收到测试报告的邮件,于是晚上十点多赶回公司,发现自动化脚本已经停止了。

对于时间久的问题,后面我尝试引入UI AuTomator2(以下简称u2)框架来代替Appium,毋庸置疑,u2在执行速度上有很大优势。

我曾经对比过这两个框架,同一个场景,Appium需要耗时60多秒的,u2只需要20多秒,足足节省了三分之二的时间。

但随之而来新的问题是,u2不太稳定,Appium中查找元素有用到显式等待、隐式等待和强制等待,而u2中看似不需要这些,实际上多跑几遍场景就会发现u2执行太快会找不到元素,因此还得手动加上强制等待。这样一来时间并没有节省多少。

这个问题当时没有得到解决,反而是在我离职后的一段时间里,通过学习pytest-xdist的文档,发现pytest-xdist可以基于ssh和socket来实现分布式执行。

举个例子,假如有200条场景,同时启动2个执行机,那么就会往执行机-1上推送100个场景,往执行机-2上推送另外100个场景,最终两个执行机的测试报告会集成为一个报告。这样的解决方案如果当时能应用到实践中,那么APP自动化测试时间过长的问题会得到完美解决,唯一需要注意的是,每个场景要独立,不能相互依赖。

话说回来,APP自动化测试做下来好像没有产生多少收益,因为只有我一个人开发和维护,所以到了维护阶段就显得耗时耗力,特别是本来一个固定的页面改了或者中间插入了一套新的逻辑,就意味着相当多的页面需要调整。

第二次接触项目

差不多这样做了几个月后,公司开始立新的项目,新的项目一开始就下决心要做接口测试,因此我又介入到这个项目中,参加立项会议、参加技术评审,了解了要做哪些,并且接口文档怎么管理,接口怎么定义等等之后,就开始了新项目的接口测试。

那个阶段,使用requests读取Excel的方式在接口不多的时候还挺方便,因为代码框架比较固定,只需要Excel里修改参数。

但随着接口越来越多,也意味着接口之间的依赖越来越多,Excel管理简直就是灾难,在Excel里要理清不同接口的依赖关系,是非常头痛的一件事。

后来我使用Postman做了一些快速测试,等待时间充裕的时候,再慢慢把整个主流程的接口测试加上。在接口测试阶段,前前后后发现了一些问题,但很大的不足是没有解决Excel存储数据的问题和没有做数据正确性的校验。

而且我们还是和支付相关的业务,这使得接口测试结果只能保证服务是正常的,返回码是正常的,但是数据是否正确无从得知。

直到后来,自动化团队换了一批人,新来的同事开始推行Java栈,使用Springboot+httpclient+Maven来作为接口自动化框架,基本舍弃了之前的Python自动化脚本。

那几个月好几位同事投入到同一个项目的接口自动化脚本的编写中,对比之前我一个人负责两个项目的自动化,情况的确好了很多。

这个自动化也是基于场景的,有做正常和异常输入的校验,以及最后的入库检查,脚本量非常大,所有异常场景的请求数据和期望结果都是入库的,后续请求的时候,先从数据库拿到请求数据发送请求,得到响应结果再和数据库的期望结果做比较,正常场景需要手动写逻辑,响应结果里重要字段的值和数据库里的值做比较。

那个时候,考虑了很多前端无法测到的复杂的场景,并发、幂等之类的,因此发现的缺陷更有意义一点,但是维护成本依然比较高。

自动化是什么?

最近的一两年,我有时会想到自动化测试是什么?自动化测试本来是为提高测试效率而生,有时候使用不得当,却成为测试活动中的累赘。

但不可否认的是,自动化测试仍然是行之有效的,区别只是使用的动机和使用的方式,在我看来,做好自动化测试需要规避以下几点:

1. 不要为了自动化为自动化

自动化测试不能基于KPI,而要看当前的项目适不适合做自动化,有没有足够资源的投入和外部团队的配合。

2. 自动化不是万能的

不要贪多求全,妄想所有的测试场景都能通过自动化实现,尤其是更新迭代快的项目。能把稳定的功能实现,并且做好回归 ,已经足够了。

3. 自动化的场景

一种是基本场景,另一种可以是前端无法实现的场景。

而对于接口中无穷无尽的字段进行严苛的异常校验,来保证足够程序足够健壮,有时候反而没有那么必要。

因为开发周期短的公司一周好几个版本,开发根本就没时间对一些不太重要的字段做异常处理,当然重要字段的类型、长度、非空校验等还是要做。

4. 对自动化的认知

有些同行认为,自动化就是为了发现缺陷的,但是自动化发现的缺陷根本比不上功能测试,发现不了缺陷的自动化就没有意义吗?

事实并非如此,尤其是一些回归测试的自动化,一方面是为了提高效率,一方面是为了增强上线前团队的信心。

5. 团队人才的培养

遇到了一些公司,好不容易做起了自动化,做得也不错,等到负责人离职之后,就没人维护了,然后再招一些自动化测试人员另起炉灶,反反复复,归根结底是没有人做技术备份。

责任编辑:赵宁宁 来源: 今日头条
相关推荐

2011-04-18 12:52:37

自动化测试功能测试软件测试

2012-02-27 17:34:12

Facebook自动化

2022-12-26 12:30:28

接口测试

2009-03-21 19:21:22

2022-02-17 10:37:16

自动化开发团队预测

2022-02-08 09:00:00

智能自动化人工智能RPA

2024-01-08 13:31:00

Rust自动化测试

2023-03-27 15:37:43

自动化测试开发

2019-02-15 15:50:10

工程师软件测试开发

2022-05-10 11:18:42

自动化测试软件测试

2022-06-08 14:22:55

自动化测试测试

2019-07-18 11:00:45

自动化运维测试

2011-12-23 17:09:57

自动化测试

2012-12-19 09:36:49

测试自动化测试

2014-04-16 14:15:01

QCon2014

2012-12-24 22:54:31

2021-06-30 19:48:21

前端自动化测试Vue 应用

2017-04-10 12:25:32

iOS自动化测试

2023-06-28 15:12:33

2023-11-01 10:18:10

自动化测试工具
点赞
收藏

51CTO技术栈公众号