CQ缺陷管理规范

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节) 修复描述 对修复内容(将什么改成什么)的描述，如果对代码进行了修改，要求在此处体现出修改 解决 方案 气瓶 现场处置方案 .pdf气瓶 现场处置方案 .doc见习基地管理方案.doc关于群访事件的化解方案建筑工地扬尘治理专项方案下载 排除缺陷的解决方案类型（见3.2.7节） 排除阶段 修复缺陷时所属的阶段(见3.2.5节) 估计工时 估计修复该缺陷所需的工时 实际工时 修复该缺陷实际使用的工时 工作分数 缺陷关闭后，项目经理/开发经理评估修复缺陷所花的工作量和修复缺陷的工作质量 工作量系数 工作质量系数 工作分数评估描述 项目经理/开发经理对缺陷修复工作量和工作质量的评估给予必要的解释说明 1.1.1 缺陷类型 # 缺陷类型 详细类型 1 功能性 ● 展现层错误、未实现、未容错 ● 控制层错误、未实现、未容错 ● 业务层错误、未实现、未容错 ● 数据层错误、未实现、未容错 ● 功能实现不完整 ● 功能实现错误 2 数据类 ● 数据不一致 ● 数据不完整 ● 数据重复 ● 信息填充错误 3 易用性 ● 业务流程操作繁琐 ● 界面布局不合理 ● 操作不习惯 ● tab键顺序不合理 ● 尽量保证一屏能显示，横向滚动条尽量避免，违反此规范的缺陷 ● 提示信息不充分，或者不友好，甚至错误提示 ● 按钮摆放位置不符合正常习惯 ● 设计图标，展示不符合常规，给人误解 ● 布局设计不合理（静态页面显示） ● 风格不统一 ● 图片、色调不符合业务系统要求 4 可维护性 ● 系统的故障恢复困难 ● 系统的升级操作困难 5 其他（性能、可靠性、可扩展性等） ● 系统的响应时间差 ● 并发处理性能差 ● 过负荷处理处理机制差 1.1.2 严重程度 # 严重程度 描述 1 致命 致命是指系统任何一个主要功能完全丧失，或用户数据受到破坏，造成系统崩溃、悬挂、死机或者危机人身安全。 ● 由于程序所引起的死机,非法退出 ● 死循环 ● 导致数据库发生死锁 ● 数据通讯错误 ● 数据流环节上严重的数值计算错误 ● 产品设计存在严重的安全问题，漏洞被利用后可能导致系统瘫痪、数据丢失或隐私泄露等问题 ● 存在严重的性能问题，导致数据库或者应用服务器压力过大，导致生产不能正常进行 2 严重 主要功能未实现或与产品需求规格书不符： ● 功能不符 ● 数据流错误，如不能保存数据 ● 程序接口错误 ● 数据流环节上轻微的数值计算错误 ● 性能如内存溢出、响应时间超长 ● 程序正常输入报错无结果或coredump 3 一般 次要功能未实现或与产品需求规格书不符： ● 界面错误(详细文档) ● 打印内容、格式错误 ● 简单的输入限制未放在前台进行控制 ● 删除操作未给出提示、功能按钮不允许使用时没有置灰或给出提示信息 ● JavaScript错误 ● 页面跳转错误 ● 非数据流环节上的数值计算错误 ● 非数据流功能提交失败 ● 长时间操作未给用户进度提示（超过10秒） ● 界面操作之后，没有刷新功能 ● 前后台不能联调（如前台插入数据不能满足后台程序需求） ● 界面没有提供不影响生产的功能（如排序、分页、小计、总计等） ● 存在必填项冗余字段或内容 4 轻微 装饰性问题：主要是界面方面问题，如错别字，提示信息不准确： ● 辅助说明描述不清楚、提示信息不正确 ● 显示格式不规范 ● 长时间操作未给用户进度提示（少于10秒） ● 提示窗口文字未采用行业术语 ● 可输入区域和只读区域没有明显的区分标志 ● 系统处理未优化 ● 脚本或说明文档未提供或提供错误 ● 界面美观性问题 ● 明显及常用的操作方便或习惯性问题 5 其他 测试建议 1.1.3 缺陷来源 # 缺陷来源 详细来源 1 需求 ● 业务/用户需求描述错误 ● 业务/用户需求描述不清楚 ● 业务/用户需求遗漏 ● 需求规格描述错误 ● 需求规格描述不清楚 ● 需求规格需求遗漏 ● 需求规格与业务/用户需求不符 2 设计 ● 系统框架存在缺陷 ● 系统采用的组件存在缺陷 ● 模块间存在高耦合性（划分不清楚） ● 接口设计错误 ● 接口设计描述不清楚 ● 数据库设计不合理 ● 设计与SRS不一致 3 编码 ● 编码和设计不一致 ● 变量赋值类错误 ● 比较表达式错误 ● 变量溢出 ● 循环条件错误 ● 日志格式或内容不符合要求 ● SQL语句错误 ● SQL语句不可用（存在性能问题等） ● 界面展现错误，如：拼写、标点符号、打字 ● 脚本不全，配置错误，提供给测试部作系统测试的文档不全 4 测试 ● 测试用例跟SRS不一致 ● 修改回归缺陷引起 ● 测试环境原因（测试环境搭建错误） 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使用一条条的记录来跟踪缺陷，每一条缺陷记录都会经历不同的状态，例如已经指派状态、已经解决状态、关闭状态等。记录通过不同的动作在各个状态间转换，如下图： ● 测试人员不能处理的Subrejected状态的缺陷需要由产品经理得出处理方案。 ● 有效缺陷：除cancelled状态以外的缺陷。 无效缺陷：cancelled状态的缺陷。遗留缺陷：除closed、cancelled状态以外的缺陷。 ● 测试人员包括以下人员 ◆ 进行单元测试、代码走读的和集成测试的开发人员 ◆ 进行系统测试的测试人员 ◆ 进行确认测试的实施人员 ◆ 对上线后系统进行维护的维护人员 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 缺陷数据统计 分析 定性数据统计分析pdf销售业绩分析模板建筑结构震害分析销售进度分析表京东商城竞争战略分析 缺陷数据统计分析是缺陷跟踪管理的内容之一。可以通过选择不同的研究对象，如缺陷的状态、严重程度、优先级、提交人、修复责任人、验证人、解决方案和解决时间等建立查询、统计缺陷数据。 项目管理人员应生成缺陷数据统计图表，对统计结果进行分析。一般可建立的缺陷数据统计图表包括缺陷趋势图、缺陷分布图、打开关闭曲线、关闭周期曲线、严重程度统计分布图、优先级统计分布图、缺陷类型统计分布图、缺陷及时处理情况统计表等。 通过建立缺陷查询、统计图表，可使项目管理层从不同角度了解当前缺陷的解决进度，更加准确地度量项目的开发质量以及整个开发团队，尤其是开发人员和测试人员的工作效率，使项目管理工作变得更加易于管理、富有成效。