禅道bug提交管理规范Word文件下载.docx
《禅道bug提交管理规范Word文件下载.docx》由会员分享，可在线阅读，更多相关《禅道bug提交管理规范Word文件下载.docx（10页珍藏版）》请在冰豆网上搜索。
选择发现Bug的对应模块，必填项。
所属项目：
选择测试所属的项目。
必填项。
影响版本：
选择发现bug的版本。
当前指派：
选择指派的开发人员。
Bug标题：
用简单明了的语句说明Bug内容，相当于BUG的中心语句。
在标题上注明bug出现的频率（稳定出现/经常出现/很少出现/出现一次）
重新步骤：
重现步骤格式如下。
[环境]：
如果系统/浏览器信息不能够全部说明发现Bug的环境，需要在重现步骤里详细描述环境信息，以便于开发定位和解决问题。
[步骤]：
写明出现Bug的操作步骤，要求简单，去掉与Bug无关的步骤。
[结果]：
写明操作的实际结果。
[期望]：
写明操作的期望结果。
相关需求：
选择与Bug相关的需求。
如果Bug关联测试用例，系统会自动关联测试用例的需求。
相关任务：
选择与Bug相关的任务。
这里的任务是在『项目』->
『任务』中创建的任务。
Bug类型如下：
●代码错误：
功能性错误。
●界面优化
●设计缺陷
●配置相关
●安装部署
●安全相关
●性能问题
●标准规范
●测试脚本
●其他
Bug严重程度如下：
Bug严重度等级
描述
范例
1–Critical
所产生的问题导致系统崩溃，蓝屏，停顿；
缺少主要功能或者主要功能毫无作用，导致无法进行下一步测试。
1．系统蓝屏，崩溃
2．由于程序所引起的死机,非法退出
3．死循环
4．数据库发生死锁
5．因错误操作导致的程序中断
6．与数据库连接错误
7．数据通讯错误
2–High
所产生的问题会导致系统部分功能不正常；
所产生的问题严重但不影响下一步测试。
1．功能不符
2．程序接口错误
3．数据库的表、业务规则、缺省值未加完整性等约束条件
4．主要功能错误
3–Medium
所产生的问题导致系统很小的功能问题；
不会影响下一步测试；
功能运作正常，可是有改进的空间。
1．操作界面错误（包括数据窗口内列名定义、含义是否一致）
2．打印内容、格式错误
3．简单的输入限制未放在前台进行控制
4．删除操作未给出提示
5．数据库表中有过多的空字段
4–Low
所产生的问题不会导致系统任何问题；
所产生的问题不影响下一步测试；
1．界面不规范
2．辅助说明描述不清楚
3．输入输出不规范
4．长时间操作未给用户提示
5．提示窗口文字未采用行业术语
6．可输入区域和只读区域没有明显的区
系统/浏览器：
选择出现问题的系统平台和使用的浏览器信息。
抄送给：
选择需要抄送的人员。
关键词：
填写关键词，便于搜索查找。
附件：
如需必要，附加可以说明bug的文件，截图，dump等信息。
注：
如果Bug是关联测试用例创建的，系统会自动取测试用例的信息（标题，前置条件，步骤，期望结果，需求）作为Bug的信息。
第一步：
开发人员查看指派给自己的Bug列表，编辑bug并确定每个bug的优先级别。
优先级别根据时间，紧急度，重要程度综合确定。
优先级别由开发人员自己定义，开发负责人具有复查/重定义/监督的责任。
优先级别：
如下表。
1–Urgent
立即修复。
产品发布前必须修改完成。
时间允许，产品发布前应该修改。
产品发布前可能修改。
不影响发布。
第二步：
确定Bug的优先级别后，开发工程师根据Bug的优先级别开始解决（复现/调试等），此时需要确认bug，表明Bug正在处理。
通过已确认/未确认状态可以查询开发人员已开始处理/未开始处理的Bug信息。
Bug状态为激活（已确认）。
开发人员解决bug后，执行『解决』操作。
填写解决方案，指派给，备注信息。
Bug状态为已解决。
之后开发人员等待build的创建，如果build创建完毕，开发及时确认在此次创建build上解决的bug，并修改bug的解决版本。
Build的创建参见迭代开发流程。
针对延期处理的Bug，需要单独创建一个Build，名称例如为“下一版本”。
如果开发解决了延期处理的Bug，需要修改Bug的解决方案，解决版本等信息。
针对重复的Bug，开发需要在重复bug中写明重复bug的ID。
新Build创建后，开发人员需要及时复查在新build上解决的Bug，并修改Bug的解决版本信息。
测试人员需要及时提醒开发人员完成此项工作。
解决方案：
选择Bug的解决方案，具体方案如下表。
名称
英文对照
设计如此
Bydesign
重复Bug
Duplicate
外部原因
External
转为需求
Tostory
已解决
Fixed
无法重现
NotReproduce
延期处理
Postponed
不予解决
willnotfix
解决版本：
选择创建的build。
Build来自与『项目视图』->
『Build』中创建的Build。
指派给：
选择验证Bug的测试人员。
默认为Bug的创建者。
备注：
开发人员填写bug的原因及解决办法。
测试人员验证状态为已解决并解决版本不为空的bug。
●验证结果一：
如果验证bug在build上已经解决，测试人员『关闭』Bug并填写验证信息。
Bug状态为已关闭。
后续操作：
如果Bug来自与case的执行，测试人员需要重新执行对应Case，确保Case最终状态是通过。
如果Case的执行仍然发现bug，将进入新一轮的Bug流程。
●验证结果二：
如果验证bug，没有通过，测试人员填写验证信息，并『激活』bug。
将正在激活的bug指派给对应开发人员。
选择复现Bug的build。
填写验证信息。
附加相关可以证明bug的附件，例如截图，错误文本，dump等。
各解决方案，测试人员对应操作。
对应操作
如果同意，关闭Bug；
如果不同意，写明原因，激活Bug。
确认重复，关闭Bug；
如果不重复，写明原因，激活Bug。
如果同意，关闭Bug，并考虑是在用户手册/FAQ记录问题；
如果同意，转为需求，关闭Bug，之后由需求负责人跟踪；
如果不同意，写明原因，激活Bug
如果验证已解决，写明验证结果，关闭Bug，重新执行测试用例；
如果验证没有解决，写明验证信息，激活Bug。
测试人员需要帮助开发人员复现Bug。
如果复现，保留测试环境，提供给开发人员进行调试；
如果不复现，保留Bug，并在以后的3-4个版本上验证，如果仍然不出现，写明验证的版本和结果，关闭Bug。
测试人员不对Bug进行操作，但需要追踪Bug，直到Bug的最终解决。
升级会员 