QC使用手册及相关操作

目 录

第一章 管理员定义 ............................................................................................................ 1

1. 自定义项目列表 ..................................................................................................... 1

1.1 针对QC的“需求”模块 ............................................................................ 1 1.2 针对QC的“测试计划”模块 .................................................................... 2 1.3 针对QC的“缺陷”模块 ............................................................................ 2 2. 自定义项目实体 ..................................................................................................... 3

2.1 “缺陷”实体修改 ....................................................................................... 3 2.2 “TEST”实体修改 ......................................................................................... 4 3. 设置组 ..................................................................................................................... 6

3.1 设置测试工作者组 ....................................................................................... 6 3.2 设置开发人员组 ........................................................................................... 8 4. 设置项目用户 ......................................................................................................... 9 5. 设置工作流 ........................................................................................................... 10

5.1 添加缺陷字段自定义 ................................................................................. 10 5.2 缺陷详细信息字段自定义 ......................................................................... 11 5.3 脚本编辑器 ................................................................................................. 11

第二章 需求模块 .............................................................................................................. 14

1. 新建需求 ............................................................................................................... 14

1.1 新建需求 ..................................................................................................... 14 1.2 需求编写要求 ............................................................................................. 14 2. 转换测试 ............................................................................................................... 15 第三章 业务组件模块 ...................................................................................................... 17

1. 业务组件介绍 ....................................................................................................... 17 2. 具体体现 ............................................................................................................... 17 3. 工作流程 ............................................................................................................... 18 4. 测试使用？ ........................................................................................................... 18 第四章 计划模块 .............................................................................................................. 19

1. 用例编写 ............................................................................................................... 19

1.1 导入用例编写 ............................................................................................. 19 1.2 新建用例编写 ............................................................................................. 19

i

1.3 用例编写要求 ............................................................................................. 19 2. 链接缺陷 ............................................................................................................... 20 第五章 实验室模块 .......................................................................................................... 21 第六章 缺陷模块 .............................................................................................................. 22

1. 新增缺陷 ............................................................................................................... 22 2. 缺陷编写要求 ....................................................................................................... 22 3. 缺陷范例 ............................................................................................................... 23 4. 界面显示 ............................................................................................................... 23 5. 缺陷状态控制 ....................................................................................................... 24

5.1 测试人员控制缺陷状态 ............................................................................. 24 5.2 测试负责人控制缺陷状态 ......................................................................... 25 5.3 开发人员控制缺陷状态 ............................................................................. 25

第七章 QC综述 ................................................................................................................ 26

1. 流程综述 ............................................................................................................... 26 2. 指导意见 ............................................................................... 错误！未定义书签。

ii

iii

第一章 管理员的定义

1. 自定义项目列表

1.1 针对QC中的“需求”模块

新建需求时，使用的“产品”的字段，进行如下修改： 进入自定义项目列表：

1．这个“所有项目”列表对应QC需求中的“产品”字段，我们公司以项目为产品，开展测试，每个开发的项目下，可以细分具体的测试子产品，所以，需要把这个“产品”细化一下，用于对新建的“测试需求”的一个属性描述，图中的“列表项”中，主要列出测试需求所属的子产品的分类。以公司开始的“竞争性谈判”这个项目实体为例，在新建测试需求时，可能会分到“节点”，“视图”，“流程”等各子产品下，所以，在QC建测试项目之初，需要在“所有项目”下的列表项中，加入图中的一些新的列表，便于在QC新建测试需求时选用。

2．列表“审阅状态”：列表项为“未审阅”和“已审阅”，默认为“未审阅”

1

1.2 针对QC中的“测试计划”模块

增加两个列表，用于新建测试用例。 1．新增“用例审查“列表

列表项为两项：“未审查”和“已审查”。默认为“未审查”

2．新增“用例优先级”列表

列表项为三项：“低”“一般”“高”，默认为“一般”

1.3 针对QC中的“缺陷”模块

QC中自定义的缺陷状态有可能一些状态值不符合测试整体过程的要求，以及对缺陷

2

流程进行控制，所以，自定义一个“bug状态”的列表，具体如图所示：

列表项中包括测试过程中缺陷的所有状态：新建，打开，已修改，非BUG，已复测，已关闭，重新打开，暂不处理，建议。

2. 自定义项目实体

2.1 “缺陷”实体修改

