Bugfree操作规范.doc

Bug记录要求 Bug标题 按“前缀+Bug标题描述” 的格式规则进行标识，长度不超过20个字符 测试组： 新发现Bug直接描述； 由主Bug引发的问题，标题格式为：(主BugID)问题描述； 开发人员/售后/技术支持： 需求问题：【XQ】问题描述； 例如：Bug15158【XQ】权属登记管理的有证抵押移交清册（缮证）增加查询条件 需求变更：【BG】问题描述； 系统问题：【WT】问题描述； 数据修改：【SJ】问题描述； 注：Bugfree中存在部分标题格式为“T_问题描述”的Bug，属于新增需求。 模块路径 新建Bug时必须正确选择与Bug所在位置对应的项目、模块路径。 严重程度 Bug严重性选择：基本功能未完成、或能引起重大问题的、异常报错的为1级；2级不属于按日常计划修正的、对工作量造成影响的、修改面积扩大的，3级日常维护的、优化建议为4级 优先级 Bug解决的紧急程度， 1级2个工作日内完成、2级二到五个工作日内完成的，3级每个月的21号前处理完、4级有空就处理，一般在两个月内解决。 Bug类型 要求描述Bug人员准确定位Bug类型，并正确的从列表中选择。 常用类型有：代码错误、用户界面、需求变动、安装部署、性能压力、事物跟踪、其他（建议优化） 复现步骤/Bug描述 测试人员新建Bug时，需根据实际情况，分析引发该Bug的必然条件，将操作步骤详细描述，标明测试数据（如登录账户、案件编号、合同编号等主键字段值），以此为依据分别填写重现步骤、实际结果、期望结果，并将错误界面抓图并以附件形式上传至Bugfree。 例如Bug# 11946 开发人员新建需求/变更性Bug，标明新需求/变更内容，如果有详细设计文档，将文档上传至vss服务器/doc对应目录路径下，并在Bugfree上标明文档在vss上的路径（在doc/**项目文档/**需求文档/文件名为年月日）。 售后/技术支持新建Bug，文字描述Bug内容，明确客户需求，同时将原始需求文档按上述要求上传至vss/doc对应目录，并在Bugfree上标明路径。 Bugree附件只上传错误界面抓图，不要直接将多个扫描件同时上传至Bugfree。 版本号 版本号统一写1.0 Bug状态控制 主要是指新建、解决、关闭、激活Bug的操作及Bug状态变更。不同角色对同一个操作有不同要求，具体如下： 新建：发现问题时都可新建Bug。 测试人员新建Bug后指派给测试组长，由测试组长确认后进行处理。 开发人员新建Bug，直接处理完成后由项目组长转测试组长进行测试。 售后/技术支持新建Bug，指派给测试确认需求，然后由管理员确认解决方案，转给相关开发人员进行处理。 售后/技术支持关于数据修改的Bug，直接给测试处理，完毕后由创建者关闭 解决：主要是开发人员操作；开发人员修改Bug完成后，点击【解决】，将Bug状态置为已解决，同时描述解决方案、修改文件等，具体要求如下： 描述问题原因：如果是系统Bug，在解决时注明引发此问题的原因； 包括做了哪些改动、修改了哪个Bug引起此问题； 解决方案：如何解决此Bug的，解放方法是什么。 修改内容： 此处修改内容主要包括Sp、Dl、Fl、Bl、Sql。 修改内容格式包括层名、路径、文件名、版本号，如下： Vss路径 +（Vss + 版本号）如： 如： SP： $/DATABASE/Packages/PKG_CLFBA.pks (Vss 41); FL： $/FDJ/WEBMODULES/CLFBA/zzxgsq/zznjsqList.aspx.cs (vss 7); DL： BL： $/FDJ/BusModules/CLFBA/CLFBA.Business/CLFZZBGSQ/CLF_ZZXXSQ_BLL.cs (vss 13); Sql： 注意：当一个Bug多次追加修改内容时，在最终转给测试组前，将本次修改的所有文件统一整理一楼。 激活：Bug验证时，发现此问题未解决，如功能没实现，则进行激活重新修改，测试组激活Bug仍然指派给测试组长，由测试组长确认后进行处理。 如果Bug功能已实现，但是有引发Bug，则新建引发Bug，在新Bug中标明主Bug编号（见Bug标题记录要求）。 关闭：由提出问题者验证，并在确认后关闭。 经验证此问题不存在，可以关闭，但必须注明测试范围和测试结果。 范围：相关连模块的功能，会影响到的模块的功能，涉及到的接口等。 结果：测试是否通过，是否还有遗留问题。 Bug处理流程 开发人员发现Bug处理流程为： 测试人员发现系统Bug处理流程： 测试建议/优化类Bug处理流程： 新需求/变更： Bugfree记录规范检查内容： Bug标题是否规范 路径选择是否正确 优先级、类型、严重程度选择是否正确 Bug描述是否符合要求（需求明确、