Question

接下来我们说测试，不光是测试人员的日常测试工作，还包括开发人员组织的自测工作。

10.5.1　冒烟测试

真正的冒烟测试，是针对修复了一个bug而进行的一系列专门的测试。我接下来说的冒烟测试机制，并不是这个意思，只是为了好听，叫起来朗朗上口，就像前几天我去饭店吃饭，那里有道菜叫枫桥夜泊，其实就是把牛肉块炖一炖，吃的就是那份雅致。

当开发人员开发完成了所有功能，接下来的几天，将主要是测试团队提bug、开发人员修bug的过程。这期间，开发人员是比较空闲的。不要安排开发人员去做新的需求，而是每天找一个时间段（一般一个小时），把他们集中起来，围坐在一张圆桌上，把App的所有功能都测一遍，我们称之为“冒烟测试”。

原本我是想帮着测试团队一起做测试的，因为开发人员都比较自信，他们在测试自己的代码时会漫不经心，但是大家都集中测试一个功能时，其他开发人员就会像见到杀父仇人一样，拼命找对方的问题，那种成就感真是妙不可言。

当然了，为了不至于把气氛搞得太紧张，我每次都买些黄飞红或者橘子来作为奖赏。有人提议发现bug奖励一碗牛肉面，被我否了，因为发现两个的时候，总不能给一个人买两碗吧，加一份肉倒是可以考虑。

“冒烟测试”主要是解决测试人力不足、覆盖场景不全的问题。在移动互联网公司，开发测试比大约是6:1，由于很多功能都是集中在最后几天提测，所以测试人员越到后期越紧张，而开发人员介入测试工作，是对产品质量的保证。

起先我只是尝试解决迭代后期开发人员闲置的问题，但几次迭代后我发现这种“冒烟测试”能发现很多bug，于是便将其纳入到敏捷开发流程中。

后来我们开发团队做过一次代码重构，把JSONObject全都换成了fastJSON，并重写了部分页面的逻辑。但是发版后却发现很多地方显示有问题，最后只好紧急修复、重新发版。事后我们痛定思痛，如何没有在发版前发现这些问题？测试工作固然没有做好，需要另外总结，但是开发团队的“冒烟测试”也没有发现问题，形同虚设，问题又出在哪儿呢？

问题的根结在于，每次冒烟测试的时候，我们都只拿一台测试机安装了最新的开发版本进行测试，并不知道线上版本长得是什么样子。于是我们就改进了冒烟测试的方法，每次都拿两个手机进行比较测试，一台手机上当然是最新的开发版本，另一台手机，有人会拿线上的版本，也有人会拿iPhone和Android对比着看，总而言之，就是要检查本次迭代是不是改坏了什么地方。我们后来称之为“找不同”——因为我是在游戏厅玩“找不同”时想到的这个办法。

执行“找不同”方案后，我们还发现了Android和iPhone上很多数据显示不一致的地方，有些是Android一直就有的bug（iPhone也有一直不对的地方），经过和产品经理确认后，就一并也改正了。

大约在3次迭代之后，那时候同时进来很多新的开发人员，他们需要熟悉业务逻辑但是又没有什么文档可供参考学习，当时的办法就是让他们一起参加冒烟测试，每测到一个模块，就请该模块的负责人把业务逻辑讲一下。不光是培养了新人，对于长期做某个模块的开发人员，也是需要了解其他业务模块的，而冒烟测试是最好的培训课，我清晰地记得，第一次迭代，冒烟测试用了5天时间，每天1个小时测一个模块，遇到的问题大都是点着点着就崩溃了，到了第7次迭代时，每天冒烟测试还是一个小时，但3天时间就够了。问题越来越少，App的稳定性已不再是问题，iPhone和Android的数据展示和业务逻辑也基本一致了。

有人兴许会问，测试工作应该是测试团队要做的啊，开发人员更多的是开发工作。其实不然，我的经验告诉我：

1）测试团队经常面临资源不足的情况，尤其是Android和iPhone同时发版。

