HP测试管理平台ALM使用基础手册.doc

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

文件状态：
【 】草 稿
【 】修 改 稿
【 】正式公布
文档编号

保 密 等 级

作 者

最终完成日期
-3-12
审核人员

最终审核日期

批 准 人

最终同意日期

1 登录到ALM缺点管理系统
打开IE8、IE9浏览器或HP ALM Explore12.2x，在地址栏输入访问:8080/ALMbin/start_a.jsp，
假如是IE10浏览器，请打开浏览器然后按F12，打开开发人职员具，然后选择IE8兼容模式，然后在输入访问: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。
假如你拥有其它项目标权限，但“更改项目”列表中并没有列出那些项目，你能够点击【选择…】按钮，转到登录页面，选择需要登录项目，登录一次后该项目名称就会出现在这个列表中了。

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

2 ALM缺点管理系统使用
2.1 缺点常见字段说明
21.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.常见操作平台不能正常使用功效(WIN XP/WIN /WIN VISTA)
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.18 SVN版本号
统计开发人员修复缺点后，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.测试组长进入“新建”缺点页面，能够操作三个字段：“优先级”，“严重程度”和“缺点有效性”其中，“优先级”，“严重程度”是针对测试者可能了解不够正确，此时测试组长能够重新选择。
2.必填“优先级”字段是测试组长审核缺点有效性操作字段
（1）选择“有效”，会跳出“开发组长”字段。

（2）选择“无效”没有字段弹出，不过“注释”必需填写。

4.2.2 测试组长新建缺点
1.点击按钮，进入新建缺点页面：

注意：测试组长新建缺点和测试者新建缺点有两处区分
（1）缺点状态是“已审核”状态。
（2）此时不是选择测试组长，而是选择开发组长

4.3 开发组长
填写账号：kzuzhang，密码：为空，域名：Default，项目：大型测试项目类模板
4.3.1 审核“已审核”缺点
1.设置筛选条件，缺点状态“已审核”，开发组长：目前用户

2.点击“缺点ID”打开“已审核”缺点页面

注意：必填字段“验证缺点有效性”
（1）选择“有效”会弹出“缺点修复人”和“估量修复时间”

其中在填写时候，估量修复时间是一定天数，缺点修复人就是开发人员。
（2）选择“无效”，会弹出“仲裁员员”

仲裁员员就是项目经理或测试组长组成。对于“拒绝”缺点进行最终确定。
4.4 开发人员
账号kaifa，密码：为空，域名：Default，项目：大型项目测试类模板
1.设置筛选条件，缺点状态：“打开”or‘回归失败’or“重新打开”，缺点修复人：目前用户

4.4.1 修复“打开”缺点
点击“缺点ID”进入缺点页面：

注意：
（1）“暂无法修改”必填字段，“是”和“否”
(a)选择“是”表示，此版本无法修改此缺点临时拒绝，会跳出“仲裁员员”必填字段且“注释”必需填写。

（2）选择“否”，表示此缺点现在能够修复，会跳出“是否已修复”必填字段，“是”和“否”

（a）选择“是”，表示缺点和修复，会跳出“实际修复时间”，“缺点原因”和“SVN版本号”

其中“实际修复时间”是测试时间和修复时间之间天数差，不是实际点。
（b）选择“否”表示此缺点，临时还没修复，不会跳出字段。

4.4.2 修复“回归失败”缺点
1.点击“缺点ID”进入缺点界面

注意：
（1）“是否已修复”必填字段，“是”和“否”
（a）选择“是”，表示缺点和修复，会跳出“实际修复时间”，“缺点原因”和“SVN版本号”
其中“实际修复时间”是测试时间和修复时间之间天数差，不是实际点。
（b）选择“否”表示此缺点，临时还没修复不会跳出字段。

4.4.3 修复“重新打开”缺点
1.点击“缺点ID”进入缺点界面

注意：
（1）“是否已修复”必填字段，“是”和“否”
（a）选择“是”，表示缺点和修复，会跳出“实际修复时间”，“缺点原因”和“SVN版本号”

其中“实际修复时间”是测试时间和修复时间之间天数差，不是实际点。
（b）选择“否”表示此缺点，临时还没修复，不会跳出字段。

