Appium 自动化入门：为什么要从线性脚本走向 POM 分层
问题背景
刚开始做 App 自动化时，最自然的写法通常是线性脚本：打开应用、定位元素、点击、输入、断言，全部写在同一个文件里。这种方式上手快，但一旦场景变多，问题也会跟着出现：
- 元素定位、操作步骤、断言逻辑混在一起；
- 登录、搜索、跳页这些流程反复复制；
- 一旦页面改版，需要在多处同步修改；
- 用例变多后，几乎很难判断“哪个部分该改、哪个部分该复用”。
线性脚本的问题到底出在哪
线性脚本不是不能用，而是只适合两个前提：
- 场景很少；
- 代码只需要临时验证，不打算长期维护。
一旦测试目标变成下面这些，线性脚本就会开始吃力：
- 同一个登录流程要被很多用例共用；
- 一个输入框既要测正常输入，也要测空值、非法值、边界值；
- 页面元素定位可能变化；
- 测试数据不再只有一组；
- 报告里需要清楚展示步骤和失败位置。
POM 在这里真正解决什么问题
这里说的 POM，不只是“Page Object Model”这个名词，更重要的是职责拆分思维。
当前这套材料把它拆成三层：
page：界面元素定位；object：步骤函数或关键字封装；module：测试流程组织和断言。
这种拆法的价值在于：
- 页面定位变了，优先改
page； - 动作步骤变了，优先改
object； - 场景流程和断言变了，优先改
module； - 测试数据变了，尽量不改流程代码。
从脚本到框架，最小迁移路径是什么
刚开始整理自动化代码时，通常不需要先把整套框架搭完整。更自然的迁移顺序是：
- 先写线性脚本，确认自己能把流程跑通；
- 把元素定位抽到 Page 层；
- 把点击、输入、等待这类基础动作抽出来；
- 把登录、搜索这类完整业务步骤封成关键字；
- 再把 Excel 或 YAML 引进来做数据驱动和配置化。
Tip
很多初学者的问题不是“不会写框架”，而是太早想写框架。先把流程跑通，再做分层，学习曲线会平很多。
这套分层最适合什么场景
这套 page -> object -> module 结构特别适合这几类场景：
- 登录、注册、搜索、表单填写这类重复性高的流程；
- 需要多组测试数据反复执行的场景；
- 需要把 UI 操作和断言拆开的用例；
- 希望后续接入 Allure、Excel、YAML 的项目。
一个简单判断标准
如果当前的自动化代码已经出现以下现象，就基本可以开始做 POM 拆分了：
- 同一个定位重复出现三次以上；
- 同一个步骤顺序在多个用例里复制；
- 新增异常场景时，要复制整段代码再改两行；
- 已经开始分不清“这块是页面问题、动作问题还是断言问题”。
小结
线性脚本适合入门，POM 分层适合维护。真正值得学的，不只是分三个目录，而是学会把“元素、动作、流程、数据、断言”分开思考。