HP测试管理平台ALM使用手册.docx

HP测试管理平台ALM使用手册.docx

《HP测试管理平台ALM使用手册.docx》由会员分享，可在线阅读，更多相关《HP测试管理平台ALM使用手册.docx（27页珍藏版）》请在冰豆网上搜索。

HP测试管理平台ALM使用手册

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

文件状态：

【】草稿

【】修改稿

【】正式发布

文档编号

保密等级

作者

最后完成日期

2018-3-12

审核人员

最后审核日期

批准人

最后批准日期

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

打开IE8、IE9浏览器或者HPALMExplore12.2x，在地址栏输入访问http:

//10.64.2.21:

8080/ALMbin/start_a.jsp，

如果是IE10浏览器，请打开浏览器然后按F12，打开开发人员工具，然后选择IE8兼容模式，然后在输入访问http:

//10.64.2.21:

8080/ALMbin/start_a.jsp，。

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

如下图：

A．增加到可信站点：

IE8》Internet选项》安全》可信站点

B．增加到Intranet站点：

IE8》Internet选项》安全》本地Intranet

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

备注：

如果使用IE不行，可以直接使用ALM12自带的浏览器，自带浏览器可以在登录界

面时进行下载。

操作步骤如下：

3、安装完插件后会自动跳转到登录页面，如图2所示。

在“用户名”输入框输入您姓名的拼音，密码默认为空，点击【身份验证】按钮。

通过验证后“项目”下拉列表会列出你有权访问的项目，如图3所示。

选择你要登录的页面，点击【登录】按钮。

说明：

域：

Default

项目：

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

大型项目类测试模板

登录后的初始页面。

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

进入缺陷列表。

点击图4所示页面左边列表中的

项，将看到如图5所示的缺陷新增界面。

更改项目。

如果你同时拥有多个项目的权限，那么登录到其中一个项目后可以不需要退出而直接更改到另一个项目。

点击页面左上角的【工具】，选择【更改项目】，再点击你所想要的项目即可，如三峡付项目UAT。

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

注销。

点击右上角的

即可注销，退出到登录页面。

2ALM缺陷管理系统的使用

2.1缺陷常用字段说明

2.1.1缺陷名称

对缺陷的简单描述。

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

2.1.2描述

详细描述重现该缺陷的步骤，错误现象和期待结果。

必要时可以上传附件辅助说明。

2.1.3状态

缺陷状态描述如下表：

序号

缺陷状态

缺陷状态描述

备注

1

1-新建

测试人员在测试过程中发现缺陷，提交新的缺陷给开发组长进行审核

2

2-打开

开发组长进行判定认定为有效缺陷，并将缺陷分配给具体的开发人员进行修改

3

3-已修正

开发人员已完成修正,等待测试人员进行回归测试

4

4-已关闭

缺陷通过测试人员回归测试，缺陷已被修复

5

5-已审核

测试组长确认测试者提交的缺陷有效

5

A-回归失败

缺陷未通过测试人员回归测试，缺陷未被修复

6

B-拒绝

拒绝修改缺陷，该缺陷可能由于测试人员理解错误或属于重复提交的缺陷，开发组长和开发人员都可以拒绝，拒绝的缺陷需要由仲裁者（一般为项目经理和测试经理）判定后才能认定为伪缺陷。

7

C-挂起

项目经理判定该缺陷不在当前版本进行修复，而在未来版本进行修复

8

D-重新打开

C-挂起的缺陷在条件允许后可重新打开供开发人员进行修复

9

E-伪缺陷

仲裁者（一般为项目经理和测试经理）对B-拒绝的缺陷进行判定后，认定该缺陷确实是由于测试人员理解问题或者重复缺陷等原因导致的无效缺陷（伪缺陷）

10

F-无效

由于测试人员提出的缺陷，测试组长确认无效后，提交缺陷，缺陷状态就会修改为“无效”

2.1.4分配给

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

缺陷状态的变化

事件描述

操作者

前状态

后状态

分配给

测试人员新建缺陷

测试人员

1-新建

测试组长（字段

测试组长判定缺陷无效

测试组长

1-新建

F-无效

无需修改

测试组长判定缺陷有效

测试组长

1-新建

5-已审核

开发组长（字段

测试组长新建缺陷

测试组长

5-已审核

开发组长（字段

开发组长确认缺陷有效

开发组长

5-已审核

2-打开

分配给（修复人

开发组长确认缺陷无效

开发组长

5-已审核

B-拒绝

仲裁人员

开发人员-暂时无法修改缺陷

开发人员

2-打开

B-拒绝

仲裁人员

开发人员-此时修改缺陷

