QC使用手册及相关操作.docx
《QC使用手册及相关操作.docx》由会员分享，可在线阅读，更多相关《QC使用手册及相关操作.docx（22页珍藏版）》请在冰豆网上搜索。
QC使用手册及相关操作
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脚本下，加入代码为：
SubRequirements_Req_New
OnErrorResumeNext
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."
OnErrorGoTo0
EndSub
实现内容：
1，在新建需求时，审阅状态默认值为“未审阅”，表示该新建的需求需要测试负责人等相关人员进行需求评审，评审后，才能将状态置为“已审阅”
2，新建需求下，在需求描述中，自动加入描述内容大纲，格式为：
一:
测试需求概述
1.
2.
二:
测试要点分析
1.
2.
5.3.2测试计划模板脚本
在新建测试用例“TestPlan_Test_New”脚本下，加入代码为：
SubTestPlan_Test_New
OnErrorResumeNext
Test_Fields（"TS_USER_02"）.Value="未审查"
Test_Fields（"TS_USER_01"）.Value="一般"
OnErrorGoTo0
EndSub
实现内容：
1．主要是对新增的两个字段“用例审查”和“用例优先级”赋默认值。
用例审查的默认值为“未审查”，表示该用例未经过评审，由测试相关负责人进行用例审查后，置为“已审查”，则该用例通过，可以进行下一步的测试工作。
“优先级”默认为一般，如果用例需要优先安排进行测试，则将该用例的优级级设置为“高”。
5.3.3缺陷模板脚本
在新建缺陷“Defects_Bug_New”脚本下，加和代码为：
SubDefects_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
EndSub
实现内容：
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：
Errorprocessingthetemplate"
（参见项目编号:
0703-095035436454，抽取专家总数5，国家3，地方2）
4.界面显示
缺陷界面显示的字段设置
选择列中，一般选用“缺陷ID”，“严重程度”，“缺陷状态”，“优先级”，“分配给”，“摘要”，“检测者”几个字段显示。
5.缺陷状态控制
5.1测试人员控制缺陷状态
测试人员新建缺陷
缺陷状态：
“新建”
测试人员修改缺陷状态转换包括：
“已修改”—“重新打开”
“已修改”—“已关闭”
“非bug”—“重新打开”
“非bug”—“已关闭”
“暂不处理”—“重新打开”
“暂不处理”—“已关闭”
（注：
按流程，测试人员应该先经过“已复测”才能进入“已关闭”，因为现在公司的测试人员在职时间都经过半年以上，业务熟悉和测试工作开展已适应项目测试，所以，直接进行缺陷的关闭操作。
对于测试新入职人员，应该先经过“已复测”，再关闭缺陷，或者“重新打开”）。
5.2测试负责人控制缺陷状态
测试负责人主要是参与缺陷的审查，缺陷状态转换
“新建”—“打开”//审查缺陷关键信息，描述内容，打开缺陷
“新建”—“建议”//确定缺陷是否“对业务或技术的建议内容”，是则置为“建议”状态
“已关闭”—“重新打开”//已关闭的缺陷又在测试过程中出现，重新打开。
5.3开发人员控制缺陷状态
开发人员主要是根据“分配给”字段确定自己的缺陷，同时，缺陷状态为“打开”，“重新打开”，“建议”的缺陷进行状态的转换，同时，缺陷修改应以缺陷的“优先级”进行，优先级高的缺陷先进行修改。
状态转换为：
“打开”—“非bug”
“打开”—“已修改”
“打开”—“暂不处理”
“重新打开”—“非bug”
“重新打开”—“已修改”
“重新打开”—“暂不处理”
“建议”—“已修改”
“建议”—“暂不处理”
同时，开发人员对缺陷的“注释”内容进行操作，
根据注释内容：
1.错误分析:
2:
解决方式:
开发人员在对缺陷状态进行修改后，须对注释的这两点内容进行填写。
第七章QC综述
1.流程综述
测试需求（评审）测试计划用例（评审）缺陷生成（评审）
升级会员 