越来越rely on Code review and Debugging （一）

有的时候觉得有些不好意思，因为作为一个刚刚具有中级title的我来说，却给大家讲高级测试的内容。自己也想了想，其实自己目前的工作还是处于中级阶段，并没有什么太多高级的内容，包括Security testing也不算什么高级。

我现在觉得测试的初级阶段测试specific的内容占了很大的比重，中级阶段则是dev的内容占了很大的比重，而高级阶段是应该超越test和dev的阶段，从而test和dev合一而更强调的是impact, influnce和leadership。在我的初级阶段，我跟很多人争论自动化测试的重要性等等，而在我的中级阶段我自然地就不去争论这个话题了，从而争论dev的重要性。到了目前的阶段，我也不会再跟其他人争论什么automation, coding这些内容了，因为他们太基本了，已经不是我所应该关注的内容了。对于初级测试人员的提问，我觉得最好去我的那本书中寻找答案，我觉得我已经把我的观点完全表达清楚了。而以后我的文章还是会集中在中级测试的内容，因为我离高级测试还是有不小的差距，希望过两年能弥补上。既然我说过中级测试阶段dev的内容占了很大的比重，因此我的文章某种程度来说对开发人员也有一定的意义。

在我的安全测试文章系列，我本来想在第三篇文章介绍一下fuzzing test，这个在安全测试最常用的测试方法。可是在我还没有时间开始写这篇文章的时候我就对他失去了兴趣，因为我发现了更efficient的方法就是Code review+Debugging。举个例子，有一个安全漏洞我通过code review大概在两个小时的时候发现的，而我通过fuzzing是在60多个小时发现的。Fuzzing的要求是运行48小时，而这个bug是在48小时以外发现的，也就是说如果我只运行48小时是发现不了这个bug的。无独有偶，在一个presentation上，在大家都讨论dumb和smart fuzzing的时候，我们team唯一的senior测试发表的fuzzing with brain的言论，就是利用code review和debugging来进行安全测试的。

下面我想先谈谈Code review和Debugging在测试中的重要性。

Code Review: 我们知道无论你手工测试用例设计的多好，无论你的自动化测试多么优秀，你的code coverage都不可能达到100%。我们CC的要求是70%，有些binary是很难达到这个要求的，而有些binary则可能接近90%，根据我的个人经验。也就是说，无论你如何测试，你至少都会有10%以上的code不能被cover，不能被test到。而Code Review则是一个很好的补充，从而可以使得产品得到更全面的测试，尤其是安全测试方面。记得《Writing Secure Code》的作者去一个公司做咨询schedule了一个小时的code review的meeting。在这个meeting之前，他们的dev manager就跟他说，这一个小时是浪费时间，因为他们雇佣了最聪明的程序员，他们自己进行了几轮的code review，没有发现一个bug。而作者说既然已经schedule好了就先开15分钟的会，看看情况再决定是否继续开下去。结果是在这15分钟里，作者通过code review抓出了10几个security的bug，最后这个会议延长了几个小时，而这个公司的员工觉得学到了很多的东西。可见对于一个有经验的测试人员来说，通过code review测试是多么的efficient。我自己最近也发现，我code review总会很容易地发现一些bug，而这些bug是在手工测试和自动化测试很难或者不可能发现的。

Debugging：我们设想一下目前最典型的test和dev的工作模式。

1. Tester: find a bug
2. Tester: try to repro
3. Tester: find repro steps
4. Tester: file a bug
5. Dev: try to repro
6. Dev: communicate with tester if non-repro
7. Dev: debug，investigate and find root cause
8. Dev: fix bug

我们有一定经验的测试人员可能都深有体会，在step2和3中，有时候非常麻烦。有些bug很难repro，有些bug甚至就发生过一次，你根本没有办法完成3。从而即使file了bug，dev也没法进行step7的工作。而由于test和dev的工作环境，机器设置等等的不同，dev往往不能repro要跟test交涉，也就是step6往往要浪费大家很多的时间和精力，甚至搞得test和dev关系出现紧张和裂痕。那么我们如何建立一个更加efficient的工作模式呢？这就要靠tester的debugging能力了。目前我的工作模式如下：

1. Tester: find a bug
2. Tester: debug, investigate and find root cause
3. Test: file a bug
4. Dev: fix bug

由于tester负责debug和investigate的工作，从而repro steps就不是那么重要了，因为dev面对的bug里就会列出root cause。甚至tester可以给出fix suggestions。而由于tester帮助dev进行了大量的琐碎工作，dev也会非常appreciate it的，从而加强了双方的合作与信任。通常dev的fix也会邀请tester来做code review的。

有的人会说，我们公司的工作模式就是前一种，你提到的后一种根本不用，也不现实。而我的回答是，你们整个公司不用不带表你不可以用，也没有人可以阻止你使用，自己的技术发展，自己的职业规划最终还是要靠自己。