论Web UI自动化测试的不稳定性（二）

Web UI自动化测试的不稳定性有两个层面：

1. 技术层面–没有构造健壮的能稳定运行的脚本
2. 非技术层面–项目原因或者用Web UI自动化企图达到不合适的目标，造成脚本频繁改动，维护成本高

第一点在上一篇博文里从代码层面分析过了，今天主要说说第二点。

丑话说在前面，Web UI自动化不是万金油，它不可能干掉手动测试人员。衡量好投入产出，最大化UI自动化的效用，才是王道！

什么项目不适合做Web UI自动化测试？

• 我觉得没有太多Web UI界面、不面向终端用户的项目，它可能只涉及到后台数据导入、处理，或者模型计算，那这种更适合接口测试，每一次开发的新代码进入目标环境之后，让CI自动跑一遍不带UI界面的接口测试，看看是否有引入新BUG。一般而言，不带UI界面的自动化测试效率以及稳定性都要更高。

怎样使用Web UI自动化测试这个工具，以期在开发维护成本&自动化产出之间找到平衡点？

我的建议是：

• 分出轻重缓急，核心部分优先自动化。对于所有Web项目而言，合法登录&不合法登录，以及权限控制都是最重要最基本的。除此之外，再拎出来系统的核心部分以及用户使用频率最高的部分，从功能的角度进行自动化测试，也就是说，点击这个按钮，判断profile页面是否如期唤起；配置报表，最后报表是否生成，里面是否有数据？（数据是否正确就应该交由集成测试来验证）；做一笔trade，返回值是否是成功，是否包含exception message等等。<