BUG管理流程与规范
目录
1概述 (4)
1.1编写目的 (4)
1.2适用范围 (4)
2关键角色及应负责任 (4)
3BUG流程图 (5)
4活动描述 (5)
5BUG书写规范 (7)
5.1测试人员BUG提交 (7)
5.1.1主题 (7)
5.1.2步骤 (7)
5.1.3实际结果 (7)
5.1.4预期结果 (7)
5.1.5备注 (8)
5.2开发人员解决BUG (8)
6BUG严重等级 (9)
6.1致命 (9)
6.2严重 (9)
6.3一般 (10)
6.4优化 (10)
7BUG优先级 (10)
7.1紧急 (10)
7.2高 (11)
7.3中 (11)
7.4低 (11)
8BUG解决方案 (11)
8.1设计如此 (11)
8.2重复BUG (11)
8.3已解决 (11)
8.4无法重现 (11)
8.5延期处理 (11)
8.6新增/变更需求 (11)
9BUG状态 (11)
9.1激活 (11)
9.2已解决 (11)
9.3关闭 (11)
10其他要求 (12)
11相关文件 (12)
12附件 (12)
1概述
1.1编写目的
本文档定义bug的整个生命周期，规范bug的管理流程。Bug在流转的过程中有章可循。
规范bug严重等级与bug解决优先级，使开发人员与测试人员能根据此文档准确判断bug的严重程度并加以解决。
1.2适用范围
本文档适用测试人员、开发人员。
2关键角色及应负责任
序号角色应负责任
01 测试工程师1)提交bug，用bug级别反映bug的严重程度，
2)验证bug是否已被解决
02 测试负责人1)审核测试人员提交的bug ；
2)定位测试工程师提交的bug优先级
3)定期对bug库进行分析，描绘出曲线图等，报告现状、预测
趋势，在测试总结报告中给出意见。
4)分析项目测试过程中存在的风险
03 开发工程师1)分析bug，写出问题原因，修改bug，
2)实行bug优先原则，严重程度5个以上的，停止新功能的开
发。
04 开发负责人1)每天对bug进行分配，标注处理意见
2)定期对bug库分析，对bug多的模块，进行代码走查。
3)分析bug修复进度，对项目的质量、进行风险评估。
4)跟踪被需求确认可延期处理的bug
05 系统工程师1)解释需求，给出处理意见，
2)将bug库中的建议整理成为需求文档
3)当开发和测试存在意见分歧时，进行需求确认。
Bug 管理流程
测试工程师
测试主管
开发工程师
开发主管
系统工程师
跟踪阶段
提出bug
修复阶段验证阶段提交bug
判断是否是bug
提交并激活
确认与分配
Y 分析是否是bug
指定优先级
确认并指派bug
修复bug ，并说明产生原因
Bug 验证是否修复关闭bug
Y 描述不清楚或不是bug
判定不是bug 或重复bug
分析是否是bug
仲裁是否是bug 指派给需求确认大的变更需求/新增需求，修改需求文档
确认是问题应变更或新增需求
需求确认不是bug
是否是bug
开发分析不是bug
修复bug
重新激活bug ，并指派
修改状态为已修复
Y 是否 在该版本修复Y
确认bug 为延期修复，但bug 状态为已解决，不能关闭，在修复完成以后需要指派给测试人员进行验证
确认是bug ，但该版本不修复并指定修复版本
是否确认延期修复
需求确认为必须在该版本修复
是否延期修复
立即修复
Y
开发确认是bug 但该版本不修复
确认bug 为无效bug ，关闭
bug
确认不是bug
修改状态为已修复
需求判定为延期指派给开发主管
是否新增/变更需求分析是问题但应该变更需求
确认是bug ，需求如此或很小的改动需求，在备注中说明，并激活bug
需求确认是bug ，指派给开发
指派给测试
Bug 状态：激活，已修复，已关闭
解决方案：设计如此，重复Bug ，已解决，无法重现，延期处理，新增/变更需求
4 活动描述
序号
活动名称 参与角色
活动描述
输入、输出信息 处理时限
01
提交bug
测试工程师
详细书写Bug ，指派给对应的测试负责人
输入信息：
无
输出信息： 在禅道上提交bug ----
02
Bug 确认与分配
测试负责人
根据<<软件需求>>判
定是否是Bug ，给出意见
输入信息：
测试人员提交的bug ，测试用例，软件需求
输出信息：
确定bug 优先级，指派给开发负责人。
0.5个 工作日 03
分析确认并指派Bug
开发负责人
根据<<软件需求>>判
定是否是Bug ，给出意见
输入信息：
测试负责人指派的bug ，软件需求，程序源代码等
0.5个 工作日
输出信息：
分析Bug，指派给对应的开发工程师，不是bug或应该需求变更时，指派给相关人员
04 修复Bug 开发工程师修改Bug，给出解决方
案，修复再次激活的
bug。
输入信息：
开发负责人确认指派的
bug，软件需求
输出信息：
Bug的解决方案，产生
bug的原因，指派给对
应的测试工程师
0.5个
工作日
05 验证Bug 测试工程师验证Bug，给出验证结
果
输入信息：
开发工程师指派的已修
复的Bug，需求确认转
为变更或新增需求的
bug
输出信息：
如果Bug未修改，激活
并指派给对应的开发工
程师；
如果Bug已修改或系统
工程师确认转为需求的
bug，关闭bug，
0.5个
工作日
06 确认bug延
期
测试主管
分析bug，确认bug是
否能延期处理
输入信息：
开发或系统工程师指派
的延期bug
输出信息：
确认是否能延期处理，
对应延期的bug在开发
修复的版本进行激活
视实际情况而定
07 Bug仲裁系统工程师根据<<软件需求>>判
定是否是Bug，给出处
理意见
输入信息：
测试主管指派的延期
bug或需要系统工程师
确认的bug，开发主管
指派的新增/变更需求
的bug。
0.5个
工作日
输出信息：
给出明确处理结果，属
于新增/变更需求的bug
需要在需求文档中记录
相关需求。
5BUG书写规范
5.1测试人员BUG提交
5.1.1主题
?用一个简短的句子描述问题，不要写成一大段
?以进入问题模块路径开头，方便项目经理分派任务，以及开发人员定位问题
?描述问题时要详细、简练、抓住要点，直接切入正题，不要罗嗦
?不要夸大或缩小问题的严重程度
5.1.2步骤
?用数字编号，一步步的描述重现问题的所有操作步骤
?提供明确的再现问题的步骤，避免问题被以“不能重现”关掉
?设置区域需要详细描述，如：各设置项值为默认、**值更改为“”，其他设置项值为默认；?尽量用动词作为开头，描述每个步骤。如：打开、点击、设置、选择、插入、双击等
?不要在一个步骤中描述不相关的多个操作。如果是相关的一系列操作，可以使用“→”
来连接描述。
?按照你写的步骤去执行，看问题能否重现
?不要在步骤中使用含糊不清的缩写词描述
5.1.3实际结果
?实际只描述一个问题
?同样的操作步骤产生多种现象，要在一个缺陷报告中加以描述
?不同的操作步骤产生不同的问题，分别报bug
?如果有截图，请列出所附的图片信息
5.1.4预期结果
?不要加入实际结果的描述信息
?描述要清晰，不要使用含糊不清的缩写词描述
?如果有截图，请列出所附的图片信息
5.1.5备注
?避免写成大段落，要写得简单、易读
?问题的特征
?出现问题后的解决方法
?对终端客户的影响情况
?如果有必要，列出产生问题的配置环境
5.2开发人员解决BUG
1.BUG的原因。
2.BUG的修改方法
3.BUG可以在哪个版本上进行验证。
4.测试人员验证bug时，需要写明：验证了什么，在什么版本验证，是否通过，如果不
通过需写明原因。如果在验证当前bug时有新现象产生阻碍了验证此bug，则该bug不能关闭，写明没有验证的原因，并为新现象提bug。
举例1：
现象：
修改后：
6BUG严重等级
6.1致命
不能执行正常工作功能或重要功能，因软件原因导致系统死机等，须马上修正致命错误。通常有如下情况：
1.内存泄漏
2.由于执行程序引发数据库发生死锁
3.用户数据丢失或破坏
4.系统崩溃
5.死机
6.程序无法启动或异常退出
7.因错误操作导致的程序中断
8.功能设计与需求严重不符
6.2严重
影响系统功能或操作，应用模块错误使业务中止无法进行后续操作，主要功能存在严重缺陷，但不会影响到系统稳定性。
具体基本上可分为：
1.功能未实现
2.功能错误
3.业务中止，无法进行后续操作
4.数据库的表、业务规则、缺省值未加完整性等约束条件
5.数据库表结构错误，字段长度不够，缺少表、存储
6.语音或数据通讯错误
7.数值计算错误
8.前台提示存储报错
9.系统所提供的功能或服务受明显的影响
6.3一般
影响系统正常运行的缺陷，主要功能出现错误，影响到产品的使用。例如：次要功能不能正常实现；查询错误，数据错误显示；简单的输入限制未放在前台进行控制具体基本上可分为：
1.操作界面错误（包括数据窗口内列名定义、含义是否一致）
2.报表打印内容、格式错误、取值错误
3.页面查询结果错误，自动读值项取值错误
4.边界条件下错误
5.提示信息错误（包括未给出信息、信息提示错误等）
6.简单的输入限制未放在前台进行控制
7.长时间操作无进度提示
8.光标跳转设置不好，鼠标（光标）定位错误
6.4优化
使操作者不合理或者不方便或操作遇到麻烦，但它不影响执行工作功能或重要功能，次要功能，对产品使用影响不大。例如：程序在一些显示上不美观，不符合用户习惯，或是一些文字的错误。
具体基本上可分为：
1.界面格式等不规范
2.辅助说明描述不清楚
3.操作时未给用户提示
4.可输入区域和只读区域没有明显的区分标志
5. 个别不影响产品理解的错别字
6.文字排列不整齐等一些小问题
7.提示窗口文字未采用行业术语
7BUG优先级
7.1紧急
阻止与此密切相关功能的进一步测试,需要立即修复
7.2高
必须修改，发版前必须修正
7.3中
必须修改，不一定马上修改，但需确定在某个特定里程碑结束前须修正
7.4低
对系统的影响较小，如果时间允许应该修改
8BUG解决方案
8.1设计如此
设计如此，测试人员理解错误，无需改动，即无效的bug
8.2重复bug
以前已经有同样的bug。
8.3已解决
Bug已经被修改正确，待测试进行验证
8.4无法重现
根据测试写的重现步骤，无法重现bug。
8.5延期处理
确实是bug，但现在不解决，以后处理。
8.6新增/变更需求
分析确实是存在问题，但需求没有描述清晰，应指派给需求确认，进行需求的新增或变更。
9BUG状态
9.1激活
1.新创建的bug；
2.已关闭的bug重新出现需要再次激活；
3.已解决但验证未通过的bug。
9.2已解决
开发已经修改完成的bug。
9.3关闭
已验证通过的bug或系统工程师确认转为需求的bug。
10其他要求
Bug的描述与Bug的流向严格遵守流程规范。11相关文件
文件编号
文件名称
12附件
文件编号文件名称保存时
间
保管
部门
附件
Bug管理规范
一、概述 本规范是常规的bug管理流程，适用于项目过程中的bug管理
二、BUG周期
三、Bug的分类、状态、级别 3.1 bug分类 1. 功能 A.重复的功能；B.多余的功能；C.功能没有达到设计的要求；D.功能实现与设计要求不相符。 2. 易用性 A.界面不美观，控件排列、格式不统一，焦点控制不合理或不全面；B.缺少帮助信息，或者帮助信息不完全； C.功能操作复杂，提示信息不合理，易产生歧义。 3. 安全性 A.数据有效性检测不合理；B.重要数据在传输中没有加密；C.缺少身份认证机制或认证不合理； 4. 可靠性 A.数据存贮的可靠性；B.业务处理的可靠性； 5. 性能 A.并发量；B.吞吐量；C.响应时间。 6. 兼容性不同厂商的浏览器以及浏览器的不同版本，手机app指不同操作系统 3.2 bug状态 Bug的状态主要分为新建、已分派、已解决、重新打开、已关闭、挂起。 ?新建状态（NEW ）：Bug创建后的初始状态。 ?已分派状态（ASSIGNED）：经过确认为有效问题后分配给开发人员的状态。 ?已解决状态（RESOLVED）：开发人员对软件问题进行处理或修改后的状态。 ?重新打开状态（REOPENED）：对开发人员修改后软件问题，经过验证，如果仍然存在，则将其状态改为“重新打开”状态。 ?关闭状态（CLOSED）：Bug解决后测试人员验证通过，则将其状态修改为已关闭 ?挂起状态：经过项目经理确认延期修改的bug 3.3 bug严重等级和优先级定义 bug的严重级别定义：
BUG优先级定义： 四bug描述规范 bug描述要简洁明了，方便开发人员重现和后续跟踪。 版本：当前测试的版本号 平台：测试使用的平台说明 摘要：概要描述问题。 描述：应该描述问题发现的步骤、期望结果和实际结果 描述可分为“步骤”、“结果”（含：期望结果、实际结果）、“补充说明”三部分，各部分之间用空行隔开。“补充说明”部分可根据实际情况选择是否需要描述。具体格式如下： 步骤： 期望结果： 实际结果： 补充说明： 1. 如果多处出现类似问题，应描述出现该问题的所有模块或界面。 2. 如果不可重现，应说明 附件：添加错误附图或错误信息。
b u g管理规范及流程 YKK standardization office【 YKK5AB- YKK08- YKK2C- YKK18】
bug管理规范及流程 1、概述 本文档定义bug的整个生命周期，规范bug的解决方案及管理流程。Bug在流转的过程中有章可循。规范bug严重等级与bug解决优先级，使开发人员与测试人员能根据此文档准确判断bug的严重程度并加以解决； 2、关键角色及职责 ?
3、Bug生命周期 4、Bug书写规范 BUG标题 1)以一个简短的句子描述某个模块存在的问题；或者某个操作导致了什么问
题； 2)描述问题时要简练、直接切入主题，但是要抓住要点； 3)偶现bug在主题前标注出现的次数； 4)有些模块功能比较多，可以在主题描述前标注上具体得操作； 示例： 【偶现3次】【账号切换】登录非本机手机号，切换回本机号码登录后，收不到消息 【偶现2次】添加载体库时程序停止运行 重现步骤 说明区域包括：步骤、预计结果、实际结果、测试环境、bug出现时间、截图、日志 1) 用数字编号，一步步的描述问题的重现步骤； 2) 不同的操作步骤产生不同的问题，需分别报bug；尽量做到一个bug汇报一个问题； 3) 偶现问题必须明确bug出现的时间、提供截图以及日志； 5、Bug解决方案 当天提交的新建状态bug，对应的开发人员需在2天内全部审核一遍，将bug分成以下3类：拒绝、进行中、延期、反馈（给产品）； 开发已修复的bug：将bug状态置为已解决；同时添加说明验证版本号、错误原因、解决办法； 示例： 验证版本：（1101表示在11月1号可以验证） 问题原因：未作条件判断 解决方法：进行合理边界判断
Bug提交管理规范 修订历史
目录 1. BUG管理工具介绍 (3) 2. BUG定义 (3) 1. BUG分类 (3) 2. Bug等级 (3) 3. Bug状态 (4) 4. Bug优先级 (4) 3. BUG的生命周期 (4) 4. BUG管理规范 (5) 1) 项目的创建 (5) 项目名称及代号规范 (5) 项目的模块及版本划分规范 (5) 用户角色权限分配规范 (6) 2) BUG提交规范 (6) BUG的报告内容 (6) 主题，即BUG简要描述 (7) 严重程度选择 (7) 优先级选择 (8) 模块及版本选择 (8) 环境 (9) BUG详细描述 (9) 其他规范 (9) 3) BUG分配及处理 (10) BUG的分配 (10) BUG处理 (10) 4) BUG验证及关闭 (10)
1.BUG管理工具介绍 常用的BUG管理工具有JIRA、BugFree、Bugzilla、Mantis、XPWeb等。我们公司采用的是JIAR，JIRA是Atlassian公司出品的项目与事务跟踪工具，被广泛应用于缺陷跟踪、客户服务、需求收集、流程审批、任务跟踪、项目跟踪和敏捷管理等工作领域。 2.BUG定义 1.BUG分类 BUG 就是指系统存的各种缺陷，可以从很多角度对BUG进行分类。 1、从功能方面分，产生BUG的原因大体可以归结为以下四种： A.重复的功能； B.多余的功能； C.功能没有达到设计的要求； D.功能实现与设计要求不相符。 2、从易用性方面分，可以归结为三点： A.界面不美观，控件排列、格式不统一，焦点控制不合理或不全面； B.缺少帮助信息，或者帮助信息不完全； C.功能操作复杂，提示信息不合理，易产生歧义。 3、从安全性方面分，BUG可以划分为以下几类： A.数据有效性检测不合理； B.重要数据在传输中没有加密； C.缺少身份认证机制或认证不合理； D.数据产生缺乏随机性； E．网络安全性：开放端口、服务； F．系统日志、审计。 4、从可靠性方面分，BUG可划分为以下几类： A.数据存贮的可靠性； B.业务处理的可靠性； C．硬件可靠性：如打印机；D.应急处理措施； E．数据备份、恢复。 5、从性能方面考虑，BUG可划分为三种： A．并发量； B．吞吐量； C．响应时间。 6、从兼容性方面考虑，BUG有两种： A．硬件兼容性； B．软件兼容性。 7、从可维护性方面考虑，可划分为两种原因： A．可扩展性； B．方便升级。 2.Bug等级 BUG等级是根据BUG出现在系统中的严重程度来分的，主要定义如下5级： 1级——致命：系统重要功能无法正常使用，系统崩溃；系统设计存在重大隐患；导致用户利益受到重大损失。该级别需要程序员修改。 2级——严重：系统主要功能无法正常实现，系统业务受到严重影响；导致用户利益受到损失。该级别需要程序员修改。 3级——一般：系统次要功能无法实现；主要功能部分失效；系统业务受到影响；导致用户利益受到一定损失。该级别需求程序员修改。
软件缺陷管理办法 1.目的 本文档定义了软件缺陷管理流程和相关规则，确保软件缺陷管理的系统性和规范性，以保证项目研发质量。 2.适用范围 适用于部门项目研发过程的缺陷管理，对各阶段的缺陷管理过程进行指导和规范。 3.定义 3.1 术语 缺陷（Defect）：存在于软件之中偏差，可被激活，以静态形式存在于软件内部。 Bug：缺陷一种表现形态，系统或程序存在的任何一种破坏正常运转能力的问题。 3.2 缺陷定义 （1）软件未达到需求规格说明书的功能； （2）软件出现了需求规格说明书指明不会出现的错误； （3）软件功能超出需求规格说明书的范围； （4）软件未达到需求规格说明书未指出但应达到的目标； （5）测试工程师认为软件难以理解、不易使用、运行速度慢，或者最终用户认为不好。 4.缺陷生命周期
4.1 缺陷生命周期图 4.2 缺陷状态说明 5. 缺陷处理过程 5.1 正常处理过程 （1）创建问题 在测试管理系统中，所有用户都可以创建新问题，包括需求问题和软件缺陷等。创建问题时，需要描述清楚，并选择正确的选项，详细请参考5.4和5.5。
（2）指派问题 创建问题时，创建者通常要指派给该项目开发负责人，再由其指派任务，或直接指派给相应模块的开发工程师。 如果指派人是错误的，或者需要他人确认或帮助，则可以重新指派给合适的工程师，写上相关备注。 （3）确认问题 通常开发工程师收到新问题后，需要分析和确认此问题是否为Bug。如果是Bug，则选择“确认状态”；如果认为非Bug，则注明原因并指派回创建者。 当创建者收到确认指派时，需要进行及时确认。如果同意为非bug，则及时关闭它；如果不同意，则需要注明理由并指派回相关工程师。 如果问题确认指派次数大于6次时，需要进入“争议处理”流程，详细请参考5.2。 （4）解决问题 此为开发工程师的主要职责，包括Bug的复现、修改和修改验证。 开发工程师需要及时对确认状态Bug进行分析和解决，并自己验证通过，则操作为解决状态，解决方案规则请参考5.4中解决方案定义部分，在缺陷管理系统中解决方案选择相应的选项，解决后系统将自动指派回给创建者。 如果Bug无法解决或修改影响比较大，可申请进入“延期解决”流程，请参考5.2中延期处理部分。 （5）验证问题 创建者需要及时对解决状态的Bug在对应版本上面进行验证。如果验证通过，则可关闭Bug；如果验证不通过，则激活此Bug，系统将自动指派回给解决者。
禅道Bug提交管理规范 修订历史
目录 目录 (2) 1. 目的 (3) 2. 禅道系统Bug流程图 (4) 3. Bug流程操作及其Bug相关信息解释 (5) 3.1.测试人员发现bug (5) 3.2.测试人员创建Bug (5) 3.3.开发人员设定Bug优先级别并确认Bug (7) 3.4.开发人员解决Bug (8) 3.5.测试人员验证Bug (9)
1.目的 本文档定义了bug管理流程及其bug相关信息内容。 本文档适用范围： ●本文档适用于新产品以及以后新产品的项目。原有项目的bug管理仍然用JIRA系 统进行管理。 ●本文档适用于新产品以及以后新产品的项目相关的测试人员和开发人员。
2. 禅道系统Bug流程图
3. Bug流程操作及其Bug相关信息解释 3.1.测试人员发现bug 3.2.测试人员创建Bug 测试人员登录禅道系统，创建Bug。Bug状态为激活（未确认） 创建Bug页面截图： 页面字段注释： 所属产品：选择发现Bug的产品，必填项。 所属模块：选择发现Bug的对应模块，必填项。 所属项目：选择测试所属的项目。必填项。 影响版本：选择发现bug的版本。必填项。 当前指派：选择指派的开发人员。必填项。 Bug标题：用简单明了的语句说明Bug内容，相当于BUG的中心语句。必填项。 在标题上注明bug出现的频率（稳定出现/经常出现/很少出现/出现一次）重新步骤：重现步骤格式如下。必填项。 [环境]：如果系统/浏览器信息不能够全部说明发现Bug的环境，需要在 重现步骤里详细描述环境信息，以便于开发定位和解决问题。 [步骤]：写明出现Bug的操作步骤，要求简单，去掉与Bug无关的步骤。 [结果]：写明操作的实际结果。
BUG处理流程说明 一、B UG处理流程图： 流程描述： 1、测试人员发现bug提交给开发。 2、开发人员判断是否是bug。 3、如果是bug，进行修改，修改完成后更改bug状态为已解决。 4、如果不是bug，退回给测试人员并描述退回原因，或为设计如此，或为外部原因， 或者不能重现。
5、开发人员修改完成的bug，由测试人员进行验证，确认修改正确，关闭bug。 6、验证未通过的bug重新激活，开发人员继续修改，直至验证通过，关闭bug。 7、测试人员需要对开发人员退回的bug进行确认。 8、确认不是bug关闭。 9、如与开发人员意见不一致，认为是bug，需提交项目负责人仲裁。 10、项目负责人确认是bug由开发人员修改，不是bug由测试人员关闭。 注：除提交项目负责人仲裁环节外，其他环节都可以在禅道上完成。 二、各角色应关注的状态 1.开发人员：激活、重新打开 激活：开发人员要对处于激活状态的bug进行处理，处理后将其状态置成“已解 决”、“设计如此”、“无法重现”、“外部原因”、“重复bug”或“延期处理”。 重新打开：重新打开的bug是已解决的bug经过测试人员验证，未修改正确，需 要继续修改。 2.测试人员：已解决、无法重现、设计如此、外部原因、延期处理 已解决：测试人员发现状态为“已解决”的BUG，要及时验证，如果确实已解 决，要将其置为“关闭”。否则“重新打开” 无法重现：测试人员发现状态为“无法重现”的BUG，要及时修改，把步骤描 述清楚，并将其状态置为“重新打开”。 设计如此：测试人员发现状态为“设计如此”和“外部原因”的BUG，要及时 通知项目经理，由项目经理来决定是否修改；对“延期处理”的问题要进行定期 跟踪，如发现问题没有按注释进行修改要及时通知开发人员或汇报给相关负责 人。 3.项目经理：设计如此、外部原因、延期处理 设计如此：因为这些BUG都是测试人员和开发人员有争议的BUG，因此项目经 理必须及时关注这些BUG，及时给出合理的定夺，如果不需修改把状态置成“关 闭”，如果需要立刻解决置成“重新打开”，否则置成“以后解决”。同时，项目 经理也要关注“延期处理”的BUG，以免其被漏掉或遗忘从而影响到项目上线。 三、缺陷严重级别及类型定义 ◆致命错误包括： 1．造成系统崩溃、死机 2．造成程序非法退出、死循环、通讯中断或异常 ◆严重错误包括：
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)
1 BUG管理工具介绍 常用的BUG 管理工具有JIRA、BugFree、Bugzilla、Mantis、XPWeb 等。我们公司采用的是 JIAR ，JIRA 是Atlassian 公司出品的项目与事务跟踪工具，被广泛应用于缺陷跟踪、客户服务、需求收集、流程审批、任务跟踪、项目跟踪和敏捷管理等工作领域。 2 BUG定义 2.1BUG分类 BUG 就是指系统存的各种缺陷，可以从很多角度对BUG 进行分类。 1、从功能方面分，产生BUG 的原因大体可以归结为以下四种： A.重复的功能； B.多余的功能； C.功能没有达到设计的要求； D.功能实现与设计要求不相符。 2、从易用性方面分，可以归结为三点： A. 界面不美观，控件排列、格式不统一，焦点控制不合理或不全面； B .缺少帮助信息，或者帮助信息不完全； C.功能操作复杂，提示信息不合理，易产生歧义。 3、从安全性方面分，BUG 可以划分为以下几类： A.数据有效性检测不合理； B.重要数据在传输中没有加密； C.缺少身份认证机制或认证不合理； D.数据产生缺乏随机性； E.网络安全性：开放端口、服务； F.系统日志、审计。 4、从可靠性方面分，BUG 可划分为以下几类： A.数据存贮的可靠性； B.业务处理的可靠性； C.硬件可靠性：如打印机； D.应急处理措施； E.数据备份、恢复。 5、从性能方面考虑，BUG 可划分为三种： A .并发量； B .吞吐量； C .响应时间。
一、文档目的 作为质量管理体系的一部分，Bug管理对一个项目组是否具有规范化的流程显得尤其重要。编写此文档的目的是为了完善项目组的Bug管理流程，提高Bug质量，帮助测试组和开发组进行更好的沟通。此文档的阅读者包括开发人员、测试人员以及项目组管理人员。 二、Bug管理流程 为了更直观的阐述Bug管理流程，本文以流程图的方式来说明。如下图：
Bug状态(Status)和解决状态(Resolution)的说明： Status： New——当测试人员新提交一个Bug, Bug的状态默认为New Open——测试组长对新提交的Bug进行确认，如为有效Bug，Bug指给相关开发人员并且把Bug状态设置为Open In Progress——开发人员确认为有效Bug，并且开始处理Bug时，修改Bug的状态为In Progress Resolved——开发人员对Bug完成处理，把Bug状态设置为Check In，并且把Bug指回给开发人员进行验证 Reopen——开发人员已解决问题，测试不认同开发人员的解决方案时，将Bug重新打开Closed——当Bug已经确认被解决或者确认不是Bug的时候将Bug的状态设置为Closed Resolution： Need More Information——需要更多信息。当测试组长确认Bug，发现Bug描述不够详尽时，把Bug指回给Bug的Reporter，并且把Resolution项设置为Need More Information，对应的状态为Open；当开发人员处理Bug时，需要测试人员提供更多的Bug信息，把Bug指回给Bug的Reporter，并且把Resolution项设置为Need More Information，对应的状态为In Progress。 Invalid——无效。测试组长确认Bug，发现该Bug无效时，把Resolution项设置为Invalid，对应的状态为Closed；当开发人员处理Bug，发现该Bug无效时，把Resolution 项设置为Invalid，对应的状态为Resolved。 Duplicate——重复。测试组长确认Bug，发现该Bug和已有Bug重复时，把Resolution 项设置为Duplicate，对应的状态为Closed；当开发人员处理Bug，发现该Bug和已有Bug重复时，把Resolution项设置为Duplicate，对应的状态为Resolved。 Fixed ——已修复。开发人员对Bug修改完成并且已经登记，等待测试人员确认，把Bug 指回给Bug的Reporter，并且把Resolution项设置为Fixed，对应的状态是Resolved；测试人员对Bug完成验证并且确认已修复，把Resolution项设置为Fixed，对应的状态是Closed。 Unable To Reproduce——无法复现。被指派的开发人员对Bug进行修改但发现Bug始终不能再现的时候，把Bug指回给Bug的Reporter，并且把Resolution项设置为Unable To Reproduce, 对应的状态是Resolved；测试人员对Bug完成验证并且确认无法复现，把Resolution项设置为Unable To Reproduce，对应的状态是Closed。 Won’t fix——不准备修。开发人员确认Bug有效但是不准备修改这个bug的时候，把Bug指回给Bug的Reporter，并且把Resolution项设置为Won’t fix，对应的状态是Resolved；测试人员对Bug完成验证并且确认Bug不需要修复的时候，把Resolution项设置为Won’t fix，对应的状态是Closed。 Suspended ——延期。开发人员确认Bug有效但是在当前版本不准备修复该Bug，下个版本再提供解决方案的时候，把Bug指回给Bug的Reporter，并且把Resolution项设置为Suspended，对应的状态是Resolved；测试人员对Bug完成验证并且确认当前版本不准备修复该Bug时，把Resolution项设置为Suspended，对应的状态是Closed。
BUG定义规范Revision History
1.目的 对BUG概念、BUG提交和验证、BUG状态、BUG严重程度等内容进行定义和规范，以便进一步指导我们的测试工作 2.概念 BUG:软件中存在的瑕疵，可能会导致软件失效。简单的说就是软件系统中存在的可能导致系统出错、失效、死机等问题的错误或缺陷 3.BUG管理工具 以Quality Center 9.0为提交、跟踪等工具 4.BUG提交和验证要求 以QC中的字段为准 提交时必选字段有：摘要，跟踪类型，检测者，检查日期，计划关闭版本，可重现，分 派给，严重程度，状态，描述 验证后，需要修改字段：关闭于版本，关闭日期，状态BUG描述模板如下： [问题概要]: [重现步骤]: 步骤1. 步骤2. [隔离分析]: [期望结果]: [重现概率]: [Test Case No.]:（若没有用例，则标注‘NA’，若是地区版本上的问题，则标注地区名称） [Test Case]:（若没有用例，则标注‘NA’，若是地区版本上的问题，则标注地区名称） QC中优先级和严重程度的区别：优先级由软件开发人员填写，严重程度由测试人员填写 计划关闭版本定义： 有2重含义：1.由测试人员填写当前发现bug的版本号；2.开发人员必须在此版本上修改 5.BUG验证 开发人员必须提供修改此bug会涉及到的功能点列表，并将此信息填写到bug描述中。 测试人员除验证此bug外，还需要将开发列出的功能点逐一验证，同时写入自己考虑到的功能点验证情况 来自需求和测试自己提交的问题，测试人员都需要验证，并填写测试结果，其中来自自己的bug，若验证通过，则修改状态为“关闭”；来自需求人员的bug，则修改状态为“验证完毕”，由需求人员来关闭（适用于胜算组）。 6.BUG状态流程 在正在BUG生命周期中，可能会经历很多状态，如：新建、提交验证、已关闭、重新打开、已挂起、重复提交等。 新建：新发现的问题 提交验证：开发修改bug后，会将状态变为提交验证，让测试工程师来执行验证操作已关闭：测试工程师经过验证后，发现此问题已经被修复，则修改状态为已关闭
Bug定义规范 1、bug类型的划分 功能类： 1、重复的功能 2、多余的功能 3、功能实现与设计要求不符合 4、功能使用性、方便性、易用性不够 5、功能未实现 界面类： 1、界面不美观 2、控件排列、格式不统一 3、焦点控制不合理或不全面 数据处理类： 1、数据有效性检测不合理 2、数据来源不正确 3、数据处理过程不正确 4、数据处理结果不正确 流程类： 1、流程控制不符合要求 2、流程实现不完整 提示信息类： 1、提示信息重复或出现时间不合理 2、提示信息格式不符合要求 3、提示框返回后焦点停留位置不合理 建议类： 1、功能性建议 2、操作建议 3、检校建议 4、说明建议 2、bug等级定义 Level 1-致命的bug：100%程序崩溃、重启、死机，自动退出，用户数据丢失，缺少主要功能。 1、程序无法正常使用，在正常操作流程中（特别是操作步骤不复杂，用户很容 易就用到）出现崩溃、死机现象 2、100%导致用户数据丢失的问题 3、被测试数据系统频繁崩溃，程序出错，使功能不能继续使用 4、性能与需求不一致 5、系统资源引发性能问题 6、系统配置引发错误 7、安全性问题
Level 2-严重的bug：所产生的问题导致系统瘫痪，重要功能未实现，严重影响用户使用的问题，关键用户需求未实现或软件功能与需求严重不符。 1、功能与需求不一致，或功能未实现 2、功能有错误 3、数据传输有错误 4、安装与卸载有问题 Level 3-一般的bug：所产生的问题会导致系统部分功能不正常，虽然产生的问题严重，但不影响下一步的测试，严重的界面提示问题。 1、功能有错误，但不影响使用 2、重要界面的显示问题 3、内存泄露导致某些功能无法正常使用，释放内存重启后系统恢复正常 4、复现率较低的死机、重启问题，步骤多用户不易操作到 5、边界条件出错 Level 4-轻微的bug：轻微界面显示问题，对用户使用无影响的问题。 1、微小功能问题，如闪烁中间界面、界面刷新慢 2、轻微的界面显示错误，界面设计不规范，交互不友好 3、消息、提示信息不准确 4、用户可以接受，对功能不影响 5、某些次要功能，在进行某些很特殊的操作后某些功能不能正常响应 Level 5-建议性bug：功能运作正常，可是有改进的空间，建议性问题所产生的问题不会导致系统任何问题。 1、可以忽略不计的问题，对用户使用没有任何影响，但有改进空间 2、软件设计有问题 3、文档不完整或不准确 4、其他建议性问题 3、BUG状态 （初始状态） 1、已提交：测试人员员发现BUG后提交到BUG管理系统中的状态。 2、已修改：开发人员在修改了BUG后提交到BUG管理系统中的状态。 3、不修改：程序员或产品人员根据需求分析、概要设计、详细设计说明书等经过考虑后决定对BUG不进行修改。其BUG的状态为不修改，需要说明理由。 4、延迟：根据目前项目进程或计划等情况，暂时延期的状态 5、待讨论：需要进行讨论后才能决定是否需要修改的BUG的状态。 6、已验证：已经解决的并经过测试员复测的BUG的状态。 7、关闭：完全解决了，只供以后备查的状态 8、重新打开：重新出现在新的版本中，重新打开以前关闭的BUG的状态
BUG提出和处理流程规范 1引言 1. 1目的 提高测试以及产品缺陷修改效率，避免出现搁置和遗漏的缺陷，从而提高产品的质量，降低质量检查和缺陷修改成本 1. 2适用范围 适用于研发部门（Confernece、Flash、监控），质量保证部门 1.3 定义 bug：通过测试检查出的产品缺陷； 新建、打回、已确认、已指派、已解决、已关闭：测试中bug的不同状态，详细信息见本规范第3部分； 1. 4参考资料 无 2 BUG提交和处理规范说明 1、在测试人员提交bug的时候，必须对bug信息进的描述必须详细全面、清晰明确，如果有条 件，需要描述使用的环境，在BUG出现前的具体操作，如果抓图，必须抓取jpg全屏图象，但不能使用BMP格式上传到BUG库中，有抓包文件需要上传BUG库，空间不够需要放到\\192.168.0.254\qa\测试\bug日志目录中，标题以BUG号区分； 2、在测试人员提交bug的时候，必须按具体情况，填写重要级别、出现频率、优先级别三个栏 目，而非测试人员不得对上述信息进行直接改变，如觉得这三个信息填写不恰当，可以在该bug下的注解中提出意见，并“打回”给bug提交人员或质量部经理处，经过确认后修改；
3、开发人员对bug进行处理后的变更状态成“打回”时，或“指派”给产品部门时以及变更成 “已确认”时必须进行必要的描述和说明,在状态变更时，必须要指定具体接收人； 4、开发人员在注解中描述该BUG计划什么时候解决或做其他阐述的时候，要明确写清承诺的 具体版本号，禁止使用“上一版本”、“本版本”、“下一版本”等字样，以免造成误会或混淆； 修改完成的BUG注释中加入相关的确认信息，如“XXX Review并通过。 5、如果已经是“关闭”状态的BUG，测试人员在后期测试中又出现了需要重新打开，重开后 的BUG状态为“打回”，测试人员需要再多一个操作，即“指派”给具体的研发人员。 6、一直处于“打回”状态的BUG，测试人员需要经过两轮（即两个版本）测试后仍然没有重 现的，可以关闭。但是此两轮测试在该BUG中必须有注释，比如：“XX版本（要求有具体版本号）测试没有重现”，当第二轮测试仍没出现时也需要注释一次，即可进行关闭。 3 Mantis Mantis是PHP/MySQL/Web-based缺陷跟踪系统。 其特点： 个人可定制的Email通知功能，每个用户可根据自身的工作特点只订阅相关缺陷状态邮件； 支持多项目、多语言； 权限设置灵活，不同角色有不同权限，每个项目可设为公开或私有状态，每个缺陷可设为公开或私有状态，每个缺陷可以在不同项目间移动； 主页可发布项目相关新闻，方便信息传播； 支持上传文件，提供进一步的bug信息； 支持上传项目文档； 方便的缺陷关联功能，除重复缺陷外，每个缺陷都可以链接到其他相关缺陷； 缺陷报告可打印或输出为CSV格式。支持可定制的报表输出，可定制用户输入域； 有各种缺陷趋势图和柱状图，为项目状态分析提供依据，如果不能满足要求，可以把数据输出到Excel 中进一步分析； 流程定制不方便，但该流程可满足一般的缺陷跟踪。 在提交bug时需要填写相关信息，还可以上传相关文件（如出错的log或者截图等），对于bug添加注释（允许再次更新）。下面是基本信息的介绍 [出现频率] 可重现-- 稳定地能重现 经常-- 比较经常出现 偶尔-- 偶尔出现 不可重现-- 无法重现 N/A -- 其他情况 [严重性] 不合理或别扭-- 使用不方便，吹毛求疵的标准 文本错误-- 文本错误 崩溃死锁-- 导致死机的bug 严重错误-- 导致功能无法正常运行下去
基于Tortoise SVN的软件产品版本管理规范[草稿]
目录 1. 引言 (1) 1.1. 目的 (1) 1.2. 范围 (1) 1.3. 术语定义 (1) 1.4. 参考资料 (2) 1.5. 版本控制记录 (2) 1.6. 版本更新记录 (2) 2. 版本管理 (4) 2.1. 版本标示方法 (4) 2.1.1. 正式版本 (4) 2.2. 目录结构 (5) 2.3. 文档的存放 (6) 2.3.1. 开发文档的存放 (6) 2.3.2. 源代码的存放 (6) 2.3.3. SQL的语句存放 (7) 2.3.4. 发行文档的存放 (7) 2.4. 配置管理流程 (7) 2.5. 权限控制的管理 (8) 3. 更新管理 (9) 3.1. 源程序的修改 (9) 3.2. 版本升级 (10) 3.2.1. 版本升级原则 (10) 3.2.2. 新版本发布 (11) 3.3. 文档的变更 (11) 4. 备份管理 (12) 5. 版本工具Tortoise SVN的使用 (13)
1.引言 版本控制就是对软件开发过程中所创建的配置对象不同版本进行管理，保证任何时间都可以取到正确的版本以及版本的组合。 版本控制的主要功能是记录开发过程中的每一次修改，让开发的工作可以随时检查过往历史记录和获得正确版本，是系统的成长记录。 1.1. 目的 本文档的编制是为了规范产品部、研发部、测试部对软件产品版本的管理。 1.2. 范围 本文档为产品部、研发部、测试部的管理员提供有关版本管理规范的相关内容，包括： ●版本标识方法 ●软件系统数据的存放 ●文档的修改控制 ●文档的备份制度 1.3. 术语定义 SCM 软件配置管理（Software Configuration Management）缩写 SVM 软件版本管理（Software Version Management）缩写 SVN 一个开源的版本控制系统Subversion. 文档 一种数据媒体和其上所记录的数据。
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．系统日志、审计。 4、从可靠性方面分，BUG可划分为以下几类： A.数据存贮的可靠性； B.业务处理的可靠性； C．硬件可靠性：如打印机；D.应急处理措施； E．数据备份、恢复。 5、从性能方面考虑，BUG可划分为三种： A．并发量； B．吞吐量； C．响应时间。 6、从兼容性方面考虑，BUG有两种：
ＢUG管理流程与规范
目录 １?概述..................................................................................................................... 错误!未定义书签。 １.1编写目的.......................................................................................... 错误!未定义书签。 1.２适用范围.......................................................................................... 错误!未定义书签。 2关键角色及应负责任?错误!未定义书签。 ３?ＢUＧ流程图...................................................................................................... 错误!未定义书签。 4活动描述........................................................................................................... 错误!未定义书签。 5ＢUG书写规范?错误!未定义书签。 5．1?测试人员BUＧ提交?错误!未定义书签。 5．1.1主题?错误!未定义书签。 ５．１.2?步骤.................................................................................................. 错误!未定义书签。 5.1.3?实际结果................................................................................................. 错误!未定义书签。 5.1.４?预期结果............................................................................................... 错误!未定义书签。 5.1.５备注.................................................................................................. 错误!未定义书签。5．2?开发人员解决BUG ................................................................................... 错误!未定义书签。 6?BＵG严重等级?错误!未定义书签。 ６.1?致命?错误!未定义书签。 6.2?严重?错误!未定义书签。 6．3?一般错误!未定义书签。 6．4优化?错误!未定义书签。 7BUG优先级..................................................................................................... 错误!未定义书签。 7.1?紧急?错误!未定义书签。 7.2高...................................................................................................... 错误!未定义书签。 7.３中...................................................................................................... 错误!未定义书签。7．4低?错误!未定义书签。 ８ＢUG解决方案................................................................................................ 错误!未定义书签。 8．1?设计如此..................................................................................................... 错误!未定义书签。 8.2重复BＵG ......................................................................................... 错误!未定义书签。8．３?已解决?错误!未定义书签。 8.4无法重现?错误!未定义书签。 ８.５?延期处理.................................................................................................... 错误!未定义书签。 ８．6新增/变更需求................................................................................. 错误!未定义书签。9?BUG状态 ............................................................................................................. 错误!未定义书签。 9．１激活.................................................................................................. 错误!未定义书签。 ９.2已解决.............................................................................................. 错误!未定义书签。９.3?关闭错误!未定义书签。
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状态为激活/不予处理/转为需求，并注明理由。
Bug提交标准规范 JIRA管理软件提交的bug做到：言简意赅，语意明确 bug报告内容： 产品模块选择产品模块 项目选择项目 主题填写该缺陷名称，在提交bug时，bug主题要描述言简意赅，语 意明确，让开发人员一眼看出哪里有问题。 优先级选择优先级 所属项目选择所属项目 影响版本 当前指派选择指派给开发人员 Bug标题填写该缺陷名称，在提交bug时，bug标题要描述言简意赅，语 意明确，让开发人员一眼看出哪里有问题。 如：龙旅在线前台系统->修改个人资料，修改用户名姓名“XX”改为“张三” 重现步骤步骤自动生成，可进行修改，内容需尽可能详细，使开发人员可 以重现该bug。 如有前置条件请说明前置条件：如特定的操作方式，特殊的用户，特殊的浏览器等，能有利于bug复现的操作尽量进行提供。 如：前置条件：系统登录成功，使用登录账号：zhangcui 密码：asd123 浏览器：firefox 操作步骤：1、点击“修改个人资料” 2、修改姓名为“张三” 3、点击“保存” 预期结果：保存成功，姓名修改为“张三” 实际结果：提示保存失败！
数据库存储相关的bug（和设计的字段不符合，和设计的长度不符合等）需要 以bug记录。其他存储，如redis相关的需要以bug进行记录。 相关需求：有相关需求则选择相关需求，么有则不选择 相关任务：有相关任务则选择相关任务，没有则不选择 类型/严重程度：选择问题类型，根据bug定义规则判断问题严重程度（如：1：致命缺陷；2：严重缺陷；3：一般缺陷；4：轻微缺陷） 系统/浏览器：选择当前测试所属系统及浏览器 抄送给：可以选择要抄送的人员 关键词：填写该缺陷需要注意的事项 添加附件：（如：图片、word、excel、txt等文档）当有bug描述说明不清楚时，可附上截图加以说明（类型分为：1、不容易描述清晰的；2、有特殊性的 如需要特殊的数据日子截图） 注：bug致命和严重问题必须全部解决，一般问题不能超过3个，轻微问题小 于5个方可达到上线（视情况而定）