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