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

1、HP测试管理平台ALM使用手册XXXXXXX项目测试缺陷管理&ALM使用手册文件状态：【 】草 稿【 】修 改 稿【 】正式发布文档编号保 密 等 级作 者最后完成日期2018-3-12审核人员最后审核日期批 准 人最后批准日期1 登录到ALM的缺陷管理系统打开IE8、IE9浏览器或者HP ALM Explore12.2x，在地址栏输入访问http:/10.64.2.21:8080/ALMbin/start_a.jsp，如果是IE10浏览器，请打开浏览器然后按F12，打开开发人员工具，然后选择IE8兼容模式，然后在输入访问http:/10.64.2.21:8080/ALMbin/start_a

2、.jsp，。2、如果之前没有安装过相关插件，浏览器会提示是否安装插件，但是在安装插件前一定要将上述站点加到可信站点和本地intranet站点上才能自动下载并安装浏览器插件。如下图：A增加到可信站点：IE8Internet选项安全可信站点B增加到Intranet站点：IE8Internet选项安全本地Intranet配置好A和B之后，点击刷新，浏览器就会自动下载并安装插件。备注：如果使用IE不行，可以直接使用ALM12自带的浏览器，自带浏览器可以在登录界面时进行下载。操作步骤如下：3、安装完插件后会自动跳转到登录页面，如图2所示。在“用户名”输入框输入您姓名的拼音，密码默认为空，点击【身份验证】

3、按钮。通过验证后“项目”下拉列表会列出你有权访问的项目，如图3所示。选择你要登录的页面，点击【登录】按钮。说明：域：Default项目：项目列表只列出你有访问权限的项目。 大型项目类测试模板 登录后的初始页面。登录成功后，点击“缺陷”，出现如图4所示页面。进入缺陷列表。点击图4所示页面左边列表中的项，将看到如图5所示的缺陷新增界面。 更改项目。如果你同时拥有多个项目的权限，那么登录到其中一个项目后可以不需要退出而直接更改到另一个项目。点击页面左上角的【工具】，选择【更改项目】，再点击你所想要的项目即可，如三峡付项目UAT。如果你拥有其他项目的权限，但“更改项目”列表中并没有列出那些项目，你可以

4、点击【选择】按钮，转到登录页面，选择需要登录的项目，登录一次后该项目名称就会出现在这个列表中了。注销。点击右上角的即可注销，退出到登录页面。2 ALM缺陷管理系统的使用2.1 缺陷常用字段说明2.1.1 缺陷名称对缺陷的简单描述。摘要包括该缺陷所属的模块名称-子模块名称，以及简单说明缺陷情况。2.1.2 描述详细描述重现该缺陷的步骤，错误现象和期待结果。必要时可以上传附件辅助说明。2.1.3 状态缺陷状态描述如下表：序号缺陷状态缺陷状态描述备注11-新建测试人员在测试过程中发现缺陷，提交新的缺陷给开发组长进行审核22-打开开发组长进行判定认定为有效缺陷，并将缺陷分配给具体的开发人员进行修改33

5、-已修正开发人员已完成修正,等待测试人员进行回归测试44-已关闭缺陷通过测试人员回归测试，缺陷已被修复5 5-已审核测试组长确认测试者提交的缺陷有效5A-回归失败缺陷未通过测试人员回归测试，缺陷未被修复6B-拒绝拒绝修改缺陷，该缺陷可能由于测试人员理解错误或属于重复提交的缺陷，开发组长和开发人员都可以拒绝，拒绝的缺陷需要由仲裁者（一般为项目经理和测试经理）判定后才能认定为伪缺陷。 7C-挂起项目经理判定该缺陷不在当前版本进行修复，而在未来版本进行修复8D-重新打开C-挂起的缺陷在条件允许后可重新打开供开发人员进行修复9E-伪缺陷仲裁者（一般为项目经理和测试经理）对B-拒绝的缺陷进行判定后，认定

