UI自动化测试
作者:网络转载 发布时间:[ 2017/5/12 11:22:44 ] 推荐标签:UI测试 自动化测试
虽然UI自动化是比较高成本的方式,但是很多时候也是功能测试的选择。
UI自动化测试不只是脚本,也需要设计
软件测试脚本的开发也是软件开发,脚本必须符合规范,必须经过设计编码测试维护的全过程。
测试脚本的设计:根据面向对象设计的原则,我们需要对变化频繁的地方进行必要的封装。在这里变化相对频繁的是UI本身,而相对稳定的是业务逻辑。所以我们可以针对UI进行封装,然后再封装一层业务逻辑层,所有的测试用例都通过业务逻辑接口进行操作。比如我们要测试一个登录窗口,那么UI层包含用户名,密码,登录按钮的UI定义,逻辑层包含接口类似login接口,测试用例里边调用login接口登录并进行必要的验证。
测试脚本的编码:既然是软件工程,那么脚本也必须遵循代码规范,比如python的脚本需要遵循python的代码规范。
测试脚本的测试:脚本是用于测试程序的,那么自身的质量也是至关重要。建议有条件的team进行code review,当然这个很难做到…… 另外是至少要人工观察脚本的操作,来确定它做了正确的事情。而且需要在不同的系统和机器上测试通过。
测试脚本的维护:UI相对来说比较容易变化,这导致测试用例的fail,那么我们需要去调试并确认是脚本问题,确认之后如果设计良好,大部分情况下只需要更新UI层可以了。另外我们需要考虑是否UI变化过于频繁,现在自动化开始是不是正确?
UI自动化测试开始的时机
从前边测试脚本的维护可以看出,维护工作量的大小,跟UI变动是否频繁直接相关。我们需要做的事情,是确定什么时候UI已经稳定了,我们再开始UI自动化,否则还是考虑先人工测试覆盖。当然了,我们也没必要等整个程序的UI稳定,比如一个独立的功能UI稳定了之后,我们可以先对那个功能进行自动化,然后等待其它功能的UI稳定。
而且一旦UI自动化开始,后边的维护工作也相应要开始
所以我建议开发过程中,有一个milestone叫UI freeze,这个阶段后可以着手开始UI的自动化测试了。当然,非UI的自动化,比如Unit Test,Integration test和API test应该很早开始了
另外一种情况,是针对上一个版本release的功能的回归测试,这个是适合UI自动化的方面。一般来说,这种情况UI变动基本上没有,而且功能比较稳定,测试写好之后,可以有效减轻手工测试的压力,而且可以更专注于新功能的验证。
需要考虑UI自动化的投入产出比
我们先说投入:与软件的投入产出一样,一个设计良好的UI自动化框架,大的投入应该是创建框架和实现测试自动化脚本,而尽量减少维护的工作量。一个坏的自动化框架,前期可能投入较少,后续的维护和更改的成本可能几倍与前期,甚至到后只能丢弃掉。
说到产出,自动化测试跑的次数越多,平台覆盖越广,产出越多,减少手工测试的工作量也越多。一旦自动化测试写好,那应该让他们持续的跑起来,比如根据情况设置每周,每日,甚至是每次提交自动部署到所有平台运行并报告结果。这个配合Jenkins来实现会比较方便。
相关推荐
更新发布
功能测试和接口测试的区别
2023/3/23 14:23:39如何写好测试用例文档
2023/3/22 16:17:39常用的选择回归测试的方式有哪些?
2022/6/14 16:14:27测试流程中需要重点把关几个过程?
2021/10/18 15:37:44性能测试的七种方法
2021/9/17 15:19:29全链路压测优化思路
2021/9/14 15:42:25性能测试流程浅谈
2021/5/28 17:25:47常见的APP性能测试指标
2021/5/8 17:01:11