• 验证

• 现场反馈bug，需要由测试接口人统一接收，并验证，验证通过后登记bug，指派给开发

• 登录（测试）

• 进入测试主页面，使用页面中的“+提bug”按钮创建新bug。

• 在登记bug前，请先搜索一下禅道中是否已经有人登记了相同的问题，如有则不要再重复登记；

• **bug**输入项说明及填写规范：

• 输入项：所属迭代填写规范：必填，否则bug统计时会有问题

• 输入项：影响版本 填写规范：版本测试填写对应的版本号；热修复填写热修复的版本号；

• 输入项：当前指派填写规范：将bug指派给开发组长，由开发组长安排bug修复计划；

• 输入项：bug类型填写规范：选择对应的问题类型

• bug的类型

• 模板：

• 输入项：bug标题

• 填写规范：

• l 版本测试和热修复测试问题：bug所在子功能名-完整的问题描述（不要写需求描述）

• l 所有bug在提交时，均需要进行是否低级bug（只需要分析一步，没有任何转折or只要最基本的自测就能发现的bug）的认定，认定为低级bug时，**在标题开头增加：*******

• l 产品经理/项目经理验收过程中发现的问题，在标题前打标记：UAT-

• l 产品上线后非用户发现反馈提交的问题，在标题前打标记：PRD-

• 产品上线后外部反馈提交的问题，是测试阶段已提交的bug，在标题前打标记：ZPRD

• 维护测试中专项测试的bug，根据实际情况在bug，在标题前打标记：清理测试/按钮防抖

• l 回归测试中明显上一版正常，这一版不正常的bug，在标题后打标记：（修复引入）

• l 测试中遇到的随机bug，在标题后打标记：（随机）

• l 产品经理提出让测试登记的需求变更bug，在标题前标记：需求变更-需求描述；填写规范：l 版本测试开始前，先与产品经理/项目经理确认好当前版本上线时间、和下个版本预计上线时间；

• l 热修复版本发现的bug，截止日期填写当天；l 测试填写的截止日期作为参考值，截止日期的最终值由项目经理确认。填写规范：问题的详细描述，或贴问题截图说明；步骤、结果、期望的顺序不能改；
  

• 输入项：严重程度填写规范：其中1级重大、2级严重、3级普通、4级轻微，详细如下：1级：核心功能无法使用、系统崩溃（含404）、数据丢失、导致冒烟测试无法通过的问题 2级：主要功能问题，关联影响其他功能使用，数据错误 3级：次要功能问题，不影响模块中其他功能。4级：各种细节建议、文字描述（错别字、歧义、词不达意）、易用性、界面布局、风格统一等PS*：核心、主要、次要功能中符合4级定义的bug，均选择4级；*性能、兼容性问题属于bug类型，不影响严重程度的判断；

• 输入项：优先级填写规范：1级最高，4级最低，详细如下：1级：核心业务、主要业务、主要功能阻塞，特殊性能要求未达到的问题；2级：核心业务、主要业务问题，不影响业务正常进行的问题；3级：主要功能的问题；4级：非核心业务、主要业务、主要功能的问题。**PS**：紧急程度使用优先级进行标记，请结合功能点清单中标记的核心业务、主要业务、主要功能来判断问题的优先级。特殊情况可请产品经理调整优先级。

• 输入项：截止日期
  

bug的截止时间

• 输入项：重现步骤
  

分配

• 开发组长将问题指派给开发人员，给出解决时间和优先级

• 如果选择外部原因、延期处理的bug，请先报告在指派给测试

• 测试人员激活bug，开发组长了解原因后在指派给开发

  
  

• 分配时核对项
  

• 输入项：优先级填写规范：1级最高，4级最低，详细如下：1级：需要立即解决的问题；2级：需要在指定时间内解决的问题；3级：项目开发计划内解决的问题；4级：为资源充沛时解决的问题。
  

修复

• 开发在指定时间修复bug并填写解决方案，将bug提交给测试验证

  
  

• 在禅道中打开某个bug，使用“解决”功能，进入该bug的解决页面，填写相应“解决方案、指派给、备注”
  

• 输入项：解决方案填写规范：正确填写

• 输入项：解决版本填写规范：填写正确的解决版本号输入项：解决方案、备注、指派给填写规范：l 设计如此、不是bug、不予解决三类bug，和产品及测试人员沟通后，再指派给测试。l 外部原因、延期处理两类bug在注释中写明原因，指派给开发组长，开发组长审核通过后指派给测试。l 研发人员正常修复bug后，需在注释中填写问题产生原因，及解决方法。填写此信息可以帮助统计研究每个人的编码习惯、薄弱环节、同时利于提升测试人员的理解，便于以后更效率的发现问题。l 代码

回归（测试）

• 测试人员根据发布版本要求对bug进行统一回归测试，避免自己在测试环境上进行无效的测试。

激活（测试）

• 回归测试中发现未修复成功的bug，激活后统一指派给开发组长。激活bug时，不能删除影响版本中原有的版本号，同时必须新增一个激活时的版本号；

关闭 （测试）

• 对已解决的bug在有效的回归测试后关闭。对不是bug、不予解决、无法重现、外部原因等bug在备注中填写测试人员的理解后关闭。对其他类型bug在验证后关闭，定期统计分析。

版本号管理（测试）

在禅道的迭代-版本中创建版本号；

• 在新功能提测时，创建版本号：x.x.x.01修复.00版本测试过程中，每次发版动作开始后，将X.X.X.01修复.00，修改为：X.X.X.0100.00，同时新增版本号：X.X.X.01修复.00；版本测试过程中，每进行一次发版动作，必须增加一个版本号，并记录该版本发版原因；版本测试过程中，遇到阻碍测试进行必须马上修复发版的bug时，新增版本号：X.X.X.XX紧急修复.00，然后告知开发修复该bug后要马上发版，该bug的解决版本号需要选紧急修复版本号；当版本测试完成后，版本中会遗留一个：X.X.X.XX修复.00版本号，在下一次提测前，所有遗留bug修复后都会进入这个版本号，在下个版本提测时，需要将该版本号修改为：X.X.X.XX00.00，再新增一个X.X.X.XX修复.00当版本测试需要分批次修复遗留bug、或完成新功能时，提前在版本中创建好每个批次需要使用的版本号，如：X.X.X.XX第一批次修复.00、X.X.X.XX第二批次修复.00……对已解决的bug在有效的回归测试后关闭。对不是bug、不予解决、无法重现、外部原因等bug在备注中填写测试人员的理解后关闭。对其他类型bug在验证后关闭，定期统计分析。

总结：

• 听从组长的bug分配任务，按时按量的完成的bug的修复

• 安装文档来编写bug的说明（比如严重程度、优先级、截止时间、重现步骤.....）

• 在禅道软件上点击bug，填写相应：解决方案、指派给、备注”

• 版本号：每次提交版主在后面叠加