4.5 仲裁员员
账号：zhongcai，密码：为空，域名：Default，项目：大型项目类测试模板
1.设置筛选条件：缺点状态：“拒绝”or“挂起”，仲裁员员：目前使用者

4.5.1 仲裁“拒绝”缺点
1.点击“缺点ID”，进入缺点界面：

注意：
（1）必填字段“仲裁是否缺点”，“是”和“否”，选择“是”表示最终确定缺点是有效，会跳出“是否挂起”必填字段
（a）“是否挂起”必填字段，“是”和“否”。选择“是”表示目前缺点此版本无法处理，延期处理，会跳出“计划关闭版本”必填字段。

（b）选择“否”，表示此版本能够处理，不跳出字段，指定开发组长。

（2）选择“否”，表示最终仲裁此缺点不是游戏缺点，是伪缺点，不跳出字段，不过“注释”字段必填。

4.5.2 仲裁“挂起”缺点
1.点击“缺点ID”，进入缺点页面。

注意：
（1）.“是否重新打开”必填字段，“是”和“否”，选择“是”，表示挂起缺点此版本下要进行修改，跳出“缺点修复人”必填字段，而且指定缺点修复人。

（2）.选择“否”，表示挂起缺点，仍为挂起状态。

5 公布和周期
5.1 公布和周期介绍
l 公布：指项目计划
l 周期：指项目计划内各个功效模块开发或测试周期。
5.2 创建公布
点击导航栏管理-公布，选中公布文件夹-新建公布，在弹出对话框输入新建公布名称，如“订票系统公布”，选择合适开始时间和结束时间，并点击确定。

5.3 创建周期
选中订票系统公布点击新建周期，在弹出对话框中填写名称日期等相关信息，确定后点击确定。

5.4 查看公布和周期中状态
选中对应公布，并点击“状态”选择卡，则能够查看关联到此公布需求、测试相关信息。

6 制订需求
6.1 新建需求文件夹
在导航栏中选择需求，对应页面中选中需求文件夹，点击工具栏中新建按钮，并在弹出对话框中填写相关信息，确定。然后会提醒选择对应优先级，选择即可，到此新建需求文件夹结束。

6.2 新建需求
选择对应订票系统文件夹，点击新建需求按钮，在弹出对话框中填入相关信息（有红色标注为必填项），确定无误后点击提交按钮，完成新建需求提交。

6.3 查看需求详情
（1）.选择需要产看需求条目，在工具栏选择“需求”-“查看需求详情”

（2）.则能够看到此条需求具体信息，如需对需求信息进行修改则在弹出具体信息页面中直接修改并点击“确定”即可。

6.4 将需求分配给周期
（1）.选中指定需求条目，点击工具栏中“需求”-“分配至周期”图：

（2）.在弹出对话框中打开公布树，勾选指定周期，并点击“确定”即可把需求条目分配至周期。

6.5 将需求转换到测试
在创建需求树后，可将需求用作在“测试计划”模块中定义测试计划树基础。
设计测试计划树时，能够使用“转换到测试”向导帮助您完成相关操作。该向导可用于将需求树中选定需求或全部需求转换到测试计划树中专题或测试。
(1). 选中需求树中需求条目或文件夹，我们这里选择“订票系统”文件夹，点击工具栏中“需求”-“转换到测试”则弹出以下向导对话框。

(2). 选中需求树中需求条目或文件夹，我们这里选择“订票系统”文件夹，点击工具栏中“需求”-“转换到测试”则弹出以下向导对话框。

我们通常选择下面三种情况
l 当选择“将最低子需求转换到测试”时，测试计划树中将生成和选中需求相同目录结构，并将最低级需求转换为相对应测试条目。
l 当选择“将全部需求转换为专题”时，测试计划树中将生成和选中需求相同目录结构，并将最低一级需求条目转换为相对应专题即文件夹，我们可在相对应专题下新建多个测试。
当选择“生成单个测试时”，测试计划中选定需求条目转换为测试条目。

(3).这里我们选择“将最低子需求转换到测试”点击“下一步”生成预览。

(4).确定勾选“自动完成子项”，则会生成和需求树中相同目录结构，点击“下一步”。

