前言

测试同学对 UI 自动化测试的热情经久不衰，从目前市面上有很多培训机构琳琅满目的课程可以看出端倪，大部分机构偏好于教授前端 UI 自动化的课程，比如 Selenium、Robotium、Appium、UiAutomator 等等。测试同学希望通过 15 到 30 天的强化训练，成功转型到 “测试开发” 队伍，摆脱之前点点点的状态，迎来崭新的人生。然而这些培训机构善于带你入坑，入坑之后你会发现，这世上哪有什么救命稻草，你唯一可以依靠的就是自己的努力和勤奋，你的成长其实是自己在填坑的过程中拿痛苦换来的。

关于 UI 自动化测试的幻想与现实

业内对 UI 自动化测试毁誉参半，一方面新人对 UI 自动化趋之若鹜，另一方面老司机对它充满了诟病，出现这种冰火两重天的现象，笔者认为主要是对 UI 自动化测试的错误预期造成的：

• 幻想一：UI 自动化可以节省人力
• 幻想二：UI 自动化可以达到超高的测试用例覆盖率
• 幻想三：UI 自动化可以一键傻瓜式解决问题

相信做过 UI 自动化的同行应该跟我一样，总会有一些 “多么痛的领悟”：

• 领悟一：在产品迭代周期频繁、产品形态多样、容易重构的情况下，UI 自动化的投入不但节省不了人力，还会因为其高维护成本拖慢项目节奏，亦或渐行渐远不去维护，成了摆设；
• 领悟二：为了满足 “领导” 对覆盖率 95% 的高预期，关于 UI 界面的检查 case 会让你万劫不复。颜色变化、换行、粗细字体等等，想想都不寒而栗，不是瞎说，我以前真的这么干过；
• 领悟三：你千辛万苦花了 4 个小时调试好了自动化脚本，结果功能测试用 20 分钟已经完成了该功能点的回归测试，如果你是自动化测试开发，你怎么说服功能测试用你写好的脚本，如何推进自动化测试这件事？如果你是测试人员，你会不自觉的怀疑这件事的意义和价值； 因此，笔者总结曾经填过的那些坑，分享一下对这件事的不成熟的理解和想法。

UI 自动化的价值

UI 自动化当然不是银弹，那它是不是一无是处呢？答案也是否定的，我们可以从以下几个方面尝试把控：

1. 控制好老板的 “高预期”，自动化测试只是为业务服务的辅助工具，尽可能把团队的好 “钢” 用到刀刃上
2. 定好策略，选对业务线和产品类型，思考自动化覆盖的模块和功能点，切入时间，代码复用性
3. 测试框架设计，工具选型、语言选型、人员知识储备分析的前期工作要做足
4. 开发人员的配合工作（比如尽量不要随意变更控件属性，提高界面的可测性），版本提测节奏的把控
5. 在烂如泥沼一样的项目里，你首先要做的不是改变测试方法，而是改善测试流程

具体有几个经验可以供大家参考：

1. 根据产品形态控制 UI 自动化介入的范围，测试重心应该避开新功能及相关模块，从较为稳定的地方着手，逐步积累自动化用例，在大版本全量回归的时候会发挥威力。（即使在做产品全量回归测试的时候也不回归的功能模块，或者八百年也不去回归的功能，请无视这一条）
2. 尽量多做逻辑和功能流程校验，不要去检查 css 式样，这些检查工作不但不会提升测试效率，反而会让你陷入维护的泥潭
3. 挖掘业务操作中需要大量重复劳动的可替代动作，把它们自动化起来
4. 前端自动化测试由于其所见即所得的特点，用于测试人员练手，提升编程技能有很好的效果，除了服务业务以外，还能丰富测试人员技能，让团队成员有成长提升的机会，建立成员的自信心，也是引入自动化测试的一个重要因素
5. 充分运用分层设计思想，集合 Page Obejct 模式，在设计测试框架的时候需要考虑几方面：
   • 数据分离，如数据的初始化、备份、销毁、还原等等，有条件的可以基于 docker 做环境隔离
   • 基本操作封装，如启动浏览器的切换、click、input、select 等等
   • 通用业务逻辑封装，如登陆操作、清空购物车操作、获取验证码等等
   • 元素分离（参考 PO 设计模式），集中管理 page element，在业务脚本中以元素变量替代，统一变更和维护
   • 复杂操作封装，如 web 测试的各种 dialog 处理、js sandbox、iframe 同源跨域，移动端的上下左右 swip、清空缓存等等
   • 脚本健壮性考虑，比如 rerun、WaitForElement 显式 or 隐式等待等
6. 如果有的选择，不建议用坐标、截图（比如 sikuli 那种）进行操作

有达人总结了一条公式：
自动化的收益 = 迭代次数 * (全手动执行成本 - 维护成本) - 首次自动化成本
业内有很多出色的设计方案，这里说的比较简单，欢迎大家踊跃补充。

再谈自动化测试定义

不论是日常跟同事们沟通也好，还是网上各种资料文章写的内容也罢，发现大部分同行提到自动化测试，第一反应往往是 UI 自动化测试，因此在讨论 UI 前端自动化测试的时候不自觉的简称为 “自动化测试”，我个人认为这个定义是不严谨的。广义的自动化测试应该包括但不限于以下方面：

• 测试环境部署、管理
• 测试环境监控、报警
• 代码的编译、构建
• 代码静态检查和报警
• 测试用例执行调度
• 测试日志和报告
• 其他测试，比如专项测试、性能测试、随机测试、探索性测试等等

我们回顾一下常规测试流程中的各个阶段：

• 单元测试
• 集成测试
• 系统测试
• 验收测试

不同领域也有很多测试方法，常用的例如：白盒测试（静态代码分析）、冒烟测试、UI 测试、黑盒测试、兼容性测试、接口测试、性能测试、安全测试、老化测试（硬件）、专项测试（移动）等等。 如果你站在更高的维度去看，会发现节省人力、缩短时间、提高质量的手段远不止 “UI 自动化” 一种途径，当我们技能达到一定水准的时候，就能结合项目实际情况，因地制宜的定制自动化方案，如独孤求败所言的” 四十岁之后不屑带物，草木竹石均可为剑。自此精进，渐入无剑胜有剑之境。“。

总结

UI 自动化作为常驻各大公司招聘 JD 的一条重要考察点，绝不是仅限于培训 15 天入门的要求，而是考察你通过这些 “基本能力” 解决了哪些业务实际问题，做了哪些创新和突破。
限制我们想象力的不是我们技能的匮乏，而是知识面的欠缺。在合适的时机恰到好处的引入了某个测试方式解决了业务的实际问题，才是一个测试人员应该具备的核心竞争力，在此之前请努力扩大我们的知识面，积累解决问题的经验，不断思考和创新，忘记那些所谓的 “救命稻草” 吧。

后记

我们团队在上述提到的各个维度都已经有了切实的实践和落地方案，再这里 “纸上谈兵”，后面会给大家分享更精彩的项目案例。