新手区 UI 自动化测试在项目中的意义

周冬彬 · April 13, 2015 · Last by 周冬彬 replied at April 29, 2015 · 3669 hits

最近在项目中领导要求需要做自动化测试,所以我跑去研究了一下Robotium,appium等自动化工具。但是在写case的过程中发现软件版本迭代太快,往往是我的case还没写完,软件已经更新了好几版本了,一些重要流程还有软件的一些架构都已经改变了。所以我只能针对某一个历史版本做UI的自动化,然后出现了一些迷茫:
1.UI自动化在整个项目中的意义何在?它到底要达到一种什么目的?(之前听monkey说的,UI自动化是不能减少人力的)
2.在版本快速迭代的过程中,它又扮演一种什么角色?
3.各位在真实的项目中通过UI自动化能找出多少有意义的BUG?
4.是否需要把性能的case和UI自动化结合在一起,才能使整个自动化变得有意义?

共收到 15 条回复 时间 点赞

我想说的是,想要做UI测试的前提,是项目的开发和测试选取框架,先做好底层的单元测试和接口测试,然后我得理解里,应用的大部分流程和功能比较稳定了,UI测试才比较可行。 UI测试在迭代里扮演着验证的角色,初期的版本改动过大就建立UI测试,成本太高了,个人愚见

这个感觉是老问题了,我个人感觉,引入自动化测试的目的在于,把枯燥的重复的手工操作进行脚本化,所以我一直认为,不要为了自动化而自动化,自动化测试引入是有前提条件的,1、版本周期不能太短 2、版本主要主流程要基本稳定。so
第一个问题:并不是每个case都可以把它脚本化的,主要针对一些基础用例,在版本回归测试阶段,把主流程的一些基础case自动化掉,大大解决了重复的手工劳动力,还有,自动化测试目的并不是在于发现更多的bug,而是为了产品质量的保证,其实更多的bug还是需要手工测试去发现的。
第二个问题:在版本快速迭代的过程中,它又扮演一种什么角色?充当版本质量的守门神,不是为了发现更多bug,而是为了保证版本没有问题。
第三个问题:同二
第四个问题:我感觉没有意义,因为功能自动化测试和性能测试关注点不同,自动化主要校验功能性是否完整,而性能更多的是关注这个系统在多并发情况下,能否出现问题、响应时间,更多的是检验这个系统架构缺陷所在以及性能优化点

UI自动化投入产出比不是太高。之所以大部分人喜欢用是因为它可以直观地看到执行过程。
从你的描述来看,你的问题在于软件更新太快(特指UI层面),导致维护成本高。

对于这种问题,建议你找个可以录制的UI测试框架(如MonkeyTalk)来做半自动化(不是全自动化,要有人在那里看着的,因为录制的结果大多不带有校验,不过你录脚本的时候其实也把测试用例执行完了。。。),达到尽量降低自己的劳动量的目的。

纯UI自动化其实和单元测试差不多,只是UI自动化只关注UI,单元测试关注功能实现。目的都是保证版本没被改坏。自动化最大的意义就是以最快速度验证功能的正确性,并以最低成本定位问题代码,就如软件工程里所说,一个bug在刚出现的时候被发现的话,修复成本最低,越到后面修复成本越高。

举个例子:
开发提交了代码,然后CI上跑一下测试用例,发现这个版本的一些基本功能被改坏了,开发赶紧再去review一下刚提交的代码哪里有问题,赶紧fix。否则一个包含了数十个提交的版本在手工测试的时候发现bug,然后开发还得从几十个提交中慢慢找是哪次变更导致这个问题出现。

#1楼 @davidyang 业务发展飞快,很多流程推倒了一遍又一遍。基本流程和功能暂时都没看到稳定的迹象,但是自动化又不能等很久以后才开始去做,所以我选了一个相对稳定的线上版本做的自动化。但是感觉孤零零一个在弄- -!

#2楼 @cpfeng0124 我觉得这句话“自动化测试目的并不是在于发现更多的bug,而是为了产品质量的保证,其实更多的bug还是需要手工测试去发现的。”说的挺好,之前一个面试问我自动化到现在发现了几个BUG?我都不知道该怎么回答- -

#3楼 @chenhengjie123 可以录制的UI测试框架,听起来是不错。不过我现在的情况是领导基本很少给我需求去写用例和去测试,基本上我现在主要的工作就是把整个自动化整起来,包括代码框架,我现在是针对线上之前的一个版本写的,写了一半,新的应用更新了很多有一些我都不太清楚了。一个人在那写UI自动化代码,学习Android开发基础知识。对于我这种现状不知道还有什么好的建议给我一个方向什么的?

