|
错误 |
错误列举 |
|
主观评价 |
使用“我”、“你”等人称代词。可以直接使用动词或必要时使用“User（用户）”代替 |
|
主观评价 |
使用情绪化的语言和强调符号，例如黑体、全部字母大写、斜体、感叹号、问号等。只要客观地反映出缺陷的现象和完整信息即可，不要对软件的质量优劣做任何主观性强烈的批评、嘲讽 |
|
语意模糊 |
“与**不同”、“有错误”、“不对”、“出错”等字眼等含义模糊的词汇，而需要报告确定的缺陷结果 |
|
主观评价 |
使用诸如“似乎”、“看上去可能”、“应该”等字眼 |
|
描述口语化 |
“程序后台直接down掉，没有反映” |
|
语意模糊 |
例如“选择停止执行后，程序开始抽取”，“监控状态统计默认的是统计最近8天的告警信息” |
|
缺陷未隔离 |
一个缺陷中记录了一个以上的问题 |
|
缺乏可读性 |
缺陷描述包含的内容，因为读者的文化、观念或岗位不同，很多内容在别人看来，往往难以准确理解，甚至可能引起误解。只需客观地描述缺陷的信息即可 |
|
习惯提交 |
将不确定的测试问题提交缺陷中。 如果对测试软件的某个现象不确定是否是软件缺陷，可以通过电子邮件或口头交流，确认是缺陷后再报告到数据库中。避免查询和统计结果的不准确性 |
|
建议模糊/主观评价 |
对于UI或者UE觉得不合理的地方，给出建议看法，
以“需调整”、“不合理”、“需要优化”去描述 |
2）建议类缺陷
针对建议类型缺陷，要解释建议的目的，并能给出提出建议的依据，包括易用性、人性化以及行业惯例等，便于开发人员接纳。
3）缺陷改进与自查
|
|
检查项 |
|
改进 |
对于多人同时测试同一模块的情况，报Bug前先检查是否已有类似的Bug |
|
Bug严重程度(Severity)必须准确 |
|
|
填写Subject字段，便于Dev Manager 分配给相应的开发人员； |
|
|
项目中共性的问题，应及时纳入专项测试用例试行 |
|
|
多个相同的问题，如是一个Dev负责完成的，撰写一个缺陷报告就可以，但须指出问题发生的多个位置 |
|
|
对于Reject的有争议的Bug，尽可能保持开发人员沟通 |
|
|
自查 |
缺陷报告已经向读者包含完整、准确、必要的信息了吗？ |
|
一个缺陷报告中是否只报告了一种缺陷？ |
|
|
读者是否能容易的搜索该缺陷？ |
|
|
步骤是否可以完全复现而且表达清楚吗？ |
|
|
是否包含了复现该缺陷需要的环境变量或测试所用的数据文件？ |
|
|
读者是否能容易的搜索该缺陷？ |
