软件缺陷的描述是是软件缺陷报告的基础部分，也是测试人员就一个软件问题与开发小组交流的最初且最好的机会。一个好的描述，需要使用简单的、准确的、专业的语言来抓住缺陷的本质。否则，它就会使信息含糊不清，可能会误导开发人员。准确报告软件缺陷是非常重要的，因为：
?
?
?
?
清晰准确的软件缺陷描述可以减少软件缺陷从开发人员返回的数量 提高软件缺陷修复的速度，使每一个小组能够有效的工作 提高测试人员的信任度，可以得到开发人员对清晰的软件缺陷描述有效的响应 加强开发人员，测试人员和管理人员的协同工作，让他们可以更好的工作
在多年实践的基础上，我们积累了较多的软件缺陷的有效描述规则，主要是：
?
?
?
? 单一准确。每个报告只针对一个软件缺陷。在一个报告中报告多个软件缺陷的弊端是常常会导致缺陷部分被注意和修复，不能得到彻底的修正。 可以再现。提供缺陷的精确操作步骤，使开发人员容易看懂，可以自己再现这个缺陷，通常情况下，开发人员只有再现了缺陷，才能正确地修复缺陷。 完整统一。提供完整、前后统一的软件缺陷的步骤和信息，例如：图片信息，Log文件等。 短小简练。通过使用关键词，可以使软件缺陷的标题的描述短小简练，又能准确解释产
生缺陷的现象。如“主页的导航栏在低分辨率下显示不整齐”中“主页”、“导航栏”、“分辨率”等是关键词。
? 特定条件。许多软件功能在通常情况下没有问题，而是在某种特定条件下会存在缺陷，
所以软件缺陷描述不要忽视这些看似细节的但又必要的特定条件（如特定的操作系统、浏览器或某种设置等），能够提供帮助开发人员找到原因的线索。如“搜索功能在没有找到结果返回时跳转页面不对”。
?
? 补充完善。从发现bug那一刻起，测试人员的责任就是保证它被正确的报告，并且得到应有的重视，继续监视其修复的全过程。 不做评价。在软件缺陷描述不要带有个人观点，对开发人员进行评价。软件缺陷报告是
针对产品、针对问题本身，将事实或现象客观地描述出来就可以，不需要任何评价或议论。
软件缺陷属性包括缺陷标识、缺陷类型、缺陷严重程度、缺陷产生可能性、缺陷优先级、缺陷状态、缺陷起源、缺陷来源、缺陷原因。
1. 缺陷标识：是标记某个缺陷的唯一的表示，可以使用数字序号表示。
2. 缺陷类型：是根据缺陷的自然属性划分缺陷种类，如表1所示
表1软件缺陷类型列表
<!--[if !supportLists]-->3. 缺陷严重程度：是指因缺陷引起的故障对软件产品的影响程度，所谓“严重性”我指的是在测试条件下，一个错误在系统中的绝对影响。如表2所示
<!--[endif]-->
表2软件缺陷严重等级列表
4. 缺陷产生的可能性：指缺陷在产品中发生的可能性，通常可以用频率来表示，如表3所示。
<!--[endif]-->
表3 缺陷产生可能性列表
<!--[if !supportLists]--> 5. 缺陷优先级：指缺陷必须被修复的紧急程度。“优先级”的衡量抓住了在严重性中没有考虑的重要程度因素，如表4所示。
<!--[endif]-->
表4 软件缺陷优先级列表
一般来讲，缺陷严重等级和缺陷优先级相关性很强，但是，具有低优先级和高严重性的错误是可能的，反之亦然。例如，产品徽标是重要的，一旦它丢失了，这种缺陷是用户界面的产品缺陷，但是它阻碍产品的形象。那么它是优先级很高的软件缺陷。
<!--[if !supportLists]--> 6. 缺陷状态：指缺陷通过一个跟踪修复过程的进展情况，也就是在软件生命周期中的状态基本定义，如表5所示。
<!--[endif]-->
表5 软件缺陷状态列表
<!--[if !supportLists]-->
<!--[if !supportLists]-->7. 缺陷来源：指缺陷所在的地方，如文档、代码等，如表6所示。
<!--[endif]-->
表6 软件缺陷来源列表
<!--[if !supportLists]-->8. 缺陷根源：指造成上述错误的根本因素，以寻求软件开发流程的改进、管理水平的提高，如表7所示。
<!--[endif]-->
表7 软件缺陷根源列表
第二篇：Bugzilla 软件缺陷报告
Bugzilla软件缺陷测试报告
1. Bugzilla成功安装
2. 登陆成功
3. 创建一个图书信息管理系统
4.添加成员
4. 添加3个模块
5. 软件缺陷3个 总页面
BUG1
BUG2
BUG3