#6楼 @azdbaaaaaa 如果领导指明要求搞自动化,我觉得你可以和领导私下交流一下,搞清楚领导搞自动化的真正目的是什么,然后对症下药。有些领导搞自动化是为了业绩,那你可以搞一个简单的自动化平台给他(推荐搞个比较成熟且领导容易体验的,能够快速录制来更新,例如MonkeyTalk),能够以最快速度搞出一个看起来很牛的用例。如果真的是为了软件质量,那得先看看哪里稳定了(除了UI,还有接口、单元测试等可以做自动化的),然后对稳定的模块做自动化。

自动化是为了减少重复劳动。没有重复劳动搞自动化没啥意义。自动化如果经常要维护,那你想通过自动化降低手工成本其实不可能(一个用例跑一次就得改一次,改完还得调整,还不如直接手工),至于维护质量就更加无从谈起了(自动化用例的质量都保证不了,怎么保证软件质量)。

其实自动化不一定是测试的自动化的。你能把打包、部署这些搞到全自动化(其实就是一键完成)其实帮助也很大的。因为这些基本都是重复劳动。

1.UI自动化在整个项目中的意义何在?它到底要达到一种什么目的?(之前听monkey说的,UI自动化是不能减少人力的)

这个吧。。嗯。。移动互联网中至少我是这样认为的。UI自动化本身的意义怎么定义也看项目本身的。有的UI自动化是做回归的,有的UI自动化就是做替代了一部分核心基础的功能测试,这个说不好。但是最终减少人力的例子很少,非常之少。

2.在版本快速迭代的过程中,它又扮演一种什么角色?

快速的话,其实我觉得能做的就是所谓的老版本的回归,在本次的迭代中几乎很难去做什么。虽然很多人不认同,但是实际项目的确就是如此

3.各位在真实的项目中通过UI自动化能找出多少有意义的BUG?

UI自动化找到有意义的bug还是有的。但是看阶段。我的观点还是UI自动化其实在一些smoke test或者regression test中还是有一定的作用的

4.是否需要把性能的case和UI自动化结合在一起,才能使整个自动化变得有意义?

嗯,好问题。这个还是有意义的。但这个性能不是服务器的性能,而是device app本地的性能,这些是需要和自动化功能测试结合的,而且必须结合。但也不是所有的性能测试都需要自动化,需要有区别的去定义和设计。

#8楼 @monkey 总结一下,UI自动化主要还是的用处在于【冒烟测试/回归测试】,快速迭代情况下多用于老版本的回归,同时需要结合一些app本地的性能参数。至于你说的有意义的BUG,能给我举个例子吗?谢谢

#9楼 @azdbaaaaaa 嗯。比如说,我在项目中使用BDD的模式,对于每个新的应用都会做smoke test。那么发现的应用的crash以及与ux稿不同的时候,case failed,那么就是有意义的:)

周冬彬 #11 · April 14, 2015 作者

#7楼 @chenhengjie123 快速录制(MonkeyTalk),在快速迭代过程中实现半自动化,节约劳动力;至于接口、单元测试,我在项目过程中测试了一些简单的接口,就是给我一个接口地址,然后我结合业务输入一些字段值,查看返回报文,过程中争取覆盖所有的返回码这一种,单元测试我还没接触过。我觉得对这两方面的测试都不是很了解,所以自动化的话还是不知道要如何着手,(但是不容置疑这2种测试都是非常重要的)。谢谢你的回答

周冬彬 #12 · April 14, 2015 作者

#10楼 @monkey 大概了解了,不过我们没在用BDD模式,百度了一下:)

据了解,目前已经越来越多的手游CP开始重视起游戏测试来了,2014年整个手游市场达到了274亿,而因游戏兼容性问题造成的损失大约达到了72亿,CP们意识到在现阶段手游产业人口红利消失的局面下,挽回这72亿可能是2015年的重要增长点。这也带动了整个行业越来越规范化的游戏测试标准出台,精品游戏开始逐渐被引起重视对于行业来说终究是好事儿。

自动化能不能发现bug,要看自动化脚本对功能的覆盖度,覆盖到了,如果这里有问题,自动化脚本就能把这个问题暴露出来。

周冬彬 #15 · April 29, 2015 作者

#14楼 @huangyaoshiauto 哦哦,半个月前的帖子你都能找到

需要 Sign In 后方可回复, 如果你还没有账号请点击这里 Sign Up