HPQC测试管理平台ALM操作使用手册

XXXXXXX项目测试缺陷管理&QC使用手册

1 / 69

1登录到QC的缺陷管理系统

打开IE8、IE9浏览器或者HP ALM Explore12.2x，在地址栏输入访问.21:8080/qcbin/start_a.jsp，如果是IE10浏览器，请打开浏览器然后按F12，打开开发人员工具，然后选择IE8兼容模式，然后在输入访问.21:8080/qcbin/start_a.jsp，。

2、如果之前没有安装过相关插件，浏览器会提示是否安装插件，但是在安装插件前一定要将上述站点加到可信站点和本地intranet站点上才能自动下载并安装浏览器插件。

如下图：

A．增加到可信站点：IE8》Internet选项》安全》可信站点

B．增加到Intranet站点：IE8》Internet选项》安全》本地Intranet

配置好A和B之后，点击刷新，浏览器就会自动下载并安装插件。

备注：如果使用IE不行，可以直接使用ALM12自带的浏览器，自带浏览器可以在登录界面时进行下载。

操作步骤如下：

3、安装完插件后会自动跳转到登录页面，如图2所示。在“用户名”输入框输入您姓名的拼音，密码默认为空，点击【身份验证】按钮。

通过验证后“项目”下拉列表会列出你有权访问的项目，如图3所示。选择你要登录的页面，点击【登录】按钮。

说明：

域：Default

项目：项目列表只列出你有访问权限的项目。

大型项目类测试模板

登录后的初始页面。登录成功后，点击“缺陷”，出现如图4所示页面。

进入缺陷列表。点击图4所示页面左边列表中的项，将看到如图5所示的缺陷新增界面。

更改项目。如果你同时拥有多个项目的权限，那么登录到其中一个项目后可以不需要退出而直接更改到另一个项目。点击页面左上角的【工具】，选择【更改项目】，再点击你所想要的项目即可，如三峡付项目UA T。

如果你拥有其他项目的权限，但“更改项目”列表中并没有列出那些项目，你可以点击【选择…】按钮，转到登录页面，选择需要登录的项目，登录一次后该项目名称就会出现在这个列表中了。

注销。点击右上角的即可注销，退出到登录页面。

2QC缺陷管理系统的使用

2.1 缺陷常用字段说明

2.1.1缺陷名称

对缺陷的简单描述。摘要包括该缺陷所属的模块名称-子模块名称，以及简单说明缺陷情况。

2.1.2描述

详细描述重现该缺陷的步骤，错误现象和期待结果。必要时可以上传附件辅助说明。

2.1.3状态

缺陷状态描述如下表：

2.1.4.1 不同角色之间缺陷状态的变化：

缺陷状态的变化

2.1.5严重程度和优先级

缺陷严重级程度与优先级别原则上是有一一对应的关系，在填写缺陷选择这两项时，可先参照该对照表：

注：测试组←→开发组的响应时间规定

紧急：2-3小时（需测试组长跟开发组长做口头提醒/电话）

非常高：1天内（需测试组长跟开发组长做口头提醒/电话,Mail）

高：3天内

中：5天内

低：5天以上

记录测试人员判断该缺陷的类型。

记录开发人员判断该缺陷发生的原因。

记录该缺陷属于哪个模块中。主题字段设置对应为测试计划中的测试主题（功能模块），方便将来统计各个模块的缺陷密度。

2.1.9测试者

记录该缺陷的登记者，系统会自动获取当前用户的用户号，不需要手工录入。

2.1.10测试日期

记录该缺陷的登记日期，通常系统会自动获取当前时间，不需要手工录入。

2.1.11检测于发布

记录发现该缺陷基线版本（Tags），测试组长在每次获取到新的基线版本程序包时，发布到测试环境之后，按照程序包上的版本标签号（一般为BL_YYYYMMDD_SVN版本号），在QC中“管理”模块中的“发布”中增加对应的版本号（注：QC中增加的版本号需与程序包的版本号一致）。如下图，在管理》发布》三峡付项目ST下》点击新增“周期”。

