每周一问&及时反馈

         大家好，又到了每周一问的反馈时间了，当然，这个＇又＇字用的不贴切，毕竟这种反馈从未发生过。先回到问题：什么样的缺陷是一个好的缺陷？

         我们来看下观众朋友们的回信，首先这一位是来自自动化测试界的朋友，跨界回复实属不易啊，这位selenium哥主要有两个论点：a.bug本身无好坏之分；b.如果硬要贴上好坏标签的话应该是先发现的bug比后发现的bug更应该成为一个好bug。我们来点掌声，这样就可以打发掉这位朋友了……

         我们再来看下一位观众朋友的回信，这一位是来自于测试管理界的朋友，事必躬亲的精神也是值得推崇的，这位老大从成本上考虑，要求bug的书写、书写、还是书写，毕竟这是减少沟通成本的必杀技，具体请各位参看邮件原文。

         那我斗胆总结下：

         一、书写规范：毕竟bug作为一个成果它是用来给人看的，不论bug以何种形式管理，工具也好、文档也好，它必须有它自身的格式规范和书写规范，主要的格式规范是要写明Bug单编号、bug严重程度、优先级别、用例编号、重现步骤、附件、触发原因、发现人、发现因素、模块、环境、版本号等等，需要做到清晰准确。就拿bugzilla来讲，摘要要简明、描述要有条理、重现步骤要清晰、附件要准确等等等等等……千万不要惜字如金而口水吐沫不要钱，口头的沟通成本是远远大于文档成本的。

         二、隐藏缺陷：测试没有穷举，当然我们也不可能发现所有的bug，那么相对于bug本身来讲，如果这个bug足够隐藏，它逃过了需求、交互、设计、开发甚至大部分测试的法眼，最终它还是被发现了，那再结合它的严重级别、影响度，它就有可能是一个好bug。

         三、缺陷再利用：缺陷是一种资源，用例复用是一个经久不衰的论题，同样bug也是可以重复利用的，当然这和reopen是两个概念，这里所讲的bug再利用，是指代表性的bug是可以帮助其它系统去发现问题的，有可能起到一定的缺陷预防作用，例如缺陷模型。

         四、缺陷的衍生意义：有这么一句话“通过对bug的分析来找出过程中的不足，从而改进我们的过程，达到缺陷的预防。”如果我们发现一个问题，结果最终讨论的结果是，这个问题应该在需求评审的时候就被发现，但是最终它逃过了众家法眼，在测试阶段才被揪出来，这时候我们如果回头想想，是不是我们过程出了问题，是不是需求评审不够仔细，是不是邮件评审没有会议评审来的好，这样子我们就可以在结项时去探讨这个问题，帮助我们进行过程的改进，也起到一定的缺陷预防作用。

         欢迎拍砖，欢迎挑错，没准你挑的就是一个绝世好bug……