文档介绍：一、目的
统一测试管理工具QC的使用规范,便于在项目执行中使用QC的管理。
二、范围
适用在测试流程中在QC中的操作,如:测试需求框架的设计、测试计划的描述、用例框架设计与书写、缺陷记录与跟踪等。
三、职责
QC管理员(TDAdmin):维护QC正常运行,可以通过站点管理对项目与相关人员的安排及管理等操作;
项目经理(Project Manager):管理和监督项目组缺陷流程与趋势;
开发经理(Developer):分配缺陷给开发人员,验证缺陷修改描述以及逻辑的正确性;
测试经理(QATester):验证缺陷描述以及逻辑的正确性,分配修改完后的缺陷给测试工程师编译部署新系统版本,添加版本号;
测试工程师(QATester):提交缺陷,验证缺陷的修复结果,关闭或重新打开缺陷;
开发工程师(Developer):修改缺陷,描述缺陷修改方案。
四、工作程序
QC在测试流程中主要功能涉及到测试需求、测试计划、用例书写与执行、缺陷记录与跟踪以及总结分析。
Requirements:
根据系统的需求进行编写测试需求,测试需求的编写需简单明了。测试需求名称一般是由测试的项目名称加上需求点(包括功能点)名称等组成。
使用规范:
在Requirements编写需求框架时,其大体分级应该遵循的顺序:测试的项目→需求点→功能点(或其他需求点,如:性能、安全性等)。
当需要对功能点的继续进行分级时,也遵循“功能点→低一级功能点”的规范
例:以学院信息化平台的缴费系统为例子,制定需求的编写格式:
在学院信息化平台的缴费系统中,一级菜单就是缴费系统,二级菜单就是分为不同的测试方法,如:功能性测试,易用性测试等。所以按“测试的项目→需求点”编写。
功能性测试分为登录模块、查询模块、费用录入模块等功能点;对这些功能点继续进行细分,登录又可分为登录和找回密码功能点。
登录这一层次的功能点可以有多个,按照一定的要求进行书写,若功能点还可以继续进行划分,则继续划分,依次类推。(见图-1)
图-1
其他操作
当需求编写完毕后可以导入到测试计划中:
选中一个一级菜单(如:缴费系统),单击菜单栏上的Requirements->Convert To Test
此时会弹出一个对话框(图-2),其中第一个是指:转变最后一个子需求为设计步骤;第二个是指:转变最后一个需求为测试项;第三个是指:转变所有的需求为测试主题。
图-2
若选中第一个,单击下一步后,会显示出转变后的样式,此时若是发现转变有误,可以单击上一步,重新选择;若没有错误,继续单击下一步,此时会显示出转变后的路径输入框,可以手动输入,完成后,单击完成按钮,就可以操作成功。成功后在Test Plan中显示如图-3所示。
图-3
Test Plan:
编写Test Plan中的主要的功能点,要和需求中的保持一致;根据功能点的具体内容进行分支,编写测试用例;
使用规范:
测试用例的上下级关系必须与需求保持一致,多级的用例可以使用文件夹进行分类;
如果在测试用例上有做功能点名称的修改,在需求中最好也做相应的更新;
例:以学院信息化平台的缴费系统为例子,制定测试计划的编写格式:
从测试需求导入到测试计划中,根据具体的功能的进行划分,然后编写测试用例。
登录模块中的测试用例分