作为一名测试人员，提交缺陷是我们必须做的功课。不知各 位是否考虑过，缺陷描述也是一门“艺术”，它影射了一个人的测试经验，测试深度。缺陷描述能否做好，直接影响了我们的测试效率，更确切的说是影响了开发人 员修改缺陷的效率。一份高质量的缺陷描述让开发人员看的时候是一种享受，可以提高他们的工作效率；而一份让人费解的缺陷描述，不仅会让开发感到无从下手，还会降低对测试人员的信任度。因此说，一份好的缺陷描述，体现了一个测试人员的基本素质。

傻哥博客中一篇文章《如何编写高质量的缺陷描述》让我对如何提高缺陷描述，有了点自己的一点想法，赶紧拿出来和大家分享一下。下面是傻哥文章中举的例子，一个关于资产财务月报折旧数据不对的缺陷，各个测试人员提交的内容。

　　从上面的例子可以看出，一个缺陷竟然出现5种说法，如果你是开发人员你想看哪位测试人员的缺陷，肯定是第5位了。不仅清晰的描述出了系统存在的缺陷，还直接帮开发人员找到的缺陷的根源。可能你还会想，不管在怎样，我已经把系统中存在的问题描述出来了，开发总会找到原因的，下面，我们再来看一下，开发对于这5个缺陷的回复。

　　可能有些调侃，不过我想这些情况在大家的工作中一定都遇到过。对于一些，描述不清或不准确的缺陷，往往都被开发拒绝掉。对于这些，我总结了几点自己的经验：

　　一、追根溯源。缺陷也存在表面现象和真正原因，我们不仅仅应该看到它在系统中表现出的表面现象，还应该通过一步步的分析，找出缺陷产生的真正原 因。有时可能通过多个测试用例才能发现，有时可能还要在多个表中查找才能查出。作为一名测试员，我们应该本着认真负责的态度，去发现任何细小缺陷的真正根 源。

　　二、面面俱到。详细的描述缺陷产生的真实情况。作为测试人员，我们对于业务要比开发人员熟悉太多。有时候，对于一个缺陷的产生过程，总以为简单描述就可以，殊不知开发人员对你”跳跃性“的步骤，往往是一头雾水。因此，我们在描述时，要尽可能的详细。

　　三、简明扼要。可能听起来和第二点有些矛盾，可这确实是我们应该注意的地方。开发的周期都是相当紧凑的。我们应该用最简单的语言描述缺陷，可多用短句，保证逻辑上的清晰。

转：http://blog.csdn.net/not_a_baby/article/details/6743300

[转]缺陷描述是这样提高的