2.1.12可重现

记录缺陷是否可重现。根据缺陷描述操作，是否可以发现缺陷所描述的问题，Y表示可以重现，N表示无法重现。例如有些问题是在特定条件下才出现的，当条件改变后问题随之消失，根据所描述的步骤操作，不会再出现缺陷所描述的问题，这类就是属于无法重现的缺陷。2.1.13子系统

记录缺陷所属的子系统。包含以下内容：

子系统名称开发组长

APP-Android

APP-iPhone

APP-iPad

电子账户

反欺诈

基础服务

门户

网络预填单

业务子系统

管理台

报表

文档

性能问题

记录开发人员修正该缺陷的修复日期，系统会自动获取当前时间，不需要手工录入。

2.1.15关闭日期

记录测试人员关闭该缺陷的关闭日期，系统会自动获取当前时间，不需要手工录入。

2.1.16关闭于发布

记录关闭该缺陷基线版本（Tags），测试组长在每次获取到新的基线版本程序包时，发布到测试环境之后，按照程序包上的版本标签号（一般为BL_YYYYMMDD_SVN版本号），在QC中“管理”模块中的“发布”中增加对应的版本号（注：QC中增加的版本号需与程序包的版本号一致）。如下图，在管理》发布》三峡付项目ST下》点击新增“周期”。

2.1.17修改次数

记录开发人员因修改本缺陷修改代码的次数，用来衡量开发人员修改缺陷的效率，即测试人员每回归测试一次发现回归失败，系统会自动将修改次数加1，不需要手工录入。

2.1.18SVN版本号

记录开发人员修复缺陷后，SVN提交代码后，由SVN自动生成的小版本号，方便测试人员根据该小版本号和基线版本的Tags进行对比，用来获取本基线版本是否包含本缺陷修改的情报信息。开发人员在将缺陷状态由2-打开修改为3-已修正时，SVN版本号必填。

2.1.19修改时间

记录本缺陷单最近一次更改的时间戳，系统自动记录，无需手工录入

2.1.20注释

开发人员在修复缺陷后，需要在注释栏记录SVN版本库中修改的文件名和文件路径以及修改的主要内容，以方便CM或者测试人员进行配置管理和回归测试。另外该栏也可作为各方人员交流的留言窗口，类似论坛的留言功能。注释栏的填写方法见下图：

2.2 系统新增字段说明

2.2.1变更编号

2.2.2测试组长

测试人员在新建缺陷时会有一个字段“测试组长”,这个字段分配到的人员就是这个缺陷的审核人。测试人员新建的缺陷经过测试组长审核，缺陷状态修改为“已审核“。

2.2.3打开时间

开发人员在确认缺陷有效后，缺陷状态由：已审核-->打开，仲裁人员在缺陷状态：拒绝-->打开以及：挂起—>重新打开，打开时间默认是时间当时时间，不需要手动填写。

2.2.4回归测试状态

测试人员在对“已修正”缺陷进行回归测试时使用此字段，进行确认回归是否通过，如果选择“是“，则回归通过，缺陷状态：已修正--->已关闭，如果回归测试不通过缺陷状态：已修正-->回归失败。

2.2.5开发组长

测试组长在确认缺陷有效后，就必须使用“开发组长”字段为缺陷指定一个开发组长，进一步确认缺陷是否有效。

2.2.6缺陷有效性

此字段是测试组长对于缺陷状态为“新建“的缺陷，进行确认缺陷是否有效：选择”无效“，则缺陷状态由：新建--->无效，选择“有效“缺陷状态由：新建—>已审核。

2.2.7是否挂起

此字段是针对仲裁人员对于缺陷状态为拒绝的缺陷，“仲裁是否缺陷”选择“是“时，会出现一个”是否挂起“字段，来进行确认是否要此缺陷挂起，留在以后版本处理。选择”“是“缺陷状态由：拒绝—>挂起，选择否缺陷状态由：拒绝-->打开。

2.2.8是否进行回归测试

