3、Bug的规范

　　a）简要的说：bug的标题摘要需要具备的描述方式应该清晰，明了。

　　i. 在什么情况下

　　ii. 进行什么操作

　　iii. 产生什么现象

　　b）如何让你的bug情景化

　　i. 在发现缺陷之后，只有当你确信你已经发现一个bug的时候开始起草bug report，不要在测试结束或每天结束之后。那样，你可能会遗忘掉一些东西。更糟的情况是，我们可能会忘掉那个bug

　　ii. 花一些时间去诊断你正在报告的缺陷。想想可能存在的原因并尝试定位问题，可能到后你会发现更多的缺陷。在你的bug report中说说你的分析。有助于提高开发的认可度和测试人员的专业程度

　　c）Bug的元素信息

　　i. 摘要：见a说明，一个好的摘要应该不超过50到60个字符。而且一个好的摘要不应该承载任何对bug主观的表达。

　　ii. 在编写bug report的时候记住你的目标读者。他们可能是开发人员，其他的测试人员，经理，或者在一些情况下，甚至是客户。Bug report应该可以被所有的人理解

　　iii. 清楚的列出前提条件

　　iv. 有清晰的可重现的步骤，可重现步骤应该详尽

　　v. 备注说明：有页面或者特殊情况下，或者可重新几率不高的问题，尽量保证有截图和相关说明信息。也可在备注中进行问题分析和bug定位的缺陷引导

　　vi. 简化和剔除步骤：在一个干净的系统里测试你的“可重现的步骤”。你可能会发现有些步骤被遗漏或是毫无关系的，这样可以剔除部分不必要的说明步骤，也能避免步骤过多对于问题定位的干扰。

　　vii. 预期结果和实际结果，清晰描述现象即可

　　viii. 附件：截图和一些配置文件，需要进行附件的添加，方便开发进行定位缺陷和分析问题点

　　d）Bug的级别划分

　　i. Bug的严重性级别划分一般分为4类：严重、主要、次要、轻微

　　ii. 对应级别的对应问题的划分，可以见QC中对应级别功能的划分

　　iii. Bug的优先级别划分

　　（1）紧急（Urgent）缺陷必须被立即解决

　　（2）高级别（High）缺陷需要尽快处理

　　（3）正常（Medium）缺陷需要正常排队等待修复或列入软件发布清单

　　（4）不紧急（Low）缺陷可以在方便时被纠正，解决的优先级别不高