前提：标准的对日项目中使用
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的分析以及测试的分析有很大帮助。
