前言：

最近浏览论坛里的帖子，只要是关于 UI 自动化测， 很大几率会看到有人在苦口婆心各种劝： UI 自动化收益不高、投入产出比低、UI 变动大，难以维护， 等等。
过去半年部门在迭代开发一个新产品，每一轮迭代和每一次发版，都坚持用我们的自动化用例进行回归验证。 作为一个 UI 自动化的中度使用者，想和大家一起探讨一下 UI 自动化的投入是否真的值得。

产品背景

产品结构：

• 一个平台，前端分 PC 和 mobile web 两个版面。其中 PC 版比 mobile web 版多了一些附加功能，其他 90% 功能重合。
• 一个 PC 版的管理后台，主要管理各种模块的增删改查。

产品迭代节奏：

• 每个小版本周期大约 20-30 天。
• 每个小版本比前一版本增加约 15% 的新功能，另有约 10% 的旧功能优化。

关于投入

1. 前期框架搭建：

前期已经使用 Python+flask+bootstrap + selenium docker 搭建了一套自动化用例管理平台（可参考之前的分享： https://testerhome.com/topics/11183 ），主要利用项目的空余时间进行开发，实际开发时间大约 10 人天。
如果你有一定的开发基础，建议可以花点时间搭一个符合自己使用习惯的框架； 如果不想花时间开发，用业界流行的成熟框架也很方便。

2. 用例覆盖与编写：

个人使用经验，UI 自动化要达到一定的健壮性，以下几点很重要：

• 用例覆盖不能贪多，覆盖基本的增删改查功能即可。
• 用例的测试目的明确、唯一，即一条用例只覆盖一个明确的测试点。
• 用例设计要尽量简单，不要有和测试点无关的步骤。
• 对重复的步骤，剥离出公共方法，方便维护。如登录、进入某个菜单，等。
• 元素定位尽量使用 id、name、text 等不常变动、可唯一识别的属性。 这样即使页面有变动，也不需修改用例。

3. 用例维护：

如果有新的版本迭代，用例维护工作如下：

新功能：按统一的套路，设计需要覆盖的用例。

如管理后台新增了一个商品管理的页面，则需要增加以下用例：

• 进入菜单公共方法：调用登录的公共方法，并增加进入到商品管理页面的步骤。该模块的所有用例都初始调用这个方法。用例如下： 公共方法 |Login,点击菜单 | 系统管理,等待 |2,点击菜单 | 商品管理,等待 |2
• 新增商品：进入页面>点击新增>填写必需字段>点击保存>验证是否成功>截图
• 查询商品（抽取为公共方法）：进入页面>输入查询条件>点击查询>验证是否成功>截图（便于后续查看）
• 修改商品：查询商品>点击修改>填写必需字段>点击保存>验证是否成功>截图
• 修改商品：查询商品>点击删除>点击确认>验证是否成功>截图

这部分用例在完成第一次冒烟测试后即可进行编写（确保功能已经调通），而且使用这个模板，可在 5-10 分钟内完成这个模块的用例设计、编写、调试，后续基本不需要维护。

功能变更：修改对应用例。

如商品管理页面中修改了一个必填字段，只需对应的用例中修改该字段即可。

执行效果：

• 执行效率：目前产品中前后端用例接近 200 条，在使用 3 个线程并发执行的情况下，大约 15-20 分钟可完成一轮回归测试。
• 执行结果：
• - 每轮迭代开发完成第一次迭代，用例失败率大约是 15%-20%，可发现若干因功能修改引发的问题；
• - 每轮迭代测试后几轮，用例成功率大约是 95%-100%（个别用例因环境问题无法执行），可替代 70% 的手动回归测试执行（剩下 30% 涉及复杂流程，更适合手动测试）

使用建议

• 不管是长期项目还是短期项目，都应该尝试把 UI 自动化用起来。即使只能覆盖 20% 的基础功能，仍然能节省你手动回归的工作量。
• 用例要多跑，才能价值最大化。每次有重新部署，都尽量让用例跑起来，甚至在空闲的时候也让他多跑几次，说不定某些偶发的 bug 就被发现了。
• 做好用例设计。这是用例健壮性最大的保障，否则每次执行都要调一次用例，节省的工作量又加回来了。
• 总结使用心得，优化框架和用例设计。 没有哪个框架是完美的，多总结自己使用中用得不爽的问题，把工具优化到自己最趁手的状态，也就越能发挥工具的作用。