diqitianzuoye

1、市面上有哪些bug管理工具，每个bug管理工具的特点是什么？
2、bug的级别有哪些？
3、bug的管理流程是怎么样的？
4、一条完整的bug应该包含哪些信息？
5、bug的状态有哪些？
6、禅道这款bug管理和用例管理工具的结构有哪些，介绍一下？


(1)Testdirector:
支持平台:Windows
构架模式：B/S
支持数据库:Oracle, M$ Access, SQL Server等
安装配置的复杂度:简单
价格:几十万，昂贵
与其他工具集成:本身又是测试需求、测试案例管理工具,与winRunner, LoadRunner集成，具有多种主流Case工具接口AddIn

       
ClearQuest:
支持平台:Windows,Unix
构架模式：C/S,B/S
支持数据库:Oracle, M$ Access, SQL Server
安装配置的复杂度:复杂
价格:几十万，昂贵
与其他工具集成:与rational公司的其它产品无缝集成，特别与Clear Case配合以可实现UCM的配置管理体系

       
微创BMS：
支持平台:Windows
构架模式：B/S
支持数据库:SQL Server等MSDE
安装配置的复杂度:容易       
价格:几万，适中
与其他工具集成:M$ VSS, Project

Bugzilla：
支持平台inux,FreeBSD
构架模式：B/S
支持数据库:MySQL
安装配置的复杂度:有些复杂
价格：免费
与其他工具集成:开源配置管理工具CVS

       
华创BMS:
支持平台:Windows
构架模式：B/S
支持数据库:Access, SQL Server
安装配置的复杂度:简单

（2）
1级bug：必须优先要改

致命错误：

1、常规操作引起的系统崩溃、死机、死循环

2、造成数据泄漏的安全性问题，比如恶意攻击造成的账户私密信息泄露

3、涉及金钱，如支付类软件，金钱计算错误


2级bug

严重错误：

1、重要功能不能实现（例如：微信没有实现语音聊天、朋友圈，等）

2、错误的波及面广，影响到其他重要功能正常实现

3、非常规操作导致的程序崩溃、死机、死循环 (非常规操作：用户使用软件时不会进行的操作）

4、外观难以接受的缺陷（例如：直播平台的封面图片的失真、压缩，完全变形）

5、密码明文显示


3级bug

一般错误：

不影响产品的运行、不会成为故障的起因、但对产品外观和下道工序影响较大的缺陷

1、次要功能不能正常实现

2、操作界面错误（包括数据窗口内列名的定义，含义不一致）

例如：列名与列名下的内容不一致

3、查询错误、数据错误显示

4、简单的输入限制未放在前端进行控制；（格式显示，如登录和注册中的格式判断可由前端判断）

5、删除操作未给出提示


4级bug

程序在一些显示上不美观，不符合用户习惯，或者是一些文字的错误

1、界面不规范

2、辅助说明描述不清楚

3、提示窗口文字未采用行业术语4、界面存在文字错误5、改进意见：可以提高产品质量的建议， 包括新需求和对需求的改进

（3）
1、测试人员发现bug提交给开发。

2、开发人员判断是否是bug。

3、如果是bug， 进行修改，修改完成后更改bug状态为已解决。

4、如果不是bug，退回给测试人员并描述退回原因，或为设计如此，或为外部原E
或者不能重现。

（4）
发现问题的版本
开发人员需要知道出现问题的版本，才能够获取对应版本的代码来重现故障。并且版本的标识也有利于统计和分析每个版本的质量。
问题出现的环境
环境分为硬件环境和软件环境，如果是web测试项目，需要描述浏览器版本，客户机操作系统等。如果是app测试项目，需要描述机型、分辨率、操作系统版本等。详细的环境描述有利于故障的定位错误重现步骤
测试用例的操作步骤
预期行为的描述
要让开发人员知道怎么样才是正确的，尤其要以用户的角度来描述程序的行为是怎样的。如果是依据需求提出的故障，能写明需求的来源。
错误行为的描述
可以上传日志或者截图。
其他某些公司会有一些其他的要求，例如故障的分类：功能测试故障，界面故障，兼容性测试故障等。有些有优先级的分类，严重影响测试需要开发人员优先修改的，可以设置优先级为高。）

（5）
1、New:（新的）
当某个“bug”被发现的时候（第一次），测试人员需要与项目负责人沟通以确认发现的的确是一个bug，如果被确认是一个bug，就将其记录下来，并将bug的状态设为New。
2、Assigned（已指派的）
当一个bug被指认为New之后，将其将给开发人员，开发人员将确认这是否是一个bug，如果是，开发组的负责人就将这个bug指定给某位开发人员处理，并将bug的状态设定为“Assigned”。
3、Open（打开的）
一旦开发人员开始处理bug的时候，他（她）就将这个bug的状态设置为“Open”，这表示开发人员正在处理这个“bug”。
4、Fixed（已修复的）
当开发人员进行处理（并认为已经解决）之后，他（她）就可以将这个bug的状态设置为“Fixed”并将其提交给开发组的负责人，然后开发组的负责人将这个bug返还给测试组。
5、Pending Reset（待在测试的）
当bug被返还到测试组后，我们将bug的状态设置为“Pending Reset”。
6、Reset（再测试）
测试组的负责人将bug指定给某位测试人员进行再测试，并将bug的状态设置为“Reset”。