如何有效地描述软件缺陷(Defect)？

最近一个月偷懒了，刚看到一篇博文很不错。最近也是碰到一样的问题，由于我记录bug的描述不够清晰。导致开发看不懂我描述的bug，还有一些配置信息没记录好。出现一问三不知的情况，还被领导训。下面的博文是来自http://blog.csdn.net/xifeijian/article/details/8363570的。

--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

作为软件测试人员，最基本的一项技能就是如何把所发现的缺陷(Defect)准确无歧义的表达出来，尤其还是全英文表达的时候。

　　其实从缺陷的描述也可以看出一个软件测试人员的基本功，甚至可以看出测试人员在做一些自由测试的时候的投入程度。

　　本文主要以缺陷出现的频率来说明测试人员在遇到不同频率的缺陷的时候如何做?

　　缺陷的频率主要有：Always, Usually(>50%), Sometimes(<50%), Once

　　对于所有的缺陷，都需要做到的是：

　　1，查看当前测试环境和测试数据，并记录下来。

　　2，记录与该缺陷相关的配置等条件

　　3，记录出现缺陷时候log信息

　　4，描述尽量做到每个步骤最多两个动作，一连串的操作尽量分句说明。

　　5，英语表达尽量用主动句型，体现操作性。

　　6，缺陷出现时候的现象一定要描述详细，不要和步骤混在一起描述，一个步骤最好对应一个相应的输出结果

　　7，缺陷出现之后若可以继续进行操作，也尽量多做几个步骤，这样更容易发现当前缺陷周围的缺陷，8/2原则或许在这里可以起到作用。

　　8，尽量把缺陷出现时候的相关功能运行情况也都描述详细

9，对于一些比较难描述清楚、或者不能稳定重现的缺陷，在缺陷中需要添加出错时截图，所谓有图有真相。

10，缺陷描述的终极目的，先抛开缺陷记录的管理意义不说，主要是能让开发人员根据缺陷描述，轻松地重现缺陷

　　对于Always和Usually这类容易重现的缺陷，除了以上必须做到的，还需要做到

　　1，按照缺陷重现的步骤重复做3次以上，这样可以寻找最短的重现路径，可以做到把不必要的过程过滤。(注意：不确定的步骤一定不能过滤)

　　2，同一缺陷现象出现在不同的地方，尽量能够做总结，可以把不同的步骤分别写出。

　　3，缺陷描述以及缺陷出现的各种环境等尽量做到简介且全面，不需要总等到开发人员问。

　　对于Sometimes的缺陷，理论上来说缺陷都能重现出来，所以我们遇到的sometime只是目前还没有找到必然的那个路径。

　　若与开发人员是在一起工作的比较好，遇到这类缺陷的时候，可以和开发人员沟通，简单描述一下，共同推测必然出现的路径。找出更多重现的路径就有可能转为Always或Usually，开发人员解决起来就容易些了。重现不出来，至少也需要把所有遇到缺陷的相关环境都详细描述出来。

　　若与开发人员不在一起工作的，那就尽量把缺陷出现时候的各种log信息作为缺陷附件提交。

　　对于Once的缺陷：偶尔出现一次的缺陷，就是短时间内测试人员自己没有重现出来的，测试时间有限，考虑成本问题，也不可能允许你一直去分析。

　　这样的缺陷，我们测试人员能做到的首先跟开发人员沟通，有时候开发人员看一眼log就知道问题所在甚至推测出必然路径的。否则，我们能做到的就是把上述1-10条把缺陷记录在库，在后续多个版本进行验证(Verify)。

　　作为测试人员，遇到缺陷的时候除了把缺陷描述简洁明了之外，我们更需要做到的是：

　　1.尽量做到及时和开发人员沟通(尤其对需求不确定的情况)

　　2.立刻检查当前状态并做记录(不要间隔时间太长，发现的时候立刻记录，好记忆不如烂笔头)

　　3.如果同样的步骤连续发生好几个缺陷，需要把每个缺陷的频率都标注好

　　4. 如果有外部网络或者设备等因素的影响，也尽量把外部环境描述清楚(这样有助于开发人员Fix缺陷)

　　作为测试人员的我们，目标只有一个——软件产品质量。 我们不但要发现问题还要协助开发人员解决问题