一个好的系统还需要：
- 严重性等级，以评估在测试条件下，错误在系统中的绝对影响；
- 优先级，评估顾客实际使用中发生事件的可能性，或对目标顾客的后续影响；
- 环境：系统软、硬件配置，测试版本号；
- 附件，错误信息或屏幕截图。
提交之后，Bug为"Submitted"状态，变更控制委员会（Change Control Board，视项目规模组织，可以是不同角色的几个人组成或一个人担当）评审决定：
- 是Bug，分配给相关开发人员修复，状态为"Assigned"；
- 不是Bug或其他原因，关闭，状态为"Closed"，解决方式（Resolution）根据实际情况选择；
- 是Bug，但延迟到下一个版本修复，状态为"Postponed"。
开发人员将Bug修复后，其状态改为"Resolved"，他们应发布到下一个测试版本（Test Build）中，测试人员测试所有"Resolved" Bug，没有问题应关闭（"Closed"状态），未修复则要重新打开（"Opened"状态）。
对于用户提交的Bug，有些系统会增加"Confirmed"的状态，表示经测试Bug确实存在。
对其他变更（如需求改变或新增），以上流程同样适用，但可能需要多次分配（assign），如需求变更，业务分析员要更新需求文档，系统分析员要更新设计文档，然后程序员改代码。
系统最好还有以下功能：
- Root Cause：根本原因分析，这需开发人员的帮助；
- Close Date和Resolution：系统生成关闭日期，可选择或输入问题是如何解决的；
- 系统自动跟踪记录缺陷历史，可输入注释；
- 方便的查询功能；
- 可定制的报表，缺陷趋势图表；
- Email提醒。
 |
延伸阅读
文章来源于领测软件测试网 https://www.ltesting.net/
