早上，看到一篇关于自动化测试的文章，其中讨论了项目早期的UI自动化测试的问题，以为“自动化测试在早期不可行”，甚至自动化测试无用论。测试也是软件质量战略的重要环节，为此，几个方面讨论下，早期项目中，如何引入自动化测试的策略。

——作者题记

——从“脚本崩溃”到“可持续自动化”的实践总结

在实际项目中，很多团队在项目初期就尝试引入 UI 自动化测试，希望通过自动化提升效率、减少人工成本。

但现实往往是：

自动化不仅没有节省时间，反而成为项目推进的负担。

尤其是在界面尚未稳定的阶段，UI 自动化测试极易“失控”。本文结合实际项目经验，总结项目早期 UI 自动化测试的核心问题与可行对策。

---

一、问题一：脚本模式在早期项目中的天然不适配

1.1 界面未定型 → 脚本无法稳定

在项目初期，UI 通常处于持续变化中：

• 页面或者界面结构频繁调整
• 控件位置、层级变化
• 元素属性（id / class / name）不断修改

在这种情况下，传统的脚本模式（Selenium / Appium / UIA 等）会出现：

• 定位失效
• XPath 大量修改
• 回归测试无法稳定运行

即便在其他类型的开发体系中，如.net, java等，层级的变化，owner或者parent的从属变化也必然导致类似问题。

👉 本质问题是：

脚本依赖的是“稳定的界面结构”，而早期项目恰恰最不稳定。

---

1.2 脚本与界面强绑定

典型脚本模式：

driver.find_element(By.XPATH, "//div[3]/table/tr[2]/td[4]/input")

这种方式存在两个问题：

• 强依赖 DOM / UI 层级
• 无法表达业务语义

一旦界面调整：

👉 不是“修一点”，而是“整段重写”

---

二、问题二：界面元素不可控，导致自动化不可控

很多项目早期没有明确规范：

• 控件命名随意
• ID 自动生成（动态变化）
• Name / Label 不一致
• 不同页面风格完全不同

结果就是：

自动化工程师需要“猜”元素，而不是“使用”元素。

我记得Finastra的知名软件Opics和TPG公司的资产管理软件TPG大量使用了动态对象，使用脚本模式，几乎就是“不可能完成的任务”。但是，这些软件在动态对象的命名中，还是存在一定的规律性，从而为自动化测试提供的可能。

---

三、对策一：在需求阶段引入“可测试性设计”

3.1 UI 设计必须考虑自动化

软件测试不是一个软件公司的孤立部门。在软件公司的质量战略务必从开发阶段即设置一定的规范，建议在需求或设计阶段，明确以下规范：

✔ 元素命名规则

• 优先使用稳定的 ID 或 Name
• 命名具有业务语义
  • ❌ btn1
  • ✅ submitOrderBtn

✔ 统一命名规范

• 页面（或者界面）前缀 + 功能语义
  • login_username_input
  • order_submit_button

✔ 避免纯动态 ID

• 不要使用随机生成 ID，即使无法避免，也需要有一定的规则
• 或提供稳定属性（data-testid 等）

---

3.2 建立“动态定位规则”

对于不可避免的动态界面：

可以引入：

• 正则表达式匹配
• 模糊匹配（contains）
• 多属性组合定位

例如：

//button[contains(@id,'submit') and contains(text(),'确认')]

👉 核心思路：

从“精确定位”转向“语义定位”

---

四、对策二：引入无脚本（Codeless）模式

4.1 为什么无脚本更适合早期项目？

脚本模式的问题在于：

• 测试逻辑写死在代码中
• 修改成本高
• 非技术人员无法参与

而无脚本模式的优势在于：

• 测试步骤以“配置/模型”形式存在
• UI 变化只需调整对象，不需修改逻辑
• 测试逻辑与实现解耦

---

4.2 从“脚本”到“模型”的转变

传统模式：

代码 = 对象 + 操作 + 逻辑（强耦合）

向无脚本模式转变

👉 变化在于：

测试从“代码工程”变为“模型工程”

---

4.3 实际效果

在实际项目中，引入无脚本模式后：

• UI 调整只影响对象层
• 测试用例无需重写
• QA 可以直接参与构建测试场景

---

五、对策三：建立统一测试资产与规范

建议建立：

5.1 对象库（Object Repository）

• 所有 UI 元素统一管理
• 支持多种定位方式
• 可复用、可维护

5.2 测试用例库

• 按业务场景组织
• 支持跨模块复用

5.3 命名与设计规范

• 页面规范
• 元素规范
• 数据规范

---

六、最终收益：自动化成本显著下降

通过上述策略（尤其是无脚本 + 规范化设计），可以带来：

✔ 成本降低（60%+）

• 脚本维护成本大幅下降
• 回归测试稳定性提升
• 人工参与减少

✔ 效率提升

• 新功能测试可快速构建
• UI 变化影响范围可控

✔ 质量提升

• 测试覆盖更稳定
• 业务场景更完整

---

七、总结

项目早期 UI 自动化的关键，不是“尽早写脚本”，而是：

尽早建立可测试性与可复用的测试体系。

从实践来看：

• 脚本模式适合稳定系统
• 无脚本 / 模型驱动更适合演进中的系统

---

一句话结论

在不稳定的系统中，用稳定的脚本去约束变化，是注定失败的；
只有用“可演进的测试模型”，才能真正支撑软件的持续迭代。