框架总体
pytest+allure+appium 采用po分层设计集成到jenkins运行
框架结构
| 名称 | 作用 | 备注 |
|---|---|---|
| BasePage | 存放相应的封装方法 | 基类层 |
| Pages | 页面层用于元素的定位封装 | 页面层 |
| TestCases | 编写测试用例 | 用例层 |
| Report | 存放报告 | 报告层 |
| Public | 公共的调用方法 | 公共层 |
| Log | 日志存放位置 | 日志层 |
| Image | 用于存放失败的截图/图像识别等 | 图像层 |
| Config | 配置中心 | 配置层 |
| ExcelData | excel数据断言校验 | 数据层 |
| InstallApp | 根据jenkins传参来安装App | |
| * | 以上均为python的包模块，以下为独立文件 | * |
| conftest.py | pytest的精髓，易用难精通 | |
| pytest.ini | pytest的主配置文件 | |
| run.py | 运行主文件，配合接收jenkins传参 |
执行流程（简要）
协同保证
关于如何获取测试用例，及用例的存放点
初期编写UI自动化用例时，采用的是与相应的业务测试沟通询问测试用例，把已编写完成的用例做了标记并交回给业务测试，即便同业务测试人员沟通了哪些部分已完成但是到了后续持续迭代会遇到用例在不断的修改，如果仍采用此方式进行沟通，成本非常大，且不直观，无法完成实时协同工作
后续经讨论搬迁到了在线的钉钉文档，文档中规划了不同的模块，每个模块中包含了测开部分的职责和测试人员的职责，业务测试人员在在线文档进行编写修改维护用例，保证用例最新的，测开人员负责标注是否实现的自动化的覆盖
| 是否可实现自动化 | 是否覆盖 | 备注 | 优先级 | 用例名称 | 前置条件 | 测试步骤 | 测试结果 | 备注 |
|---|---|---|---|---|---|---|---|---|
| 0为否1为是 | 0为否1为是 | 有疑问测开备注 | P0 | 登录XXX | XXX | XXX | XXX | 业务测试人员备注 |
部分场景会存在个别步骤无法实现的情况，需与业务测试沟通好
测开人员与测试人员使用不同的颜色进行标注
对于测试用例的覆盖率统计即可根据excel文档的下载，通过代码计算统计，传入数据库，通过Grafana展示各个模块的数据
接下来的内容：
【iOS自动化测试】第四章：实践运用