一、框架介绍
1、框架组成
通过 Python+Unnitest+Airtest+Poco+HtmlTestRunner 构建框架，支持 iOS 和 Android 两端，支持通过元素属性、路径和图片识别查找元素，实现一键执行并输出测试报告。

2、框架目录结构
暂时无法在飞书文档外展示此内容

3、设计模式
框架采用分层的 page-object 设计模式，包括对象层、逻辑层和业务层。

• 对象层

#元素
@classmethod
def remit_detail_account(cls):
    return poco(name="XXX") 

• 逻辑层

# operate=1:click 2:exists 3:getText 4:setText 
@classmethod  
def page_operate(cls, element, operate=1): 
    if operate == 1: 
        element.click() 
    elif operate == 2: 
        if element.exists(): 
            return True 
    elif operate == 3:  
        return element.get_text() 

• 业务层

def test(self):
    #登陆
    testFunction.poizon_login(globalparam.mail, globalparam.password)
    sleep(1)
    #判断我的买卖、卖家中心、我的鉴别是否存在
    flag =basePage.page_operate_exists(basePage.my_identify(), basePage.sellerCenter())
    assert_equal(True, flag)

通过 PO 的分层设计模式，使得代码层次清晰，控件元素在工程中仅维护一次即可，提高了复用率，降低维护成本。

4、国际化方法使用
APP 支持多种语言，需要让同一套脚本可以在所有语言中正常执行。按照传统方法一个控件，需要根据语言的不同维护多种元素。为了提高编写和维护效率，借助翻译平台提供的翻译数据，使用 Python 的国际化方法，实现通过翻译 key，匹配所有语言的控件，无需手动维护，显著提高了编写效率、降低维护成本。

从过往经验来看，一个长期稳定运行的自动化项目，维护成本占整个自动化生命周期的 90% 以上的时间，所以在构建框架时，设计模式、元素维护、测试数据的单独管理、公共方法的封装等，都是出于维护成本的考虑。

二、实施过程

1、识别 UI 自动化场景
在框架确定好之后，找到 UI 自动化的切入场景变得尤为关键。UI 自动化适用于长期迭代、功能相对稳定的项目，偏向前端交互的场景。适合 UI 自动化的场景，脚本在编写和维护时能达到事半功倍的效果，反之不适合的场景覆盖自动化就会变得事倍功半。

2、场景覆盖优先级

• BVT case 优先级最高。从 BVT 用例识别适合 UI 自动化的 case，通过和接口自动化交叉覆盖的方式，实现最大限度的 BVT 自动化覆盖效果；
  
• 线上问题 亡羊补牢犹未为晚。从线上问题识别出适合 UI 自动化的场景，通常线上问题可以举一反三，进而补充自动化脚本的场景或断言点；
• 主链路场景 包括重点场景、资损场景、根据埋点数据识别的高访问量的模块、全量用例集高复用率脚本等。

3、脚本编写
UI 自动化脚本通常来讲编写简单，复杂逻辑很少，但是想编写出高质量的 UI 自动化脚本，需要注意以下事项。

脚本设计
a、自动化 case 业务件互相解耦；b、自动化 case 环境的解耦，执行脚本前进行初始化，如在 setup 方法中先 stop_app，再 start_app。

编写规范
按照框架的设计，对元素进行封装、必要的方法进行封装等

脚本命名
通过脚本名称，能明显识别出脚本覆盖的模块，方便后续对报告的检查、对脚本的维护

断言标准
采用相对稳定的元素进行断言，为了降低维护成本，尽量避免采用图片进行断言

元素识别优先级
元素属性 > 元素绝对路径 > 图片识别

公共方法的封装策略
对于重复使用到的步骤，尤其是前置的入口类操作，进行封装，降低维护成本
多地区功能不一致、脚本区分测试和预发环境

通过装饰器、全局参数进行控制

注释
为了能最短时间定位到问题，建议 UI 的每一步操作都添加注释

外部接口支持
特定场景，UI 脚本和接口配合能达到高效、稳定的结果，如注册、注销、登录场景需要验证码接口的支持

脚本执行数据初始化
如收藏、出价等，操作后要有相应的取消操作，保证脚本的稳定性同时，对逆向场景也进行了覆盖

4、投入成本

• 开发成本：从测试用例中识别自动化场景，构建自动化测试用例，编写脚本、调试脚本等；
• 运行成本：通过各种开关配置执行地区、执行语言、执行环境后，一键触发批量执行所有自动化 case，以及执行后的结果收集。测试报告中会附带执行结果、断言时的截图、错误时的日志等，通过以上信息人工确认是否有 bug；
• 维护成本：业务流程有变更时，在脚本中更新业务逻辑；元素有变更时，在 page-object 或公共方法中重新维护元素即可，不需要到具体的 case 中逐一修改元素。 提效人日计算公式: M * N * 2 * 3 * K

M：用例总数
N：单个 Case 执行固定时长 30 秒
J：ios、android 两端、每迭代在冒烟、集成、预发至少执行一次
K：变化因子 [0.8 - 1 ] 考虑 case 维护、调试成本

三、阶段性成果
ios&android 两端总计脚本 200 条左右，覆盖 360+ 条 BVT&功能用例，成功率 95% 左右