HP测试管理平台ALM使用手册Word文档下载推荐.docx
《HP测试管理平台ALM使用手册Word文档下载推荐.docx》由会员分享，可在线阅读，更多相关《HP测试管理平台ALM使用手册Word文档下载推荐.docx（28页珍藏版）》请在冰豆网上搜索。
备注：
如果使用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-已审核
测试组长确认测试者提交的缺陷有效
A-回归失败
缺陷未通过测试人员回归测试，缺陷未被修复
6
B-拒绝
拒绝修改缺陷，该缺陷可能由于测试人员理解错误或属于重复提交的缺陷，开发组长和开发人员都可以拒绝，拒绝的缺陷需要由仲裁者（一般为项目经理和测试经理）判定后才能认定为伪缺陷。
7
C-挂起
项目经理判定该缺陷不在当前版本进行修复，而在未来版本进行修复
8
D-重新打开
C-挂起的缺陷在条件允许后可重新打开供开发人员进行修复
9
E-伪缺陷
仲裁者（一般为项目经理和测试经理）对B-拒绝的缺陷进行判定后，认定该缺陷确实是由于测试人员理解问题或者重复缺陷等原因导致的无效缺陷（伪缺陷）
10
F-无效
由于测试人员提出的缺陷，测试组长确认无效后，提交缺陷，缺陷状态就会修改为“无效”
2.1.4分配给
2.1.4.1不同角色之间缺陷状态的变化：
缺陷状态的变化
事件描述
操作者
前状态
后状态
分配给
测试人员新建缺陷
测试人员
测试组长（字段
测试组长判定缺陷无效
测试组长
无需修改
测试组长判定缺陷有效
5-已审核
开发组长（字段
测试组长新建缺陷
开发组长确认缺陷有效
开发组长
分配给（修复人
开发组长确认缺陷无效
仲裁人员
开发人员-暂时无法修改缺陷
开发人员
开发人员-此时修改缺陷
开发人员已经修复缺陷
测试者
开发人员修改延期缺陷
开发人员修改回归失败缺陷
测试者（默认
测试人员回归测试-通过
测试人员回归测试-不通过
开发人员（默认
判定是伪缺陷（仲裁人员
仲裁者
判定不是伪缺陷，立即修改（仲裁
判定不是伪缺陷，延期修改
延期缺陷重新打开进行修改
具体开发人员
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-其他；
2.1.8主题
记录该缺陷属于哪个模块中。
主题字段设置对应为测试计划中的测试主题（功能模块），方便将来统计各个模块的缺陷密度。
2.1.9测试者
记录该缺陷的登记者，系统会自动获取当前用户的用户号，不需要手工录入。
2.1.10测试日期
记录该缺陷的登记日期，通常系统会自动获取当前时间，不需要手工录入。
2.1.11检测于发布
记录发现该缺陷基线版本（Tags），测试组长在每次获取到新的基线版本程序包时，发布到测试环境之后，按照程序包上的版本标签号（一般为BL_YYYYMMDD_SVN版本号），在ALM中“管理”模块中的“发布”中增加对应的版本号（注：
ALM中增加的版本号需与程序包的版本号一致）。
如下图，在管理》发布》三峡付项目ST下》点击新增“周期”。
2.1.12可重现
记录缺陷是否可重现。
根据缺陷描述操作，是否可以发现缺陷所描述的问题，Y表示可以重现，N表示无法重现。
例如
升级会员 