《cq操作文档和测管理平台的应用》由会员分享，可在线阅读，更多相关《cq操作文档和测管理平台的应用（23页珍藏版）》请在金锄头文库上搜索。
1、第一篇 测试管理平台,第二篇 ClearQuest的使用,质量管理部 程宝红,测试管理平台的使用,一、管理平台的登陆 二、用例的导入与更新 三、测试计划的查询和管理,登陆,1、登陆地址：http:/ 2、输入账号登录，账号密码和OA一致；,用例的导入与更新,1、导入用例 登陆进入平台，点击左边框导入/更新用例（或上边测试用例导入,1、点击选择文件选择需要导入的测试用例文件 2、点击提交任务（文件会显示在任务查询下）,注：成功导入用例的前提条件 1、导入测试用例：批量生成TC，会产生新的CQ-ID，导入文件必须是03版excel，用例文档必须按要求编写（测试标识、所属项目、子系统、设计人员有效）
2、； 2、更新执行用例：批量更新CTC，不会产生CTC，导入文件必须是03版excel，文档必须包含这些字段“id、执行人员、测试结果、结果说明、集成编号、测试数据、执行日期”； 3、查看导入结果 在“任务信息”栏可以看到当前处理文档的信息概况,4、在“任务查询”可以查询导入文档队列状况及处理状态等信息，其中： 查询：查询以及刷新队列信息； 任务类型：导入测试用例、更新执行用例； 当前状态：说明文档的处理状态，有已提交待处理、处理中、处理成功、处理失败； 提交人：提交文档的登录用户员工号； 结果文件下载：导入后的文件，其中导入测试用例会将导入结果更新到文档中； 日志文件下载：查看详细的导入日志；
3、 5、查看数据 登录CQ； 根据导入的项目新建查询“测试用例”或者“执行用例”即可；,1、查询测试计划 点击侧边栏：测试计划管理测试计划查询； 通过查询条件（项目、子系统）进行条件查询，默认查询全部；,测试计划的查询,2、新增测试计划 查询结果页面可进行的操作包括：全选/添加/删除测试计划； 点击“添加”可新增测试计划表单； 单个表单后有详情和编辑按钮,3、测试计划表单 注意必填项输入，其中“计划概述”是可以不填写的，“是否紧急”必填；,4、新增测试任务 测试计划查询结果页面，点击“详情”进入测试计划信息页面，在“关联测试任务栏”可进行：全选/批量添加/添加/删除测试任务表单； 批量添加：查询
4、所在子系统所有的测试用例集（TS），勾选所需要操作的TS，保存自动产生测试任务； 新增：弹出测试任务表单页面，输入信息后保存；,5、测试任务表单 注意必填项的输入；,测试用例集 测试用例关联测试用例集 执行用例 如何提交缺陷 如何验证缺陷 遗留缺陷管理 Q&A,CQ使用,1、测试用例集（TS），即Test Suit，测试用例集，指某一次测试版本（迭代版本）创建的测试用例集合，包含了所测试版本的执行环境、集成版本等相关信息；,2、测试用例（TC），即Test Case，测试用例，指根据系统功能点而编写的功能测试用例。行业内比较常用的定义是指对一项特定的软件产品进行测试任务的描述，体现测试方案、方
5、法、技术和策略。内容包括测试目标、测试环境、输入数据、测试步骤、预期结果、测试脚本等；,3、执行用例（CTC），即Configured Test Case，执行用例（配置的测试用例），指根据测试用例集所选取的测试用例而产生的测试用例，相比测试用例，执行用例增加了执行环境、执行人员、执行结果等内容；,TC对应的是测试设计阶段，由测试设计人员完成用例设计，新增的用例需要由测试负责人审核确认后才可以导入到CQ； TS对应的是测试计划阶段，根据项目计划创建，串行模式下，一次上线版本对应一个迭代版本，对应一个TS；并行模式下，一次上线计划可以对应多个迭代版本，一个迭代版本对应一个TS； 注：某些特殊项目
6、（如移动应用），可以存在一次迭代版本对应多个TS； CTC对应的是测试执行阶段，通过创建TS后，将TC关联到TS，产生相应的CTC；测试执行的结果在CTC表单中记录，每一轮测试完成后都需要及时更新CTC；,关联关系说明,角色：业务人员、测试人员等 操作：新建缺陷。 输入： 概要描述 所属项目 子系统 责任人(owner)：根据情况判定，明显属于某责任人的，直接提交到责任人本人，或相应的项目经理。 严重性：缺陷的影响范围，详细定义请见附录一。 优先级：解决缺陷时的先后顺序，详细定义请见附录二。 期望完成日期（默认第二天） 根源：缺陷产生的主要原因，详细定义请见附录三 发现阶段：缺陷是在什么阶段被
7、发现的，详细定义请参见附录四 测试类型：缺陷发现时所处的测试类型，详细定义请参见附录五 二次缺陷：关闭后又出现的缺陷。 根源 功能点 测试用例编号（发现阶段为系统测试、UAT、集成测试时必填） 发现版本：缺陷发现时的程序版本 缺陷内容的详细描述（症状、发生环境、重现步骤、期望结果、实际结果）,缺陷的提交,条件：缺陷在Refused、Resolved状态 角色：测试人员（提交者） 操作：验证缺陷根源和缺陷的修正情况， （1）如果确认已经正确被修正，则执行Validate操作。 （Refused/Resolved- Closed) 只有缺陷的提交者或项目的质量负责人才能够关闭缺陷。 （2）如果缺陷
8、未被修正或未完全被修正， 1） Resolved状态，则执行Reject操作，填写Reject的原因， 并保存。（Resolved- Opened ） 2） Refused状态，则执行Resubmit操作，填写相关原因， 并 保存。（Refused- Submitted ）,缺陷的验证,（一）如何将缺陷标记为延迟状态？ 条件：缺陷在Submitted或Opened状态，且该缺陷一时无法解决 角色：项目经理 操作：执行Postpone操作 输入：根源 责任人（默认为系统当前的用户） Notes（延迟的详细原因描述）,遗留缺陷,（二）如何处理延迟状态的缺陷？ 条件：缺陷在Postponed状态 角色：项目经理 操作：对这些延迟状态的缺陷定期进行评审。 （1） 如果评审后，缺陷需要开发人员着手解决，则执行，Resubmit操作 （2） 如果评审后，缺陷不需要处理了，则执行Resolve操作。 上述（1）（2）的操作均需输入： 根源 责任人（默认为系统当前的用户） Notes（处理意见）,遗留缺陷,Q&A,
