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