2016.03.01 丨 壹佰案例
十年测试经验悟出的测试心得
2016.03.01 丨 壹佰案例
许奔,联想集团研发主管工程师,资深自动化测试工程师,《深入了解Android自动化测试》作者。曾带领联想手机单元测试团队、联想手机自动化测试团队为公司开发出多款实用的Android自动化测试工具。同时,他还是联想集团年度发明人,MBG专利大师。
论坛「骂战」让我快速提升测试技能
做黑盒/功能测试的同学总想尝试一下自动化测试或单元测试,或者说,自动化测试或单元测试对于从事软件测试的童鞋而言具有一种不可名状的吸引力。
多年后,有的同学已经成功跨过这道坎进入到自动化测试或单元测试领域,但大多数同学仍在观望着,继续抱着那种期待和恐惧——期待自动化测试或单元测试的魔力,恐惧于他们对技术上的要求。
作为一只从事软件自动化测试和单元测试将近10年的老鸟,我是如何一步步踏上这条路的?十年一回头,对我而言,从事软件自动化测试和单元测试最重要的技能又是什么呢?
十年前,作为一名毫无编程经验的初学者,抱着一本Paul C.Jorgensen的《软件测试》,无所畏惧地踏上这条路。当时负责一个Windows平台的财务系统项目测试,由于公司经费有限,每个项目只有一名测试,自己写测试用例,自己测试,自己出测试报告,自己报bug,没有人管你是如何测试,甚至没人审查你的用例,项目经理只看bug,以及最后客户是否满意。
为了减少自己的工作量,开始逛测试论坛,开始知道有QTP这么个玩意儿,可以录制回放,如果稍微参数化一下,可以大大减少测试录入的工作量——就这样,懵懵懂懂地开始了第一款自动化软件的学习和使用。
随着对QTP越来越深入的了解,随着脚本录制/回放过程中诸多不满意,开始自己试着修改脚本,当时的脚本应该是VBScript脚本,然后试着描述性编程,学了一些必须掌握的语法,开始自己写更为稳定的脚本——毕竟是为了自己用起来方便,而不是为了秀demo,所以一切以实用为目的。就这样做了一两年,这期间由于对VBScript的熟练,顺便学习了C#和Java的基础知识,发现都不是很难,也更便于自己发现研发的bug。
除此之外就是,在论坛上掀起很多「骂战」,一方面是自己出来嘚瑟的帖子被人骂,一方面是去骂其他出来嘚瑟的帖子——这种「骂战」的好处就是,可以快速发现自己知识和实践中的不足和错漏,还可以结识到相关技术的大牛。记得当时和我「对骂」最厉害的一位QTP大牛,为了证明他的确比我牛,把他总结的《QTP难点及解答》发给我,这篇长达数十页的word文档让我在QTP自动化测试的疑难杂症面前攻无不克,还帮助他顺利进入梦想中的HP,继续钻研QTP,当然,这是后话。
现在很多童鞋问我,学习自动化,我该看什么书?我该从哪开始?我该问谁?我的回答是:找个当下就能帮你减轻负担的工具,从这里开始,玩转它,并到论坛上去分享,去掀起「骂战」,让自己快速提升。
最基础的脚本为什么是「大牛」来写
两年后,项目结束,我跳槽到一个外包公司,将我外包到微软嵌入式团队,做「嵌入式自动化测试」。这里所谓的「嵌入式自动化测试」,是指在只安装Windows core以及某个组件(component)的基础上对其进行自动化测试。比如自动取款机就是Windows core+IE结构。
要知道,如此简化的系统是运行不起QTP这样的工具的,因为没有.net framework,也运行不起市面上大部分成熟的自动化框架或工具,只能通过最原始的命令行运行。所以当时我们写的都是批处理(batch)和Javascript脚本,然后通过微软的WTT,将脚本和测试资源导入到测试机后通过命令行运行脚本。
在此之前我通过批处理写过一些简单的批量运行或文件检查的脚本,但在这里,需要通过批处理写出大量复杂的、相互调用的脚本,这让我对批处理刮目相看,也逼着自己把脚本管理和脚本联调的能力修炼得更好。
但我认为,这个阶段真正学到的,并不是脚本管理和联调能力,而是什么人应该编写最基础的脚本。为什么这样说?
我刚进公司最困惑的一件事是:IE所有最简单的开启、关闭,以及最基本的每个下拉菜单的打开,这类最最基础的脚本,居然是由美国一位大牛负责。而作为菜鸟的我,却需要编写非常复杂的脚本,比如:打开IE后在地址栏输入某个链接,确认跳转后截图对比,然后将该链接保存收藏夹,将IE关闭后再打开,去收藏夹确认该链接已被成功保存。
我非常郁闷和不服,因为在国内,都是菜鸟写最简单和最基础的脚本,越牛的人写的脚本越复杂,为什么在外企反而倒过来——牛人写简单脚本,每天喝咖啡游泳晒太阳。菜鸟写复杂脚本,每天苦逼累个半死。这还有天理吗?还有王法吗?
结果我领导反问我一句话:你那条复杂脚本有多少人调用?如果出了问题需要紧急停止会造成多大的损失?换句话说,你需要承担多大的责任?我想了想道:好像就我自己调用,如果紧急停止不会造成太大损失…我领导继续问:那他那条基础脚本有多少人调用?出了问题会造成多大损失?我彻底反应过来:他那条脚本全世界不知道多少人在调用,出了问题那还真是蝴蝶效应,估计直接受影响的用例就高达几千条!
这件事一直影响我到现在,最基础的脚本谁来负责?值得大家反思。
自动化测试最重要的技能是什么
从移动互联网大潮兴起一直到现在,我一直做着Android自动化测试。关于Android的各款测试工具,从被我称之为「小李飞刀」的monkey,到具备录制回放能力的monkeyrunner,再到自动化「屠龙刀」Instrumentation和「倚天剑」UIAutomator,还有那把单元测试的「手术刀」CTS,一路走来,每一款工具的使用,每一款框架的源码剖析,每一次对框架的二次封装或工具开发,以及一点一滴的反思,都被我记录在《深入理解Android自动化测试》这本书中,感兴趣同学可以自行查阅。
很多同学认为,从事自动化测试或单元测试,最需要的技能是个人的编程能力,或是对自动化工具的驾驭能力,或是自动化相关的实践经验。我认为,这些都不是自动化最重要的技能!
从业十年,回头来看,发现自动化测试或单元测试最最重要的技能,就是我当初我怀抱着进入自动化行业的那本Paul C.Jorgensen的《软件测试》。自动化测试也好,单元测试也罢,说到底,都是软件测试。
向谷歌学习怎么写用例
举个真实的例子:我刚开始做Android单元测试时,领导让我为媒体播放器(Media player)设计单元测试用例。
当时我想了下,设计了这么几条用例:
Priority 1:播放器正常开启、暂停、停止;
Priority 2:播放器在播放时切换下一首歌、上一首歌;
Priority 3:播放器在播放时突然停止,几种常用格式音频文件播放;
设计完后,我还专门看了一下Android官网针对播放器的状态切换图:
我觉得没什么遗漏,测试覆盖得很完美。就这样,这些单元测试用例一直执行着,执行着,直到某天我突然看到CTS里Google工程师为播放器编写的单元测试用例,整个人一下就不好了。
首先是测试资源预置及环境清理总结,资源预置时创建了两个播放器对象并获取相关资源文件,环境清理时释放这两个对象并删除相关资源文件,如下图所示。
然后开始测试,先是「空文件及音视频播放测试」,如下图所示。看到这里,我发现我漏掉了空文件播放这个边界值,也忘记了视频播放测试。
再下来是「切换下一首测试」,如下图所示。看到这里,我发现单纯的音频切换,我只做了基本状态检查,其他状态检查都没有覆盖到。
接下来是「频谱测试」,如下图所示。这里,我发现自己完全没考虑到这些「奇葩」文件。
接下来是「无缝播放测试」,如下图所示。不用说,这个方面就更没考虑到。
然后是「视频界面重置测试」,如下图所示。似乎这个测试很简单,但仍然被我无情地漏掉了。
再下来是「录制视频播放角度测试」,如下图所示。只考虑播放,没考虑录制后播放,这是我的错…
然后是「不同格式视频文件测试」,该单元测试用例涵盖了绝大部分文件类型,如下图所示。想想我只选择了几个常用音频格式文件,就无比汗颜,这里不仅选择了不同的类型、编码格式、分辨率、比特率、帧率、声道、频率,而且做了组合测试——请注意,是组合测试!
再下来是「字幕选择/取消选择测试」,如下图所示。当时完全没考虑到视频,更没考虑到字幕,更没考虑到内置字幕和外置字幕的不同,更没考虑到字幕选择和取消…
紧接着是「字幕切换测试」,如下图所示。
接下来是「播放器回调测试」,如下图所示。是的,我承认之前完全没考虑到要不要测一下回调是否正常…
最后是「视频录制播放测试」,如下图所示。
看完这些,我当时特别汗颜。
从普通走向优秀
一名普通自动化/单元测试工程师与一名优秀的自动化/单元测试工程师之间,最大的差别是什么?
• 是对软件测试理解的深刻程度。
• 是对测试理论掌握的熟悉程度。
• 是对测试技术运用的熟练程度。
一些测试员仗着编程能力较好,看不起基本的测试技术(如边界值、等价类,还有诸如决策表、因果图、状态机等)。
事实上,优秀的测试工程师首先需要具备的就是扎实的测试技术功底。只有掌握了最最基本的测试技术后,无论做什么测试(黑盒、白盒、自动化、性能或是单元测试),都能游刃有余,设计的测试用例也才能真正深入进入,进而发现隐藏的bug。
如果不打好这个基本功,哪怕编程能力再好,设计的用例也漏洞百出,发现不了问题的根源。以“不同格式视频文件测试”为例,如果要确保测试到位,就一定要设计各种不同格式的播放文件(类型、编码格式、分辨率、比特率、帧率、音频格式、声道、频率等等),所以有此测试。
大家不难看出,设计这个用例的单元测试工程师是多么的不厌其烦,一点点地从细节上去把控。而很多同学却认为这些琐碎的小事情不值得花时间,或认为没有技术含量而只是草草写上几个,相比Google的大牛们,难道不汗颜吗?
想和许奔探讨更多测试方面的知识?搜索公众号「巴哥奔」可以找到许老师。
本文根据TOP100Summit讲师投稿原创首发,转载或节选内容前需获授权。同时,也欢迎更多企业、社区与TOP100公众账号展开内容合作,更欢迎您成为原创作者。更多内容合作请发邮件至wow@top100summit.com,我们期待认识你:)