起航学习网

虽然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来实现会比较方便。

软件开发测试人才四大魅力元素

——就业竞争小

——高薪没商量

——就业质量高

——无性别歧视

套用狄更斯那句话说：对于急需软件开发测试人员的企业来说，这是一个最坏的时代，但对软件开发测试人才来说，这是一个最好的时代。“随着软件市场的成熟，人们对软件作用的期望值也越来越高，软件的质量和功能可靠性也正逐渐成为人们关注的焦点。”

文章出自：http://qh.itpxw.cn/jyzn/202179302.html

文章标题：深圳软件开发测试中不得不谈的UI自动化测试

免责声明：本站文章均由入驻起航学习网的会员所发或者网络转载，所述观点仅代表作者本人，不代表起航学习网立场。如有侵权或者其他问题，请联系举报，必删。侵权投诉