QC使用说明

QC使用说明

qc是目前social game组使用的缺陷管理工具。在部门内程序，策划和测试（日后可包括客服）都可能使用到。以下是使用说明。

一． 登录

目前QC的地址为http://服务器IP/qcbin/start_a.htm，访问以上地址即可打开QC登录

界面。如图1.

图1

提示：第一次使用QC会安装一些插件，非IE浏览器的默认设置可能会影响插件的安装，第一次使用请尽量用IE6，7登录，并将安全级别暂时调低，插件安装之后可以用其他浏览器登录(或者安装QC客户端插件)

登录具体步骤：（请参照图1）： 1. 输入Login Name为自己的中文名

2. 输入Password即可登陆（默认密码为空，请登录后修改密码，修改方法见下文） 3. 一般选中图中的复选框并按“Authenticate”按钮

二． 具体使用方法

1. 进入QC的BUG管理界面

如图2，登录后在界面上方有绿色的导航栏，默认显示为REQUIREMENTS。点击第六项DEFECTS，进入BUG管理界面，即可开始相关BUG查看和管理工作。

图2

（附：修改密码方法：见图2，点击TOOLS下的Customize选项（在屏幕右上方），在弹出图3界面，选择Change Password（屏幕右下角）即可打开密码修改窗口。）

图3

2. QC使用主要功能介绍

图4

如图4，粉色框住部分是一个过滤器，你可以设置需要浏览哪些BUG。另外，还可以通过粉色椭圆泉起来的漏斗按钮来选择过滤条件。

例如，想浏览所有提交给你的BUG，方法为：点击Assigned to下面的白色方框，在User中选择你的名字，点击OK，即可浏览提交给你的BUG。

如果要浏览提交给你的处于new状态的BUG，则需要同时在Assigned to中和Status中设置。

如上所述，可设置更多的选项来限制浏览的条件，从而达到更精确的浏览。

提醒：

1) 点击图4中红色中按钮（Select Columns），即可修改过滤器的设置。点击此按钮，将左

侧的项目加入右侧，即可加入过滤器中。

2) 与时间有关项目的设置。选择>=，即可设置时间为某日之后。例如，想浏览6月1日

之后提交的BUG，在Detected on date项中点击>=，再选择6月1日，即可。选择<=，<,>,功能类似，也可以直接选择Today，Yesterday等项来设置时间。

3. BUG查看

图5

在主界面中双击某的BUG项即可查看BUG的具体描述，双击后打开如图4窗口。左侧有4个主按钮：Details中显示BUG提交时的信息，Attachments为BUG相关的附件，Linked Entities 暂时无视，History为操作记录。

Details中几个比较重要的项的相关说明：  Detected in Version：BUG发现的版本号  Detected on Date：BUG发现日期

 问题类型：BUG所属的类型，具体是设计缺陷，还是界面问题，或者是其他问题。(该

字段目前还在配置中)

 重现频率：Always为必现，Often为非必现但非常容易出现的BUG，not often为偶尔

出现的BUG，once为仅仅出现过一次（配置中）

 Assigned to：BUG提交向谁，相关人员查看TD并对BUG做出处理之后必须修改Assigned

to的对象

 Severity：BUG的严重等级，表示对产品会产生多大的影响（较为重要）

 Priority：BUG的优先级，表示BUG的修复级别，开发人员从这个可以看出哪些BUG

需要马上修复，哪些可以延迟修复，此字段由PM填写。

Description项相关说明：

BUG在Description中查看之后，请注意下方Comments框的内容，QC使用人员主要在Comments中信息交互，有具体的说明和备注请写上

如图5，每个人尽量使用一种颜色并附上备注人的姓名和日期，颜色修改可在红框标注地方设置。

图5

Attachments项为附件的查看，如果查看BUG的人员感觉BUG描述不清晰，可以查看相关的附件了解BUG的相关截图或者查看崩溃文件。

History项为操作历史记录，BUG从产生到处理的每一步都有记录，可以点History了解此BUG被处理的流程。

另外，QC使用过程中各用户组权限有所不同，由BUG处理流程而定。 BUG处理流程图：

1． 测试人员，开发人员，策划人员均有权限提交BUG，BUG的初始状态为NEW。BUG

可以提交给对应的开发人员，也可以直接提交给PM。

2． 如果PM或者开发人员认为此BUG描述有问题或者不是BUG，可以将状态改为

rejected。

3． 如果确认为BUG，PM需要将assigned to改为对应的开发人员，并将status更改为

open，开发人员则只需要将状态更改为open;

4． 开发人员修改BUG后，将状态改为fixed。测试人员对FIXED的BUG进行回归； 5． 回归不通过，将status改为reopen，开发人员再重复4的步骤。

NEW确认是BUG否REJECTED是测试人员开发人员确确认是BUG认不是BUGOPENREOPENPM-DEFERRED经过产品、测试、开发确认该版本不修改，由PM挂起开发修改完成FIXED因为环境不允许等其他原因目前版本已无法重现的BUGTM-DEFERRED测试验证OK回归OK回归不通过CLOSED

图6

400+(n-1).500+(n-2)400

400 800 1400 2300