十年软件自动化测试生涯的三点心得

xuben

启程：该如何迅速入门？

做黑盒/功能测试的童鞋总想尝试一下自动化测试或单元测试，或者说，自动化测试或单元测试对于从事软件测试的童鞋而言具有一种不可名状的吸引力。

多年后，有的童鞋已经成功跨过这道坎进入到自动化测试或单元测试领域，但大多数童鞋仍在观望着，继续抱着那种期待和恐惧——期待自动化测试或单元测试的魔力，恐惧于他们对技术上的要求。

作为一只从事软件自动化测试和单元测试将近10年的老鸟，我是如何一步步踏上这条路的？十年一回头，对我而言，从事软件自动化测试和单元测试最重要的技能又是什么呢？

十年前，作为一名毫无编程经验的初学者，抱着一本Paul C.Jorgensen的《软件测试》，无所畏惧地踏上这条路。

当时负责一个Windows平台的财务系统项目测试，由于公司经费有限，每个项目只有一名测试，自己写测试用例，自己测试，自己出测试报告，自己报bug，没有人管你是如何测试，甚至没人审查你的用例，项目经理只看bug，以及最后客户是否满意。

为了减少自己的工作量，开始逛测试论坛，开始知道有QTP这么个玩意儿，可以录制回放，如果稍微参数化一下，可以大大减少测试录入的工作量——就这样，懵懵懂懂地开始了第一款自动化软件的学习和使用。

随着对QTP越来越深入的了解，随着脚本录制/回放过程中诸多不满意，开始自己试着修改脚本，当时的脚本应该是VBScript脚本，然后试着描述性编程，学了一些必须掌握的语法，开始自己写更为稳定的脚本——毕竟是为了自己用起来方便，而不是为了秀demo，所以一切以实用为目的。

就这样做了一两年，这期间由于对VBScript的熟练，顺便学习了C#和Java的基础知识，发现都不是很难，也更便于自己发现研发的bug。

除此之外就是，在论坛上掀起很多骂战，一方面是自己出来嘚瑟的帖子被人骂，一方面是去骂其他出来嘚瑟的帖子——这种骂战的好处就是，可以快速发现自己知识和实践中的不足和错漏，还可以结识到相关技术的大牛。

记得当时和我对骂最厉害的一位QTP大牛，为了证明他的确比我牛，把他总结的《QTP难点及解答》发给我，这篇长达数十页的word文档让我在QTP自动化测试的疑难杂症面前攻无不克，还帮助他顺利进入梦想中的HP，继续钻研QTP，当然，这是后话。

现在很多童鞋问我，学习自动化，我该看什么书？我该从哪开始？我该问谁？

我的回答是：找个当下就能帮你减轻负担的工具，从这里开始，玩转它，并到论坛上去分享，去掀起骂战，让自己快速提升。

节选自《深入理解Android自动化测试》。

xuben

困惑：最简单的脚本谁来写？

两年后，项目结束，我跳槽到一个外包公司，将我外包到微软嵌入式团队，做嵌入式自动化测试。

这里所谓的“嵌入式自动化测试”，是指在只安装Windows core以及某个组件（component），如IE，的基础上对其进行自动化测试。比如自动取款机就是Windows core+IE结构。

要知道，如此简化的系统是运行不起QTP这样的工具的，因为没有.netframework，也运行不起市面上大部分成熟的自动化框架或工具，只能通过最原始的命令行运行。

所以当时我们写的都是批处理（batch）和Javascript脚本，然后通过微软的WTT，将脚本和测试资源导入到测试机后通过命令行运行脚本。

在此之前我通过批处理写过一些简单的批量运行或文件检查的脚本，但在这里，需要通过批处理写出大量复杂的、相互调用的脚本，这让我对批处理刮目相看，也逼着自己把脚本管理和脚本联调的能力修炼得更好。

但我认为，这个阶段真正学到的，并不是脚本管理和联调能力，而是什么人应该编写最基础的脚本。

为什么这样说？

我刚进公司最困惑的一件事是：IE所有最简单的开启、关闭，以及最基本的每个下拉菜单的打开，这类最最基础的脚本，居然是由美国一位大牛负责。

而作为菜鸟的我，却需要编写非常复杂的脚本，比如：打开IE后在地址栏输入某个链接，确认跳转后截图对比，然后将该链接保存收藏夹，将IE关闭后再打开，去收藏夹确认该链接已被成功保存。

