Bug 报告的流程以及要素分析 前提：标准的对日项目中使用 Bug发行和处理流程 测试中发现问题 寻找参照文档即发行依据。 进行对比信息采集 进行不重复bug的自我确认 进行bug发行确认（pl确认） 书写bug report-〉submit 项目组长check, 测试员再现操作-〉bug report 状态便更为open 开发方-〉确认-〉1. 待确认（缺少信息）-> bug report 打回6，进行信息添加。 2．分析修改 bug report待测试状态 -〉测试员进行测试—〉测试OK->closed —〉 测试NG-〉等待继续修改。 Bug 报告的要素 概要 用最精简的话语，最好是一句来描述你发现的问题。一般逻辑为，哪里，进行了什么操作，本该出现什么，结果出现了什么。（比较严重的缺陷不需要说明期望结果） 步骤 从第一步开始书写你的操作手顺。一般原则为：让一个不熟悉此操作的人，按照你的步骤能够再现这个bug. **需要注意的是。需要书写的步骤不能含有冗余。也就是说，需要测试员在发现问题后对自己已经确定的再现操作步骤进行排除和分析。只保留缺一不可的步骤。 再现率 一般为 X/Y的格式。即再现次数/操作次数。 发行依据，就是参考文件，你是依据什么文件（权威，一般为需求文档或者开发方的说明文档等）而发行的这个bug. 对比信息。包括类比和对比信息。 测试环境 使用的测试数据 测试附件图片，录影（图片无法说明的），log文件。 其他 以上是书写bug的重要要素。当然，一个bug报告的组成还有以下： bug的概要分析。分析这个bug属于什么范围的问题，什么模块的问题。是进行了什么操作而造成的。 Bug的优先级。有三级与五级这两种不同的区分。依据项目而定。这种级别一般是测试员没有权限决定但是有权利进行建议的。 Bug的分析过程。一般由开发和分析人员填写。 Bug的再测试纪录，一般由测试人员填写测试经过，测试时间，步骤，结果然后会由PL进行确认和提交。