开发人员

2-打开

2-打开

无需修改

开发人员已经修复缺陷

开发人员

2-打开

3-已修正

测试者

开发人员修改延期缺陷

开发人员

D-重新打开

3-已修正

测试者

开发人员修改回归失败缺陷

开发人员

A-回归失败

3-已修正

测试者（默认

测试人员回归测试-通过

测试人员

3-已修正

4-已关闭

无需修改

测试人员回归测试-不通过

测试人员

3-已修正

A-回归失败

开发人员（默认

判定是伪缺陷（仲裁人员

仲裁者

B-拒绝

E-伪缺陷

无需修改

判定不是伪缺陷，立即修改（仲裁

仲裁者

B-拒绝

2-打开

开发组长

判定不是伪缺陷，延期修改

仲裁者

B-拒绝

C-挂起

无需修改

延期缺陷重新打开进行修改

仲裁者

C-挂起

D-重新打开

具体开发人员

2.1.5严重程度和优先级

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

注：

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

紧急：

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

非常高：

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

高：

3天内

中：

5天内

低：

5天以上

严重程度

缺陷严重程度描述

优先级

缺陷优先级描述

A-致命

阻碍流程、系统崩溃导致重大任务不能正常进行的缺陷,例如:

由于程序所引起的死机,非法退出

死循环

数据库发生死锁

错误操作导致的程序中断

严重的计算错误

与数据库连接错误

数据通讯错误等

1-紧急

1.当缺陷所引发的问题没有达到紧急的级别，但当该缺陷出现后，影响到了后续的测试工作进行

2.客户无法容忍的页面，如页面上显示其他公司名称

3.当前操作方式与客户使用习惯背道而驰。

4.严重不合理，核心功能完全违反软件规范或业务规范，可能导致用户强烈的反感

5.系统响应时间过长（例如WEB响应时间超过10s）

6.模块提供的数据不合理，例如（查询“录入人”的下拉项提示为非用户名字段）

7.负载测试、压力测试结果和用户需求不符

B-严重

缺陷导致失去系统主要功能,基本功能不能完整使用例如:

功能不符

程序接口错误

数据流错误

轻微数据计算错误等

2-非常高

1.快捷方式不正确，如能够回车直接进入下一步的设计成了空格直接进入下一步

2.严重的逻辑错误

3.常用操作平台不能正常使用功能（WINXP/WIN2000/WINVISTA）

4.常用浏览器不能正常使用（IE6.0/IE7.0/FireFox）

5.超时限制的时间设置不合理

6.未登录即可浏览页面

7.给客户演示等过程中客户重点指出的，严重级别却不是很高的缺陷,建议级别定义至少是非常高

C-一般

操作性错误、错误结果、遗漏功能等影响系统要求或基本功能的实现,例如:

界面错误（附详细说明）

打印内容、格式错误

简单的输入限制未放在前台进行控制

删除操作未给出提示

数据输入没有边界值限定或不合理

3-高

1.提示信息不明确，并且非常容易误导用户做出错误操作或判断。

2.软件功能的实现过程中弹出未控制的系统错误提示，导致流程中断

3.Cookies没有正常保存

4.服务器和客户端的脚本修改未被记录和

5.非法操作等Urgent程度的缺陷，如果不具有普遍性而是在极端环境下出现，例如特定的操作环境。

建议级别定义为High。

D-微小

错别字、罕见故障等不影响执行工作或功能实现,例如:

辅助说明描述不清楚

系统处理未优化

提示窗口文字未采用行业术语

4-中

1.提示信息不明确，不正确或不合理

2.界面设计存在缺陷、凌乱或不友好

3.整体风格不统一

E-建议

建议,不影响使用的瑕疵或更好的实现等

对软件各方面提出的更好的改进性的意见。

5-低

1.虽有不尽人意之处，但不影响用户操作或用户使用频率较低，并且不会造成错误

2.局部界面不够美观

2.1.6缺陷类型

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

分类

具体描述

1-功能类；

A.重复的功能B.多余的功能C.功能实现与设计要求不相符D.功能使用性、方便性、易用性不够

2-界面类；

A.界面不美观B.控件排列、格式不统一C.焦点控制不合理或不全面

3-流程类；

A.流程控制不符和要求B.流程实现不完整

4-提示信息类；

A.提示信息重复或出现时机不合理B.提示信息格式不符和要求C.提示框返回后焦点停留位置不合理

5-建议类；

A.功能性建议B.操作建议C.检校建议D.说明建议

6-性能类；

A.并发量B.数据量C.压缩率D.响应时间

7-其他类；

A.1-6以外的情况

2.1.7缺陷原因

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

