单元测试BUG管理表

. BUG管理流程与规目录1概述 (5)1.1编写目的 (5)1.2适用围 (5)2关键角色及应负责任 (5)3BUG流程图 (6)4活动描述 (6)5BUG书写规 (8)5.1测试人员BUG提交 (8)5.1.1主题 (8)5.1.2步骤 (8)5.1.3实际结果 (8)5.1.4预期结果 (8)5.1.5备注 (9)5.2开发人员解决BUG (9)6BUG严重等级 (10)6.1致命 (10)6.2严重 (10)6.3一般 (11)6.4优化 (11)7BUG优先级 (12)7.1紧急 (12)7.2高 (12)7.3中 (12)7.4低 (12)8BUG解决方案 (12)8.1设计如此 (12)8.2重复BUG (12)8.3已解决 (12)8.4无法重现 (12)8.5延期处理 (12)8.6新增/变更需求 (12)9BUG状态 (12)9.1激活 (12)9.2已解决 (13)9.3关闭 (13)10其他要求 (13)11相关文件 (13)12附件 (13)1概述1.1编写目的本文档定义bug的整个生命周期，规bug的管理流程。

Bug在流转的过程中有章可循。

规bug严重等级与bug解决优先级，使开发人员与测试人员能根据此文档准确判断bug 的严重程度并加以解决。

1.2适用围本文档适用测试人员、开发人员。

2关键角色及应负责任5BUG书写规5.1测试人员BUG提交5.1.1主题•用一个简短的句子描述问题，不要写成一大段•以进入问题模块路径开头，方便项目经理分派任务，以及开发人员定位问题•描述问题时要详细、简练、抓住要点，直接切入正题，不要罗嗦•不要夸大或缩小问题的严重程度5.1.2步骤•用数字编号，一步步的描述重现问题的所有操作步骤•提供明确的再现问题的步骤，避免问题被以“不能重现”关掉•设置区域需要详细描述，如：各设置项值为默认、**值更改为“”，其他设置项值为默认；•尽量用动词作为开头，描述每个步骤。

B U G管理规范与流程标准化文件发布号：（9312-EUATWW-MWUB-WUNN-INNUL-DQQTY-BUG管理流程与规范目录1概述 (5)编写目的 (5)适用范围 (5)2关键角色及应负责任 (5)3BUG流程图 (6)4活动描述 (6)5BUG书写规范 (8)测试人员BUG提交 (8)主题 (8)步骤 (8)实际结果 (8)预期结果 (8)备注 (9)开发人员解决BUG (9)6BUG严重等级 (10)致命 (10)严重 (10)一般 (11)优化 (11)7BUG优先级 (12)紧急 (12)高 (12)中 (12)低 (12)8BUG解决方案 (12)设计如此 (12)重复BUG (12)已解决 (12)无法重现 (12)延期处理 (12)新增/变更需求 (12)9BUG状态 (12)激活 (12)已解决 (13)关闭 (13)10其他要求 (13)11相关文件 (13)12附件 (13)1概述1.1编写目的本文档定义bug的整个生命周期，规范bug的管理流程。

Bug在流转的过程中有章可循。

规范bug严重等级与bug解决优先级，使开发人员与测试人员能根据此文档准确判断bug的严重程度并加以解决。

1.2适用范围本文档适用测试人员、开发人员。

2关键角色及应负责任5BUG书写规范5.1测试人员BUG提交5.1.1主题•用一个简短的句子描述问题，不要写成一大段•以进入问题模块路径开头，方便项目经理分派任务，以及开发人员定位问题•描述问题时要详细、简练、抓住要点，直接切入正题，不要罗嗦•不要夸大或缩小问题的严重程度5.1.2步骤•用数字编号，一步步的描述重现问题的所有操作步骤•提供明确的再现问题的步骤，避免问题被以“不能重现”关掉•设置区域需要详细描述，如：各设置项值为默认、**值更改为“”，其他设置项值为默认；•尽量用动词作为开头，描述每个步骤。

如：打开、点击、设置、选择、插入、双击等•不要在一个步骤中描述不相关的多个操作。

