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

  • 大家有问题吗?期待交流...

  • #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 自动化测试》

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

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

  • #38 楼 @sandman 你很幸运啊,在什么公司?