Bug报告的流程以及要素分析前提：标准的对日项目中使用Bug发行和处理流程1．测试中发现问题2．寻找参照文档即发行依据。3．进行对比信息采集4．进行不重复bug的自我确认5．进行bug发行确认（pl确认）6．书写bugreport-〉submit7．项目组长check,测试员再现操作-〉bugreport状态便更为open8．开发方-〉确认-〉1.待确认（缺少信息）->bugreport打回6，进行信息添加。2．分析修改9．bugreport待测试状态-〉测试员进行测试—〉测试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.但是不能将结束原因归咎于测试员的误操作。比如需求变更，环境原因等。以上这些都是在系统...
