QC使用流程定制及操作规范模板.doc

时间
状态
修订人
-11-2
初稿
张彦彬

必联（北京）电子商务信息技术
2024年5月
和操作说明
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
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. 指导意见 26

第一章 管理员定义
1. 自定义项目列表
1.1 针对QC中“需求”模块
新建需求时，使用“产品”字段，进行以下修改：
进入自定义项目列表：

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

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

1.2 针对QC中“测试计划”模块
增加两个列表，用于新建测试用例。
1．新增“用例审查“列表

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

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

列表项为三项：“低”“通常”“高”，默认为“通常”

1.3 针对QC中“缺点”模块
QC中自定义缺点状态有可能部分状态值不符合测试整体过程要求，和对缺点步骤进行控制，所以，自定义一个“bug状态”列表，具体图所表示：

列表项中包含测试过程中缺点全部状态：新建，打开，已修改，非BUG，已复测，已关闭，重新打开，暂不处理，提议。

2. 自定义项目实体
2.1 “缺点”实体修改
1. 在“系统字段”中，点击“状态”进入字段设置，把“必填”，“验证值”勾选去掉！以后项目测试过程中缺点状态，全部不再使用该QC提供该字段。

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

字段名统计为“BG_USER_01”，字段类型为“查找列表”，选中“必填”
查找列表选择在自定义项目列表时新建“bug状态”列表
以后项目测试过程中缺点状态改变全部用此字段中值来表示！

2.2 “TEST”实体修改
新增用户字段为“* 用例审查”，“* 用例优先级”
以下两图所表示：

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

3. 设置组

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

3.1 设置测试工作者组
设置以下：
Admin_tester设置基于“TDAdmin”组下，权限设置为：
只对“缺点”分页下进行设置：

在“缺点”页面下，添加缺点下，取消勾选“状态”，因为我们缺点状态将使用针对项目测试所设置“缺点状态”字段，不再使用“状态”字段！设置结果如上图所表示。
点击上图中“缺点数据隐藏筛选器”：

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

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

3.2 设置开发人员组
设置以下：
“开发人员”设置基于“Developer”组下，权限设置为：
只对“缺点”分页下进行设置：
1． 取消勾选“添加缺点”。开发人员不能够添加缺点，假如是本身调试过程中缺点，直接在开发过程中修改，假如是测试过程中，开发人员发觉缺点，能够直接通知项目测试人员，由测试人员将缺点提交至QC。
2． 在“修改缺点”栏下，取消勾选“状态”，表示不再使用该字段，同时，在“缺点数据隐藏筛选器”下，取消勾选“状态”字段，以下图设置：

3． 在“修改缺点”栏下，进入“缺点状态”设置，开发人员具体设置以下：

开发人员能够对“打开”，“重新打开”，“提议”三种状态BUG进行状态修改，修改后值为图中“到”值。
4. 设置项目用户
添加参与该项目标全部用户到“项目用户”栏内， 然后，给每个用户定义新组，QC管理员只使用TDAdmin即可。
测试人员使用“admin_tester”组
开发人员使用“开发人员”组
项目经理使用“PM”组
其它人员能够使用“Viewer”组。
使用到具体组用户，不再添加并列其它组，避免造成实际操作使用QC开展工作时混乱。
5. 设置工作流
5.1 添加缺点字段自定义
1．用户组admin_tester下，设置为：

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

一样，关键是确定没有勾选“状态”字段。
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."
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:处理方法:"
Bug_Fields("BG_USER_01").Value="新建"
Bug_Fields("BG_PROJECT").Value= Req_Fields("RQ_REQ_PRODUCT").Value
End Sub
实现内容：
1． 确定新建缺点时，缺点状态为“新建”。
2． 对新建缺点时，“注释”中，需要修改缺点相关开发人员加入两个内容，一是缺点错误分析，二是处理方法。便于进行缺点回归测试，便于开发，测试技术交流。
3． 新建缺点“项目”值继承从新建需求时选择“产品”字段值。
第二章 需求模块
1. 新建需求
1.1 新建需求

名称：是必填项，输入测试需求名称。
产品：选择在“自定义项目列表”中，设置“全部项目”列表中列表值。
已审阅：默认已为“未审阅”。
描述：按默认题纲（需求概述，关键点分析）进行编写。
1.2 需求编写要求
1． 需求名称：要求和产品需求说明或技术需求说明文档基础一致，转化为测试认为显著需求名称。
2． 描述内容：
Ø 测试需求概述：基于业务需求说明书和技术需求说明书，转化为测试需求信息，写入新建需求中。
Ø 测试关键点分析：列出基于该测试需求概述下，测试关注点，指导测试用例设计，预防测试点遗漏，完善测试用例覆盖度
Ø 需求描述内容编写，每行文字达成QC默认该需求页面宽度时，编者应该主动回车换行，便于以后需求查看浏览。
Ø 描述语句简练，精练，内轻易读。避免长语句。
Ø 测试关键点需要特殊注意部分，能够使用“蓝色”颜色进行标志。
4． 需求树格式：