1. 在“系统字段”中，点击“状态”进入字段设置，把“必填”，“验证值”的勾选去掉！以后项目测试过程中的缺陷的状态，都不再使用该QC提供的该字段。

2. 新增“用户字段”—缺陷状态

3

字段名记录为“BG_USER_01”，字段类型为“查找列表”，选中“必填” 查找列表选择在自定义项目列表时新建的“bug状态”列表 以后项目测试过程中的缺陷的状态变化都用此字段中的值来表示！

2.2 “TEST”实体修改

新增用户字段为“* 用例审查”，“* 用例优先级” 如下两图所示：

4

其中：“* 用例审查”字段名称“TS_USER_02”，“查找列表”使用之前在“自定义项目列表”中新增的“用例审查”；

“* 用例优先级”字段名称“TS_USER_01”，“查找列表”使用之前在“自定义项

5

目列表”中新增的“用例优先级”；

3. 设置组

不使用QC自带的测试组划分，新增两个基于QC原有组的新组，分别为：admin_tester 和 “开发人员”

3.1 设置测试工作者组

设置如下：

Admin_tester的设置基于“TDAdmin”组下，权限设置为： 只对“缺陷”分页下进行设置：

6

在“缺陷”页面下，添加缺陷下，取消勾选“状态”，因为我们的缺陷状态将使用针对项目测试所设置的“缺陷状态”字段，不再使用“状态”字段！设置结果如上图所示。

点击上图中的“缺陷数据隐藏筛选器”：

在“可见字段”下，取消勾选“状态”字段。表示该字段在QC添加缺陷时，该字段不再显示！如上图所示。

7

在“缺陷”分页下，“修改缺陷”栏下，取消勾选“状态”，因为我们的缺陷状态将使用针对项目测试所设置的“缺陷状态”字段。设置结果如上图所示。同时，在“缺陷数据隐藏筛选器”下，在“可见字段”中，取消勾选“状态”字段。

3.2 设置开发人员组

设置如下：

“开发人员”的设置基于“Developer”组下，权限设置为： 只对“缺陷”分页下进行设置： 1．

取消勾选“添加缺陷”。开发人员不可以添加缺陷，如果是自身调试过程中的缺陷，直接在开发过程中修改，如果是测试过程中，开发人员发现缺陷，可以直接告知项目测试人员，由测试人员将缺陷提交至QC。

在“修改缺陷”栏下，取消勾选“状态”，表示不再使用该字段，同时，在“缺陷数据隐藏筛选器”下，取消勾选“状态”字段，如下图设置：

2．

8

3．

在“修改缺陷”栏下，进入“缺陷状态”设置，开发人员的具体设置如下：

开发人员可以对“打开”，“重新打开”，“建议”三种状态的BUG进行状态修改，修改后的值为图中“到”的值。

4. 设置项目用户

添加参与该项目的所有用户到“项目用户”栏内， 然后，给每个用户定义新的组，

9

QC的管理员只使用TDAdmin即可。

测试人员使用“admin_tester”组 开发人员使用“开发人员”组 项目经理使用“PM”组

其他人员可以使用“Viewer”组。

使用到具体组的用户，不再添加并列的其他组，避免造成实际操作使用QC开展工作时的混乱。

5. 设置工作流

5.1 添加缺陷字段自定义

1．用户组admin_tester下，设置为：

主要是确定没有勾选“状态”字段！ 2．用户组“开发人员”下，设置为：

10

同样，主要是确定没有勾选“状态”字段。

5.2 缺陷详细信息字段自定义

设置同5.1“添加缺陷字段自定义”，确定“admin_tester”和“开发人员”两个用户组下的可见字段中，都没有勾选“状态”字段。

5.3 脚本编辑器 5.3.1 需求模板脚本

在新建需求Requirements_Req_New脚本下，加入代码为： Sub Requirements_Req_New On Error Resume Next

