提交bug的内容书写规范

1、标题 【项目名称——简短的 bug 说明】 描述 bug 的最主要关键词，如 xx 项目——数据库输入输出数据不一致 2、项目名称 【项目名称+项目版本号】 3、Bug 所属项目/模块 Bug 所属项目和模块，最好能较精确地定位至模块； 4、严重等级 【紧急，严重，一般，微小】 紧急 Bug：造成系统或应用程序崩溃(Crash)、死机、系统悬挂，或者造成数据丢失、主要功 能完全丧失等。 严重的 Bug：功能或者特性没有实现，主要功能部分丧失，次要功能完全丧失，或者致命错 误声明。 一般的 Bug：不太严重，虽然不影响系统的基本使用，但没有很好地实现功能，没有达到预 期效果。如：次要功能丧失，提示信息不太准确，或用户界面差，操作时间长等。 微小的 Bug：对功能几乎没有影响，产品及属性仍可使用，如有个错别字、文字排列不整齐 等。 5、优先级 【P1，P2，P3，P4】 P1：立即解决，导致系统几乎不能使用或测试不能继续，需要立即修复； P2：高优先级，严重，影响测试，需要优先考虑； P3：正常排队，需要正常排队等待修复； P4：可以在开发人员有时间的时候再纠正；。 6、Bug 状态 【New，Open，Fixed，Rejected，Delay，Closed，Reopen】l New:新发现的 bug，开发人员尚未确认； Open：确实是 bug，并认为需要修改，指派给相应的开发人员； Fixed：开发人员进行修改后标识成修改状态，有待测试人员的回归测试验证； Rejected：如果认为不是 bug，则决绝修改； Delay：暂时不修改或者暂时不能修改，则延后修改； Closed：fixed 状态的 Bug 经测试人员回归测试验证通过，则关闭 Bug； Reopen：fixed 状态的 Bug 经验证仍然存在，则需要重新打开 Bug，开发人员重新修改； 7、测试环境 【硬件设备环境，软件设备以及配置环境，具体到使用的版本号，类型号】 测试人员要充分说明测试环境的情况，以便开发人员可以快速定位错误，防止出现因开发环 境与测试环境不符，而无法重现 bug 的情况。 8、重现步骤 【详细、精炼的描述 bug 出现的操作过程，一步一步地描述】 提供如何重复当前 Bug 的准确描述，应该简明而完备、清楚而准确；录入之前要多做几次尝 试，尽量把操作步骤缩减到必须要执行才能重现错误的几个步骤。 9、期望结果 【需求给出的输出结果，即正常结果】 按照设计规格说明书和用户需求，在上述步骤之后，所期望的结果，即正确结果；要描述清 楚产品需求制定的正确结果是什么，避免开发人员因产品需求不明，而产生不必要的沟通开 销。 10、实际结果 【实际测试输出的结果，即错误的结果】 客观反映事实。如：程序抛出异常信息如下… 11、出现频率 【必现，通常，有时，很少】描述 bug 出现的可能性 1%~100%； 必现：总是出现这个 Bug，产生频率为 100%； 通常：按照测试用例，通常情况下回产生这个 Bug，频率大概 80%~90%； 有时：按照测试用例，有的时候会产生这个 Bug，频率大概 30%~50%； 很少：按照测试用例，很少产生这个 Bug，频率大概是 1%~5%； 12. 、问题隔离 【描述环境的版本，类型等的单一变化和组合状态下，是否出现】 13、必要的附件 【图片，Log 文件】 对于某些只用文字描述还不足够清楚的 Bug，使用图片，错误日志等必要的附加；对于软件 崩溃等现象，需要捕捉到日志文件作为附件提供给开发人员