Bug状态流程图对Bug的处理开发组长/经理每天对Bug进行分配，标注处理意见，给定优先级（发版前必须三方:需求、开发、产品共同确定）。

问题分配时，应尽可能将咨询类、理解错误类等问题处理掉，而不是留给开发人员。

有可能是需求的问题,分配给需求人员.定期对Bug库分析，找出常出错的模块，进行代码审查开发人员分析Bug，写出问题原因，修改Bug；实行Bug优先原则,严重程度B-Major类或紧急程度3—High 类以上（包含）bug5个或5个以上，停止新功能的开发。

需求人员解释需求，给出处理意见，将Bug库中的建议整理成需求文档。

评审确定后列入开发计划测试人员不参与问题的优先级的定位，只用Bug级别反映Bug的严重程度.验证Bug是否已被解决测试组长/经理审核测试人员提交的Bug。

定期对Bug库进行分析，描绘出曲线图等,报告现状、预测趋势.在测试总结报告中给出意见产品人员可以对优先级和处理意见等进行审核，如果有意见,和项目组商量定夺Bug状态(Status）：指缺陷通过一个跟踪修复过程的进展情况。

包括New、Open、Reopen、Fixed、Closed及Rejected等Bug严重级别（Severity，Bug级别)：是指因缺陷引起的故障对软件产品的影响程度.由测试人员指定.Bug优先级（Priority）:指缺陷必须被修复的紧急程度.由Bug分配者（开发组长/经理）指定.功能模块(Subject)：TD中需在Test Plan页中定义好Subject,才能在Defects页中使用。

问题描述、附件附图请参见后面第四部分‘Bug描述要求’的有关内容。

