当设计好用例、数据准备好后，就可以将设计好的成果应用于软件，如果在执行用例的过程中，发现软件执行的结果和测试用例中的预期结果不一致，那么，这就是软件缺陷即我们通常听到的软件bug，我们需要把该缺陷报告给相关开发人员进行修改，如何报告呢，即需要记录缺陷，也就是我们通常所说的缺陷报告。那么缺陷报告包含哪些内容？
缺陷报告模板
缺陷报告通常包含如表所示的内容：
缺陷报告模板
此模板仅为众多缺陷报告模板中的一种，并不是缺陷报告的标准。读者应根据公司的实际情况来制定合理的缺陷报告模板。
以下，针对严重程度和优先级来进一步阐述。
-
缺陷严重程度：表示软件缺陷所造成的危害的恶劣程度 。缺陷严重程度的分类在不同的软件公司，分类有的也不同，在此给出一种分类，内容如下：
-
-
Fatal：致命的错误，造成系统或应用程序崩溃、死机、系统悬挂，或造成数据丢失、主要功能完全丧失等。
-
Critical：严重错误，主要指功能或特性没有实现，主要功能部分丧失，次要功能完全丧失，或致命的错误声明。
-
Major：主要错误，这样的缺陷虽然不影响系统的使用，但没有很好的实现功能，没有达到预期效果。如提示信息不太准确，或用户界面差，操作时间长等。
-
Minor：一些小问题，对功能几乎没有影响，产品及属性仍可使用。
-
Suggestion：一些友好的建议。
-
-
缺陷优先级：表示修复缺陷的先后次序的指标。优先级的分类在不同的软件公司，分类也不尽相同，一般优先级的划分用ABCD或数字1—4表示，A或1表示最高级别，D或4表示最低级别。
-
-
n 最高优先级：立即修复，停止进一步测试。
-
n 次高优先级：在产品发布之前必须修复。
-
n 中等优先级：如果时间允许应该修复。
-
n 最低优先级：可能会修复，但是也能不修复。
-
缺陷报告流转过程
将缺陷报告提交给相应的开发人员，最终目的是为了能够进行缺陷的修复。那么软件缺陷究竟要经过怎样一个流转过程呢？以下，结合图所示的流程进行介绍。
缺陷流转过程
通常，软件缺陷的处理需经过如下过程：
1）软件测试人员提交缺陷报告；
2）测试经理审核后将缺陷报告分配给相关的开发人员修改；
3）缺陷被修改后由测试人员根据缺陷报告中的修改记录进行返测；
4）返测通过的缺陷报告由负责人关闭，返测未通过的缺陷报告直接返回开发人员重修修改，缺陷报告直到缺陷被修复以后才关闭。
以上仅是描述了一种缺陷报告的处理流程，在实际工作中应根据实际情况进行处理流程的调整。
本文转自hblxp32151CTO博客，原文链接：http://blog.51cto.com/starpoint/1308715，如需转载请自行联系原作者
