在这篇文章,我想和大家聊聊,是否应该开展UI自动化测试?
当然,如果我们广义上认为只要是UI层的都算,比如Monkey测试、各种专项测试等等,那么答案是一定要做的,但这次我是想聊狭义上的,只是针对UI层的功能自动化,我们是否应该开展?
不知道有多少公司真正把UI自动化做好了,假定我指的是覆盖率很高,比如80%以上。那你说,这公司、这产品、这版本,得多稳定啊!
首先,还是把UI自动化的开展思路和大家聊一下吧:
1、通过代码方式实现框架,要么自研,要么直接使用开源;
2、使用开源软件进行工具级别投入使用,少量自己开发,基本无代码;
下面来聊聊这两个方面
1、代码方式
好处:灵活、定制化高、可锻炼人员能力。
问题:需要大家掌握代码,起码达到用例编写级别。
2、工具方式
好处:对人员能力要求低,基于成熟工具可达到量产的地步。
问题:工具本身可能存在限制,过于依赖工具本身,也可能无法解决某些特殊的问题。
其实,所有工具都是为了一个目标,即:降低人员要求,提高团队效率。
这里顺便提下两款UI自动化测试工具:Robot Framework,Katalon。
不过多做细节阐述了,尤其Robot Framework知道的人太多了,这里我们简单聊一下Katalon。
总结以下几点好处:
1、能和CI集成,且很简单(这个是极其重要的)。
2、Web、App均可以。
3、无代码、易学习。
附2张图,图1是官方放出的Katalon Studio vs. Open source frameworks的直观对比,图2是2018 Top5的自动化测试工具,通过这2张图,你会发现Katalon确实是值得学习并且投入使用的。
回到正题,是否应该开展UI自动化测试?
1、应该开展UI层面的自动化,但不一定是功能的;
2、如果要做功能级别的UI自动化,前提是API层做的比较好了;
3、我们要结合公司当前现状,发版节奏、需求变化、产品生命周期等等综合因素一起确定。
如果你要做,那么我们聊聊应该怎么样让他产生价值:
1、优先挑选稳定少变的模块覆盖;
2、选择重点场景进行覆盖;
3、不要仅按照功能测试用例的步骤实现,而是要按照功能测试用例的一个suite为单位进行实现(设想如果一个用例有10步,你实现了其中6步,你认为覆盖率是60%,其实是0%。。。因为你少了4步,这个用例还是得需要人工执行);
4、框架设计一定要好,这里面包括几点:用例分层、数据分离、模块公用、元素分离、数据驱动。
最后应该达成的最次效果,应该是这样的:
每天晚上服务器部署后,按照模块+场景执行API测试 → 按照模块+场景执行UI测试 → 进行各项专项测试(当然,2和3的顺序不一定一样),然后大家第二天上班,就可以看报告分析结果了。
最后:
做为管理者,我们本着以终为始的方式做事情,本着每件事情都有正确的方向和目标,基于这两点判断,相信本文的问题,你一定会有好的答案。