qc使用计划书Word文档下载推荐.docx

qc使用计划书Word文档下载推荐.docx

《qc使用计划书Word文档下载推荐.docx》由会员分享，可在线阅读，更多相关《qc使用计划书Word文档下载推荐.docx（12页珍藏版）》请在冰豆网上搜索。

QC能够控制整个测试过程，并创建整个测试工作流的框架和基础，使整个测试管理过程变得更为简单和有组织。

qc管理测试资源：

——域（domain）

——项目（project）

qc支持的后台数据库：

——SQLServer

——Oracle

qc支持的webserver和Appserver：

——IIS（只适合windows安装）

——Jboss

——Apache

——Weblogic

二、QC测试管理流程

1.指定需求

定义测试范围—〉创建需求—〉详述需求—〉分析需求

（1）定义测试范围：

根据实际情况定义测试的范围；

（2）创建需求：

建立需求树，定义总体的测试需求；

（3）详述需求：

为需求树上的每一个主题，建立一个详细的测试需求列表；

（4）分析需求：

生成报告和图表辅助分析创建的测试需求，检验需求是否适用于测试范围。

2.测试计划

测试计划主要包括以下几个部分：

制定测试策略—〉制定测试目标—〉定义测试—〉创建需求覆盖—〉设计测试步骤—〉自动测试—〉分析测试计划

（1）制定测试策略：

确定应用程序、系统环境、测试资源

（2）制定测试目标：

把应用程序分解为可测试的功能。

建立一棵测试计划树按级别把应用程序分解为测试单元或主题。

（3）定义测试：

为每个测试主题确定测试类型。

（4）创建需求覆盖：

把每个测试与一个或多个测试需求关联起来。

（5）设计测试步骤：

通过在测试计划树上增加测试步骤来开发手工测试。

（6）自动测试：

通过自动化测试工具进行自动测试

（7）分析测试计划：

生成报告和图表辅助分析测试计划。

检查计划是否符合测试目标。

3.执行测试

运行测试是测试流程的核心，主要包括以下几个部分：

定义测试集—〉将测试添加到测试集—〉计划测试运行—〉手动运行测试—〉自动运行测试

4.缺陷跟踪

找到并修复缺陷是应用程序开发的重要阶段。

开发人员、测试人员和最终用户在测试流程的任何阶段都可以检测和提交缺陷。

使用QualityCenter，可以提交在应用程序中检测到的缺陷，并对这些缺陷进行跟踪，直到它们被修复。

缺陷跟踪主要包括以下部分：

添加新缺陷—〉审阅新缺陷—〉修复打开的缺陷—〉测试新的应用程序内部版本—〉分析缺陷数据

三、开发人员使用指南

1.访问http:

//192.168.0.120:

8080/qcbin

2.登录

点击QualityCenter进入登录界面

用户名：

由个人姓的拼音全拼和名的拼音首字母组成

密码：

默认为空

3.修改个人信息

点击页面右上角的工具——自定义——更改用户属性

在此页面进行密码修改，添加邮箱和手机号码，在描述框填上自己在本项目中负责的模块。

4.缺陷模块使用

4.1一个缺陷的生命周期简单的可以分为三步：

（1）测试人员发现并提交一个缺陷。

（2）开发人员查看缺陷，并作出处理，然后改变缺陷状态。

（3）测试人员进行验证，决定关闭或者重新打开。

4.2开发人员处理缺陷的流程：

（1）查看缺陷：

开发人员在接到测试人员报告的缺陷后，第一件要做的事情是仔细阅读摘要和描述部分，确认自己理解了缺陷所描述的情况后，再决定是否做修改。

还有一种情况测试人员的描述有歧义或者根本不清楚，这时候开发人员可以在注释中说明此情况（请注意此时不必修改缺陷的状态），接着处理下面缺陷。

把所有不清楚的缺陷列出来，当面跟测试人员沟通。

（2）重现缺陷：

测试人员提出的缺陷都是在测试环境下发现的。

而开发人员本地都有自己的一套测试环境，对于每个缺陷，开发人员都必须首先本地的测试环境中重现。

如果无法重现，最有可能的问题是代码不同步。

如果可以重现，那么需要做的事情就是定位并修改了。

（3）处理缺陷：

对于决定修改的缺陷，开发人员需要在本地测试通过后并保证本地编译通过后修改缺陷的状态为“已修复”；

对于一些不影响用户使用的缺陷，经过与PM、测试人员沟通后可以把状态修改为“下一版本修复”；

对于测试人员错误提交的缺陷，将其状态修改为“不是问题”。

这类缺陷是不会统计到项目的缺陷数中的。

注：

1.由PM将缺陷分配给相应开发人员；

2.开发人员可以将缺陷状态改为被拒绝、延期修复、已修复。

如果拒绝或者延期修复缺陷请在注释里面说明原因。

同时建议将状态修改为已修复时，在备注中说明下什么原因导致该缺陷，修改了什么地方，可能关联到什么模块等信息，方便测试人员验证缺陷，同时也防止开发人员下次犯同样错误。

4.3缺陷管理流程

缺陷管理主要是对缺陷的流转控制，测试人员将发现的缺陷提交到QC上进行跟踪，项目经理将缺陷分配给相应的开发人员进行缺陷修改；

开发人员将缺陷修改后把缺陷状态置为已修复，等已修复缺陷集成到新版本发布后，测试人员对已修复的缺陷进行回归测试；

对于回归测试未通过的缺陷要将状态置为修复失败，等开发人员修复后进行重测直到关闭为止；

当开发人员认为提交的缺陷不为缺陷时可以将缺陷拒绝，但必须注释拒绝原因；

某些缺陷在改版本不需要修复时可以置为延期修复进行后续跟踪；

除了被拒绝和延期修复的缺陷状态外，其它缺陷的最终状态都为关闭状态。

四、测试人员使用计划

测试人员针对堡垒机按功能模块分析了需求，如有任何需求变动都应该通知测试人员修改需求，以便测试可以100%覆盖。

建立需求之后转换为测试计划，在测试计划上测试人员编写测试用例。

针对堡垒机，我们现阶段主要做功能性配置测试，验证堡垒机的功能实现情况。

对界面等地方提出优化性建议。

公共用例主要针对各个模块均涉及的功能进行测试，如翻页，注册用户等。

测试用例对应覆盖需求。

后期在功能测试完毕以后，还有安全测试、兼容性测试等方面的内容。

测试人员在缺陷模块中提交缺陷，同时也和对应测试计划和需求相对应。

五．建议

QC的使用需要开发人员和测试人员的共同协作完成，缺陷的合理管理和修复可以完善软件，提高客户满意度。

测试人员尽可能完善测试用例，提交所有缺陷，用简短准确的文字描述，并附上截图或附件在最大程度上能重现缺陷，便于开发人员理解。

开发人员在时间允许的情况下尽可能修复提交的缺陷，修复或者拒绝修复都应在注释里详细填写，以供其他人员详细查阅。