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

周冬彬 · 2015年04月13日 · 最后由 周冬彬 回复于 2015年04月29日 · 155 次阅读

最近在项目中领导要求需要做自动化测试,所以我跑去研究了一下 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,那么就是有意义的:)

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

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

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

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

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

需要 登录 后方可回复, 如果你还没有账号请点击这里 注册