QYFWI52QC具体使用管理要求.docx
- 文档编号:10894191
- 上传时间:2023-02-23
- 格式:DOCX
- 页数:14
- 大小:284.49KB
QYFWI52QC具体使用管理要求.docx
《QYFWI52QC具体使用管理要求.docx》由会员分享,可在线阅读,更多相关《QYFWI52QC具体使用管理要求.docx(14页珍藏版)》请在冰豆网上搜索。
QYFWI52QC具体使用管理要求
文件编号:
Q-YF-WI-5.2-2011
密级:
□公开使用■内部使用
主管部门:
产品中心
受控状态:
受控文件
QC具体使用管理要求
版本号
版本说明/变更理由/变更内容
作者/日期
审批人/日期
备注
1.0
创建
袁培茹
1.1
修改测试执行添加开发自测试部分
袁培茹/2013-7-19
侯鹏亮/2013-7-22
变更说明分为四个部分:
初始创建;增加内容;修改;删除
目录
一、总体要求3
1.测试需求3
2.测试计划3
3.测试执行4
4.缺陷跟踪5
5.测试分析6
二、测试负责人要求6
一、总体要求
测试需求操作流程图:
1.测试需求
要求:
1、标识优先级(高中低)
2、需要对测试需求进行描述
3、对审核状态进行标识
4、选择项目名称
5、需求树形管理,
按照编号+需求名称来组织
推荐组织形式:
一级:
01子系统
1.1二级功能模块
1.1.1三级子模块
1.1.1.1四级有效测试
1.1.1.1.1测试需求点
1.1.1.2四级无效测试
1.1.1.2.1测试需求点
一级:
公共用例
一级:
流程测试
一级:
其他与其他部分不重叠可以并列一级的目录
2.测试计划
测试计划操作流程图:
要求:
0、测试计划的分层结构规定
1)产品用例以产品版本来进行维护,对于每个产品大版本包括一、二
位版本,建立一级目录,目录下放全部此版本的用例。
对于三位版本不需要
单独建立用例集,在最近的产品版本下进行维护,需要写明用例变更。
2)目录结构分层顺序如下
一级:
产品版本
01子系统
1.1二级功能模块
1.1.1三级子模块
1.1.1.1四级有效测试
1.1.1.1.1五级测试用例
1.1.1.2四级无效测试
1.1.1.2.1五级测试用例
02公共用例
03流程用例
04其他与其他部分不重叠可以并列一级的目录
举例:
DSVS测试
V1.3
01WEB管理系统
02应用接口测试
03流程测试
04demo测试
05公共用例
06自动化测试
V1.4
01WEB管理系统
02应用接口测试
03流程测试
04demo测试
05公共用例
06自动化测试
1、填写描述
编写人/日期:
操作类型:
添加修改删除
版本:
详细说明:
多个信息是以*******************分隔
举例:
编写人/日期:
袁培茹/2011-8-22
操作类型:
建立
版本:
1.0
详细说明:
根据此版本的变更将原来的证件类型中的身份证限制修改为
支持8位和12位。
************************************************************
编写人/日期:
袁培茹/2011-9-22
操作类型:
修改
版本:
1.1.1
详细说明:
根据此版本的变更将原来的证件类型中的身份证限制修改为
支持8位和12位。
2、填写优先级
3、填写项目名称
4、关联需求
5、审核信息
6、测试计划树形结构,按照
标号+测试计划名称来组织
7、用例分为有效和无效两个部分,以文件夹标识,下面放具体的用例。
8、测试步骤部分,需要描述步骤的概括内容,不要以步骤几命名。
9、测试用例要可执行,预期结果要可验证。
3.测试执行
要求:
0、测试任务建立
产品的测试任务建立:
一级产品版本
二级BAT------------------------在测试用例执行前筛选BAT测试用例,作为前提执行,执行通过接受测试。
测试级别为1的。
二级开发自测试
三级测试版本
二级测试执行
三级测试版本
四级测试人员名称
举例:
一级V1.1
二级BAT
二级Build1
三级BAT-刘飞
三级袁培茹
三级张琴
项目测试任务建立:
一级测试版本
二级测试人员名称
1、缺陷关联
2、状态标识
3、未执行和没有执行完全的用例,需要在“测试集属性”-“详细信息”部分进行说明
说明信息包括:
用例名称
类型:
包括未执行和没有执行完毕
未执行和没有执行完毕原因说明
例如:
用例名称:
[1]1.10.01sql注入说明类型:
未执行
说明:
由于此部分功能出现提供。
测试执行操作流程图:
测试缺陷操作流程图:
4.缺陷跟踪
要求:
1.缺陷和测试用例关联
2.缺陷的必填信息
3.修复的测试缺陷需要开发再备注部分
详细描述变更部分
4.验证问题后,需要在备注部分描述
验证结果及验证软件版本
5.测试详细描述需要包括如下:
测试前提说明(可选)
操作步骤、预期结果、实际结果,并以此作为关键字,
以此种格式说明:
测试前提:
操作步骤:
预期结果:
实际结果:
6.摘要描述需要该要描述测试缺陷,不宜太长
7.分配设置如果不清楚具体开发人员,分配给项目经理
分配人员时,请点击邮件发送,以便开发人员能够及时通过邮件获得缺陷。
操作如下:
操作1:
操作2:
8.对于需要仲裁的问题,发邮件通知高层经理(研发部经理和质量管理部经理)
9.测试问题中的测试数据描述要具体,要求可以根据数据+操作,能够指导问题的重现。
10.问题等级需要按照“缺陷管理子过程”中的定义来设定。
提倡:
1.就严重问题和不能确定的问题先进行必要的记录,并及时和开发进行沟通
2.添加必要的图片说明。
测试分析功能流程:
➤创建报告
➤自定义报告
➤添加子报告
➤删除子报告
5.测试分析
要求:
以后测试报告,需要包括
1.测试需求覆盖报告
2.测试用例执行报告
3.测试缺陷趋势报告
4.测试缺陷等级、模块报告
6.Qc测试内容归档
需要归档内容包括:
1、测试用例
2、测试执行记录
3、测试缺陷
具体操作如下:
Qc-工具-文档生成器-收藏夹“公共:
文档生成”-整个文档
1、测试计划
2、测试执行记录
3、测试缺陷
二、测试负责人要求
1、根据需要添加用户
Ntester
Ndeveloper
Npm
Nhm
2、定义项目名称
Bug中填写的项目意义为:
大阶段测试标识,一般为产品或项目的不同版本发布测试或变更测试。
注意:
不能等同于测试版本,应该说一个项目包括若干测试版本。
此处石景山项目就出现了测试版本和项目混淆的情况,目前已经修改,石景山本次测试均属于一次变更测试,项目为一个,但是已经进行了三个版本测试,版本为三个。
项目的命名规范,原则上以编号(1位证书)+产品/项目版本+具体版本号(不清楚版本号的以提交申请日期标识日期格式为YYYYmmdd)。
如果有一些特殊情况,也可以以本阶段的测试标识进行命名,原则是需要通过项目来区分不同大测试阶段。
例如电子原件前期进行过界面原型测试,这个项目的命名可以为“1界面原型测试”。
例如:
1产品版本1.0测试
2产品版本20100721测试
此处命名原则以能通用的标识便是本阶段的测试。
3、定义操作系统
4、定义测试版本
5、规划总体的需求、测试用例总体目录
6、建立测试集
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- QYFWI52QC 具体 使用 管理 要求