如何让缺陷填写的更加规范

　　1、目的

　　缺陷记录是软件测试生命周期中最重要的可用产出之一。因此，怎么填写有效的缺陷是非常重要的。一般来说，一条好的缺陷记录至少有以下3个方面的积极作用。

　　(1)减少测试人员和开发人员的沟通成本。

　　(2)加快缺陷修复的速度。

　　(3)增加测试的可信度。

　　缺陷记录的最终目的是准确地传达测试人员的思想或缺陷的真正所在。只要遵循本规范中的一些简单原则，我们就可以轻松的填好每一条缺陷记录，从而提高工作效率。

　　2、适用范围

　　3、填写缺陷规范

　　3.1 缺陷概要规范

　　缺陷概要需以简洁的语言表述准确的信息。那么能准确表达意义的缩略语在描述中则具有更高的优先级，一些关键词如“程序崩溃”、“系统无反应”和“文字错误”等，在把缺陷概要作为检索条件的时候，显得非常必要。

　　3.2 缺陷描述规范

　　缺陷描述需要遵循以下7个要点：精练、正确、中立、准确、普遍性、可再现和有证据。

　　3.2.1 精练

　　缺陷记录的描述需简单明了。不加入与问题无关的叙述，去除不必要的信息。但同时，要涵盖所有必要的信息。

　　3.2.2 正确

　　一定要清楚你所记录的缺陷的确存在。在提交前，请先考虑如下5个问题：

　　(1)我对系统需求是否真正理解?

　　(2)是否安装和系统相关的软件?我的机器设置有没有问题?

　　(3)是不是我手动设置的某个地方不合适(被测软件本身的设置)?

　　(4)是不是我以前测试时遗留的错误数据导致的错误?

　　(5)会不会是网络状况变化引起的问题?或者其它外在环境因素(如防火墙)引起的错误?

　　以上这些都对测试的结果有很大的影响，确认这些问题是否存在。

　　3.2.3 中立

　　客观地描述每一个缺陷，不要带任何情绪化的语言。在提交一个缺陷记录前首先把它通读一遍，确信你的描述没有伤害到任何人员。

　　3.2.4 准确

　　缺陷记录需要准确的描述缺陷发生的位置，产生条件和结果。最好做到让阅读缺陷记录者不需要亲自上机操作就知道问题所在。

　　3.2.5 普遍性

　　记录缺陷需要明确的描述出该问题在整个系统中普遍存在的地方。通常，当开发人员修改缺陷的时候，他可能只是修复了你提到的一些特定情况，他并不知道这个问题具有普遍性，尚需更大范围的修复。

　　3.2.6 可再现

　　原则上所提交的缺陷都应该能够重现。对很难重现的Bug，你应该记录下什么情况下可以再现它，列出再现Bug的所有步骤，执行次序以及所需要的数据等。

　　如果你无法再现这个Bug，或者是你怀疑某些条件你还没有想到，你应尽可能的把那些认为可能有用的信息描述清楚。

　　一个缺陷在你重现它以前，不要假设它是可以重现的，如果你确实无法重现它，在缺陷记录中明确说明也是很重要的。

　　在考虑对缺陷的重现时我们应该注意以下3点：

　　(1)怎样才能以最简单的方式把缺陷重现。对于难重现的缺陷，这常常是个漫长而费时的过程。

　　(2)是否有外在的原因在测试中导致了该缺陷。例如是否和其它软件相冲突的情况。

　　(3)如果在测试中要输入很多值，尽量在大量的输入中找出导致缺陷的那些特定值，并准确地写出那些导致缺陷的输入。

　　3.2.7 证据

　　对于一些数值型的、暂时不能重现的和难以描述的缺陷等，最好提供可以证明它存在的数据、图片和文挡等证据。对记录的缺陷，就应该确信这里的确存在缺陷并提供所有你能提供的证据，说服别人这里确实存在缺陷。这些证据可能来自于系统数据、现场截图以及需求文挡等。当然这也有利于关闭缺陷和做回归测试的时候重现该缺陷。

　　3.3 缺陷属性规范

　　缺陷属性需要根据不同的软件项目定制不同的属性值。

　　必须的属性值有：DefectID、Subject、Status、Severity、AssignedTo、Summary、DetectedBy、DetectedonDate、DetectedinVersion和Detectedphase。

　　3.4 缺陷填写建议

　　在填写一条缺陷记录的时候，提醒你参考以下2点建议：

原文转自：http://www.uml.org.cn/Test/201203192.asp