我非常郁闷和不服，因为在国内，都是菜鸟写最简单和最基础的脚本，越牛的人写的脚本越复杂，为什么在外企反而倒过来——牛人写简单脚本，每天喝咖啡游泳晒太阳。菜鸟写复杂脚本，每天苦逼累个半死。这还有天理吗？还有王法吗？

结果我领导反问我一句话：你那条复杂脚本有多少人调用？如果出了问题需要紧急停止会造成多大的损失？换句话说，你需要承担多大的责任？

我想了想道：好像就我自己调用，如果紧急停止不会造成太大损失…

我领导继续问：那他那条基础脚本有多少人调用？出了问题会造成多大损失？

我彻底反应过来：他那条脚本全世界不知道多少人在调用，出了问题那还真是蝴蝶效应，估计直接受影响的用例就高达几千条！！！

这件事一直影响我到现在，最基础的脚本谁来负责？值得大家反思。

节选自《深入理解Android自动化测试》

购书链接：http://item.jd.com/11824622.html

Candidate

楼主 你到底是原创 还是节选？

不管了！只求《QTP难点及解答》 那10多页的WORD！

千里

《深入理解Android自动化测试》看起来不错的样子

灰灰渣渣

支持一下

xuben

我觉得没什么遗漏，测试覆盖得很完美。

就这样 ，这些单元测试用例一直执行着，执行着，直到某天我突然看到CTS里Google工程师为播放器编写的单元测试用例，整个人一下就不好了。

不卖关子，给大家看看。

首先是测试资源预置及环境清理总结，资源预置时创建了两个播放器对象并获取相关资源文件，环境清理时释放这两个对象并删除相关资源文件，如图2所示。

图

2  

测试资源预置及环境清理

选自本人《深入理解Android自动化测试》一书

未完待续...

fhhh_eyou

支持分享，学习，谢谢

xuben

回首：自动化最最重要的技能是什么？

2011年，随着以联想乐phone为代表的国产智能手机的兴起，我第一时间来到联想。当时正好赶上乐phone 2代的开发。从那时起一直到现在，我一直做着Android自动化测试。

关于Android的各款测试工具，从被我称之为小李飞刀的monkey，到具备录制回放能力的monkeyrunner，再到自动化屠龙刀Instrumentation和倚天剑UIAutomator，还有那把单元测试的手术刀CTS，一路走来，每一款工具的使用，每一款框架的源码剖析，每一次对框架的二次封装或工具开发，以及一点一滴的反思，都被我记录在《深入理解Android自动化测试》这本书中，感兴趣的童鞋可以自行查阅。

对于软件自动化实践的反思，也可以关注我的微信：巴哥奔，并回复“反思”查看之前那篇文章《软件自动化实施之八个反思》。

很多童鞋认为，从事自动化测试或单元测试，最需要的技能是个人的编程能力，或是对自动化工具的驾驭能力，或是自动化相关的实践经验。

我认为，这些都不是自动化最重要的技能！

从业十年，回头来看，发现自动化测试或单元测试最最重要的技能，就是我当初我怀抱着进入自动化行业的那本Paul C.Jorgensen的《软件测试》。

自动化测试也好，单元测试也罢，说到底，都是软件测试。

举个真实的例子：我刚开始做Android单元测试时，领导让我为媒体播放器（Media player）设计单元测试用例。

当时我想了下，设计了这么几条用例：

1.      Priority 1：播放器正常开启、暂停、停止；

2.      Priority 2：播放器在播放时切换下一首歌、上一首歌；

3.      Priority 3：播放器在播放时突然停止，几种常用格式音频文件播放；

设计完后，我还专门看了一下Android官网针对播放器的状态切换图：

图1 播放器的状态切换图

选自本人《深入理解Android自动化测试》一书

未完待续...

wangwuding

求《QTP难点及解答》 那10多页的WORD！

wangwuding

求《QTP难点及解答》 那10多页的WORD！

tester92

看完后感触很深

Miss_love

老前辈啊

sandy-guo

学习了

wuxi88

也是奇怪了，我的回复也没有提示什么，貌似也没有成功嘛

wuxi88

无论怎么样，觉得写的挺真实，挺好的。