一. 业务背景介绍
本例是以扫地机器人展开的,其中有一个功能是APP点击“立即升级‘按钮,扫地机会开始固件版本的升级(固件版本:指扫地机内置的算法版本)
1.人工测试痛点
测试1次升级需要1min30s–3min (视型号和固件版本大小有所不同),升级是发版必测项,为了测试其稳定性需要长时间不间断测试,非常耗费人力
2.自动化业务需求
长时间进行循环升级功能测试,并可以输出结果,如果失败需要提供时间节点和失败截图
二. 测试脚本流程梳理
- 模拟用户点击立即升级按钮 ——uiautomator2
- 升级完成后确定扫地机器人是否在线 ——接口请求获取
- 测试用例需要设置断言(我这边是判断升级前检测到的最新版本和升级后的当前实际版本是否一致) ——接口请求获取升级前和升级后
- 以上所有业务接口传入值必须有cookies,所以必须请求登录接口获取 ——接口请求
- cookies值在重新登录后ssid会变化 ——抓包获取后替代
——后面是我们的实现方式
三、测试前提
先考虑正向单一情况,实现脚本可以正常运行,主要点如下:
- 登录后不退出,保证cookies可正常使用(我们的目的是测试升级,所以登录只是为了让我们获取到cookies信息即可,不对其进行循环测试)
- 建立一个单独的测试账号,该账号下绑定一台待测设备
- 开始运行脚本前保证待测设备在线
- 后台提前配置好循环升级版本
四、框架搭建
由《二、测试脚本流程梳理》我们可以看到,大部分实现是需要接口请求获取的,而这些接口又需要多次调用,为了代码复用性更高,我们将采用POM思想来封装框架。