处理意见：开发组长/经理(或具体Bug分配人员）在审核新Bug时、将Bug分配给开发人员解决前，需要给出该Bug的处理意见。

说明：1。

定为Duplicated的Bug，必须注明和XXXbug重复2。

测试人员对标明为Duplicated的Bug复测,需要XXXBug修改后方可进行3. 定期回顾Can’t Reproduce，Postponed4。

C 100% 开启 关机时间过长
闭，有时需要24秒才能关闭本机，参考参考对比 （FLIR样机）2秒关屏，5秒关闭本机，关机时间
优化关机时间
刘仁彬
需要优化。
A
100%
开启
长时间待机休眠后无法开启 画面。
待机进入休眠，出现进度条显示0%，此时无法打 开图像，只能关机重启。
可正常开启
如图4 刘仁彬
B
100%
刘仁彬
B 100% 开启 按键调节亮度无变化
手动触摸调节正常，按左右键调节亮度，亮度条 有反应，但屏幕亮度无变化。
可调节
刘仁彬
格式化USB存储设备，同时描述的“清除手机的
C
100%
开启
存储设置中，USB存储设备描 述有误
内部USB存储设备中的全部数据”建议改为SD卡 或TF卡存储设备，描述改为：清除热像仪的内部
BUG0069 软件 设置界面
BUG0070 软件 BUG0071 软件
设置界面 设置界面
BUG0072 软件 设置界面
BUG0073 液晶板 电流参数
BUG0074 软件 主界面操作
BUG0075 软件 BUG0076 软件 BUG0077 软件
设置界面 设置界面 设置界面
BUG0078 软件 主界面操作
开启
设置界面中电池显示电量数 字位置偏移
电池图标显示的电量数字偏上，建议居中
居中
刘仁彬
B
100%
开启
USB图标处，无连接状态，却 打开界面没有连接时，USB图标处显示USB已连
显示“已连接”
接；
显示正常
刘仁彬
BUG0066 软件 设置界面 BUG0067 软件 设置界面 BUG0068 软件 设置界面

bug记录表No模块名称BUG描述1综合管理/权限管理前台收银时的开单、点菜、退菜、换菜等功能无法在此处实现，应添加相关按钮2前台收银/开单开单时，一名服务员可以服务的客人数量没有限制3前台收银/开单开单时，一名服务员可以服务的包间或桌子数量没有限制4前台收银/开单同一个包间或桌子可以开单的数量应该有限制5前台收银/菜品调价菜品调价应该不能调为零6前台收银/提示开关提示开关无效7前台收银/打印点菜单没有连接打印机时，打印功能仍能运行，但没有给出任何提示。

8前台收银用鼠标拖动滚动条时，对话框不能实时滚动9前台收银/屏保点开屏保后，所弹出的对话框无法关闭10前台收银/结账最低消费无法更改，一直为零11前台收银/结账服务费无法更改，一直为零12前台收银/结账结账时，菜品打折应该有所限制13前台收银结帐时，如果顾客被选为VIP成员（中行－金卡），并且采用非打折方式时，VIP成员的打折算法会出错。

14前台收银/换桌如果将客人换至另一个已有其他客人的包间，仍可以操作，造成混乱15前台收银/菜品评议此模块中，如果不能查出账单，系统不能自动给出提示。

16前台收银/屏保没有屏保17前台收银/当日消费单据没有连接打印机时，打印功能仍能运行，但没有给出任何提示。

18前台收银/当日消费单据如果查不出账单或查询条件选择错误，系统不能给出任何提示。

19综合管理/大堂管理/客户管理新增功能中的姓名项应该设置为能重复20综合管理/大堂管理/客户管理新增功能中的客户姓名数据类型不正确21综合管理/大堂管理/客户管理新增功能中的电话号码数据类型不正确22综合管理/大堂管理/客户管理新增功能中的手机号码数据类型不正确23综合管理/大堂管理/客户管理新增功能中的身份证号码数据类型不正确24综合管理/大堂管理/客户管理新增功能中的卡凸号数据类型不正确25综合管理/大堂管理/客户管理新增功能中的卡号数据类型不正确26综合管理/大堂管理/客户管理新增功能中的身份证号码长度不正确27综合管理/大堂管理/客户管理新增功能中的身份证号码应该禁止输入特殊字符28综合管理/大堂管理/客户管理新增功能中的电话号码应该禁止输入特殊字符29综合管理/大堂管理/客户管理新增功能中的邮政编码应该禁止输入特殊字符30综合管理/大堂管理/客户管理新增功能中的卡号应该禁止输入特殊字符31综合管理/大堂管理/客户管理用鼠标拖动滚动条时，对话框不能实时滚动32综合管理/大堂管理/客户管理新增功能中的荣誉度没有大小限制33综合管理/大堂管理/客户管理新增功能中的卡凸号应该禁止输入特殊字符34综合管理/大堂管理/客户管理没有连接打印机时，打印功能仍能运行，但没有给出任何提示。

软件测试-BUG规范BUG 规范一、BUG编写规范BUG的summary描述需简明扼要，例如：“上传文档：输入超长字符，系统出黄页！”（应尽量少出现不肯定的词语，如：是否）。

由于输入特殊字符而出现的BUG，BUG的Description或summary中应写明是哪些字符。

相同的BUG出现在不同的页面，应在summary中写明哪些页面也出现此问题，不应书写多条BUG（若书写为多条BUG则在前面打上记号如“--”，方便删除）。

若不能定位BUG出现的原因，应写明操作时所使用的帐号与操作步骤。

在第一次执行测试时尽量写出所有发现问题及建议。

若BUG描述不能说明清晰应夹带附件（有附件也应夹带附件），并在BUG的Description中加上文字描述（如：附件１：导出EXCEL 前，附件2：导出EXCEL后）。

若在测试过程中，不能及时记住BUG的操作步骤，应在记起时将BUG书写完整，并致电告知开发人员使之进行处理。

在测试过程中，若遇到严重问题应该致电告知开发人员使之尽早进行处理。

对于所发现的问题不太清楚是不是BUG，可打电话与开发人员确认，或者询问测试组负责人或测试跟进人员。

在选择BUG的Severity(严重级别)时，应注意根据BUG的严重程度来确定，理清建议与BUG的意义，（建议：可修复也可不修复，修复了会更好，不修复也可以）不应将建议写成BUG，或将BUG写成建议。

——BUG严重级别定义详见附录二、验证BUG在验证BUG时，R&D Comments应注明验证时的实际输出结果，方便日后跟踪及统计。

在验证BUG时，应查看History，查明BUG修改的时间，避免将刚Fixed的BUG 重新Reopen。

在验证BUG时，若原有的BUG未修复，则应该Reopen；若原有的BUG所描述的现象已不存在，则Closed；若由于对原有BUG的修改而引发新的BUG，则应该Open记为新的BUG，不应将原有的BUG再Reopen。

3.27软件Bug详细记录表
不是因为你相信“学习是苦根上长出来的甜果”，所以你总能坚持着努力学习？经过两年的不懈努力，你已成为全校闻名的好学生。新的学习生活已经在你面前展开，愿你驾驶着装满知识的巨轮，树起理想的风帆，擎着奋斗的指南针，抵达成功的彼岸。功能模块
因为你坚信：“人生的道路不会一帆风顺，事业的征途也充满崎岖艰险，只有奋斗，只有拼搏，才会达到成功的彼岸。”所以，经历了两次大考的失败，你没有垮下，磨练得更加坚强又回到了“第一”。相信在冲刺阶段的一年中，困难挡不住勇敢者的脚步，你会靠实力做一个出类拔萃的人。生动性和实效性。2、树立以人为本的学生观生的品德形成和社会性发展源于他们对生活的体验、认知和感悟，我们引导他们区关注生活，珍视学生独特的生活经验，强调体验式、探究式和研讨式等学习方式，帮助他们尝试着自己区解决生活中的问题；我们要关注学生的健康成长，就要尊重他
谢谢你看完全篇文本，希望所编写的内容对你有所帮助！你有好的想法和见解可以编辑文档添加上去。Bug说明
级别
状态
修改人

bug管理规范及流程1、概述本文档定义bug的整个生命周期，规范bug的解决方案及管理流程。

Bug在流转的过程中有章可循。

规范bug严重等级与bug解决优先级，使开发人员与测试人员能根据此文档准确判断bug的严重程度并加以解决；2、关键角色及职责3、Bug生命周期4、Bug书写规范4.1 BUG标题1)以一个简短的句子描述某个模块存在的问题；或者某个操作导致了什么问题；2)描述问题时要简练、直接切入主题，但是要抓住要点；3)偶现bug在主题前标注出现的次数；4)有些模块功能比较多，可以在主题描述前标注上具体得操作；示例：【偶现3次】【账号切换】登录非本机手机号，切换回本机号码登录后，收不到消息【偶现2次】添加载体库时程序停止运行4.2重现步骤说明区域包括：步骤、预计结果、实际结果、测试环境、bug出现时间、截图、日志1) 用数字编号，一步步的描述问题的重现步骤；2) 不同的操作步骤产生不同的问题，需分别报bug；尽量做到一个bug汇报一个问题；3) 偶现问题必须明确bug出现的时间、提供截图以及日志；5、Bug解决方案当天提交的新建状态bug，对应的开发人员需在2天内全部审核一遍，将bug分成以下3类：拒绝、进行中、延期、反馈（给产品）；开发已修复的bug：将bug状态置为已解决；同时添加说明验证版本号、错误原因、解决办法；示例：验证版本：V1.0.1.1101（1101表示在11月1号可以验证）问题原因：未作条件判断解决方法：进行合理边界判断开发认为不是bug：将bug状态置为已拒绝；指派给bug提出者；同时注明拒绝理由；示例：参考XXX设计，测试人员理解错误；bug缺乏必要的信息，无法重现：将bug状态置为已拒绝（无法重现）；指派给bug提出者；同时注明拒绝理由；示例：缺少必须日志；开发已修复，测试验证通过的bug：将bug状态置为关闭，并注明通过版本号；示例：V1.0.1.1103验证通过开发已修复，测试验证不通过的bug：将bug状态置为打回（激活），并根据实际情况注明反馈理由；示例：V1.0.1.1103版本验证此问题仍然存在；步骤：XXX出现时间：XXX测试环境：XXX截图、日志；测试、开发有争议的bug：指派给对应产品经理，进行讨论确认修改方案；由产品经理编辑bug状态为激活/不予处理/转为需求，并注明理由。

