QC使用手册.docx
- 文档编号:2871254
- 上传时间:2022-11-16
- 格式:DOCX
- 页数:21
- 大小:670.60KB
QC使用手册.docx
《QC使用手册.docx》由会员分享,可在线阅读,更多相关《QC使用手册.docx(21页珍藏版)》请在冰豆网上搜索。
QC使用手册
QC使用手册以及操作说明
第一章管理员定义
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新建用例编写
如果从“测试计划”模块下新建用例,编写:
Ø测试名称:
应该继承“文件夹”的名称,或者和同级的其他从需求导入的用例
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- QC 使用手册