Req_Fields(\"RQ_REQ_REVIEWED\").Value=\"未审阅\"

Req_Fields(\"RQ_REQ_COMMENT\").Value=\"一:测试需求概述\"& vbCrLf & _ space(1)& \"1.\"& vbCrLf & _ space(1)& \"2.\"& vbCrLf & _

vbCrLf &\"二:测试要点分析\"& vbCrLf & _ space(1)& \"1.\"& vbCrLf & _ space(1)& \"2.\"

11

On Error GoTo 0 End Sub 实现内容： 1， 2，

在新建需求时，审阅状态默认值为“未审阅”，表示该新建的需求需要测试负责人等相关人员进行需求评审，评审后，才能将状态置为“已审阅” 新建需求下，在需求描述中，自动加入描述内容大纲，格式为：

一:测试需求概述 1. 2.

二:测试要点分析 1. 2.

5.3.2 测试计划模板脚本

在新建测试用例“TestPlan_Test_New”脚本下，加入代码为： Sub TestPlan_Test_New On Error Resume Next

Test_Fields(\"TS_USER_02\").Value =\"未审查\" Test_Fields(\"TS_USER_01\").Value =\"一般\" On Error GoTo 0 End Sub 实现内容：

1．主要是对新增的两个字段“用例审查”和“用例优先级”赋默认值。用例审查的默认值为“未审查”，表示该用例未经过评审，由测试相关负责人进行用例审查后，置为“已审查”，则该用例通过，可以进行下一步的测试工作。“优先级”默认为一般，如果用例需要优先安排进行测试，则将该用例的优级级设置为“高”。

5.3.3 缺陷模板脚本

在新建缺陷“Defects_Bug_New”脚本下，加和代码为： Sub Defects_Bug_New

WizardFieldCust_Add ' 由向导添加

Bug_Fields(\"BG_DEV_COMMENTS\").Value =\"1.错误分析:\"& vbCrLf & _ \"2:解决方式:\"

12

Bug_Fields(\"BG_USER_01\").Value=\"新建\"

Bug_Fields(\"BG_PROJECT\").Value= Req_Fields(\"RQ_REQ_PRODUCT\").Value End Sub 实现内容：

1．确定新建缺陷时，缺陷的状态为“新建”。

2．对新建缺陷时，“注释”中，需要修改缺陷的相关开发人员加入两个内容，一是缺陷错误分析，二是解决方式。便于进行缺陷的回归测试，便于开发，测试技术交流。 3．新建缺陷的“项目”值继承从新建需求时选择的“产品”字段值。

13

第二章 需求模块

1. 新建需求

1.1 新建需求

名称：是必填项，输入测试需求的名称。

产品：选择在“自定义项目列表”中，设置的“所有项目”列表中的列表值。 已审阅：默认已为“未审阅”。

描述：按默认的题纲（需求概述，要点分析）进行编写。

1.2 需求编写要求

1． 需求名称：要求和产品需求说明或技术需求说明文档基本一致，转化为测试认为显著的需求名称。

14

2． 描述内容：

 测试需求概述：基于业务需求说明书和技术需求说明书，转化为测试需求信息，

写入新建需求中。  测试要点分析：列出基于该测试需求概述下，测试关注点，指导测试用例的设计，

防止测试点遗漏，完善测试用例覆盖度  需求的描述内容编写，每行文字达到QC默认的该需求页面宽度时，编者应该主

动回车换行，便于以后需求的查看浏览。  描述语句简洁，精练，内容易读。避免长语句。

 测试要点需要特殊注意的部分，可以使用“蓝色”颜色进行标志。 4．需求树格式：

格式参考为图所示，每个需求继承上一级需求特征，并且从“_1”进行编号，同级的号从“_1”开始累加，下一级以“_1_1”开始，或者“新内容_1_内容”开始，保证同级需求的格式前面字符串是一致，并以编号排序。

5．需求编写：根据项目功能点复杂度，自主确定测试需求树层次，一般需求树为四层，第四层自动转化后为“测试用例”。所以，测试需求编写时，一定要进行必要细化，方便最后一层的子需求转化为“测试用例”。

注： 之所以把编号后置，是因为编号到最后一级需求时，可能编号会很长，而我们关注的是需求的内容，所以，内容置前，编号置后。

2. 转换测试

转换测试使用“需求”菜单下“转换测试”进行操作。

自动转换操作中，转换方法选取“将最底层的子需求转换为测试”

15

16

第三章 业务组件模块

1. 业务组件介绍

这是一个利用QTP与QC的完美结合组成的一个体系架构。它可以轻易实现目前比较流行的三层测试架构：脚本层，业务层，数据层相分离，为开展功能自动化测试提供一个高效、稳定、测试实现平台

2. 具体体现

 相关业务人员可以在没有脚本的环境下组合业务组件，实现业务流程

 对业务人员的编程能力没有要求，业务人员只需了解系统的业务流程，不用关心具体

的脚本实现。这一点也实现了业务层和脚本层的分离。  一旦某个组件开发完毕，即可在不同的流程中使用该组件，实现高可复用性，从而加

快业务流程测试的速度。  明确的角色分工，业务人员负责流程的开发、组织；QTP工程师负责脚本的开发、维

护以及相应函数库的开发、维护。  因为实现了脚本的复用，提高了自动化开发的效率，无形中就降低了测试过程中维护

的时间和成本。

17

3. 工作流程

4. 测试使用？

因为现在的公司QC版本为9，现在测试人员学习并逐步使用于测试的QTP的版本在9.5以上。所以，不能创建QTP的应用域到QC。

另外，QTP自动化框架中的业务，脚本，数据分开实现也可以在公司原有的框架下进一步实现，所以，QC中的“业务组件”模块可以暂时不考虑使用。

18

第四章 计划模块

1. 用例编写

1.1 导入用例编写

从测试需求中，导入的用例编写：

 在用例“详细信息”分页下，设置“用例审查”为“未审查”，并对“用例优先

级”进行设置  在用例“设计步骤”分页下，添加测试步骤，步骤中的描述和预期结果编写方式

规范，到页面宽度时，设计用例者主动回车换行  上传用例需要的附件

1.2 新建用例编写

如果从“测试计划”模块下新建用例，编写：

 测试名称：应该继承“文件夹”的名称，或者和同级的其他从需求导入的用例名

称保持结构一致！  在用例“详细信息”分页下，设置“用例审查”为“未审查”，并对“用例优先

级”进行设置（默认应该已经设置）  在用例“设计步骤”分页下，添加测试步骤，步骤中的描述和预期结果编写方式

规范，到页面宽度时，设计用例者主动回车换行  上传用例需要的附件

 在用例“需求覆盖”分页下，选择需求，手动把用例关联到相应的需求。

1.3 用例编写要求

 每一个文件夹下的用例格式是一致的，按编号+内容进行排序。如下图：

19

 用例设计“步骤名称”简短，“描述”和“预期结果”编写到达页面宽度，主动

回车换行，描述和预期结果对应，有参数输入就必须有输出结果  一种描述或输入，有多种测试期望结果，应该把测试步骤分开设计编写  一种描述或输入，影响到多个业务或功能模块，则设计另外测试用例进行测试步

骤设计。  执行测试用例时，按“用例优先级”进行。

2. 链接缺陷

QC中的每个测试缺陷都有它的源，源在测试需求，经过测试计划中的用例，测试实验室对测试用例的执行，最终会产生一个新的缺陷。

因为测试需求自动转化为测试计划和用例，测试实验室执行测试浪费人力和时间，且自动生成的缺陷内容中，有很多冗长的无用信息，使缺陷看似“宠大”，易读性差

所以，我们公司的缺陷出处，即“源”应该设置在测试用例中。具体操作：  在每个测试用例中的“链接的缺陷”分页下，点击“添加和链接缺陷”，进行缺

陷添加操作。 注：QC中所有的缺陷新增，都应该是以测试用例为源进行新增！

20

第五章 实验室模块

注：测试实验室模块主要控制测试执行，包括手工测试用例以及其他测试用例，如自动化用例等。因为现阶段公司的测试执行工作一般由测试用例编写人员进行。并非要指定测试员去执行用例，所以，对实验室可以不作使用。节约时间成本，人力成本。

同时，从实验室导出的缺陷描述，本身有很多冗长的没用信息，缺陷查看也不方便，所以也不建议从实验室导出生成缺陷。而直接从相关测试用例直接去生成，关联缺陷！

21

第六章 缺陷模块

1. 新增缺陷

新增缺陷入口为QC“计划”模块下的测试用例（链接的缺陷分页面下） 这样新增缺陷目的在于：

1．便于缺陷和需求，用例的链接。方便查找缺陷出处

2．避免测试人员测试交叉功能用例，造成的缺陷提交重复的问题，因为更方便

通过用例查看原有链接缺陷 3．其他部门查看缺陷产生原因更易明白。

2. 缺陷编写要求

结合公司原有的缺陷流程管理规范以及项目测试实际应用， 在缺陷编写方面做以下要求：

 缺陷“摘要”书写：

用例文件夹名--测试用例名--编号

如：节点--上传竞争性谈判文件_1_单个上传--001，其中，“节点”是该用例所在的文件夹的名称，“上传竞争性谈判文件_1_单个上传”是测试用例名，“001”是该用例下的缺陷编号，表示这是该用例的第一个缺陷。

 缺陷“严重程度”，缺陷“优先级”，按QC原有设置，在新建缺陷时，测试人

员根据个人经验选择不同级别，最终完成缺陷提交，测试负责人进行缺陷审查时，再进一步确定缺陷级别是否合理，并把缺陷状态从“新建”状态转为“打开”状态。  缺陷“描述”，

第一行：测试 用例名--问题描述关键字

其中，“测试 用例名”是新增缺陷时，从用例自动关联过来的字符串，后面的“问题描述关键字”则要测试人员根据这个缺陷内容书写 如：“测试 上传竞争性谈判文件_1_单个上传—上传失败”

表示用例“上传竞争性谈判文件_1_单个上传”中，存在上传失败的缺陷！  缺陷“描述”

1．第二行往下，具体描述缺陷产生步骤，按1，2，3如此步骤分行进行描述，每行文字达到缺陷页面默认宽度时，缺陷创建人员主动回车换车； 2．描述要求文字精练，避免使用过长语句，缺陷出处描述清晰；

22

3．实际结果（实际缺陷问题）可以用“红色”颜色字体标志。

 缺陷“注释”，测试人员新建缺陷时，不关注“注释”，开发人员修改后，需要

根据注释要求，填写注释并提交，测试人员在进行缺陷验证时，需关注“注释”内容并进行总结。

3. 缺陷范例

摘要：状态节点--废弃专家--001

测试: 状态节点--废弃专家--缺少“废弃专家”节点 1．执行\"抽取谈判专家\"提交，查看节点展现情况

2．错误描述：节点\"抽取谈判专家\"提交后节点\"废弃专家\"未出现。

摘要：评标--抽取谈判专家--001

测试: 抽取谈判专家-视图页面报错 1．节点\"抽取谈判专家\"完成，检查视图页面数据

2．视图-评标页签页面报错。提示\"VelocityViewServlet： Error processing the template\" （参见项目编号:0703-0950354354，抽取专家总数5，国家3，地方2）

4. 界面显示

缺陷界面显示的字段设置

23

选择列中，一般选用“缺陷ID”，“严重程度”，“缺陷状态”，“优先级”，“分配给”，“摘要”，“检测者”几个字段显示。

5. 缺陷状态控制

5.1 测试人员控制缺陷状态

测试人员新建缺陷 缺陷状态：“新建”

测试人员修改缺陷状态转换包括： “已修改”—“重新打开” “已修改”—“已关闭” “非bug”—“重新打开” “非bug”—“已关闭” “暂不处理”—“重新打开” “暂不处理”—“已关闭”

（注：按流程，测试人员应该先经过“已复测”才能进入“已关闭”，因为现在公司的测试人员在职时间都经过半年以上，业务熟悉和测试工作开展已适应项目测试，所以，

24

直接进行缺陷的关闭操作。对于测试新入职人员，应该先经过“已复测”，再关闭缺陷，或者“重新打开”）。

5.2 测试负责人控制缺陷状态

测试负责人主要是参与缺陷的审查，缺陷状态转换

“新建”—“打开” //审查缺陷关键信息，描述内容，打开缺陷

“新建”—“建议” //确定缺陷是否“对业务或技术的建议内容”，是则置为

“建议”状态 “已关闭”—“重新打开” //已关闭的缺陷又在测试过程中出现，重新打开。

5.3 开发人员控制缺陷状态

开发人员主要是根据“分配给”字段确定自己的缺陷，同时，缺陷状态为“打开”，“重新打开”，“建议”的缺陷进行状态的转换，同时，缺陷修改应以缺陷的“优先级”进行，优先级高的缺陷先进行修改。

状态转换为： “打开”—“非bug” “打开”—“已修改” “打开”—“暂不处理” “重新打开”—“非bug” “重新打开”—“已修改” “重新打开”—“暂不处理” “建议”—“已修改” “建议”—“暂不处理”

同时，开发人员对缺陷的“注释”内容进行操作， 根据注释内容：

1.错误分析: 2:解决方式:

开发人员在对缺陷状态进行修改后，须对注释的这两点内容进行填写。

25

第七章 QC综述

1. 流程综述

测试需求（评审） 测试计划用例（评审） 缺陷生成(评审)

26