目前项目节奏一月可能 2~4 个版本,每次发版都是需要进行回归测试,回归用例大概 300 条左右。而且项目基本都是已客户端为主,基本都是改动不是很大,算是优化和新增功能,老功能都很稳定不变的。针对于这种情况来说,做自动化再好不过了。
使用 appium+python 这算是比较大众的方式了,采用关键词驱动的方式,就是用中文汉字去驱动执行操作。
当初选择这种方式是因为不想写代码,其次看起来比较方便易理解用例。
只需要录入元素 和编写用例就可以完成。数据都存储到 yaml 文件中。
录入元素内容是这样:
当需要使用的元素全部录入,就可以这样的方式去写用例,验证方式目前使用的是:元素是否存在、文案是否一致、图片对比等。
对于结果本地会生成一份 html 包函结果数据,可以查看验证结果图,还有操作视频。
到这里基本就实现了自动化了,问题是目前还是单机游戏,结果没有汇总没有统一查看位置,没有与回归用例进行关联。
基于我们目前的情况,回归用例是在 MeterShpere 中执行的。就在脚本中封装了一层基于 MeterShpere 请求的方法。
然后保证了在平台上的用例名称与脚本名称一致,在创建回归用例后拿到计划 id 与脚本绑定,跑完的自动化用例会把结果打在回归用例计划上。
对于回归层面上,个人觉得算是到位了,也想了解下大家对于回归用例的想法,方便丰富下当前项目。
阶段 0~1 的过程是这样的,在做成果分享的时候,也汇总了一些问题和后续的想法,目前正准备 2 阶段,目前状态大概是 1~5 的过程。
1、硬件设备导致的各自的电脑环境搭建问题,其实也还算好。
2、用例收集到一起去跑会发现,用例间的兼容问题,这也是没有想到的,比如:因为 A 测试执行的用例产生的数据,导致 B 测试在执行用例数据影响无法获取操作元素的情况。
3、持续稳定去跑,不仅是在回归阶段,那么单机模式就不适合了
对于上面问题,目前想到的是申请一台设备单独当服务器去执行。
基于平台的方式去运行脚本,目前只写了一个 demo。想分享下个人思路,还有大家对这方面的建议。
方式还是基于脚本执行,只是封装了一层 web 页面去调用脚本执行方法。测试小伙伴就可以通过局域网访问这台设备去执行自动化。
但是如果单纯的执行自动化用于回归,有些浪费这台设备了,所以想到了持续执行。
每晚去打最新的包去跑一遍自动化用例。
通过定时任务调用 jenkins 打包,然后执行全部用例。可以做到不必在发版当天去执行了,也算是做好提前的打算。这里只跑结果,不与回归用例关联的。只有回归测试时才会关联回归用例。
2 阶段内容大概就是这样的,还请大家可以交流起来,看后续有什么要做的,之前做 UI 自动化基本都是停留在 1 阶段,没有后续的持续集成相关的经验,这次算是弥补这块空缺了,还请大家给出建议。