格式参考为图所表示，每个需求继承上一级需求特征，而且从“_1”进行编号，同级号从“_1”开始累加，下一级以“_1_1”开始，或“新内容_1_内容”开始，确保同级需求格式前面字符串是一致，并以编号排序。
5． 需求编写：依据项目功效点复杂度，自主确定测试需求树层次，通常需求树为四层，第四层自动转化后为“测试用例”。所以，测试需求编写时，一定要进行必需细化，方便最终一层子需求转化为“测试用例”。
注： 之所以把编号后置，是因为编号到最终一级需求时，可能编号会很长，而我们关注是需求内容，所以，内容置前，编号置后。
2. 转换测试
转换测试使用“需求”菜单下“转换测试”进行操作。
自动转换操作中，转换方法选择“将最底层子需求转换为测试”

第三章 业务组件模块
1. 业务组件介绍
这是一个利用QTP和QC完美结合组成一个体系架构。它能够轻易实现现在比较流行三层测试架构：脚本层，业务层，数据层相分离，为开展功效自动化测试提供一个高效、稳定、测试实现平台
2. 具体表现
Ø 相关业务人员能够在没有脚本环境下组合业务组件，实现业务步骤
Ø 对业务人员编程能力没有要求，业务人员只需了解系统业务步骤，不用关心具体脚本实现。这一点也实现了业务层和脚本层分离。
Ø 一旦某个组件开发完成，即可在不一样步骤中使用该组件，实现高可复用性，从而加紧业务步骤测试速度。
Ø 明确角色分工，业务人员负责步骤开发、组织；QTP工程师负责脚本开发、维护和对应函数库开发、维护。
Ø 因为实现了脚本复用，提升了自动化开发效率，无形中就降低了测试过程中维护时间和成本。
3. 工作步骤

4. 测试使用？
因为现在企业QC版本为9，现在测试人员学习并逐步使用于测试QTP版本在9.5以上。所以，不能创建QTP应用域到QC。
另外，QTP自动化框架中业务，脚本，数据分开实现也能够在企业原有框架下深入实现，所以，QC中“业务组件”模块能够临时不考虑使用。
第四章 计划模块
1. 用例编写

1.1 导入用例编写
从测试需求中，导入用例编写：
Ø 在用例“具体信息”分页下，设置“用例审查”为“未审查”，并对“用例优先级”进行设置
Ø 在用例“设计步骤”分页下，添加测试步骤，步骤中描述和预期结果编写方法规范，到页面宽度时，设计用例者主动回车换行
Ø 上传用例需要附件

1.2 新建用例编写
假如从“测试计划”模块下新建用例，编写：
Ø 测试名称：应该继承“文件夹”名称，或和同级其它从需求导入用例名称保持结构一致！
Ø 在用例“具体信息”分页下，设置“用例审查”为“未审查”，并对“用例优先级”进行设置（默认应该已经设置）
Ø 在用例“设计步骤”分页下，添加测试步骤，步骤中描述和预期结果编写方法规范，到页面宽度时，设计用例者主动回车换行
Ø 上传用例需要附件
Ø 在用例“需求覆盖”分页下，选择需求，手动把用例关联到对应需求。

1.3 用例编写要求
Ø 每一个文件夹下用例格式是一致，按编号+内容进行排序。以下图：

