今天的主题是对程序进行测试,并完成了视频的制作,文档整理,完成了第一阶段的作业
具体流程如下:
1 登录到QC的缺陷管理系统
打开IE8、IE9浏览器或者HP ALM Explore12.2x，在地址栏输入访问http://10.64.2.21:8080/qcbin/start_a.jsp，
如果是IE10浏览器，请打开浏览器然后按F12，打开开发人员工具，然后选择IE8兼容模式，然后在输入访问http://10.64.2.21:8080/qcbin/start_a.jsp，。
2、如果之前没有安装过相关插件，浏览器会提示是否安装插件，但是在安装插件前一定要将上述站点加到可信站点和本地intranet站点上才能自动下载并安装浏览器插件。
如下图：
A．增加到可信站点：IE8》Internet选项》安全》可信站点
B．增加到Intranet站点：IE8》Internet选项》安全》本地Intranet
备注：如果使用IE不行，可以直接使用ALM12自带的浏览器，自带浏览器可以在登录界
面时进行下载。
操作步骤如下：
3、安装完插件后会自动跳转到登录页面，如图2所示。在“用户名”输入框输入您姓名的拼音，密码默认为空，点击【身份验证】按钮。
通过验证后“项目”下拉列表会列出你有权访问的项目，如图3所示。选择你要登录的页面，点击【登录】按钮。
说明：
域：Default
项目：项目列表只列出你有访问权限的项目。
大型项目类测试模板
登录后的初始页面。登录成功后，点击“缺陷”，出现如图4所示页面。
进入缺陷列表。点击图4所示页面左边列表中的 项，将看到如图5所示的缺陷新增界面。
更改项目。如果你同时拥有多个项目的权限，那么登录到其中一个项目后可以不需要退出而直接更改到另一个项目。点击页面左上角的【工具】，选择【更改项目】，再点击你所想要的项目即可，如三峡付项目UAT。
如果你拥有其他项目的权限，但“更改项目”列表中并没有列出那些项目，你可以点击【选择…】按钮，转到登录页面，选择需要登录的项目，登录一次后该项目名称就会出现在这个列表中了。
2 QC缺陷管理系统的使用
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.常用操作平台不能正常使用功能(WIN XP/WIN 2000/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版本号），在QC中“管理”模块中的“发布”中增加对应的版本号（注： QC中增加的版本号需与程序包的版本号一致）。如下图，在管理》发布》三峡付项目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版本号），在QC中“管理”模块中的“发布”中增加对应的版本号（注： QC中增加的版本号需与程序包的版本号一致）。如下图，在管理》发布》三峡付项目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重复。目的是让开发人员再确认一下这两个缺陷是否真的描述同一个问题。
小提示：在新增注释说明时，可以直接点击页面右下方的 按钮，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.如果填写的信息正确直接提交
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 发布和周期简介
发布：指项目计划
周期：指项目计划内各个功能模块的开发或者测试周期。
5.2 创建发布
点击导航栏的管理-发布，选中发布文件夹-新建发布，在弹出的对话框输入新建发布的名称，如“订票系统发布”，选择适当的开始时间和结束时间，并点击确认。
5.3 创建周期
选中订票系统发布，点击新建周期，在弹出的对话框中填写名称日期等相关信息，确认后点击确定。
5.4 查看发布和周期中的状态
选中相应发布，并点击“状态”选择卡，则可以查看关联到此发布的需求、测试的相关信息。
6 制定需求
6.1 新建需求文件夹
在导航栏中选择需求，对应的页面中选中需求文件夹，点击工具栏中的新建按钮，并在弹出的对话框中填写相关信息，确认。然后会提示选择相应的优先级，选择即可，到此新建需求文件夹结束。
6.2 新建需求
选择相应的订票系统文件夹，点击新建需求按钮，在弹出的对话框中填入相关信息（有红色标注的为必填项），确认无误后点击提交按钮，完成新建需求的提交。
6.3 查看需求详情
（1）.选择需要产看的需求条目，在工具栏选择“需求”-“查看需求详情”
（2）.则可以看到此条需求的详细信息，如需对需求信息进行修改则在弹出的详细信息页面中直接修改并点击“确定”即可。
6.4 将需求分配给周期
（1）.选中指定需求条目，点击工具栏中的“需求”-“分配至周期”如图：
（2）.在弹出的对话框中打开发布树，勾选指定的周期，并点击“确定”即可把需求条目分配至周期。
6.5 将需求转换到测试
在创建需求树后，可将需求用作在“测试计划”模块中定义测试计划树的基础。
设计测试计划树时，可以使用“转换到测试”向导帮助您完成相关操作。该向导可用于将需求树中选定的需求或所有需求转换到测试计划树中的主题或测试。
(1). 选中需求树中的需求条目或者文件夹，我们这里选择“订票系统”文件夹，点击工具栏中的“需求”-“转换到测试”则弹出如下向导对话框。
(2). 选中需求树中的需求条目或者文件夹，我们这里选择“订票系统”文件夹，点击工具栏中的“需求”-“转换到测试”则弹出如下向导对话框。
我们一般选择下面三种情况
当选择“将最低子需求转换到测试”时，测试计划树中将生成与选中需求相同的目录结构，并将最低级的需求转换为相对应的测试条目。
当选择“将所有需求转换为主题”时，测试计划树中将生成与选中需求相同的目录结构，并将最低一级的需求条目转换为相对应的主题即文件夹，我们可在相对应的主题下新建多个测试。
当选择“生成单个测试时”，测试计划中选定的需求条目转换为测试条目。
(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 创建覆盖率
测试计划中的测试必须符合您的需求。为帮助确保在整个应用程序生命周期管理过程中的合规性，可添加测试和需求之间的覆盖率。
如果您的测试计划条目是由需求转化过来的，则需求覆盖率以创建好了。如果测试计划条目是后来创建的，则需要手工创建覆盖率。
我们先在需求树中加入一条“订单提交”的需求，此处步骤省略，详见第三部分-定制需求。
选中相应的测试计划，点击打开“需求覆盖率”选择卡，点击“选择需求”按钮，右边会加载出需求树，选择我们提前建好的“订单提交”条目，点击“添加到覆盖率”即左向箭头，则完成需求到测试的关联，即添加完成需求覆盖率。
添加成功后，如图：
7.6 查看覆盖率
(1).从导航栏选择需求，在页面中点击“查看”-“覆盖率分析”。
(2).则会加载出覆盖率分析视图，我们会看到添加的两条需求的状态为“No Run”即测试已经覆盖到了需求，但是测试还未运行。
(3).双击条目时可看到详细的覆盖率分析
8 案例的批量导入
导入前须知
注意：导入案例前须安装“HP-ALM-MSExcelAddin.exe”工具，安装完成后EXCEL中会增加“加载项”一栏。
导入选择：测试名称即测试编号A；测试要点即步骤J；类型即手动测试S；描述即步骤内容K；主题即主题G；测试概述即测试概述H；预期结果即预期结果M.
注意：以上选项为必选项目，同时案例集末模板如果不同，对应的列需要进行调整。
8.1 案例批量导入步骤
(1). 在EXECL中选中需导入的案例行（只选案例行，不要选标题栏，支持office2007、 2010没试过），点击“加载项”，选中“Export...”，如图所示：
(2). 输入自己登录ALM的用户名、密码，下一步，选择“域、项目”，如图：
(3).选择"Tests",如图：
(4).首次导入案例时，选择第2种类型，自己建一个名称（导入成功后，后次导入可以复用该名字）。
(5).按如下图所示，将ALM中的列名称对应到EXCEL表中案例列名称，注意案例设计者一列须与ALM中用户对应，比如“ut_liuyu”，对应完成后点击“Export”。
(6).导入成功界面。完成后可登录ALM平台->测试->测试计划中查看自己所导入的案例，注意检查设计步骤中是否有内容。
(7). 案例检查，测试》测试计划中找到相应的测试案例，查看案例导入目录是否正确、导入案例数量是否正确、导入案例的相关要素（步骤、描述等）是否正确。
8.2 测试案例状态明细
英文名 中文名 说明
No run 未执行 案例的初始状态
No com 未完成 执行过程中被打断，部分步骤未执行
Blocked 阻塞 环境、程序、缺陷等导致案例无法执行
N/A 无效 需求变更、需求理解错误等导致案例无效
Pass 通过 执行通过
Failed 失败 执行失败
9 测试执行
9.1 测试执行概述
在整个应用程序生命周期管理过程中，可以运行自动和手动测试来查找缺陷并评估应用程序质量。创建测试集、选择每个测试集中包括哪些测试后，便可开始。
测试集包含 ALM 项目中为实现特定测试目标而设计的测试的子集。
定义测试集后，便可开始执行测试。某些测试可自动运行，而某些则可手动运行。
9.2 测试执行步骤
(1).新建文件夹
在导航栏中选择“测试”-“测试实验室”，选中“Root”文件夹，点击添加文件夹，在弹出的对话框中填写测试集文件夹名称，并确定。
(2).将文件夹分配到周期
选中相应的测试集文件夹，点击详细信息，在已分配周期中点击下拉菜单，选中相应发布中的周期，点击确定，则将测试集分配到了周期。
(3).新建测试集
选中测试集文件夹，点击新建测试集按钮，在弹出的对话框中输入详细信息，点击确定提交。
(4).向测试集添加测试
(a).选中相应的测试集，点击“执行网格”选择卡，点击“选择测试”，右边会加载出测试计划树和需求树，从测试计划树中选中“订票系统登录”和“订票数据输入和提交”测试计划，点击“向测试集添加测试”按钮，相应测试计划将加到执行网格中。
(b).在添加过程中会弹出添加参数对话框，可以填入实际的测试数据，也可以不填。
(c).添加成功后，网格显示如下
(5).为测试设置执行流
(a).我们可以在“执行流”页面对测试集中的测试添加先决条件。
点击“执行流”选择卡，选中“订票数据提交”节点，右键选中“测试运行计划”
(b).在弹出的对话框中点击“新建执行条件”在弹出的新建对话框中点击测试的下拉菜单，选中“订票系统登录”，确定提交，则“订票数据提交”必须要等到“订票系统登录”测试结束后才能进行测试。
(c).设置成功后执行流会如下显示：
(6).运行测试集中的测试
(a).选中制定测试配置条目，点击“运行”按钮
(b).在手动运行器界面点击“开始运行”
(c).如果在测试计划期间没有制定参数实际值此时将弹出输入实际值对话框，填写实际值，点击确定。
(d).我们将按照测试步骤执行手动测试，并根据测试结果填写每一步的测试运行状态，我们可以选中其中一个步骤，点击“标记成功”或者“标记失败”按钮来记录测试结果，如果测试过程中发现缺陷，我们可以点击“添加缺陷”按钮，对缺陷进行记录。
(e).手动测试结束后点击“结束运行”按钮。
(f).如果步骤全部通过则返回后相应的配置条目将会标志为“Passed”
9.3 查询覆盖率分析
返回需求页面，点击刷新按钮，将看到“订单提交”需求覆盖率已经标志位“Passed”。