| 错误 | 错误列举 |
| 主观评价 | 使用“我”、“你”等人称代词。可以直接使用动词或必要时使用“User（用户）”代替 |
| 主观评价 | 使用情绪化的语言和强调符号，例如黑体、全部字母大写、斜体、感叹号、问号等。只要客观地反映出缺陷的现象和完整信息即可，不要对软件的质量优劣做任何主观性强烈的批评、嘲讽 |
| 语意模糊 | “与**不同”、“有错误”、“不对”、“出错”等字眼等含义模糊的词汇，而需要报告确定的缺陷结果 |
| 主观评价 | 使用诸如“似乎”、“看上去可能”、“应该”等字眼 |
| 描述口语化 | “程序后台直接down掉，没有反映” |
| 语意模糊 | 例如“选择停止执行后，程序开始抽取”，“监控状态统计默认的是统计最近8天的告警信息” |
| 缺陷未隔离 | 一个缺陷中记录了一个以上的问题 |
| 缺乏可读性 | 缺陷描述包含的内容，因为读者的文化、观念或岗位不同，很多内容在别人看来，往往难以准确理解，甚至可能引起误解。只需客观地描述缺陷的信息即可 |
| 习惯提交 | 将不确定的测试问题提交缺陷中。
如果对测试软件的某个现象不确定是否是软件缺陷，可以通过电子邮件或口头交流，确认是缺陷后再报告到数据库中。避免查询和统计结果的不准确性 |
| 建议模糊/主观评价 | 对于UI或者UE觉得不合理的地方，给出建议看法， 以“需调整”、“不合理”、“需要优化”去描述 |
