A. 功能性建议
B. 操作建议
C. 检校建议
D. 说明建议
性能类
A. 并发量
B. 数据量
C. 压缩率
D. 响应时间
常识类
A. 违背正常习俗习惯的，比如日期 / 节日等
特殊类
A. 不符合 OEM 版本或 DEMO 版本特殊要求的
四、 BUG 状态
已提交：软件测试员发现 BUG 后提交到 BUG 管理系统中的状态。(初始状态)
已修改：程序员在修改了 BUG 后提交到 BUG 管理系统中的状态。
不修改：程序员或项目经理根据需求分析、概要设计、详细设计说明书等上的要求经过考虑后决定对 BUG 不进行修改。其 BUG 的状态为不修改，需要说明理由。
延迟：根据目前项目进程或计划等情况，暂时延期的状态
待讨论：需要进行讨论后才能决定是否需要修改的 BUG 的状态。
已验证：已经解决的并经过测试员复测的 BUG 的状态。
关闭：完全解决了，只供以后备查的状态
重新打开：重新出现在新的版本中，重新打开以前关闭的 bug 状态
( 当然在 bug 工具中，可以自己定制适合项目的状态项目，比如废除，拒绝等 )
五、 BUG 的等级划分与优先级
1 、严重：死机，数据丢失，主要功能完全丧失，系统悬挂等错误。修改优先级为最高，该级别需要程序员立即修改。
2 、较高：主要功能丧失，导致严重的问题，或致命的错误声明。修改优先级为高，该级别需要程序员尽快修改。
3 、一般：次要功能丧失， 不太严重，如提示信息不太准确。修改优先级为中，该级别需要程序员修改。
4 、轻微：微小的问题，对功能几乎没有影响，产品及属性仍可使用，如有个错别字。修改优先级为低，该级别需要程序员修改或不修改。
六、 BUG 的优先级 (一般与 BUG 等级挂钩)
参考 1 、紧急、非常高、高、中等、低
参考 2 、下一个 build 版本 ,a 测试 ,b 测试 , 发布版本，最终发布版本
七、 BUG 记录内容
文章来源于领测软件测试网 https://www.ltesting.net/
