背景

目前项目节奏一月可能 2～4 个版本，每次发版都是需要进行回归测试，回归用例大概 300 条左右。而且项目基本都是已客户端为主，基本都是改动不是很大，算是优化和新增功能，老功能都很稳定不变的。针对于这种情况来说，做自动化再好不过了。

实现

使用 appium+python 这算是比较大众的方式了，采用关键词驱动的方式，就是用中文汉字去驱动执行操作。
当初选择这种方式是因为不想写代码，其次看起来比较方便易理解用例。
只需要录入元素 和编写用例就可以完成。数据都存储到 yaml 文件中。
录入元素内容是这样：

用例内容是这样的：

当需要使用的元素全部录入，就可以这样的方式去写用例，验证方式目前使用的是：元素是否存在、文案是否一致、图片对比等。

对于结果本地会生成一份 html 包函结果数据，可以查看验证结果图，还有操作视频。

到这里基本就实现了自动化了，问题是目前还是单机游戏，结果没有汇总没有统一查看位置，没有与回归用例进行关联。

基于我们目前的情况，回归用例是在 MeterShpere 中执行的。就在脚本中封装了一层基于 MeterShpere 请求的方法。

然后保证了在平台上的用例名称与脚本名称一致，在创建回归用例后拿到计划 id 与脚本绑定，跑完的自动化用例会把结果打在回归用例计划上。

对于回归层面上，个人觉得算是到位了，也想了解下大家对于回归用例的想法，方便丰富下当前项目。

阶段 0～1 的过程是这样的，在做成果分享的时候，也汇总了一些问题和后续的想法，目前正准备 2 阶段，目前状态大概是 1～5 的过程。

对于 1 阶段的问题：

1、硬件设备导致的各自的电脑环境搭建问题，其实也还算好。
2、用例收集到一起去跑会发现，用例间的兼容问题，这也是没有想到的，比如：因为 A 测试执行的用例产生的数据，导致 B 测试在执行用例数据影响无法获取操作元素的情况。
3、持续稳定去跑，不仅是在回归阶段，那么单机模式就不适合了

对于上面问题，目前想到的是申请一台设备单独当服务器去执行。

阶段 2

基于平台的方式去运行脚本，目前只写了一个 demo。想分享下个人思路，还有大家对这方面的建议。


方式还是基于脚本执行，只是封装了一层 web 页面去调用脚本执行方法。测试小伙伴就可以通过局域网访问这台设备去执行自动化。

但是如果单纯的执行自动化用于回归，有些浪费这台设备了，所以想到了持续执行。
每晚去打最新的包去跑一遍自动化用例。

通过定时任务调用 jenkins 打包，然后执行全部用例。可以做到不必在发版当天去执行了，也算是做好提前的打算。这里只跑结果，不与回归用例关联的。只有回归测试时才会关联回归用例。

2 阶段内容大概就是这样的，还请大家可以交流起来，看后续有什么要做的，之前做 UI 自动化基本都是停留在 1 阶段，没有后续的持续集成相关的经验，这次算是弥补这块空缺了，还请大家给出建议。