2）开发团队没有那么多的开发工作要做，因为产品团队经常会没有太多的新需求。

3）App不同于MobileAPI开发。MobileAPI开发可以使用单元测试来保证质量，但是App就很难做单元测试了。也就是说，App前端开发人员并没有做单元测试的Task，那么这些时间要用来做什么？

4）App自动化测试的事情就别指望了，那是大公司才愿意投入大量人力去烧钱的事。尤其是互联网行业，需求变动频繁，往往是刚写好一个自动化测试用例，一次迭代后就废弃了。

10.5.2　探索性测试

前面介绍的开发人员自发组织的“冒烟测试”，其实就是探索性测试，只是执行人员是开发团队而不是测试团队罢了。

测试团队在新功能测试结束后，应该做一轮探索性测试。操作方法和前面介绍的“冒烟测试”类似，把所有测试人员组织在一起，逐个模块进行测试，可以每天一小时，分为3-4天进行。这样就确保了有bug可以及早发现，而不是等到最后一天全功能回归测试时一次性提出几十个bug。此外，测试团队所有成员都参与，可以保证每个测试人员对每个模块都熟悉，而不是长期只负责自己那个模块。

10.5.3　Monkey测试

Android项目每天下班前都要跑Monkey，然后每天会有专人分析Crash日志。Crash一般分三种：

1）代码逻辑上的空指针，这个比较容易看出来，有助于我们查找bug。

2）系统问题，比如说不同手机ROM，问题也不太一样。

3）ANR，这个就没办法了，因为在A页面发生的ANR，并不一定是A页面的逻辑导致的，可能在前面很多页面持续积累下来的内存占用过多，就像我的一个兄弟说过的，A页面可能是压死骆驼的最后一根稻草。

编写Monkey脚本，我们要注意几点：

1）要把App中的电话拨打按钮都禁止。否则就会因为误点了电话按钮而跳出App。

2）要确保Monkey能进入到App的所有页面。

有些模块、有些页面因为层级比较深，所以Monkey进入的概率比较小。我们可以订制Monkey包，让Monkey每次只跑一个模块。

比如说首页由8个模块的入口，我们为每个模块创建一个开关，如果今天我跑Monkey只想进入第8个模块，那么我就把第8个模块对应的开关设置为true，其他7个都设置为false。这样App运行时，首页就只有第8个模块可以点击进入，其他页面因为开关为false，所以都不可以点击。

3）有很多页面需要用户登录后才能进入。为了让这些页面也能跑Monkey，我们需要每晚跑Monkey的包与发版到线上的包略有不同。

最简单的做法是，在程序中新建一个变量isMoney，以标记当前打的包是否为Monkey所准备的。在Monkey包中为true，在正式包中为false。

那么在登录页，我们把代码改为如下形式：

if(isMonkey){
  password=baobao
  userName="qwer";
}else{
  userName=etUserName.getText().toString();
  password=etPassword.getText().toString();
}

也就是说，如果是monkey包，我把用户名和密码写死在程序中，这样Monkey点击登录按钮肯定能够成功，接下来就能进入其他用户相关的页面了。

但是后来我们发现一个问题，这段含有用户名和密码的代码会一起编译到线上的包中，即使做了代码混淆，用户名和密码在反编译后还是能看到的。这是极不安全的。于是便有了解决方案2：把用户名和密码放在一个文件上，每次读取这个文件。对于跑Monkey包的测试机，要把这个文件事先存到SD卡上；正式包就不需要这个文件了。

这是我们开发人员一厢情愿想出来的办法，按照这个思路把代码改写完才发现，跑Monkey包的测试机上大都没有SD卡。

于是我们在碰了一鼻子灰之后，给出了终极解决方案：

在打包脚本上做文章。把这个文件放在项目中。只有Monkey包才会在打包时把这个文件包含进来，而正式包不会包括这个文件。这样就彻底解决了安全性问题，只是编写打包脚本时要额外小心，同时，在每次发版前，都要检查一下apk包中是否有这个文件。

4）要把设计支付的按钮都禁止，以防止在线上下单而造成的各种纠纷。