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