15.12本章讨论

　　15.12.1韩昭候

　　果冻：韩昭候真过分！我很好心地帮助别的同事，没有功劳也有苦劳，他怎么能说“甚于寒”？这样我的心都寒了。

　　阿亨：果冻，你不是有“各司其职”的笔记么，好好看看。

　　九条：谢谢你的帮助，你如果急需验证某些问题，可以告诉我，我会安排尽量早日完成。

　　15.12.2测试经验交流

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

　　15.12.3传说中的拐点

　　小飞：我听说在软件项目中，有这样一个拐点存在——在这一点之前，新的bug产生的数量大于bug解决的数量；在这一点之后，bug的解决数量大于新的bug 产生的数量。这样bug的曲线就向下移动。我们移山项目的拐点到了么？

　　阿超：我也听说过，不过我们不能等待拐点的到来，对于我们这样的日期驱动的项目，拐点必须在发布日之前的若干时间发生，如果我们的bug 数量还是继续向上攀升，我们无法保证以后曲线会像悬崖一样掉下来。我们就得主动让拐点发生，例如推迟一些bug，砍掉一些功能，等等。