Web UI自动化测试的不稳定性有两个层面:
- 技术层面–没有构造健壮的能稳定运行的脚本
- 非技术层面–项目原因或者用Web UI自动化企图达到不合适的目标,造成脚本频繁改动,维护成本高
第一点在上一篇博文里从代码层面分析过了,今天主要说说第二点。
丑话说在前面,Web UI自动化不是万金油,它不可能干掉手动测试人员。衡量好投入产出,最大化UI自动化的效用,才是王道!
什么项目不适合做Web UI自动化测试?
- 我觉得没有太多Web UI界面、不面向终端用户的项目,它可能只涉及到后台数据导入、处理,或者模型计算,那这种更适合接口测试,每一次开发的新代码进入目标环境之后,让CI自动跑一遍不带UI界面的接口测试,看看是否有引入新BUG。一般而言,不带UI界面的自动化测试效率以及稳定性都要更高。
怎样使用Web UI自动化测试这个工具,以期在开发维护成本&自动化产出之间找到平衡点?
我的建议是:
- 分出轻重缓急,核心部分优先自动化。对于所有Web项目而言,合法登录&不合法登录,以及权限控制都是最重要最基本的。除此之外,再拎出来系统的核心部分以及用户使用频率最高的部分,从功能的角度进行自动化测试,也就是说,点击这个按钮,判断profile页面是否如期唤起;配置报表,最后报表是否生成,里面是否有数据?(数据是否正确就应该交由集成测试来验证);做一笔trade,返回值是否是成功,是否包含exception message等等。<