CQ缺陷管理标准规范.docx

1
1.1 缺点统计信息
对缺点描述包含以下内容：
可追踪信息
缺点ID
唯一缺点ID，能够依据该ID追踪缺点
缺点基础信息
缺点状态
缺点状态，分为11种（见3.2.8节）
标 题
对缺点简单描述
缺点类型
缺点所属类型（见3.2.1节）
严重程度
缺点严重程度，通常分为“致命”、“严重”、“通常”、“轻微”和“其它”五种(见3.2.2节)
缺点起源
引入缺点开发阶段（见3.2.3节）
发觉阶段
发觉缺点时所属阶段（见3.2.4节）
重现步骤
重现缺点步骤
现象描述
对缺点具体描述；因为对缺点描述具体程度直接影响开发人员对缺点修改，描述应该尽可能具体
内部版本号
发觉缺点时产品内部版本号
外部（正式）版本号
公布给用户使用版本号。
修复责任人
在缺点提交后，由项目经理/开发经理指定修复缺点责任人
修复期限
项目经理/开发经理指定修复缺点截止日期
优先级
缺点紧急程度，修复优先级，从1－3，1是优先级最高等级，3是优先级最低等级(见3.2.6节)
修复描述
对修复内容(将什么改成什么)描述，假如对代码进行了修改，要求在此处表现出修改
处理方案
排除缺点处理方案类型（见3.2.7节）
排除阶段
修复缺点时所属阶段(见3.2.5节)
估量工时
估量修复该缺点所需工时
实际工时
修复该缺点实际使用工时
工作分数
缺点关闭后，项目经理/开发经理评定修复缺点所花工作量和修复缺点工作质量
工作量系数
工作质量系数
工作分数评定描述
项目经理/开发经理对缺点修复工作量和工作质量评定给必需解释说明
1.1.1 缺点类型
#
缺点类型
具体类型
1
功效性
l 展现层错误、未实现、未容错
l 控制层错误、未实现、未容错
l 业务层错误、未实现、未容错
l 数据层错误、未实现、未容错
l 功效实现不完整
l 功效实现错误
2
数据类
l 数据不一致
l 数据不完整
l 数据反复
l 信息填充错误
3
易用性
l 业务步骤操作繁琐
l 界面布局不合理
l 操作不习惯
l tab键次序不合理
l 尽可能确保一屏能显示，横向滚动条尽可能避免，违反此规范缺点
l 提醒信息不充足，或不友好，甚至错误提醒
l 按钮摆放位置不符合正常习惯
l 设计图标，展示不符合常规，给人误解
l 布局设计不合理（静态页面显示）
l 风格不统一
l 图片、色调不符合业务系统要求
4
可维护性
l 系统故障恢复困难
l 系统升级操作困难
5
其它（性能、可靠性、可扩展性等）
l 系统响应时间差
l 并发处理性能差
l 过负荷处理处理机制差
1.1.2 严重程度
#
严重程度
描述
1
致命
致命是指系统任何一个关键功效完全丧失，或用户数据受到破坏，造成系统瓦解、悬挂、死机或危机人身安全。
l 因为程序所引发死机,非法退出
l 死循环
l 造成数据库发生死锁
l 数据通讯错误
l 数据流步骤上严重数值计算错误
l 产品设计存在严重安全问题，漏洞被利用后可能造成系统瘫痪、数据丢失或隐私泄露等问题
l 存在严重性能问题，造成数据库或应用服务器压力过大，造成生产不能正常进行
2
严重
关键功效未实现或和产品需求规格书不符：
l 功效不符
l 数据流错误，如不能保留数据
l 程序接口错误
l 数据流步骤上轻微数值计算错误
l 性能如内存溢出、响应时间超长
l 程序正常输入报错无结果或coredump
3
通常
次要功效未实现或和产品需求规格书不符：
l 界面错误(具体文档)
l 打印内容、格式错误
l 简单输入限制未放在前台进行控制
l 删除操作未给出提醒、功效按钮不许可使用时没有置灰或给出提醒信息
l JavaScript错误
l 页面跳转错误
l 非数据流步骤上数值计算错误
l 非数据流功效提交失败
l 长时间操作未给用户进度提醒（超出10秒）
l 界面操作以后，没有刷新功效
l 前后台不能联调（如前台插入数据不能满足后台程序需求）
l 界面没有提供不影响生产功效（如排序、分页、小计、总计等）
l 存在必填项冗余字段或内容
4
轻微
装饰性问题：关键是界面方面问题，如错别字，提醒信息不正确：
l 辅助说明描述不清楚、提醒信息不正确
l 显示格式不规范
l 长时间操作未给用户进度提醒（少于10秒）
l 提醒窗口文字未采取行业术语
l 可输入区域和只读区域没有显著区分标志
l 系统处理未优化
l 脚本或说明文档未提供或提供错误
l 界面美观性问题
l 显著及常见操作方便或习惯性问题
5
其它
测试提议
1.1.3 缺点起源
#
缺点起源
具体起源
1
需求
l 业务/用户需求描述错误
l 业务/用户需求描述不清楚
l 业务/用户需求遗漏
l 需求规格描述错误
l 需求规格描述不清楚
l 需求规格需求遗漏
l 需求规格和业务/用户需求不符
2
设计
l 系统框架存在缺点
l 系统采取组件存在缺点
l 模块间存在高耦合性（划分不清楚）
l 接口设计错误
l 接口设计描述不清楚
l 数据库设计不合理
l 设计和SRS不一致
3
编码
l 编码和设计不一致
l 变量赋值类错误
l 比较表示式错误
l 变量溢出
l 循环条件错误
l 日志格式或内容不符合要求
l SQL语句错误
l SQL语句不可用（存在性能问题等）
l 界面展现错误，如：拼写、标点符号、打字
l 脚本不全，配置错误，提供给测试部作系统测试文档不全
4
测试
l 测试用例跟SRS不一致
l 修改回归缺点引发
l 测试环境原因（测试环境搭建错误）
1.1.4 发觉阶段
#
发觉阶段
描述
1
需求阶段
在需求阶段发觉缺点
2
设计阶段
在设计阶段发觉缺点
3
编码阶段
在编码阶段发觉缺点
4
集成测试阶段
在集成测试阶段发觉缺点
5
系统测试阶段
在系统测试阶段发觉缺点
6
确定测试阶段
在确定测试阶段发觉缺点
7
运行维护阶段
在运行维护阶段发觉缺点
1.1.5 排除阶段
#
排除阶段
描述
1
需求阶段
在需求阶段排除缺点
2
设计阶段
在设计阶段排除缺点
3
编码阶段
在编码阶段排除缺点
4
集成测试阶段
在集成测试阶段排除缺点
5
系统测试阶段
在系统测试阶段排除缺点
6
确定测试阶段
在确定测试阶段排除缺点
7
运行维护阶段
在运行维护阶段排除缺点
1.1.6 优先级
#
优先级
描述
1
1-立即处理
缺点必需被立即处理。
2
2-正常
缺点需要正常排队等候处理或列入软件公布清单。
3
3-不紧急
缺点能够在方便时处理
1.1.7 处理方案
#
处理方案
描述
1
Duplicate
提交缺点和以前某个缺点属于同一个缺点，处理方案直接复制
2
Enhancement Request
提交缺点属于需求功效增强
3
Fixed
修正BUG（直接修复）
4
Fixed Indirectly
提交缺点是由其它缺点引发（间接修复）
1.1.8 缺点状态
#
缺点状态
描述
1
Submitted
已提交缺点
2
Ready
已指派修复责任人缺点
3
Canceled
已取消缺点(提交后经评审不需要修复或不是缺点)
4
Postponed
已推迟缺点，暂不修复
5
Active
已打开缺点，正在处理中
6
Resolved
已处理缺点
7
Rejected
已拒收缺点（已处理缺点经验证不经过）
8
Validated
已验证经过缺点
9
Closed
已关闭缺点
10
Subrejected
已拒绝测试组提交缺点（项目接口人经审核后，发觉提交缺点单有问题，需要测试组修改.
11
Unactived
开发人员拒绝项目接口人分配缺点。
1.2 缺点管理步骤
Rational ClearQuest使用一条条统计来跟踪缺点，每一条缺点统计全部会经历不一样状态，比如已经指派状态、已经处理状态、关闭状态等。统计经过不一样动作在各个状态间转换，以下图：