状态流程图：软件错误的状态新信息(New)：测试中新报告的软件缺陷；打开 (Open)：被确认并分配给相关开发人员处理；修正(Fixed)：开发人员已完成修正，等待测试人员验证；拒绝(Declined):拒绝修改缺陷；延期(Deferred): 不在当前版本修复的错误，下一版修复关闭(Closed)：错误已被修复；人员角色new—tester（测试工程师）declined-not bug--Test Supervisor（测试主管）declined-duplicated--Test Supervisor（测试主管）open--Project Manager/Technical Manager（项目经理/技术主管）fixed—programer（工发工程师）closed—tester（测试工程师）deferred-next build--Test Supervisor（测试主管）deferred-next main release--TestSupervisor（测试主管）Bug管理的一般流程1. 测试人员提交新的Bug入库，错误状态为New。

2. 高级测试人员验证错误，如果确认是错误，分配给相应的开发人员，设置状态为Open。

如果不是错误，则拒绝，设置为Declined(拒绝)状态。

3. 开发人员查询状态为Open的Bug，如果不是错误，则置状态为Declined；如果是Bug则修复并置状态为Fixed。

不能解决的Bug，要留下文字说明及保持Bug为Open状态。

对于不能解决和延期解决的Bug，不能由开发人员自己决定，一般要通过某种会议（评审会）通过才能认可。