测试者针对缺陷状态为“已修正”的缺陷，打开界面时会呈现“是否回归测试字段“进行判断当前是否要进行回归测试，如果选择”是“，表示当前进行回归测试，则会跳出一个“回归测试状态“的字段，如果选择”否“则会跳出“未回归原因“字段。

2.2.9是否已修复

此字段表示开发人员对于缺陷状态为“打开”，“重新打开”和“回归失败“的缺陷判断是否已经修复的操作，如果选择“是“，则缺陷状态会由：打开—>已修正，如果选择”否“则状态不变。

2.2.10是否重新打开

此字段是仲裁人员对于缺陷状态为“挂起“的缺陷，判断是否要重新打开，如果选择”是“则缺陷状态由：挂起--->重新打开，选择“否“缺陷状态不变。

2.2.11未回归原因

此字段针对缺陷状态为“已修正”的缺陷测试者的，”是否回归测试“选择的是否就会出现让测试者填写，不进行回归测试的原因。

2.2.12验证缺陷有效性

此字段是开发组长针对缺陷状态为“已审核“的缺陷再次确认缺陷是否有效，选择”有效“表示缺陷是有效的，选择”无效“表示缺陷是无效的。

2.2.13预计回归工时

测试者选择“是否进行回归测试“字段，选择”是“的时候进行判断大概回归测试需要耗时

多少。

2.2.14暂无法修改

开发人员针对缺陷状态为”打开“的缺陷是否由于此缺陷，本版本无法解决，要留在以后版本解决的操作字段,选择”是“表示此缺陷当前版本下，可以进行修改，选择“否“表示此版本下，当前缺陷可以进行修复。

2.2.15仲裁人员

仲裁人员一般是项目经理，仲裁人员主要是针对缺陷状态为“拒绝”和“挂起“的缺陷进行操作，对于拒绝的缺陷是最终确认缺陷的有效性，如果无效就是伪缺陷，如果有效则进行下一步操作。针对挂起的缺陷主要是判断当前版本下，此缺陷是否要重新打开。

2.2.16仲裁是否缺陷

仲裁人员使用此字段进行最终缺陷有效性的判断，如果选择“是”,表示此缺陷是有效的，可以进行下一步操作，如果选择“否“则表示此缺陷是无效的，是伪缺陷。

2.3 缺陷管理流程图

1、不论是简单还是复杂的缺陷，开发人员都要在修改了代码并确保代码提交到服务器后，再将缺陷状态由“2-打开”置为“3-已修正”，并填写SVN版本号。

2、对于非常简单明了的缺陷（例如界面上的一个错别字），可以在注释中加简单的注释说明：（如：已修改）但对于复杂的缺陷，开发人员在填写注释的时候需包含以下几点：

配置库修改代码对应文件名和文件路径。

缺陷解决的方法：（该项描述主要是方便以后遇到同类问题的同事，可以查看当时的解决办法，如果该缺陷的修改引发了其他的缺陷产生，则开发人员可以查看一下当时的修改情况）3 这个改动引起了哪些变动：（方便测试人员在进行回归测试时，确定回归范围）

如果缺陷是由于测试人员理解错误导致，或者开发人员认为不需要修改的，开发人员可以将缺陷状态设置为“B-拒绝”，但是必须在【注释】栏中填写拒绝修改的原因。

如果目前不具备修改本缺陷的条件（环境原因、涉猎面太广、难度系数很大），开发人员可将缺陷状态设置为“C-挂起”进行延迟修改，但是必须在【注释】栏中填写延迟修改的原因。

4、如果开发人员认为该缺陷与其他缺陷重复，也需要在【注释】栏中填写与之重复的缺陷ID，例如注释内容可以填写：与缺陷10重复。目的是让开发人员再确认一下这两个缺陷是否真的描述同一个问题。

小提示：在新增注释说明时，可以直接点击页面右下方的按钮，QC可以直接添加你的登录帐号在“注释”中，省去自己填写的麻烦！如图12.请大家在填写时养成加入自己信息的习惯，方便测试人员在回归测试时可以看到是谁回复的，有问题方便直接沟通！