l 测试人员不能处理Subrejected状态缺点需要由产品经理得出处理方案。
l 有效缺点：除cancelled状态以外缺点。 无效缺点：cancelled状态缺点。遗留缺点：除closed、cancelled状态以外缺点。
l 测试人员包含以下人员
u 进行单元测试、代码走读和集成测试开发人员
u 进行系统测试测试人员
u 进行确定测试实施人员
u 对上线后系统进行维护维护人员

1.2.1 提交(Submit)
一个缺点，必需经过提交（Submit），才能够成为ClearQuest数据库中一条统计，从而才能够对其进行跟踪管理。
1.2.2 拒绝提交缺点（Subreject）
提交缺点由项目接口人审核，发觉测试人员提交缺点单描述不清楚或不正确，需要打回给测试人员进行修改。
1.2.3 重新提交（Resubmit）
对于被项目接口人打回缺点，测试人员修改完缺点单后，重新提交给项目接口人。
1.2.4 指派(Assign)
由项目接口人指派（Assign）修复责任人，并明确修复期限。
1.2.5 打开(Open)&缺点排除(Resolve)
修复责任人打开（Open）缺点统计开始修复工作，在缺点排除（Resolve）后，填写处理方案、修复描述等信息将缺点提交验证人，等候验证。
1.2.6 验证(Validate)
已修复缺点，经测试人员验证（Validate）经过；如验证不经过（缺点未消除），验证人将此缺点统计退回（Reject）给修复责任人。
1.2.7 再次打开(Re_Open)
已修复缺点能够被修复责任人在缺点被验证之前再次打开（Re_Open）。
1.2.8 评定(Audit)
最终，测试人员对已验证经过缺点进行工作量和工作质量评定（Audit），评定完成，缺点自动关闭。
1.2.9 推迟（Postpone）
项目接口人审核发觉该缺点需要暂停修复，并明确修复期限。
1.2.10 取消（Cancel）
Subrejected状态缺点，测试人员确定不是缺点，则能够实施取消操作。Subrejected状态缺点，测试人员不能确定是否缺点，由产品经理确定不是缺点，也能够实施取消操作。
1.3 缺点提交规范
1、标题 (headline)：简练、正确，完整，揭示错误实质，统计缺点或错误出现位置。描述要正确反应错误本质内容，简短明了。
2、明确指明错误表现类型：功效、界面、性能、其它。
3、每一个步骤尽可能只统计一个操作，确保简练、条理井然，轻易反复操作步骤。
4、确定步骤完整，正确，简短，确保快速正确反复错误，“完整”即没有缺漏，“正确”即步骤正确，“简短”即没有多出步骤。
5、依据缺点或错误类型，选择图象捕捉方法。为了直观观察缺点或错误现象，通常需要附加缺点或错误出现界面，以位图形式作为附件附着在统计“附件”部分。为了节省空间，又能真实反应缺点或错误本质，能够捕捉缺点或错误产生时全屏幕，活动窗口和局部区域。
6、附加必需特殊文档和个人提议和注解。假如打开某个特殊文档而产生缺点或错误，则必需附加该文档，从而能够快速再现缺点或错误；为了使缺点或错误修正者深入明确缺点或错误表现，能够附加个人修改提议或注解。
7、每条错误汇报只包含一个错误。每条错误汇报只包含一个错误，能够使错误修正者快速定位一个错误，校验者每次只校验一个错误是否已经正确修正。
8、检验拼写和语法错误。在提交每条缺点或错误之前，检验拼写和语法，确保内容正确，正确描述错误。
9、版本号：缺点版本号研发团体、实施团体应该保持一致，根据企业要求：如MMS-SX-V2.0.0.0 (MMS：系统名称、SX:地域简称、V2.0.0.0：回归版本号、V2.0.0外部版本号)
10、尽可能使用业界常见表示术语和表示方法。使用业界常见表示术语和表示方法，确保表示正确，表现专业化。
11、尽可能使用短语和短句，避免复杂句型句式。

实例：
1、 基础信息

2、 缺点步骤描述

3、 附件信息
附件信息可依据缺点需要进行提交。
1.4 缺点数据统计分析
缺点数据统计分析是缺点跟踪管理内容之一。能够经过选择不一样研究对象，如缺点状态、严重程度、优先级、提交人、修复责任人、验证人、处理方案和处理时间等建立查询、统计缺点数据。
项目管理人员应生成缺点数据统计图表，对统计结果进行分析。通常可建立缺点数据统计图表包含缺点趋势图、缺点分布图、打开关闭曲线、关闭周期曲线、严重程度统计分布图、优先级统计分布图、缺点类型统计分布图、缺点立即处理情况统计表等。
经过建立缺点查询、统计图表，可使项目管理层从不一样角度了解目前缺点处理进度，愈加正确地度量项目标开发质量和整个开发团体，尤其是开发人员和测试人员工作效率，使项目管理工作变得愈加易于管理、富有成效。