第一节-UI自动化测试-项目方案调研

第一节-项目方案调研

一、自动化测试的追求是什么？

自动化脚本跑起来->将脚本覆盖率输出到极致->做工具、建平台？
在我看来，自动化测试的终点是将自动化的实施实际产生有高效益的结果，也就是投入回报率。

二、ROI 定义

显而易见，如果脚本使用频次低，实际上单次手工测试的成本更低些，但重复的内容测试频次增加，相对而言自动化测试效益将倍数提升。在此看来，只要ROI大于1便说明自动化的实施是成功的。

三、本方案在什么背景下立项？

公司的应用包含微信小程序、web后台、APP，前端的发布节奏是按周维度，固定有两个工作日为特定发布窗口，在发布前会迭代会经历测试环境测试->验收->灰度体验版本集成验收->灰度体验版本集成冒烟回归。在此流程中，灰度体验版本集成冒烟回归节点回归内容基本为增量重复工作，比如微信小程序的发版手工单轮的冒烟回归时间为1-2h，机器化测试按月度来计算效益情况约为：1.5人天。如果能将APP、web各系统都能推动完成落地，效益情况将倍数输出。
前端中心化组织结构迭代频繁，因而小优化也相对较多，在有限的测试资源情况下，部分优化项目由前端开发同学自测验证上线，前端同学自测针对性强但对交互业务回归重视度低，第二方兼容问题频出。
在该背景下，暴露了几个问题：
1.固定重复的集成冒烟测试投入。
2.对于比较枯燥的测试执行工作，背后可能产生测试颗粒度的不均匀。
3.排班测试人员测试习惯不同，人工覆盖可能存在主观遗漏。
4.开发同学自测版本，稳定性保障较弱。

四、影响ROI的几个因素

上文提到回报率，影响回报率的因素主要是以下几个：
1.脚本的稳定性。
2.被测系统代码变更引起的维护成本如果降低
3.脚本是否支持跨操作系统、平台。
4.脚本的数据管理，环境复用率。
5.检测出问题后的诊断效率。
6.脚本的输出难度、输出效率。
7.自动化使用推广。

五、工具对比

提炼出几个关键点：支持跨端、支持跨环境、脚本编写门槛低、维护成本低、问题诊断效率高、自动化测试在团队的影响力。
结合以上，第一迭代引入了airtest工具，自定义封装了工具能力，通过抽象pageObject，各线测试团队公共维护页面元素。在此迭代中，脚本的运用场景主要还覆盖在测试环境各类核心主流程的回归测试。在持续的回归测试途中，通过对脚本维护的频次数据中发现，因变更引起的维护次数较高，且维护时间成本也不低，且图片在项目中空间占用也非常严重，导致远程执行传输项目时间持续拉长。

在此之上，借鉴图片对比的思路，引入了ocr库，将对组件的点击、文字、数字的校对能力进行了二次升级。通过对截取图片中文字提取，拓展了新了定位方式—基于文字相对坐标位置定位方法。图片组件维护去化率接近90%，脚本维护成本降低80%以上，往往只需要改动定位的文案内容即可。
设计概要：

本文讲述了我对过往自动化实施的理解，简单描述了下过往的解决方案。后续会在此方案的基础上优化一个骨架版本。
1.提升ocr的识别效率
2.将模块化、节点化形成配置
3.脚本case使用配置替代.py，实现关键字驱动