# AirtestSupportLib

**Repository Path**: ray0728/airtest-support-lib

## Basic Information

- **Project Name**: AirtestSupportLib
- **Description**: 基于airtest，opencv的控件捕获库
- **Primary Language**: Python
- **License**: Not specified
- **Default Branch**: master
- **Homepage**: None
- **GVP Project**: No

## Statistics

- **Stars**: 1
- **Forks**: 2
- **Created**: 2021-04-28
- **Last Updated**: 2023-08-14

## Categories & Tags

**Categories**: Uncategorized

**Tags**: None

## README

# Airtest Support
  2019年第一次接触Airtest的时候，很兴奋，因为它让我看到一个“可能性”。可以解决自动化测试原生痛点的可能性。但是随着实际使用的深入，发现网易发布出来的Airtest，体验上并不友好。比如运行时间长，特定场景下匹配误差率高，多次运行还存在稳定性问题（现在也可能得到了改进）。但是长期困扰项目组的自动化痛点问题，仍然希望能通过Airtest解决。所以为了能顺利普及，开始针对实际业务编写私有的support库，用来辅助Airtest更好的运行。

## 目标
  期望基于此构建一个可自动遍历APP，并依据测试策略自动开展测试执行的脚本工具。

## 当前状态
  当前已初步实现对Android App界面的自动遍历。可自动寻找界面上可操作控件（可点击或可编辑），并自动做出对应的操作（并可对外暴露回调接口）。

## 代码结构
|-- test.py  演示代码\
|--|-- support\
|--|--|-- app\
|--|--|--|-- ui\
|--|--|--|--|-- analysis.py 对Activity解析类，大部分比对均在此完成\
|--|--|--|--|-- confidence.py 图像比对算法调用类，提供多种比对算法\
|--|--|--|--|-- const\
|--|--|--|--|--|-- state.py 全局参数类，运行所需各种参数均在此\
|--|--|--|-- manager.py 管理类，外部调用接口均在这里\
|--|--|-- dbms\
|--|--|--|-- helper.py Sqlite数据库操作接口\
|--|--|-- logging\
|--|--|--|-- log.py 输出日志管理类\
|--|--|-- system\
|--|--|--|-- device.py 基于adb命令提供简单操作\
## 关于自动化痛点问题
  测试执行其实就是根据既定策略，对被测对象反复多次操作并观测记录操作结果。换句话讲就是“体力活”。而IT行业，特别是以软件为主的IT行业迭代更新速度快，这就意味着需要测试人员能快速反馈本轮迭代周期内的功能质量。虽然可以通过测试策略圈定本轮测试范围，但是测试人员的任务却并不轻松。一方面有大量需要执行的测试任务，另一方面还有能提高测试质量的测试设计需要完成。

  在项目交付前期，交付的功能很多，迭代速度快。而产品经理又希望在这个阶段能最大限度暴露产品问题，防止问题流出到后端。所以这个阶段是测试压力最大的时候。

  再来看被寄予厚望的自动化呢？自动化确实很不错，将人力释放出来，而且可以7×24小时不间断执行。但是这一切都是有前提的，那就是得提前准备好**可用的**自动化脚本。别小看了这个“可用”，在如今快速迭代的时代，软件版本也在不断的经历**“研发”-“验证”-“研发”**的过程（参见DevOps）。所以在上个版本还运转很溜的自动化脚本可能到这个版本就不行了，更何况在上一个版本周期内能否输出这个“脚本”还是个疑问呢，毕竟测试任务在这个阶段太重了。

  经过测试经理不断劝说，老板不断被频频爆出的质量问题打脸，终于同意成立专职的**自动化小组**来做自动化脚本适配工作。这样脚本由专职人员负责输出。测试人员专注在测试执行上。听上去是不是很美好？但是事实却很残酷。因为自动化脚本有两大特征。

- 时效特征

  自动化脚本编写的过程是将测试步骤代码化的过程，此过程也可看做是另一种“手工测试”方式。既然是测试过程那么也可以认为当脚本交付的时候，该脚本能发现的产品问题已充分暴露（脚本交付意味着脚本所有执行的结果均符合预期，这样才能证明脚本自身无问题）。此时在用于产品测试是无法发现更多功能性问题（时序性问题不属于此）。

- 测旧特征

  测试老旧（过去已有，且未变化）功能是否发生回退。对于新交付的功能，由于并无对应的自动化脚本适配，所以无法进行测试。

  有如此两大特征就意味着在项目最忙，最需要暴露问题的阶段（项目初期以及早期迭代期），自动化脚本的作用其实也仅仅是保证新引入问题导致没有老旧功能回退而已。这也是为什么项目组投入大量人力在自动化建设上，但项目组却始终感受不到相应的收益。