译释Dozen ways to find bugs(7)——Corner Bugs

        英文原文名叫《A Dozen Ways to Get the Testing Bug in the New Year》，是Aaron在java.net上发现的文章。原文地址http://today.java.net/pub/a/today/2004/01/22/DozenWays.html，原文是在2004年1月22日发表的，按常理说一片早已经过了时效期的文章是没有多大用处的，但是Aaron却认为时至今日该文依然值得一阅。

     在还是测试菜鸟的时候，我们就被告知：即使经过很专业很完备的测试，也不可能造就“零缺陷”的软件。在软件的开发过程中，或许我们做了很多测试工作，建立了很完备的测试框架来测试我们的应用程序，但当软件交付使用之后，客户（用户）或者其他的某个人总还是会在我们的软件中找到bug。好了，够了，不要让这些因素影响到我们继续测试下去的信心，相反我们应该抓住机会来提高我们的测试技能。一旦我们发现了一个bug，我们需要将这个bug报告到缺陷管理系统中去并要求修复该bug。如果你拥有一定的编程基础的话，你可以在阅读代码的时候快速定位那些（可能）有问题的代码行；紧接着我们打开我们最喜欢的代码编辑器，开始着手对这些代码做一些必要的修改。但是，请注意，在你做这些之前，千万不要错过控制住这个bug的绝佳机会。（我们需要为已发现专门添加一些测试，如果我们还没有相关的测试的话，我们需要确保在bug被修复之后依然处于我们的监控范围之内，决不能让之前发现的bug再次出现在一个Release中，Aaron注）。 

    那么怎样才能知道我们对于代码的更改确实是干掉了这些bug呢？我想，在对代码作出更改之前，你必须了解改正后的代码应该达到哪些期望。我们可以通过测试来达到这一目的，我们将这些代码期望转化为自动化测试。当所有的测试通过的时候，就是我们确认这个bug被干掉的时候。此外，当测试通过的时候，我们也拥有了一种自动化的方法（自动化的回归测试）来确保这些已知的bug处于我们的掌控之中。

Aaron后注：

    其实，作者想要表达的意思很简单：我们不能发现所有bug，所以当客户在我们的软件中发现bug的时候，是可以原谅的，但是——第一次可以原谅，第二次是万万不可原谅的。为已知的这些bug建立相关的测试用例则是避免悲剧第二次发生的最佳方法。