2.4 缺陷管理岗位职责

项目经理：对整个项目负责，对产品质量负责，判定缺陷是否应修复，作为仲裁小组成员判定缺陷是否伪缺陷，是否可进行延期修改，严格控制缺陷的生命周期，跟踪缺陷修复情况，直至缺陷关闭；

开发组长：判定缺陷是否可修复，进行缺陷定位，提供修复方案、设计给开发人员，按照计划跟踪编码、缺陷修复任务；

测试组长：按照缺陷管理规范进行跟踪处理，协助开发人员进行缺陷定位，作为仲裁小组成员判定缺陷是否伪缺陷，是否可进行延期修改，严格控制缺陷生命周期，跟踪缺陷修复情况，直至缺陷关闭；

测试人员：执行测试的人员，发现缺陷、提交缺陷，待修复后进行回归测试；

开发人员：执行开发任务的人员，按照计划完成设计、编码、缺陷修复的任务；

2.5 仲裁小组决定伪缺陷和延期修改缺陷的职责

1、仲裁小组的成员包括：项目经理和测试组长，仲裁方式采取项目经理和测试组长定期共同对被拒绝缺陷和挂起缺陷进行逐个分析的方式，并且商议得出最终的处理意见，最终由测

试组长在QC上进行意见反馈和缺陷状态的流转。

2、仲裁小组需要对“B-拒绝”的缺陷进行判定，以决定该缺陷是否伪缺陷，若是，需将缺陷状态置为“E-伪缺陷”，并在注释栏填写确定为伪缺陷的原因；若不是，可以将缺陷置为“2-打开”（立即修改），或者置为“C-挂起”（延迟修改）。

3、仲裁小组若决定延迟修改缺陷，需在注释中写明延迟修改的原因，再将缺陷状态置为“C-挂起”。

4、仲裁小组在对缺陷进行延迟修改后，需在合适的时间将缺陷重新打开，将缺陷状态置为“D-重新打开”让开发人员继续修改

3缺陷填写规范

3.1 缺陷的填写原则

测试人员填写测试缺陷记录时的原则：

单一：一个测试案例执行后可能发现多个缺陷，但一条缺陷记录建议记录一个缺陷；

准确：对问题的描述准确，按照步骤操作，可以重现问题；同时也指对操作和对象的描述准确，不会出现歧义；最好是能够找到错误的直接原因；

完整：对问题现象的描述完整，包括环境（不同的环境），数据，结果（正确和错误部分）等；

延伸：能够举一反三，由发现的问题，对其它可能的情况进行测试，并列出错误或正确的情况；

不要重复提报告：测试人员在提交自己的缺陷之前，先要快速查找缺陷库中是否已经有相似或相关的缺陷。一个缺陷库中，重复的缺陷越少越好；

再小的缺陷也要报告并提交缺陷跟踪系统；

测试人员提交合理的建议，同时对于存在的问题提出自己的建议及表现方法；

以前系统存在的缺陷，作为本项目缺陷提交到缺陷库。

3.2 缺陷填写的相关支持文档

测试人员应该在自己的缺陷记录中加入很好的支持文档，或者至少是供参考的文档。

有用的支持文档包括：

屏幕截图；

重现缺陷的测试案例；

测试脚本；

用来创建某个状态的特定数据（前置条件）；

使用的数据库连接串（环境说明）。

总的来讲，有效的缺陷记录应包含许多信息，在提交报告时通过多种方式准确地描述每项内容。

4不同角色操作缺陷

4.1 测试者

4.1.1新建缺陷

1.填写账号，用户名：ceshi 密码：123456域名：Default 项目：大型测试项目类模板

2.点击“新建缺陷”打开新建缺陷页面：

3.按实际缺陷信息填写缺陷

注意：填写的过程中标红的字段是必填的，灰色字段的是不能操作，也不用操作的字段。

4.填写完信息后，点击按钮。

注意：1.如果填写的信息正确直接提交