分类

具体描述

1-式样遗漏/错误；

需求文档中，没有相关的说明

设计文档中，没有相关的说明

需求文档中，相关的说明与实际现象不一致

设计文档中，相关的说明与实际现象不一致

2-编程遗漏/错误；

编码中没有包含必要的功能

编码结果与实际现象不一致

3-测试不正；

测试时使用的数据不正确

测试或确认使用的不是测试目标版本

测试时使用的操作过程不正确

4-环境不备；

测试环境配置不正确。

比如没有导入必要的基础数据。

或者必要的消息内容不存在

应用程序在发布，部署时出现错误导致的错误

5-外联系统；

A.因为其他系统的原因导致的错误

6-重复；

A.同样缺陷的已经指摘过的错误

7-其他；

A.1-6以外的情况

2.1.8主题

记录该缺陷属于哪个模块中。

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

2.1.9测试者

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

2.1.10测试日期

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

2.1.11检测于发布

记录发现该缺陷基线版本（Tags），测试组长在每次获取到新的基线版本程序包时，发布到测试环境之后，按照程序包上的版本标签号（一般为BL_YYYYMMDD_SVN版本号），在ALM中“管理”模块中的“发布”中增加对应的版本号（注：

ALM中增加的版本号需与程序包的版本号一致）。

如下图，在管理》发布》三峡付项目ST下》点击新增“周期”。

2.1.12可重现

记录缺陷是否可重现。

根据缺陷描述操作，是否可以发现缺陷所描述的问题，Y表示可以重现，N表示无法重现。

例如有些问题是在特定条件下才出现的，当条件改变后问题随之消失，根据所描述的步骤操作，不会再出现缺陷所描述的问题，这类就是属于无法重现的缺陷。

2.1.13子系统

记录缺陷所属的子系统。

包含以下内容：

子系统名称

开发组长

APP-Android

APP-iPhone

APP-iPad

电子账户

反欺诈

基础服务

门户

网络预填单

业务子系统

管理台

报表

文档

性能问题

2.1.14修复日期

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

2.1.15关闭日期

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

2.1.16关闭于发布

记录关闭该缺陷基线版本（Tags），测试组长在每次获取到新的基线版本程序包时，发布到测试环境之后，按照程序包上的版本标签号（一般为BL_YYYYMMDD_SVN版本号），在ALM中“管理”模块中的“发布”中增加对应的版本号（注：

ALM中增加的版本号需与程序包的版本号一致）。

如下图，在管理》发布》三峡付项目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重复。

目的是让开发人员再确认一下这两个缺陷是否真的描述同一个问题。

小提示：

在新增注释说明时，可以直接点击页面右下方的

按钮，ALM可以直接添加你的登录帐号在“注释”中，省去自己填写的麻烦！

如图12.请大家在填写时养成加入自己信息的习惯，方便测试人员在回归测试时可以看到是谁回复的，有问题方便直接沟通！

2.4缺陷管理岗位职责

项目经理：

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

开发组长：

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

测试组长：

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

测试人员：

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

开发人员：

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

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

1、仲裁小组的成员包括：

项目经理和测试组长，仲裁方式采取项目经理和测试组长定期共同对被拒绝缺陷和挂起缺陷进行逐个分析的方式，并且商议得出最终的处理意见，最终由测试组长在ALM上进行意见反馈和缺陷状态的流转。

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.如果填写的信息正确直接提交

2.如果不想提交缺陷了，可以直接点击

或者

按钮。

3.选择测试组长时，必须是在测试组长组内的人员，否则或有提示：

4.选择测试组长时，可以按组选择：

4.1.2验证缺陷（已修正）

1.选择缺陷状态是“已修正”的缺陷，测试者是当前用户的。

通过筛选条件筛选：

设置筛选条件：

缺陷状态为：

已修正，测试者：

当前用户

2.点击缺陷ID，打开缺陷

3.进入缺陷页面

注意：

1.必填“是否进行回归测试”

a选择“是”会有“回归测试状态”字段弹出

必填“回归测试状态”字段：

（1）选择“通过”会有“关闭于版本”和“关闭于发布”字段弹出。

（2）选择“不通过”，没有新字段弹出

b.“是否进行回归测试”选择“否”，会有“未回归原因”字段弹出：

4.2测试组长

4.2.1缺陷审核（新建）

填写账号：

czuhzang，密码：

空，域名：

Default项目：

大型项目类模板

1.设置筛选条件“缺陷状态”为“新建”，测试组长为：

当前用户

2.点击“缺陷ID”，进入页面：

注意：

1.测试组长进入“新建”缺陷页面，可以操作三个字段：

“优