Appium 自动化框架进阶：YAML、Allure 与读书屋搜索案例
当前面的分层和数据驱动已经跑起来后，接下来最自然的问题是：
- 配置和步骤是否可以继续外置；
- 报告是否可以更清楚；
- 搜索这种比登录更复杂的功能，能不能沿用同一套思路。
这篇就聚焦这三件事：YAML、Allure，以及“读书屋搜索”案例。
YAML 为什么经常出现在自动化框架里
YAML 的优势不是“更高级”，而是很适合表达结构化配置和步骤数据。
基本规则
- 大小写敏感；
- 用缩进表示层级关系；
- 不能使用 Tab 缩进；
#可以表示注释；- 字符串可以不加引号。
常见数据形态
数组序列
YAML
- admin1: 123456
- admin2: 111111
- admin3: 222222
纯量
YAML
n1: 52.10
n2: true
n3: false
n4: ~
键值对
YAML
user: admin
pwd: 123
job:
- teacher
- nurese
混合结构
YAML
- user: admin1
psw: '123456'
- user: admin2
psw: '111111'
这些形态说明 YAML 很适合放：
- 账号密码；
- 运行环境；
- 测试步骤；
- 断言参数；
- 数据库配置。
Pytest + YAML + Allure 组合起来意味着什么
当 YAML 被引入后，它不只是另一种数据文件，而是在把测试脚本往“配置驱动”推进。
当前材料里，这套组合大致分工如下：
Pytest：负责执行、参数化、fixture、断言；YAML：负责配置和步骤数据；Allure：负责报告和步骤可视化；Appium：负责移动端驱动；- 关键字层：把 YAML 步骤翻译成具体动作。
关键字类为什么是这一步的核心
材料里的 Keywords 类把很多动作和断言收口在了一起。
输入和点击
PYTHON
class Keywords:
def __init__(self, driver):
self.driver = driver
def input_context(self, **kwargs):
if kwargs["定位方式"].lower() == 'id':
kw = (AppiumBy.ID, kwargs["目标对象"])
if kwargs["定位方式"].lower() == 'xpath':
kw = (AppiumBy.XPATH, kwargs["目标对象"])
self.driver.find_element(*kw).send_keys(kwargs["数据内容"])
def option_click(self, **kwargs):
if kwargs["定位方式"].lower() == 'id':
kw = (AppiumBy.ID, kwargs["目标对象"])
if kwargs["定位方式"].lower() == 'xpath':
kw = (AppiumBy.XPATH, kwargs["目标对象"])
self.driver.find_element(*kw).click()
等待和截图
PYTHON
def wait_sleep(self, **kwargs):
time.sleep(int(kwargs["数据内容"]))
def 截图(self):
allure.attach(
self.driver.get_screenshot_as_png(),
"截图快照",
allure.attachment_type.PNG
)
文本断言、SQL 断言、比较器
PYTHON
comparators = {
'>': lambda a, b: a > b,
'<': lambda a, b: a < b,
'==': lambda a, b: a == b,
'>=': lambda a, b: a >= b,
'<=': lambda a, b: a <= b,
'!=': lambda a, b: a != b,
'in': lambda a, b: a in b,
'not in': lambda a, b: a not in b
}
这类封装最有价值的地方在于：
- YAML 里的动作可以映射到关键字方法；
- 不同业务场景共享同一套底层能力；
- 截图、文本断言、数据库断言都可以统一接到 Allure。
读书屋搜索案例为什么值得单独拿出来
登录场景更适合理解 POM 拆分，而搜索案例更适合理解“框架如何扩展”。
当前材料里，搜索主要有三类场景：
- 输入不存在的书名，搜索结果为空；
- 输入存在的书名，做精确查询；
- 输入部分关键字，做模糊查询。
线性实现里，先做搜索动作：
PYTHON
driver.find_element(AppiumBy.ID, 'com.zhao.myreader:id/iv_search').click()
driver.find_element(AppiumBy.ID, 'com.zhao.myreader:id/et_search_key').send_keys('九重华锦')
driver.find_element(AppiumBy.ID, 'com.zhao.myreader:id/tv_search_conform').click()
再把页面结果和数据库结果做对比：
PYTHON
bb = []
eles = driver.find_elements(AppiumBy.ID, 'com.zhao.myreader:id/tv_book_name')
for pg in eles:
bb.append(pg.text)
l1 = list(set(bb))
l2 = list(dbmysql("SELECT book_name FROM book WHERE book_name ='九重华锦';"))
assert l1 == l2
这个案例的价值在哪
- 它说明自动化测试不仅是 UI 点击；
- 还可以验证前端展示和数据库结果是否一致；
- 也说明搜索功能完全可以沿用登录时那套 Page / Object / Module 的拆分方式。
如果继续做实，这篇后面最值得补什么
Question
这篇目前更像框架升级路线图，还不是完整实战文。最值得补的是证据和样例。
优先级最高的补充项：
- 真实 YAML 文件样例；
readyaml的具体读取方式；- Allure 报告截图；
- 搜索功能的 Page/Object/Module 目录结构；
- SQL 断言与 UI 断言如何在报告里对应展示。
小结
这一阶段真正重要的，不是又多学了几个工具名，而是开始把配置、报告和复杂业务场景纳入同一套框架视角里考虑。
它把三个问题放在了一起：
- YAML 让配置和步骤更结构化；
- Allure 让执行过程更可读；
- 搜索案例说明这套设计不是只对登录有效，而是可以迁移到更复杂的业务场景。