6、该缺陷确实是由于测试人员理解问题或者重复缺陷等原因导致的无效缺陷（伪缺陷）10F-无效由于测试人员提出的缺陷，测试组长确认无效后，提交缺陷，缺陷状态就会修改为“无效”2.1.4 分配给2.1.4.1 不同角色之间缺陷状态的变化： 缺陷状态的变化事件描述操作者前状态后状态分配给测试人员新建缺陷测试人员1-新建测试组长（字段测试组长判定缺陷无效测试组长1-新建F-无效无需修改测试组长判定缺陷有效测试组长1-新建5-已审核开发组长(字段测试组长新建缺陷测试组长5-已审核开发组长（字段开发组长确认缺陷有效开发组长5-已审核2-打开分配给（修复人开发组长确认缺陷无效开发组长5-已审核B-拒绝仲裁人员开发

7、人员-暂时无法修改缺陷开发人员2-打开B-拒绝仲裁人员开发人员-此时修改缺陷开发人员2-打开2-打开无需修改开发人员已经修复缺陷开发人员2-打开3-已修正测试者开发人员修改延期缺陷开发人员D-重新打开3-已修正测试者开发人员修改回归失败缺陷开发人员A-回归失败3-已修正测试者（默认测试人员回归测试-通过测试人员3-已修正4-已关闭无需修改测试人员回归测试-不通过测试人员3-已修正A-回归失败开发人员（默认判定是伪缺陷 （仲裁人员仲裁者B-拒绝E-伪缺陷无需修改判定不是伪缺陷，立即修改（仲裁仲裁者B-拒绝2-打开开发组长判定不是伪缺陷，延期修改仲裁者B-拒绝C-挂起无需修改延期缺陷重新打开进行修

8、改仲裁者C-挂起D-重新打开具体开发人员2.1.5 严重程度和优先级缺陷严重级程度与优先级别原则上是有一一对应的关系，在填写缺陷选择这两项时，可先参照该对照表：注：测试组开发组的响应时间规定紧急：2-3小时（需测试组长跟开发组长做口头提醒/电话）非常高：1天内（需测试组长跟开发组长做口头提醒/电话,Mail）高：3天内中：5天内低：5天以上严重程度缺陷严重程度描述优先级缺陷优先级描述A-致命阻碍流程、系统崩溃导致重大任务不能正常进行的缺陷,例如:由于程序所引起的死机,非法退出死循环数据库发生死锁错误操作导致的程序中断严重的计算错误与数据库连接错误数据通讯错误等1-紧急1.当缺陷所引发的问题没有

9、达到紧急的级别，但当该缺陷出现后，影响到了后续的测试工作进行2.客户无法容忍的页面，如页面上显示其他公司名称3.当前操作方式与客户使用习惯背道而驰。4.严重不合理，核心功能完全违反软件规范或业务规范，可能导致用户强烈的反感5.系统响应时间过长(例如WEB响应时间超过10s)6.模块提供的数据不合理，例如(查询“录入人”的下拉项提示为非用户名字段)7.负载测试、压力测试结果和用户需求不符B-严重缺陷导致失去系统主要功能,基本功能不能完整使用例如:功能不符程序接口错误数据流错误轻微数据计算错误等2-非常高1.快捷方式不正确，如能够回车直接进入下一步的设计成了空格直接进入下一步2.严重的逻辑错误3.

10、常用操作平台不能正常使用功能(WIN XP/WIN 2000/WIN VISTA)4.常用浏览器不能正常使用（IE6.0/IE7.0/FireFox）5.超时限制的时间设置不合理6.未登录即可浏览页面7.给客户演示等过程中客户重点指出的，严重级别却不是很高的缺陷,建议级别定义至少是非常高C-一般操作性错误、错误结果、遗漏功能等影响系统要求或基本功能的实现,例如:界面错误（附详细说明）打印内容、格式错误简单的输入限制未放在前台进行控制删除操作未给出提示数据输入没有边界值限定或不合理3-高1.提示信息不明确，并且非常容易误导用户做出错误操作或判断。2.软件功能的实现过程中弹出未控制的系统错误提示，

11、导致流程中断3 .Cookies没有正常保存4.服务器和客户端的脚本修改未被记录和5.非法操作等Urgent程度的缺陷，如果不具有普遍性而是在极端环境下出现，例如特定的操作环境。建议级别定义为High。D-微小错别字、罕见故障等不影响执行工作或功能实现,例如:辅助说明描述不清楚系统处理未优化提示窗口文字未采用行业术语4-中1.提示信息不明确，不正确或不合理2.界面设计存在缺陷、凌乱或不友好3.整体风格不统一E-建议建议,不影响使用的瑕疵或更好的实现等对软件各方面提出的更好的改进性的意见。5-低1.虽有不尽人意之处，但不影响用户操作或用户使用频率较低，并且不会造成错误2.局部界面不够美观2.1.

12、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以

13、外的情况2.1.7 缺陷原因记录开发人员判断该缺陷发生的原因。分类具体描述1-式样遗漏/错误；需求文档中，没有相关的说明设计文档中，没有相关的说明需求文档中，相关的说明与实际现象不一致设计文档中，相关的说明与实际现象不一致2-编程遗漏/错误；编码中没有包含必要的功能编码结果与实际现象不一致3-测试不正；测试时使用的数据不正确测试或确认使用的不是测试目标版本测试时使用的操作过程不正确4-环境不备；测试环境配置不正确。比如没有导入必要的基础数据。或者必要的消息内容不存在应用程序在发布，部署时出现错误导致的错误5-外联系统；A. 因为其他系统的原因导致的错误6-重复；A. 同样缺陷的已经指摘过的错误

14、7-其他；A. 1-6以外的情况2.1.8 主题记录该缺陷属于哪个模块中。主题字段设置对应为测试计划中的测试主题（功能模块），方便将来统计各个模块的缺陷密度。2.1.9 测试者记录该缺陷的登记者，系统会自动获取当前用户的用户号，不需要手工录入。2.1.10 测试日期记录该缺陷的登记日期，通常系统会自动获取当前时间，不需要手工录入。2.1.11 检测于发布记录发现该缺陷基线版本（Tags），测试组长在每次获取到新的基线版本程序包时，发布到测试环境之后，按照程序包上的版本标签号（一般为BL_YYYYMMDD_SVN版本号），在ALM中“管理”模块中的“发布”中增加对应的版本号（注： ALM中增加的

15、版本号需与程序包的版本号一致）。如下图，在管理发布三峡付项目ST下点击新增“周期”。2.1.12 可重现记录缺陷是否可重现。根据缺陷描述操作，是否可以发现缺陷所描述的问题，Y表示可以重现，N表示无法重现。例如有些问题是在特定条件下才出现的，当条件改变后问题随之消失，根据所描述的步骤操作，不会再出现缺陷所描述的问题，这类就是属于无法重现的缺陷。2.1.13 子系统记录缺陷所属的子系统。包含以下内容：子系统名称开发组长APP-AndroidAPP-iPhoneAPP-iPad电子账户反欺诈基础服务门户网络预填单业务子系统管理台报表文档性能问题2.1.14 修复日期记录开发人员修正该缺陷的修复日期，

16、系统会自动获取当前时间，不需要手工录入。2.1.15 关闭日期记录测试人员关闭该缺陷的关闭日期，系统会自动获取当前时间，不需要手工录入。2.1.16 关闭于发布记录关闭该缺陷基线版本（Tags），测试组长在每次获取到新的基线版本程序包时，发布到测试环境之后，按照程序包上的版本标签号（一般为BL_YYYYMMDD_SVN版本号），在ALM中“管理”模块中的“发布”中增加对应的版本号（注： ALM中增加的版本号需与程序包的版本号一致）。如下图，在管理发布三峡付项目ST下点击新增“周期”。2.1.17 修改次数记录开发人员因修改本缺陷修改代码的次数，用来衡量开发人员修改缺陷的效率，即测试人员每回归测

17、试一次发现回归失败，系统会自动将修改次数加1，不需要手工录入。2.1.18 SVN版本号记录开发人员修复缺陷后，SVN提交代码后，由SVN自动生成的小版本号，方便测试人员根据该小版本号和基线版本的Tags进行对比，用来获取本基线版本是否包含本缺陷修改的情报信息。开发人员在将缺陷状态由2-打开修改为3-已修正时，SVN版本号必填。2.1.19 修改时间记录本缺陷单最近一次更改的时间戳，系统自动记录，无需手工录入2.1.20 注释开发人员在修复缺陷后，需要在注释栏记录SVN版本库中修改的文件名和文件路径以及修改的主要内容，以方便CM或者测试人员进行配置管理和回归测试。另外该栏也可作为各方人员交流的

18、留言窗口，类似论坛的留言功能。注释栏的填写方法见下图：2.2 系统新增字段说明2.2.1 变更编号2.2.2 测试组长 测试人员在新建缺陷时会有一个字段“测试组长”,这个字段分配到的人员就是这个缺陷的审核人。测试人员新建的缺陷经过测试组长审核，缺陷状态修改为“已审核“。2.2.3 打开时间开发人员在确认缺陷有效后，缺陷状态由：已审核-打开，仲裁人员在缺陷状态：拒绝-打开以及：挂起重新打开，打开时间默认是时间当时时间，不需要手动填写。2.2.4 回归测试状态测试人员在对“已修正”缺陷进行回归测试时使用此字段，进行确认回归是否通过，如果选择“是“，则回归通过，缺陷状态：已修正-已关闭，如果回归测试

19、不通过缺陷状态：已修正-回归失败。2.2.5 开发组长 测试组长在确认缺陷有效后，就必须使用“开发组长”字段为缺陷指定一个开发组长，进一步确认缺陷是否有效。2.2.6 缺陷有效性 此字段是测试组长对于缺陷状态为“新建“的缺陷，进行确认缺陷是否有效：选择”无效“，则缺陷状态由：新建-无效，选择“有效“缺陷状态由：新建已审核。2.2.7 是否挂起 此字段是针对仲裁人员对于缺陷状态为拒绝的缺陷，“仲裁是否缺陷”选择“是“时，会出现一个”是否挂起“字段，来进行确认是否要此缺陷挂起，留在以后版本处理。选择”“是“缺陷状态由：拒绝挂起，选择否缺陷状态由：拒绝-打开。2.2.8 是否进行回归测试 测试者针对

20、缺陷状态为“已修正”的缺陷，打开界面时会呈现“是否回归测试字段“进行判断当前是否要进行回归测试，如果选择”是“，表示当前进行回归测试，则会跳出一个“回归测试状态“的字段，如果选择”否“则会跳出“未回归原因“字段。2.2.9 是否已修复 此字段表示开发人员对于缺陷状态为“打开”，“重新打开”和“回归失败“的缺陷判断是否已经修复的操作，如果选择“是“，则缺陷状态会由：打开已修正，如果选择”否“则状态不变。2.2.10 是否重新打开此字段是仲裁人员对于缺陷状态为“挂起“的缺陷，判断是否要重新打开，如果选择”是“则缺陷状态由：挂起-重新打开，选择“否“缺陷状态不变。2.2.11 未回归原因 此字段针对

21、缺陷状态为“已修正”的缺陷测试者的，”是否回归测试“选择的是否就会出现让测试者填写，不进行回归测试的原因。2.2.12 验证缺陷有效性此字段是开发组长针对缺陷状态为“已审核“的缺陷再次确认缺陷是否有效，选择”有效“表示缺陷是有效的，选择”无效“表示缺陷是无效的。2.2.13 预计回归工时测试者选择“是否进行回归测试“字段，选择”是“的时候进行判断大概回归测试需要耗时多少。2.2.14 暂无法修改 开发人员针对缺陷状态为”打开“的缺陷是否由于此缺陷，本版本无法解决，要留在以后版本解决的操作字段,选择”是“表示此缺陷当前版本下，可以进行修改，选择“否“表示此版本下，当前缺陷可以进行修复。2.2.1

22、5 仲裁人员 仲裁人员一般是项目经理，仲裁人员主要是针对缺陷状态为“拒绝”和“挂起“的缺陷进行操作，对于拒绝的缺陷是最终确认缺陷的有效性，如果无效就是伪缺陷，如果有效则进行下一步操作。针对挂起的缺陷主要是判断当前版本下，此缺陷是否要重新打开。2.2.16 仲裁是否缺陷 仲裁人员使用此字段进行最终缺陷有效性的判断，如果选择“是”,表示此缺陷是有效的，可以进行下一步操作，如果选择“否“则表示此缺陷是无效的，是伪缺陷。2.3 缺陷管理流程图1、不论是简单还是复杂的缺陷，开发人员都要在修改了代码并确保代码提交到服务器后，再将缺陷状态由“2-打开”置为“3-已修正”，并填写SVN版本号。2、对于非常简单

23、明了的缺陷（例如界面上的一个错别字），可以在注释中加简单的注释说明：（如：已修改）但对于复杂的缺陷，开发人员在填写注释的时候需包含以下几点：配置库修改代码对应文件名和文件路径。缺陷解决的方法：（该项描述主要是方便以后遇到同类问题的同事，可以查看当时的解决办法，如果该缺陷的修改引发了其他的缺陷产生，则开发人员可以查看一下当时的修改情况）3 这个改动引起了哪些变动：（方便测试人员在进行回归测试时，确定回归范围）如果缺陷是由于测试人员理解错误导致，或者开发人员认为不需要修改的，开发人员可以将缺陷状态设置为“B-拒绝”，但是必须在【注释】栏中填写拒绝修改的原因。如果目前不具备修改本缺陷的条件（环境原因

24、、涉猎面太广、难度系数很大），开发人员可将缺陷状态设置为“C-挂起”进行延迟修改，但是必须在【注释】栏中填写延迟修改的原因。4、如果开发人员认为该缺陷与其他缺陷重复，也需要在【注释】栏中填写与之重复的缺陷ID，例如注释内容可以填写：与缺陷10重复。目的是让开发人员再确认一下这两个缺陷是否真的描述同一个问题。小提示：在新增注释说明时，可以直接点击页面右下方的按钮，ALM可以直接添加你的登录帐号在“注释”中，省去自己填写的麻烦！如图12.请大家在填写时养成加入自己信息的习惯，方便测试人员在回归测试时可以看到是谁回复的，有问题方便直接沟通！2.4 缺陷管理岗位职责项目经理：对整个项目负责，对产品质量

25、负责，判定缺陷是否应修复，作为仲裁小组成员判定缺陷是否伪缺陷，是否可进行延期修改，严格控制缺陷的生命周期，跟踪缺陷修复情况，直至缺陷关闭；开发组长：判定缺陷是否可修复，进行缺陷定位，提供修复方案、设计给开发人员，按照计划跟踪编码、缺陷修复任务；测试组长：按照缺陷管理规范进行跟踪处理，协助开发人员进行缺陷定位，作为仲裁小组成员判定缺陷是否伪缺陷，是否可进行延期修改，严格控制缺陷生命周期，跟踪缺陷修复情况，直至缺陷关闭；测试人员：执行测试的人员，发现缺陷、提交缺陷，待修复后进行回归测试；开发人员：执行开发任务的人员，按照计划完成设计、编码、缺陷修复的任务；2.5 仲裁小组决定伪缺陷和延期修改缺陷的

26、职责1、仲裁小组的成员包括：项目经理和测试组长，仲裁方式采取项目经理和测试组长定期共同对被拒绝缺陷和挂起缺陷进行逐个分析的方式，并且商议得出最终的处理意见，最终由测试组长在ALM上进行意见反馈和缺陷状态的流转。2、仲裁小组需要对“B-拒绝”的缺陷进行判定，以决定该缺陷是否伪缺陷，若是，需将缺陷状态置为“E-伪缺陷”，并在注释栏填写确定为伪缺陷的原因；若不是，可以将缺陷置为“2-打开”（立即修改），或者置为“C-挂起”（延迟修改）。3、仲裁小组若决定延迟修改缺陷，需在注释中写明延迟修改的原因，再将缺陷状态置为“C-挂起”。4、仲裁小组在对缺陷进行延迟修改后，需在合适的时间将缺陷重新打开，将缺陷状

27、态置为“D-重新打开”让开发人员继续修改3 缺陷填写规范3.1 缺陷的填写原则测试人员填写测试缺陷记录时的原则：单一：一个测试案例执行后可能发现多个缺陷，但一条缺陷记录建议记录一个缺陷；准确：对问题的描述准确，按照步骤操作，可以重现问题；同时也指对操作和对象的描述准确，不会出现歧义；最好是能够找到错误的直接原因；完整：对问题现象的描述完整，包括环境（不同的环境），数据，结果（正确和错误部分）等；延伸：能够举一反三，由发现的问题，对其它可能的情况进行测试，并列出错误或正确的情况；不要重复提报告：测试人员在提交自己的缺陷之前，先要快速查找缺陷库中是否已经有相似或相关的缺陷。一个缺陷库中，重复的缺陷

28、越少越好；再小的缺陷也要报告并提交缺陷跟踪系统；测试人员提交合理的建议，同时对于存在的问题提出自己的建议及表现方法；以前系统存在的缺陷，作为本项目缺陷提交到缺陷库。3.2 缺陷填写的相关支持文档测试人员应该在自己的缺陷记录中加入很好的支持文档，或者至少是供参考的文档。有用的支持文档包括：屏幕截图；重现缺陷的测试案例；测试脚本；用来创建某个状态的特定数据（前置条件）；使用的数据库连接串（环境说明）。总的来讲，有效的缺陷记录应包含许多信息，在提交报告时通过多种方式准确地描述每项内容。4 不同角色操作缺陷4.1 测试者4.1.1 新建缺陷1.填写账号，用户名：ceshi 密码：123456域名：De

29、fault 项目：大型测试项目类模板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.测试组长进入“新建”缺陷页面，可以操作三个字段：“优