#57 楼 @ansonwoo 我喜欢这种风格，没法让大家都喜欢，抱歉

#53 楼 @lihuazhang 收到

大家有问题吗？期待交流...

#19 楼 @caikaibai 谢谢

#16 楼 @doctorq 写太多了，放不下啊

看完这些，我当时特别汗颜。

一名普通自动化/单元测试工程师与一名优秀的自动化/单元测试工程师之间，最大的差别是什么？

是对软件测试理解的深刻程度。
是对测试理论掌握的熟悉程度。
是对测试技术运用的熟练程度。

一些测试员仗着编程能力较好，看不起基本的测试技术（如边界值、等价类，还有诸如决策表、因果图、状态机等）。

事实上，优秀的测试员首先需要具备的就是扎实的测试技术功底。只有掌握了最最基本的测试技术后，无论做什么测试（黑盒、白盒、自动化、性能或是单元测试），都能游刃有余，设计的测试用例也才能真正深入进入，进而发现隐藏的 bug。

如果不打好这个基本功，哪怕编程能力再好，设计的用例也漏洞百出，发现不了问题的根源。

以 “不同格式视频文件测试” 为例，如果要确保测试到位，就一定要设计各种不同格式的播放文件（类型、编码格式、分辨率、比特率、帧率、音频格式、声道、频率等等），所以有此测试。

大家不难看出，设计这个用例的单元测试工程师是多么的不厌其烦，一点点地从细节上去把控。而很多同学却认为这些琐碎的小事情不值得花时间，或认为没有技术含量而只是草草写上几个，相比 Google 的大牛们，难道不汗颜吗？

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

最后是 “视频录制播放测试”，如图 13 所示。

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

接下来是 “播放器回调测试”，如图 12 所示。

是的，我承认之前完全没考虑到要不要测一下回调是否正常…

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

紧接着是 “字幕切换测试”，如图 11 所示。

好吧，我服了！

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

再下来是 “字幕选择/取消选择测试”，如图 10 所示。

当时完全没考虑到视频，更没考虑到字幕，更没考虑到内置字幕和外置字幕的不同，更没考虑到字幕选择和取消…oh, my god！

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

然后是 “不同格式视频文件测试”，该单元测试用例涵盖了绝大部分文件类型，如图 9 所示。

想想我只选择了几个常用音频格式文件，就无比汗颜，这里不仅选择了不同的类型、编码格式、分辨率、比特率、帧率、声道、频率，而且做了组合测试——请注意，是组合测试！！！

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

再下来是 “录制视频播放角度测试”，如图 8 所示。

呵呵，只考虑播放，没考虑录制后播放，这是我的错…

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

然后是 “视频界面重置测试”，如图 7 所示。

似乎这个测试很简单，但仍然被我无情地漏掉了。

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

接下来是 “无缝播放测试”，如图 6 所示。

不用说，这个方面就更没考虑到。

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

接下来是 “频谱测试”，如图 5 所示。

这里，我发现自己完全没考虑到这些奇葩文件。

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

再下来是 “切换下一首测试”，如图 4 所示。

看到这里，我发现单纯的音频切换，我只做了基本状态检查，其他状态检查都没有覆盖到。

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

然后开始测试，先是 “空文件及音视频播放测试”，如图 3 所示。

看到这里，我发现我漏掉了空文件播放这个边界值，也忘记了视频播放测试。

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

不卖关子，给大家看看。

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

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

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

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 官网针对播放器的状态切换图：

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

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

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

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

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

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

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

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

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

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

为什么这样说？

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

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

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

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

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

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

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

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

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

#49 楼 @350705144 谢谢

#46 楼 @sandman 大概有多少呢？你们黑盒用例分优先级吗？优先级最高的用例是否都已覆盖？

#44 楼 @sandman 哈哈，不错，乐视很多联想人呢，我好多同事都在那边，不过你们自动化环境这么好，的确出乎我的想象。你们现在自动化测试的 case 覆盖率如何？

#38 楼 @sandman 你很幸运啊，在什么公司？