4. 测试人员查询状态为Fixed的Bug，然后验证Bug是否已解决，如解决置Bug的状态为Closed，如没有解决置状态为Reopen。

软件错误流程管理要点为了保证错误的正确性，需要有丰富测试经验的测试人员验证发现的错误是否是真正的错误，书写的测试步骤是否准确，可以重复。

附录二：单元测试Bug清单 附录二：单元测试Bug清单 Bug
单元测试Bug清单
项目名称 Bug ID 提交人 提交给 问题名称 问题描述 项目阶段 用例 ID 下面由测试人员填写 版本号 提交时间 Email Email
□需求分析 □结构设计 问题类别 □硬件 问题级别 □重大 可再现否 □是 再现描述
下面由问题解决者填写 □无法再现问题 □依照设计 □保留 □问题被撤回 解决时间
下面由测试验证人员填写 验证人 验证版本 验证Bug ID 验证时间 □没有解决 □已经解决但引起新的问题 问题状态 □已经解决 已经解决但引起新的问题Bug ID 备注
□详细设计 □单元测试 □设计 □高 □否
□集成测试 □系统测试 □编码 □中 □不一定
□验收测试 □维护 □建议 □疑问 □低
修改建议 备 优先级 意见 注 下面由Bug管理人员填写 □立即解决 □尽快解决 □下一阶段解决 □可能的情况下解决 对问题解决的意见，建议，修改期限等 □ 解决 问题状态 □已经解决 已解决版版本 处理说明

密闭空间安卓版
2/6
145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201
密闭空间安卓版
3/6
验证人
末次验证日期
备注
密闭空间安卓版
4/6
密闭空间安卓版
5/6
密闭空间安卓版
6/6
严重等级
解决过程描述
回答者
回答日期
原因归类
其它原因 第1次验证结果 验证人
末次验证日期
备注 第2次验证结果
截图1，是 操作手册上 预期结果， 和实际结果 截图2 截图3 截图4 截图5 截图6
1/6
68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144
8 未解决 5 通过替代方案解决/暂不处理 0 保留（已通过讨论） 1 正常解决

1.附录1.1BUG优先级与严重级别定义1.1.1BUG优先级(Priority)定义➢P5-urgent 最高优先级设定原则：此优先级别的Bug，如果不进行修改会影响到系统主要功能的测试，优先级别最高。

