4 轻微 错误是表面化或微小的（提示信息不太准确友好、不准确、误导、错别字、界面布局或罕见故障等），对功能几乎没有影响，产品及属性仍可使用。 5 建议 建设性的意见或建议。 需求文档没有规定的特性，如果实现会对系统功能或者易用性有所提高。 5.8 优先级
优先级和严重程度有一定关系，但是不同于严重程度。严重程度表示对软件系统功能的影响程度，而优先级表明哪些缺陷应当尽早处理，反映了处置缺陷的时间安排。
优先级一般由测试人员建议，项目负责人确定。 1紧急 如果障碍相关开发人员的进一步开发活动，应立即进行修复工作； 如果阻止与此密切相关功能的进一步测试，应立即修复。 一般严重程度是1的需要立刻处理。 2必须的 3应该的 4可选的 5不需要 必须修改，发版前必须修正。 必须修改，不一定马上修改，但需确定在某个特定里版本发布前须修正 如果时间允许应该修改 允许不修改 测试人员和项目负责人负责督促缺陷的修改进度。测试人员、测试经理负责定期生成《测试报告》，统计该阶段缺陷的登记和处置情况。
5.9 缺陷来源
来源 需求 说明 需求描述不充分 需求有歧义 业务规则不完整 流程环节描述不完整 不合理的流程 设计 不正确的流程 不恰当的角色 不正确的前后条件（输入，输出） 功能描述不完整，不匹配 补充规范描述不完整 不一致的表述 开发 异常处理不充分或不恰当 结构不当 逻辑判断不当 对攻击性的使用处理不足，例如无效数据，非法字符。 变量定义和使用不当，例如作用域不当 多余的循环和分支 测试 流程错误 功能没有完全测试 补充规范（有效，格式等）没有完全测试 缺少工具和资源的使用规范 使用了错误的环境（比如数据库） 其他文档 建构 需求，设计，测试用例，测试计划以外其他文档 建构过程导致的 5.10 缺陷描述
缺陷描述的要求为分类准确、叙述简洁、步骤清楚、有实例、可再现、复杂问题有据可查（截图或其它形式的附件）。
具体要求为：
? 单一：尽量一个报告只针对一个软件缺陷
? 简洁：每个步骤的描述应尽可能简洁明了。只解释事实、演示和描
述软件缺陷必要的细节
? 再现：必须描述重现的步骤和条件，比如具体输入参数值，以便进
行回归验证。如果能截图就应当提供截图。截图文件不建议用BMP格式。
? 不能使用笼统的抽象词句：比如“有错误”之类 ? 问题描述一般格式：
? 可重现的步骤: 包括发生错误时的输入值 ? 期望结果 ? 实际结果
? 其它信息，可依实际情况增加
5.11 处理意见
处置意见是缺陷负责人对缺陷处置结果的简短描述。
如果缺陷已经修正解决，处置意见是“已修正”，对于否决的缺陷，处置意见参考4.4 的表格
5.12 处置记录
处置记录通常是解决方法。 缺陷解决办法的描述要求包括：
? 原因：说明缺陷产生的原因，比如：设计考虑不周，边界处理不严
密，逻辑判断不合理。要求描述具体简洁，以便总结经验。 ? 解决方法：修改涉及的文件，源代码，配置，脚本等。 ? 概括：缺陷是否可能存在于其他位置，或引起其他问题。
软件缺陷管理制度
