缺陷描述是这样提高的

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

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

人员	缺陷描述
测试员1	资产财务月报折旧数据不对。
测试员2	资产财务月报折旧数据跟资产台账明细的折旧数据之和不等，差287.53元。
测试员3	资产财务月报折旧数据不对，zc_zjjl（资产折旧记录）和zc_yjjl（资产月结记录）折旧额不等。
测试员4	只要出现资产重置，资产财务月报折旧数据跟资产台账明细的折旧数据之和就不等。
测试员5	资产财务月报折旧数据不对，经查发现资产重置以后，资产月结的时候和zc_yjjl（资产月结记录）的重置金额未更新，折旧金额还是按照重置前的金额计算，造成资产月报数据不对。月结处理算法不对，请修改。

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

人员	开发人员回复
测试员1	我这里测了一下，折旧数据是对的，不是缺陷。
测试员2	我这里测了一下，折旧数据是对的，不是缺陷。
测试员3	我开发库里的这两张表数据是对，请再确认一下。
测试员4	晕，我查了两个小时，我的财务报表是对，是张三的月结处理的算法是错的，请提交给张三。
测试员5	张三回复：兄弟辛苦了，中午一起吃饭。

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

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

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

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

（以上言论仅代表作者的个人观点，不代表51Testing观点）

http://www.51testing.com/html/47/n-212047.html