传统的适配方法有两种:第一种我们通过制作多个账号、然后使用这些账号去登陆、再由外包同学扫码、通过人工比对的方式去判断我们的页面兼容性是否良好,第二种是通过我们制作不同的mock码去模拟各个状态、再有外包同学扫码通过人工对比去完成兼容性适配。无论哪种方案对于我们这种多状态、多机型、多app的X乘场景都是工作量巨大、耗时耗力的。其次对于一些扫码功能隐藏得很深甚至没有扫码能力的app比如“美图秀秀”更是变得无能为力。
详细设计
▐ 设计思路
我们该如何去解决这些问题呢?首先我们分析问题所在的业务特性,我们的业务横跨多个端,淘宝、支付宝、优酷这样的的一方二方app,甚至抖音、头条、快手、微信这样的三方app,那么我们基于客户端能力的方法就失效不通用了;其次我们的业务横跨了多个技术栈,H5、小程序、WEEX、轻应用,那么我们基于浏览器能力的方法也会变得无力,所以我们需要一种不依赖于客户端不依赖于技术栈的解决方案。
我们同多个团队同学进行了沟通和调研,发现有两个技术现在正在逐渐发展成熟,一是真机技术、二是视觉技术。真机技术使得我们可以通过代码命令调度机器去完成很多事情,比如:截屏,录屏,滚动、点击、输入甚至文件操作、APP操作等。视觉技术随着opencv和机器学习的发展,图像识别、文件识别等能力变得比较成熟,并逐渐可以被作为判断标准使用,于是我们有了去构建一个以真机和图像为基础的自动化框架的思路,这样的一个方案是与app无关、与开发技术无关的。
▐ 核心交互
这样的一套方案核心交互逻辑便为:首先使用adb命令去打开我们的应用页面,然后在通过adb去截屏,再通过图像识别出截屏中的元素和位置,之后就可以去断言或者根据识别结果判断下一步的操作,再通过adb去执行操作、截屏如此循环。
▐ 能力推导
有了这样的一个核心流程之后,我们还需要一些其他能力,才能使得整个方案能完整的跑起来,我们从功能性、稳定性、易用性三个方向去考虑这些能力该如何建设。
首先是功能性方面:对于那些没有扫码能力的app,我们需要借助adb+scheme去打开app,而每个app的scheme是不同的,所以我们需要借助业务以及技术的手段去构建一个scheme池,这里面涵盖我们业务所涉及的常用的scheme形式。
其次我们的业务多以人群和设备的维度呈现出不同的功能,所以我们需要去管理一个账号池和设备池,并能够让这些池子有个动态扩张、更新的机制,比如随着业务的发展,定时的去统计常用的机器,以扩展我们的测试设备池。
再者我们业务增长快、业务多状态交互,我们需要一套具备强扩展能力和动态性的解决方案去适应各种业务场景,我们选择构建一个js脚本解析器+一些通用的js api函数的组合形式,使得各个业务能够通过自定义脚本去定制自己的适配流程。
在机器的调度上,对于无登录或