测试进行一段时间后，大家发现阿毛报告的Bug比较多，九条其次，小燕最少。阿亨让测试人员交流一下各自的经验。

　　阿毛：我的原则是 “如果问题看起来像一个Bug，那我就要报告这个Bug”。宁可多报一千，也不放过一个。这个原则也导致了我的Bug 有不少被归为“As Design”。

　　阿亨：“As Design”也不是什么坏事，至少我们明确了Design 是什么。这样以后就有依据了。

　　小燕：我发现了一个问题，都是先跑去找开发人员商量是什么情况。或者自己研究，想找到问题的根源，有时自己想到如何修复，之后再报告Bug。

　　九条：小燕的做法，似乎越界到了开发人员的职责范围了。我们的职责就是找到足够多的Bug，让开发人员有事可干。

　　阿亨：可以选定一个典型用户（Persona），然后按照典型人物的思路和看问题的角度，把整个系统的各项功能都经历一遍。如果有什么你觉得典型用户不满意的，那就可以考虑开一个Bug。我有时知道这个功能的设计想法，但是在测试的时候没必要替别人考虑太多，要把自己当成用户，而不是设计者。

　　阿毛：测试的时候，要各个角度都试试看，一些犄角旮旯也得用一些随机的数据去捣捣乱。黑箱、白箱都可以换着玩。就像对软件一窍不通的用户在使用软件一样。

　　阿亨：阿毛的这一个经验，用正式的语言描述就是——保证测试方法的多样化。

　　九条：我拿到一个测试任务，就想——这个功能最可能出问题的会是在什么地方？然后就集中火力，在容易出问题的地方测试。比如，如果一个产品的标题长度规定是32 个字符，那我就测试31、32、33 个字符，看看在这种边界条件下是否会出问题。

　　阿毛：测试的时候还要举一反三，看到产品标题字段出了问题，我就会检查一下别的字段有没有类似的问题。

　　阿亨：对，我们要注重从产品的风险出发，进行测试。还有，我们要根据当前的产品特性来决定测试的策略，不必强求一律，举一反三很重要。

　　阿毛：有时候我测试自己负责的功能比较多了，就想和别人换一换，有点新鲜感。不料小燕拒绝了我的交换请求，说是没经过领导批准，是侵官之害。我只好和九条交换。

　　阿亨：我批准这样的交换，关键是找到Bug。我们都是同一类工作人员，在事先通知和安排好的情况下，不存在“侵官之害”的问题。

　　小燕：我发现随着Bug 的增多，我又要验证以前的Bug，又要发现新的Bug，工作量越来越大，你们都怎么办？

　　九条：我一般都把一些比较稳定的测试写成自动测试，这样就减轻了我手工测试的压力。