(5). 点击“专题”下拉框，则会加载出测试计划树，我们选中根目录“Subject”点击确定（在此过程中也能够新建文件夹），则会在根目录下生成“订票系统”测试计划树。点击“确定”再点击“完成”，则开始转换过程，在此过程中会提醒输入测试计划必填项，输入确定即可完成转换。

(6).打开导航栏“测试”-“测试计划”则能看到从需求转换过来测试。

(7). 点击打开对应测试计划“需求覆盖率”选择卡，则能看到已经关联到需求中订票系统登录条目，以后这条测试计划实施状态将自动关联到需求树中测试覆盖率。

6.6 批量导入需求
假如需要批量导入需求则需要已安装Excel导入插件，能够到ALM开始界面“快速开始”对应页面下载。安装成功后打开Excel会出现以下“加载项”选择卡。
尤其提醒：以下图“需求目录”字段说明，当我们需要导入文件目录结构时必需确保需求条目标父节点已经存在，或在同一次导入中，在低ID先创建文件夹类型目录，以确保高ID数据导入时父目录已经存在。
(1).选中需要导入数据，点击“Export ToHP ALM“。

(2).在弹出向导中填入服务器Url地址，然后点击“Next”。

(3).在向导中填写用户登录名和密码（密码要在英文输入法下才能输入），点击“Next”。

(4).像平时登录一样选择域和项目，并点击“Next”。

(5).选择“Requirements”即导入需求，点击“Next”。同理，假如导入是测试集或缺点要选中对应条目。

(6).创建映射关系集（这一步只创建映射名称），即要将Excel指定列对应到对应ALM字段中，假如以前已经存在映射关系则能够直接选中，这里我们选择已存在映射，假如不合我们要求能够在后几步中进行修改，我们也能够新建一组映射关系。下次再导入时就能够直接用这条映射关系。

(7).选择是导入单一类型还是导入在Excel中拥有列定义类型，这里我们选择已在Excel拥有列定义类型，填入Excel中对应列编号，点击“Next”。
尤其注意：假如选择用Excel对应列去映射需求类型，则在下一步具体字段映射时只会显示全部需求类型拥有共有字段，假如你需要导入需求中拥有指定类型专有字段信息则必需使用单一类型映射。

(8).设置Excel和ALM字段映射关系，选择ALM字段如“名称”，点击右向箭头，在弹出对话框中填写Excel中对应列英文字母，点击OK则完成此字段映射，一样方法建立其它字段映射关系（红色为必需映射字段）。

(9).全部映射完成后点击“Export”，假如系统校验成功，则实施需求导入。成功后会显示以下对话框。点击“Finish”。

(10).回到系统需求模块，点击“刷新”则能看到我们导入文件夹和需求条目。

7 制订测试计划
在确定测试目标后，应构建测试计划树，此树以层次结构方法将应用程序划分为测试单元或专题。对于测试计划树中每个专题，可定义包含步骤测试。对于每个测试步骤，能够指定要对应用程序实施操作和预期结果。
7.1 .新建测试计划
(1).在测试计划中选中“订票系统”文件夹，点击工具栏中“新建测试”按钮，在弹出对话框中填写相关信息，点“确定”进行提交。则会在“订票系统”目录下多一项对应测试计划。

(2).将测试添加到测试计划树并定义基础测试信息后，可定义测试步骤，即指定怎样实施测试具体分步说明。步骤包含要对应用程序实施操作和预期结果。
选中对应测试计划条目，点击“设计步骤”选择卡，点击“新建步骤”按钮，在弹出对话框输入对应操作及输入输出操作并点击“确定”进行提交。

7.2 设计测试步骤
提交完成后，设计步骤页面多出一条步骤，一样方法添加覆盖一个测试计划多条步骤，效果以下:

7.3 定义测试参数
(1).选中制订测试计划，点击“参数”选择卡，点击“新建参数”按钮，在弹出对话框中填写参数名称，默认值等项，点击“确定”提交。

(2).能够填写多个参数值，效果以下：

7.4 将参数分配给测试步骤
(1).选中对应测试计划，点击“设计步骤”选择卡，将光标定位到输入姓名以后，点击“插入参数”按钮，在弹出对话框中选择“姓名”行，点击“确定”提交。

(2).提交成功后会出现如家参数标志，证实分配参数成功。同理可分配日期和
航班号。

7.5 创建覆盖率
l 测试计划中测试必需符合您需求。为帮助确