关于常见的缺陷提交错误分析。希望能给大家在日常工作中提个醒。

　　1）常见错误

错误

错误列举

主观评价

使用“我”、“你”等人称代词。可以直接使用动词或必要时使用“User（用户）”代替

主观评价

使用情绪化的语言和强调符号，例如黑体、全部字母大写、斜体、感叹号、问号等。只要客观地反映出缺陷的现象和完整信息即可，不要对软件的质量优劣做任何主观性强烈的批评、嘲讽

语意模糊

“与**不同”、“有错误”、“不对”、“出错”等字眼等含义模糊的词汇，而需要报告确定的缺陷结果

主观评价

使用诸如“似乎”、“看上去可能”、“应该”等字眼

描述口语化

“程序后台直接down掉，没有反映”

语意模糊

例如“选择停止执行后，程序开始抽取”，“监控状态统计默认的是统计近8天的告警信息”

缺陷未隔离

一个缺陷中记录了一个以上的问题

缺乏可读性

缺陷描述包含的内容，因为读者的文化、观念或岗位不同，很多内容在别人看来，往往难以准确理解，甚至可能引起误解。只需客观地描述缺陷的信息即可

习惯提交

将不确定的测试问题提交缺陷中。
如果对测试软件的某个现象不确定是否是软件缺陷，可以通过电子邮件或口头交流，确认是缺陷后再报告到数据库中。避免查询和统计结果的不准确性

建议模糊/主观评价

对于UI或者UE觉得不合理的地方，给出建议看法， 以“需调整”、“不合理”、“需要优化”去描述

　　2）建议类缺陷

　　针对建议类型缺陷，要解释建议的目的，并能给出提出建议的依据，包括易用性、人性化以及行业惯例等，便于开发人员接纳。

　　3）缺陷改进与自查

检查项

改进

对于多人同时测试同一模块的情况，报Bug前先检查是否已有类似的Bug

Bug严重程度(Severity)必须准确

填写Subject字段，便于Dev Manager 分配给相应的开发人员；

项目中共性的问题，应及时纳入专项测试用例试行

多个相同的问题，如是一个Dev负责完成的，撰写一个缺陷报告可以，但须指出问题发生的多个位置

对于Reject的有争议的Bug，尽可能保持开发人员沟通

自查

缺陷报告已经向读者包含完整、准确、必要的信息了吗？

一个缺陷报告中是否只报告了一种缺陷？

读者是否能容易的搜索该缺陷？

步骤是否可以完全复现而且表达清楚吗？

是否包含了复现该缺陷需要的环境变量或测试所用的数据文件？

读者是否能容易的搜索该缺陷？