Ø 用例设计“步骤名称”简短，“描述”和“预期结果”编写抵达页面宽度，主动回车换行，描述和预期结果对应，有参数输入就必需有输出结果
Ø 一个描述或输入，有多个测试期望结果，应该把测试步骤分开设计编写
Ø 一个描述或输入，影响到多个业务或功效模块，则设计另外测试用例进行测试步骤设计。
Ø 实施测试用例时，按“用例优先级”进行。
2. 链接缺点
QC中每个测试缺点全部有它源，源在测试需求，经过测试计划中用例，测试试验室对测试用例实施，最终会产生一个新缺点。
因为测试需求自动转化为测试计划和用例，测试试验室实施测试浪费人力和时间，且自动生成缺点内容中，有很多冗长无用信息，使缺点看似“宠大”，易读性差
所以，我们企业缺点出处，即“源”应该设置在测试用例中。具体操作：
Ø 在每个测试用例中“链接缺点”分页下，点击“添加和链接缺点”，进行缺点添加操作。
注：QC中全部缺点新增，全部应该是以测试用例为源进行新增！
第五章 试验室模块
注：测试试验室模块关键控制测试实施，包含手工测试用例和其它测试用例，如自动化用例等。因为现阶段企业测试实施工作通常由测试用例编写人员进行。并非要指定测试员去实施用例，所以，对试验室能够不作使用。节省时间成本，人力成本。
同时，从试验室导出缺点描述，本身有很多冗长没用信息，缺点查看也不方便，所以也不提议从试验室导出生成缺点。而直接从相关测试用例直接去生成，关联缺点！
第六章 缺点模块
1. 新增缺点
新增缺点入口为QC“计划”模块下测试用例（链接缺点分页面下）
这么新增缺点目标在于：
1． 便于缺点和需求，用例链接。方便查找缺点出处
2． 避免测试人员测试交叉功效用例，造成缺点提交反复问题，因为更方便经过用例查看原有链接缺点
3． 其它部门查看缺点产生原因更易明白。
2. 缺点编写要求
结合企业原有缺点步骤管理规范和项目测试实际应用， 在缺点编写方面做以下要求：
Ø 缺点“摘要”书写：
用例文件夹名--测试用例名--编号
如：节点--上传竞争性谈判文件_1_单个上传--001，其中，“节点”是该用例所在文件夹名称，“上传竞争性谈判文件_1_单个上传”是测试用例名，“001”是该用例下缺点编号，表示这是该用例第一个缺点。
Ø 缺点“严重程度”，缺点“优先级”，按QC原有设置，在新建缺点时，测试人员依据个人经验选择不一样等级，最终完成缺点提交，测试责任人进行缺点审查时，再深入确定缺点等级是否合理，并把缺点状态从“新建”状态转为“打开”状态。
Ø 缺点“描述”，
第一行：测试 用例名--问题描述关键字
其中，“测试 用例名”是新增缺点时，从用例自动关联过来字符串，后面“问题描述关键字”则要测试人员依据这个缺点内容书写
如：“测试 上传竞争性谈判文件_1_单个上传—上传失败”
表示用例“上传竞争性谈判文件_1_单个上传”中，存在上传失败缺点！
Ø 缺点“描述”
1．第二行往下，具体描述缺点产生步骤，按1，2，3如此步骤分行进行描述，每行文字达成缺点页面默认宽度时，缺点创建人员主动回车换车；
2．描述要求文字精练，避免使用过长语句，缺点出处描述清楚；
3．实际结果（实际缺点问题）能够用“红色”颜色字体标志。
Ø 缺点“注释”，测试人员新建缺点时，不关注“注释”，开发人员修改后，需要依据注释要求，填写注释并提交，测试人员在进行缺点验证时，需关注“注释”内容并进行总结。
3. 缺点范例
摘要：状态节点--废弃教授--001
测试: 状态节点--废弃教授--缺乏“废弃教授”节点
1． 实施"抽取谈判教授"提交，查看节点展现情况
2．错误描述：节点"抽取谈判教授"提交后节点"废弃教授"未出现。

摘要：评标--抽取谈判教授--001
测试: 抽取谈判教授-视图页面报错
1． 节点"抽取谈判教授"完成，检验视图页面数据

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

4. 界面显示
缺点界面显示字段设置

选择列中，通常选择“缺点ID”，“严重程度”，“缺点状态”，“优先级”，“分配给”，“摘要”，“检测者”多个字段显示。

5. 缺点状态控制
5.1 测试人员控制缺点状态
测试人员新建缺点
缺点状态：“新建”
测试人员修改缺点状态转换包含：
“已修改”—“重新打开”
“已修改”—“已关闭”
“非bug”—“重新打开”
“非bug”—“已关闭”
“暂不处理”—“重新打开”
“暂不处理”—“已关闭”
（注：按步骤，测试人员应该先经过“已复测”才能进入“已关闭”，因为现在企业测试人员在职时间全部经过六个月以上，业务熟悉和测试工作开展已适应项目测试，所以，直接进行缺点关闭操作。对于测试新入职人员，应该先经过“已复测”，再关闭缺点，或“重新打开”）。
5.2 测试责任人控制缺点状态
测试责任人关键是参与缺点审查，缺点状态转换
“新建”—“打开” //审查缺点关键信息，描述内容，打开缺点
“新建”—“提议” //确定缺点是否“对业务或技术提议内容”，是则置为“提议”状态
“已关闭”—“重新打开” //已关闭缺点又在测试过程中出现，重新打开。

5.3 开发人员控制缺点状态
开发人员关键是依据“分配给”字段确定自己缺点，同时，缺点状态为“打开”，“重新打开”，“提议”缺点进行状态转换，同时，缺点修改应以缺点“优先级”进行，优先级高缺点优异行修改。
状态转换为：
“打开”—“非bug”
“打开”—“已修改”
“打开”—“暂不处理”
“重新打开”—“非bug”
“重新打开”—“已修改”
“重新打开”—“暂不处理”
“提议”—“已修改”
“提议”—“暂不处理”
同时，开发人员对缺点“注释”内容进行操作，
依据注释内容：
1.错误分析:
2:处理方法:
开发人员在对缺点状态进行修改后，须对注释这两点内容进行填写。
第七章 QC综述
1. 步骤综述
测试需求（评审） 测试计划用例（评审） 缺点生成(评审)

2. 指导意见
请阅读全文，并提出您意见和提议：

编号
指导内容
指导人员