此级别的BUG将操作中断测试不能继续进行；程序崩溃；预期功能未实现；bug重现率在90%以上；处理原则：原则上处理周期控制在BUG发布当天；➢P4-Very High 较高优先级设定原则：此优先级别的Bug，如果不进行修改，会影响到相关此组件其他功能的测试，优先级别较高；处理原则：原则上处理周期控制在BUG发布后的一天内；➢P3-High 一般优先级设定原则：此优先级别的Bug，如果不进行修改，说明该功能没有实现或实现有错误，优先级别一般；处理原则：原则上处理周期控制在BUG发布后的一天内；➢P2-Medium 较低优先级设定原则：此优先级别的Bug，如果不进行修改，不影响主要功能，属于页面美观和易用性的问题；处理原则：原则上处理周期控制在BUG发布后的两天内；➢P1-Low 最低优先级设定原则：此优先级别的Bug，不影响主要功能，只是页面上的文字错误或者需要改进的建议；处理原则：原则上处理周期控制在BUG发布后的两天内；1.1.2BUG严重级别(Severity)定义➢S5-urgent类严重错误，主要现象包括：✓由于程序所引起的死机,非法退出✓死循环✓导致数据库发生死锁✓数据通讯错误✓严重的数值计算错误➢S4-Very High类较严重错误，主要现象包括：✓功能不符✓数据流错误✓程序接口错误✓轻微的数值计算错误➢S3-High类一般性错误，主要现象包括：✓界面错误(详细文档)✓打印内容、格式错误✓简单的输入限制未放在前台进行控制✓删除操作未给出提示➢S2-Medium类较小错误，主要现象包括：✓辅助说明描述不清楚✓显示格式不规范✓长时间操作未给用户进度提示✓提示窗口文字未采用行业术语✓可输入区域和只读区域没有明显的区分标志✓系统处理未优化➢S1-Low类微小缺陷测试过程中站在用户角度提出一些易用性，人性化等更利于系统优化的建议（非系统缺陷）；1.2BUG中角色变更BUG状态对应说明1.2.1测试人员可以改变的bug状态➢Open：测试中新报告的软件缺陷；➢Invalid：描述的问题不是一个bug (输入错误后，通过此项来取消)；对于开发人员置为“Duplicate”且经过确认的BUG测试人员将后提交的BUG置为该状态；➢Reopen：测试人员验证fix状态的bug，发现bug没有修订好；➢Closed：错误已被修复；1.2.2开发人员可以改变的bug状态➢Fixed：开发人员已完成修正，等待测试人员验证；➢Confirmed：一个bug已经被确认，已经决定修复这个bug。

项目5测试中的BUG管理项目简介软件测试人员的职责是找出软件系统中存在的各种缺陷，以及跟踪处理这些缺陷。

从测试管理的角度来讲，如何有效管理发现Bug将直接影响软件的质量与工作效率，本项目将介绍在测试工作中Bug管理的流程，和两种有效的Bug管理工具。

实施模块1.Bugizilla工具的使用。

2.Test Director工具的使用。

能力目标1.了解软件测试中是管理Bug的一般流程。

2.了解Bugizilla工具的配置，工作原理及简单使用。

3.了解Test Director工具的配置，工作原理及简单使用。

模块1 Bugizilla工具的使用软件BUG管理系统功能有多有少。

但最少要管理以下几种信息：●如何重复软件BUG的详细步骤●正常情况（无BUG）应是怎样●现在情况（有BUG）又是怎样●谁来负责修补BUG●问题有没有解决Bugzilla是Mozilla公司向我们提供的一个开源的免费缺陷跟踪工具。

作为一个产品缺陷的记录及跟踪工具，它能够为你建立一个完善的Bug跟踪体系，包括报告Bug、查询Bug 记录并产生报表、处理解决、管理员系统初始化和设置四部分。

在Bugizilla中，Bug的管理流程如图5-1：图5-1任务1：Bugzilla操作1、用户登录及设置1.1用户登录<1>用户输入服务器地址，如：http://192.168.1.9/cgi-bin/bugs/index.cgi。

<2>进入主页面后，点击【Log in to an existing account】，再点击【login in】进入。

<3>进入注册页面，输入用户名和密码即可登录。

用户名为Email 地址，初始密码为用户名缩写。

登录后自动进入查询页面。

<4>如忘记密码，输入用户名,点击【submit request】，根据收到的邮件进行重新设置。

1.2 修改密码及设置<1>Login登录后，【Edit prefs】->【accout settings】进行密码修改。

