1、缺陷管理指导书文件版本： V1.0 文件编号： QMS-WI-024首版发布日期： 2006-5-22 编 制： 刘洪刚审 核： 林峣 批 准： 林峣卓望数码技术（深圳）有限公司 版权所有内部资料 注意保密缺陷管理指导书第 2 页修订记录：修订版本号 修订人 修订日期 修订描述V1.0A 刘洪刚 2006-4-7 创建V1.0B 田原 2006-10-19 增加第 6、7、8 章及附录一缺陷管理指导书第 3 页目 录1 目的与范围 .42 定义与缩略语 .42.1 定义 42.2 缩略语 43 控制机制 .54 缺陷级别 .55 缺陷状态 .65.1 状态定义 65.2 状态迁移 66 相关工
2、具/表格/记录 .8附录：引用 .8缺陷管理指导书第 4 页1 目的与范围本文描述 Test Director 和 ClearQuest 中缺陷管理的相关内容（下面简称缺陷管理办法） ，为参与缺陷管理活动的人员提供信息和指导，以保证开发的产品满足功能、质量等方面的配置属性。文件提供缺陷管理的一般性指导，不同产品可以进行裁剪和修订，制订符合具体产品的缺陷管理规范，产品的缺陷管理规范必须经质量管理部审核批准后才能实施。本文描述的缺陷管理规范适用于卓望公司的所有产品的软件测试工作。主要的使用人员为系统测试部和产品线。2 定义与缩略语2.1 定义缺陷：存在于一个已交付产品中的异常现象或缺陷。这样的例子
3、包括在生命周期的早期阶段发现的疏忽和有缺陷的地方，以及在一个足以成熟的用于测试或操作的软件中包含的错误的症状。缺陷可以是任何你想跟踪并解决的问题。2.2 缩略语缩写 中文名称CCB 变更控制委员会CMO 配置管理员PQA (产品)质量保证人员RDPDT 产品开发代表PDT 产品开发团队SWE 软件开发工程师VP 副总SEPG 软件过程工程组QM 质量管理部缺陷管理指导书第 5 页HLD 高层设计LLD 底层设计SDE 软件开发工程师STE 软件测试工程师TL-D 开发组长TL-T 测试组长3 控制机制测试 TWG 、系统测试部负责维护本指导书， SEPG 组长审核、质量部主管 VP 签发本指导
4、书。4 缺陷级别严重级别 严重程度1-Very Low 对系统的改进建议2-Low 微小的错误，不会影响系统的功能风格不统一，包括相近流程的界面布局相异，相同的问题点提示信息相异，但对用户的使用方法和使用习惯不造成影响（需求中明确的风格要求除外）该问题是一个不准确或容易误解的行为，但不会引起下面（2、3、4、5 级别）列出的问题3-Medium 该问题增加了安装、测试或用户操作的复杂度或成本该问题轻微降低了系统的性能，但系统仍然能工作非核心功能实现不完整或不正确，但对系统影响很小，系统仍然能工作业务流程对应的功能未实现，但是有替代方法解决，不影响实际的使用部署文档描述不明确，增加部署难度4-H
5、igh 该问题会严重降低系统的性能需求实现不完整，设计实现上的缺陷，且无替代方法，如：设计了 3 条路上山，但是实际只有一条可以上该问题不符合需求规格书数据库建库（或升级）脚本错误，遗失表或字段或回滚脚本，影响系统的正常部署和运行数据库存储过程不能正常执行对应的设计功能配置项设计错误，无法正常配置，或配置后，测试中出现与配置相关的错误部署文档错误，导致部署失败缺陷管理指导书第 6 页与其它网元的接口，调用或提供错误5-Very High 提交物缺失，导致测试、部署和维护无法正常进行需求未实现正常的操作，导致系统（进程）崩溃系统不能启动或启动后无法正常工作系统（进程）经常自动崩溃（至少一天一次）
6、5 缺陷状态5.1 状态定义NEW：新增的缺陷OPEN：开发人员处理中的缺陷FXIED：开发人员已修复的缺陷VERIFIED：测试人员已验证的缺陷SUSPENDED：开发人员挂起暂不解决的缺陷REOPEN：测试人员重新打开的缺陷REJECTED：开发人员拒绝的缺陷CLOSED：关闭的缺陷5.2 状态迁移N E W O P E N C L O S E DR E O P E NS U S P E N D E DF I X E D V E R I F I E DR E J E C T E DT L - DO p e n D e f e a tS D EF i x D e f e a tT L - D
7、S u s p e n d D e f e a tT L - DR e j e c t D e f e a tS T ER e o p e n D e f e a tS T EV e r i f y D e f e a tT L - TC l o s e D e f e a tS D EF i x D e f e a tT L - DR e j e c t D e f e a tT L - DS u s p e n d D e f e a tT L - DS u s p e n d D e f e a tT L - DO p e n D e f e a tS T EO p e n D e f
8、e a t缺陷管理指导书第 7 页动作 1：缺陷提交（Submit Defeat）输入：发现缺陷输出：缺陷已创建，缺陷状态变成 NEW。角色和活动：STE-测试人员提出缺陷并说明其类型及评估。必须给出缺陷的严重级及优先级以及基本的描述。具体可以参考缺陷中的缺陷提交表单（见附件） 。如果测试人员可以将此缺陷定位到某开发人员，则此开发就已经获得授权进行修改了；如果不能，则需要提交给项目经理或开发组长，项目经理或开发组长对问题做进一步的分析，然后授权某开发人员修改。动作 2：缺陷打开（Open Defeat）输入：已创建的缺陷请求。输出：项目经理或开发组长对这个缺陷进行初步的接纳和确认，状态由 NE
9、W 变成OPEN。角色和活动：PM/TL-D-项目经理或开发组长对这个变更进行初步的接纳和确认，表示其已经进入处理阶段。动作 3：缺陷拒绝（Reject Defeat）输入：已提交缺陷请求输出：项目经理或开发组长拒绝此缺陷，状态由 OPEN 变成 REJECTED。角色和活动：PM/TL-D-项目经理或开发组长对已提交的缺陷进行评估后,认为有理由拒绝,并且将理由写在表单上，由测试人员确认，如果存在争议，由产品经理、项目经理、测试主管，直至 CCB 对此进行进一步评估。动作 4：已拒绝的缺陷重新打开（Reopen Defeat）输入：项目经理或开发组长已拒绝的缺陷请求输入准则：评估后确认需要修复
10、的已拒绝的缺陷请求输出：测试人员重新打开已拒绝的缺陷，变更状态由 REJECTED 变成 REOPEN。角色和活动：STE-对已拒绝的缺陷进行评估后 ,认为有必要修复此缺陷,测试人员将评估结果写在表单上并将缺陷打开，开发人员重新处理此缺陷。动作 5：缺陷挂起（Suspend Defeat ）输入：已提交的缺陷请求输出：项目经理或开发组长暂时挂起此缺陷，缺陷状态由 OPEN/REOPEN/NEW 变成 SUSPENDED。角色和活动：PM/TL-D-项目经理或开发组长评估已提交的缺陷，如果认为此缺陷由于某些原因目前还不能完成，可以注明挂起原因，并将此缺陷的状态变为挂起。在今后的缺陷回顾报告见附件
11、 和缺陷回顾会议 见附件上要重点进行讨论，来决定此挂起的缺陷将在什么时候解决。动作 6：缺陷重启动（Reopen Defeat）输入：项目经理或开发组长已挂起的缺陷请求输出：项目经理或开发组长重新启动已挂起缺陷，状态由 SUSPENDED 变成OPEN。角色和活动：缺陷管理指导书第 8 页PM/TL-D-项目经理或开发组长评估曾经挂起的缺陷，如果认为此缺陷有条件或必需重新给予考虑可以将此缺陷重新启动。动作 7：缺陷任务执行（Fix Defeat）输入：项目经理或开发组长已分配的缺陷修复任务输出：开发人员完成任务，缺陷状态由 OPEN/REOPEN 变成 FIXED。角色和活动：SDE-开发人员
12、根据项目经理或开发组长分配/授权的任务以及相应的资源环境，进行变更的完成，并提交该完成的任务，等待验证。对动作 7 的说明：如果经 CCB 确认此缺陷设计到对需求，高层设计，底层设计修改的话，那么后续流程请按照变更控制管理规范 。动作 8：缺陷任务验证通过（Verify Defeat）输入：被提交了的已完成的缺陷修复任务。输出：验证变更任务成功，缺陷状态由 FIXED 变成 VERIFIED。角色和活动：STE-测试人员对提交的已完成的缺陷任务进行充分的验证，如果此提交的版本成功完成了缺陷修改请求里的要求，则视为验证通过。动作 9：缺陷修复任务验证拒绝（Reopen Defeat）输入：被提交
13、了的已完成的缺陷修复任务。输出：验证缺陷修复失败，缺陷状态由 FIXED 变成 REOPEN。角色和活动：STE-测试人员对提交的已完成的缺陷修复任务进行充分的验证，如果此提交的版本没有成功完成缺陷修复请求里的要求，则视为验证失败，并拒绝之。动作 10：验证通过的缺陷修改请求关闭（Close Defeat）输入：已经成功被验证的缺陷修复任务。输出：将已成功被验证的缺陷修复任务关闭，缺陷状态由 VERIFIED 变成CLOSE。角色和活动：TL-T-测试主管对已成功被验证的缺陷修复请求进行审查，如果没有其他问题就可以将此缺陷修复请求予以关闭。6 缺陷类型缺陷类型 类型描述功能性 1、因产品需求规
14、格说明书中业务特性描述缺失、不清晰或错误而导致的缺陷；2、因软件需求规格说明书中功能性需求特性描述缺失、不清晰或错误导致的缺陷；3、因架构设计说明书中对功能性设计的缺失、不清晰或错误引发的缺陷。4、指因版本发布测试案例对功能性测试案例的缺失或描述不清晰或错误引起的缺陷；5、指因系统测试案例中对功能性案例缺失或描述不清晰或错误引缺陷管理指导书第 9 页起的缺陷；6、指因用户文档对产品功能描述的缺失或描述不清晰或错误引起的缺陷。非功能性 1、 因产品需求规格说明书中的某个非功能性需求缺失或描述不清晰或错误引起的缺陷；2、 因软件需求规格说明书中的某个非功能性需求缺失或描述不清晰或错误引起的缺陷；3
15、、 因架构设计说明书中对非功能特性设计的缺失、不清晰或错误引发的缺陷；4、 指因版本发布测试案例对非功能性测试案例的缺失或描述不清晰或错误引起的缺陷；5、 指因系统测试案例中对非功能性案例缺失或描述不清晰或错误引起的缺陷；6、 指因用户文档对产品功能描述的缺失或描述不清晰或错误引起的缺陷。产品间接口 1、 因产品需求规格说明书中对外部接口描述缺失或描述不清晰或错误引起的缺陷；2、 因软件需求规格说明书中对外部接口描述缺失或描述不清晰或错误引起的缺陷；3、 因架构设计说明书中对产品间接口设计的缺失、不清晰或错误引发的缺陷；4、 因高层设计说明书中因模块对外部系统提供的接口描述缺失或不清晰或错误引
16、起的缺陷；5、 指因版本发布测试案例对产品间接口测试案例的缺失或描述不清晰或错误引起的缺陷；6、 指因系统测试案例对产品间接口测试案例的缺失或描述不清晰或错误引起的缺陷；7、 指因集成测试案例对产品间接口测试案例的缺失或描述不清晰或错误引起的缺陷；8、 指因用户文档对产品间接口描述的缺失或描述不清晰或错误引起的缺陷。用户界面(UI) 1、 因产品需求规格说明书的总体界面描述缺失或描述不清晰或错误引起的缺陷；2、 因软件需求规格说明书的总体界面描述缺失或描述不清晰或错误引起的缺陷；3、 指因版本发布测试案例对用户界面测试案例的缺失或描述不清晰或错误引起的缺陷；4、 指因系统测试案例对用户界面测试
17、案例的缺失或描述不清晰或错误引起的缺陷；5、 指因用户文档对用户界面描述的缺失或描述不清晰或错误引起的缺陷。数据定义 1、 因架构设计中关于数据模型的设计错误/缺失/ 不清晰引发的缺陷；2、 因高层设计中关于数据结构以及数据库结构相关内容的错误/缺陷管理指导书第 10 页缺失/不清晰引发的缺陷；3、 因底层设计说明书中因局部数据定义缺失或不清晰或错误引起的缺陷；4、 编码中因数据定义缺失或错误引起的缺陷。5、 指因集成测试案例对数据定义测试案例的缺失或描述不清晰或错误引起的缺陷；6、 指因单元测试案例对数据定义测试案例的缺失或描述不清晰或错误引起的缺陷。组件/模块设计 1、 因架构设计说明书中
18、对子系统或组件设计的缺失、不清晰或错误引发的缺陷；2、 因高层设计说明书中因模块设计缺失或不清晰或错误引起的缺陷；3、 因集成测试案例中因模块设计的测试案例缺失或不清晰或错误引起的缺陷。逻辑 1、 因高层设计说明书中关于模块状态/模块交互等等逻辑设计缺失/错误/不清晰引发的缺陷；2、 因底层设计说明书中因函数逻辑描述缺失或不清晰或错误引起的缺陷；3、 代码实现过程中未能按底层设计实现程序逻辑引发的缺陷；4、 因集成测试案例中关于模块状态/模块交互等等逻辑设计的测试案例缺失/错误/不清晰引发的缺陷；5、 因单元测试案例中因函数逻辑描述的测试案例缺失或不清晰或错误引起的缺陷。异常处理 1、 底层设
19、计中对于异常处理的错误/缺失/ 不清晰引发的缺陷；2、 编码中因对异常处理的缺失或错误引起的缺陷；3、 因单元测试案例中对于异常处理的案例错误/缺失/ 不清晰引发的缺陷；4、 因用户文档对异常操作描述的缺失或描述不清晰或错误引起的缺陷。编码规范 1、编码中因不遵守编码规范或编码规范不合理引起的缺陷。算法 1、 因底层设计说明书中因对算法描述缺失或不清晰或错误引起的缺陷；2、 编码中因算法错误引起的缺陷；3、 因单元测试案例中因对算法案例缺失或不清晰或错误引起的缺陷。数据处理 1、 底层设计中设计的数据处理方案错误/缺失/ 不清晰导致的缺陷；2、 编码中因数据处理缺失或错误引起的缺陷；3、 因单
20、元测试案例中对数据处理方案的测试案例错误/缺失/ 不清晰导致的缺陷。组件/模块间接口与实现 1、 架构设计中对组件间接口描述缺失或错误或不清晰导致的缺陷；2、 高层设计说明书中因模块间接口描述缺失或不清晰或错误引起的缺陷；缺陷管理指导书第 11 页3、 底层设计说明书中因单元对外接口的描述或接口函数描述缺失或不清晰或错误引起的缺陷；4、 编码中因接口实现部分的缺失或错误引起的缺陷；5、 因单元测试案例中因单元对外接口的案例的缺失或不清晰或错误引起的缺陷。7 缺陷根源缺陷根源 根源描述产品需求 指因产品需求规格说明书的内容缺失、不清晰或错误在本交付物或后续交付物中引起的缺陷；软件需求 指因软件需
21、求规格说明书的内容缺失、不清晰或错误在本交付物或后续交付物中引起的缺陷；架构设计 指因架构设计说明书的内容缺失、不清晰或错误在本交付物或后续交付物中引起的缺陷；高层设计 指因高层设计说明书的内容缺失、不清晰或错误在本交付物或后续交付物中引起的缺陷；底层设计 指因底层设计说明书的内容缺失、不清晰或错误在本交付物或后续交付物中引起的缺陷；编码 指因编码的缺失或错误在本交付物或其他交付物中引起的缺陷；版本发布测试案例 指因版本发布测试案例的缺失、不清晰或错误在本交付物中引起的缺陷；系统测试案例 指因系统测试案例的缺失、不清晰或错误在本交付物中引起的缺陷；集成测试案例 指因集成测试案例的缺失、不清晰或
22、错误在本交付物中引起的缺陷；单元测试案例 指因单元测试案例的缺失、不清晰或错误在本交付物中引起的缺陷；用户文档 指因用户文档的内容缺失、不清晰或错误在本交付物中引起的缺陷；其他 非上述根源引起的缺陷缺陷类型与缺陷根源的对应关系见附录一。8 缺陷模式模式 模式描述缺失 指因文档的内容描述或代码实现的缺失引起的缺陷不清晰 指因文档的内容描述不清晰引起的缺先错误 指因文档的内容描述或代码实现的错误引起的缺陷缺陷管理指导书第 12 页9 相关工具/表格/记录无。附录：引用9.1 附录一：缺陷类型及缺陷根源的对应关系。注：打指在此类型缺陷由对应的根源产生，缺陷根源与缺陷类型交叉处无者即该类缺陷不可能由相应根源产生。根源类型 产品需求 软件需求 架构设计 高层设计 底层设计 编码版本发布测试案例系统测试案例集成测试案例单元测试案例 用户文档 其他功能性 非功能性 产品间接口 用户界面(UI) 数据定义 组件/模块设计 逻辑 异常处理 编码规范 算法 数据处理 缺陷管理指导书第 14 页组件/模块间接口与实现
