CQ缺陷管理标准规范.docx

11.1 缺点统计信息对缺点描述包含以下内容：可追踪信息缺点ID唯一缺点ID，能够依据该ID追踪缺点缺点基础信息缺点状态缺点状态，分为11种（见3.2.8节）标 题对缺点简单描述缺点类型缺点所属类型（见3.2.1节）严重程度缺点严重程度，通常分为“致命”、“严重”、“通常”、“轻微”和“其它”五种(见3.2.2节)缺点起源引入缺点开发阶段（见3.2.3节）发觉阶段发觉缺点时所属阶段（见3.2.4节）重现步骤重现缺点步骤现象描述对缺点具体描述；因为对缺点描述具体程度直接影响开发人员对缺点修改，描述应该尽可能具体内部版本号发觉缺点时产品内部版本号外部（正式）版本号公布给用户使用版本号。修复责任人在缺点提交后，由项目经理/开发经理指定修复缺点责任人修复期限项目经理/开发经理指定修复缺点截止日期优先级缺点紧急程度，修复优先级，从13，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 程序正常输入报错无结果或coredump3通常次要功效未实现或和产品需求规格书不符：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 优先级#优先级描述11-立即处理缺点必需被立即处理。22-正常缺点需要正常排队等候处理或列入软件公布清单。33-不紧急缺点能够在方便时处理1.1.7 处理方案#处理方案描述1Duplicate提交缺点和以前某个缺点属于同一个缺点，处理方案直接复制2Enhancement Request提交缺点属于需求功效增强3Fixed修正BUG（直接修复）4Fixed Indirectly提交缺点是由其它缺点引发（间接修复）1.1.8 缺点状态#缺点状态描述1Submitted已提交缺点2Ready已指派修复责任人缺点3Canceled已取消缺点(提交后经评审不需要修复或不是缺点)4Postponed已推迟缺点，暂不修复5Active已打开缺点，正在处理中6Resolved已处理缺点7Rejected已拒收缺点（已处理缺点经验证不经过）8Validated已验证经过缺点9Closed已关闭缺点10Subrejected已拒绝测试组提交缺点（项目接口人经审核后，发觉提交缺点单有问题，需要测试组修改.11Unactived开发人员拒绝项目接口人分配缺点。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 缺点数据统计分析缺点数据统计分析是缺点跟踪管理内容之一。能够经过选择不一样研究对象，如缺点状态、严重程度、优先级、提交人、修复责任人、验证人、处理方案和处理时间等建立查询、统计缺点数据。项目管理人员应生成缺点数据统计图表，对统计结果进行分析。通常可建立缺点数据统计图表包含缺点趋势图、缺点分布图、打开关闭曲线、关闭周期曲线、严重程度统计分布图、优先级统计分布图、缺点类型统计分布图、缺点立即处理情况统计表等。经过建立缺点查询、统计图表，可使项目管理层从不一样角度了解目前缺点处理进度，愈加正确地度量项目标开发质量和整个开发团体，尤其是开发人员和测试人员工作效率，使项目管理工作变得愈加易于管理、富有成效。