XXXXXXXXXXXXXXXXXXXXXXXXXX 测试组BUG管理规范版本历史目录1BUG管理工具介绍 (3)2BUG定义 (3)2.1BUG分类 (3)2.2Bug等级 (4)2.3Bug状态 (4)2.4Bug优先级 (5)3BUG的生命周期 (5)4BUG管理规范 (6)4.1项目的创建 (6)4.1.1项目名称及代号规范 (7)4.1.2项目的模块及版本划分规范 (7)4.1.3用户角色权限分配规范 (7)4.2BUG提交规范 (7)4.2.1BUG的报告内容 (8)4.2.2问题类型选择 (9)4.2.3BUG简要描述 (11)4.2.4优先级选择 (11)4.2.5模块及版本选择 (11)4.2.6BUG详细描述 (11)4.2.7其他规范 (12)4.3BUG分配及处理 (12)4.3.1BUG的分配 (12)4.3.2BUG处理 (13)4.4BUG验证及关闭 (13)1BUG管理工具介绍常用的BUG管理工具有JIRA、BugFree、Bugzilla、Mantis、XPWeb等。

我们公司采用的是JIAR，JIRA是Atlassian公司出品的项目与事务跟踪工具，被广泛应用于缺陷跟踪、客户服务、需求收集、流程审批、任务跟踪、项目跟踪和敏捷管理等工作领域。

2BUG定义2.1BUG分类BUG 就是指系统存的各种缺陷，可以从很多角度对BUG进行分类。

1、从功能方面分，产生BUG的原因大体可以归结为以下四种：A.重复的功能；B.多余的功能；C.功能没有达到设计的要求；D.功能实现与设计要求不相符。

2、从易用性方面分，可以归结为三点：A.界面不美观，控件排列、格式不统一，焦点控制不合理或不全面；B.缺少帮助信息，或者帮助信息不完全；C.功能操作复杂，提示信息不合理，易产生歧义。

3、从安全性方面分，BUG可以划分为以下几类：A.数据有效性检测不合理；B.重要数据在传输中没有加密；C.缺少身份认证机制或认证不合理；D.数据产生缺乏随机性；E．网络安全性：开放端口、服务； F．系统日志、审计。

三、需求规格说明书需求规格说明书1.前言1.1 编写目的软件缺点追踪管理系统在现代软件开发中已经据有了很重要的地点。

每一个软件组织都知道一定妥当办理软件中的缺点，这是关系到软件组织生计、发展的质量根本。

因此我们要熟习认识软件追踪管理系统的基本流程。

1.2 项目背景软件名称：软件缺点追踪管理系统软件。

1.3 定义软件测试的主要目的在于发现软件存在的错误 (Bug) ，关于怎样办理测试中发现的错误，将直接影响到测试的成效。

只有正确、快速、正确地办理这些错误，才能除去软件错误，保证要公布的软件切合需求设计的目标。

在实质软件测试过程中，关于每个 Bug 都要经过测试、确认、修复、考证等的管理过程，这是软件测试的重要环节。

为了正确追踪每个软件错误的办理过程，往常将软件测试发现的每个错误作为一条条记录输入拟订的错误追踪管理系统。

作为一个缺点追踪管理系统，需要正确设计每个错误的包含信息的字段内容和记录错误的办理信息的所有内容。

字段内容可能包含测试软件名称，测试版本号，测试人名称，测试事件，测试软件和硬件配置环境，发现软件错误的种类，错误的严重等级，详尽步骤，必需的附图，测试说明。

办理信息包含办理者姓名，办理时间，办理步骤，办理建议，错误记录的目前状态。

缺点就是：不知足用户确立的需求；软件使用中间出现的问题；不切合设计要求。

2．任务概括2.1 缺点管理的目标（1）保证被发现的缺点可以被解决；这里解决的意思不必定是被修正，也可能是其余办理方式（比如，在下一个版本中修正或是不修正），总之，对每个被发现的 BUG 的办理方式一定可以在开发组织中达到一致；（2）采集缺点数据并依据缺点趋向曲线辨别测试过程的阶段；决定测试过程是否结束有好多种方式，经过缺点趋向曲线来确立测试过程能否结束是常用而且较为有效的一种方式；（ 3）采集缺点数据并在其长进行数据剖析，作为组织的过程财产。

2.2 缺点管理的一般流程缺点信息提交后，会进行分派，进入待修正状态。