接触自动化
在我第一次接触自动化测试，团队里用的是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自动化测试做下来好像没有产生多少收益，因为只有我一个人开发和维护，所以到了维护阶段就显得耗时耗力，特别是本来一个固定的页面改了或者中间插入了一套新的逻辑，就意味着相当多的页面需要调整。
这是我整理的《2024最新Python自动化测试全套教程》，以及配套的接口文档/项目实战【网盘资源】，需要的朋友可以下方视频的置顶评论获取。肯定会给你带来帮助和方向。
【已更新】B站讲的最详细的Python接口自动化测试实战教程全集（实战最新版）
扫一扫
644
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
