QC使用手册.docx
《QC使用手册.docx》由会员分享,可在线阅读,更多相关《QC使用手册.docx(23页珍藏版)》请在冰豆网上搜索。
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的完美结合组成的一个体系架构。
它可以轻易实现目前比较流行的三层测试架构:
脚本层,业务层,数据层相分离,为开展功能自动化测试提供一个高效、稳定、测试