缺陷管理规程.doc

江西省通信产业服务有限公司 文件编写规范缺陷管理规程文档版本号：V1.0文档编号：江通服_TST_05 文档密级：内部公开归属部门/项目：研发部编写人：朱佳佳生效日期：2018-05-10版权信息本文件涉及之信息，属江西省通信产业服务有限公司所有。未经江西省通信产业服务有限公司允许，文件中的任何部分都不能以任何形式向第三方散发。文档修订记录版本号修订日期修订人修订说明修订状态审核日期审核人批准人V0.12018-05-02朱佳佳新增缺陷管理规程A2018-05-02熊婧汝李伟V1.02018-05-10朱佳佳评审并发布正式版本M2018-05-10熊婧汝李伟修订状态：A-增加，M-修改，D-删除日期格式：YYYY-MM-DD目录1.目的12.角色与职责13.入口准则14.输入15.主要步骤25.1.定义缺陷25.1.1 缺陷属性25.1.2 缺陷类型25.1.3 缺陷严重程度25.1.4 缺陷优先级35.1.5 缺陷状态35.1.6 缺陷发现的阶段45.1.7 缺陷引入的阶段45.2.缺陷管理流程45.3.缺陷报告65.4.遗留缺陷跟踪75.5.缺陷分析76.输出77.出口准则78.引用文档79.使用模板81. 目的 缺陷管理的最终目标是最大限度地减少缺陷的出现率，从而提高软件产品的质量。细分为：1) 从缺陷发生到结束的全生命周期进行跟踪管理，尽可能发现所有的缺陷，确保每个被发现的缺陷都能够被解决；2) 收集缺陷数据并根据缺陷趋势图识别测试过程的阶段；可以通过缺陷趋势图来确定测试过程是否结束；3) 在已收集到的缺陷数据的基础上进行统计分析。总结缺陷出现的原因、类型和规律，采取相应措施避免该类型缺陷再次出现，并在开发过程的早期阶段予以确定，起到缺陷预防的作用，并作为组织的过程财富。本规程规定了缺陷管理流程以及缺陷统计分析要求，项目组必须严格遵循本规程要求保证在较短的时间内高效率地解决所有缺陷，缩短软件开发测试进程，提高软件质量，减少开发和维护成本。2. 角色与职责角色职责项目经理评审缺陷测试工程师提交，验证缺陷软件工程师修改缺陷CM工程师在缺陷管理中受控已解决的缺陷代码3. 入口准则l 缺陷发生时4. 输入无5. 主要步骤5.1. 定义缺陷是对软件产品预期属性的偏离现象，它包括检测缺陷和残留缺陷。每一个软件组织都知道必须妥善处理软件中的缺陷。这是关系到软件组织生存、发展的质量根本。5.1.1 缺陷属性属性名称描述缺陷标识缺陷标识是标记某个缺陷的一组符号。每个缺陷必须有一个唯一的标识。缺陷类型缺陷类型是根据缺陷的自然属性划分的缺陷种类。缺陷严重程度缺陷严重程度是指因缺陷引起的故障对软件产品的影响程度。缺陷优先级缺陷的优先级指缺陷必须被修复的紧急程度。缺陷状态缺陷状态指缺陷通过一个跟踪修复过程的进展情况。缺陷发现的阶段指缺陷引起的故障或事件第一次被检测到的阶段。缺陷引入的阶段指引入缺陷的阶段。5.1.2 缺陷类型缺陷类型编号缺陷类型描述10功能影响了重要的特性、用户界面、产品接口、硬件结构接口和全局数据结构。并且设计文档需要正式的变更。如逻辑，指针，循环，递归，功能等缺陷。20逻辑需要修改少量代码，如初始化或控制块。如声明、重复命名，范围、限定等缺陷。30接口与其他组件、模块或设备驱动程序、调用参数、控制块或参数列表相互影响的缺陷。40标准编码/文档的标准问题，例如缩进、对齐方式、布局、组件应用、编码和拼写错误等。50性能处理速度慢、因文件的大小而导致系统崩溃等。60语法不符合所用程序设计语言的语法规则。70设计缺陷设计错误、设计不符合用户习惯等。5.1.3 缺陷严重程度序号缺陷严重等级描述1致命缺陷数据丢失，数据计算错误、数据传递错误、对数据库造成破坏，造成操作系统或其他支撑系统崩溃、非正常关闭和非正常死机，不能执行正常工作功能或重要功能。或者危及人身安全。2严重缺陷应用系统崩溃、非正常关闭和无响应，但没有造成数据丢失。系统的主要功能不能正确实现或不完整，严重地影响系统要求或基本功能的实现，且没有办法更正。（重新安装或重新启动该软件不属于更正办法）3一般缺陷规定的非主要功能没有实现或不完整、影响系统的运行，设计不合理造成性能低下，比较严重地影响系统要求或基本功能的实现，但存在合理的更正办法。（重新安装或重新启动该软件不属于更正办法）4轻微缺陷使操作者不方便或遇到麻烦，但它不影响执行工作功能或重要功能。5建议（非缺陷）从用户角度考虑在软件设计和功能实现等不完全合理之处提出建议。5.1.4 缺陷优先级序号缺陷优先级描述1立即解决立即解决是指缺陷导致系统几乎不能使用或者测试不能继续，需立即修复2高优先级高优先级是指缺陷严重影响测试，需要优先考虑3正常排队正常排队是指缺陷需要正常排队等待修复；。4低优先级而低优先级是指缺陷可以在开发人员有时间的时候再被纠正一般地，严重程度高的软件缺陷具有较高的优先级，但是严重程度和优先级并不总是一一对应。有时候严重程度高的软件缺陷，优先级不一定高，甚至不需要处理，而一些严重程度低的缺陷却需要及时处理，反而具有较高的优先级。例如，公司名字和软件产品徽标是重要的，一旦它们误用了，这种缺陷是用户界面的产品缺陷，并不影响用户使用。但是它影响公司形象和产品形象，因此这也是优先级高的软件缺陷。5.1.5 缺陷状态缺陷状态描述New已提交的缺陷Open确认“提交的缺陷”，等待处理Rejected不予解决，不需要修复或不是缺陷Fixed缺陷被修复Reopen缺陷未通过验证Closed确认被修复的缺陷，将其关闭tostory转为需求5.1.6 缺陷发现的阶段缺陷起源描述需求阶段在需求阶段发现的缺陷设计阶段在设计阶段发现的缺陷编码阶段在编码阶段发现的缺陷集成测试阶段在集成测试阶段发现的缺陷系统测试阶段在系统测试阶段发现的缺陷验收测试阶段在验收测试阶段发现的缺陷维护阶段在维护阶段发现的缺陷5.1.7 缺陷引入的阶段缺陷引入阶段描述需求阶段需求阶段引起的缺陷设计阶段设计阶段引起的缺陷编码阶段编码阶段引起的缺陷5.2. 缺陷管理流程对于缺陷管理（注1），从发现缺陷到最终解决的流程图如下：图1 缺陷管理流程图【注1】可以采用自动化的BUG管理工具进行管理，例如公司的BUG追踪系统，生成缺陷跟踪表。（1）缺陷的提交发现的缺陷均提交给项目内指定人员，缺陷的状态为：New由指定人员进行评审、分配。提交缺陷必须填写：缺陷的描述、优先级、严重性、缺陷的状态、解决人、发现缺陷的阶段，缺陷引入的阶段等信息。这些信息由提交缺陷的人负责填写。测试人员登录BUG追踪系统，将缺陷的信息录入，然后提交给项目经理审核。（2）缺陷的分配项目组内对缺陷评审，决定缺陷计划解决的版本、时间和负责人员。分配缺陷后的状态可能为：Open & Rejected缺陷分配必须修改：缺陷的状态、解决人、计划关闭的版本和评审信息。这些信息由缺陷的解决人（一般是项目经理、开发经理或者是模块负责人）负责填写。项目经理登录BUG追踪系统，接到测试人员提交的缺陷信息，对缺陷进行评审，如果评审缺陷通过，则该缺陷的状态变为Open，项目经理将该缺陷分配给开发人员解决；如果评审缺陷不通过，则该缺陷的状态变为Rejected，该缺陷不能作为缺陷进入缺陷管理流程。（3）缺陷的解决缺陷由指定的开发人员解决后，经过单元测试或代码走查，填写缺陷修改完成时间和缺陷处理结果描述。解决后的缺陷的状态为：Fixed解决缺陷必须修改：缺陷的状态、解决人、涉及到的代码等信息。这些信息由解决缺陷的人负责填写。开发人员登录BUG追踪系统，修复该缺陷后，填写该缺陷的基本信息，缺陷状态变为Fixed，提交给CM工程师。（4）缺陷的关闭经过验证后的缺陷由测试专员关闭，状态为Closed，否则为：Reopen缺陷的验证必须修改：缺陷的状态、解决人、解决的版本等信息。这些信息由测试工程师负责填写。缺陷验证后的关闭必须修改：缺陷的状态、实际关闭缺陷的版本、解决的版本等信息。这些信息由测试专员负责填写。测试工程师登录BUG追踪系统，对状态为Fixed的缺陷进行验证，通过验证，缺陷状态变为Closed，否则状态变为Reopen，提交给开发人员重新修复。5.3. 缺陷报告阶段性的测试完成后，测试工程师将该阶段发现的缺陷进行统计分析，可以作为测试报告的一部分，包括：缺陷的数量、缺陷类型分类、缺陷分类百分比等。5.4. 遗留缺陷跟踪l 跟踪遗留缺陷对于发布的产品，需要跟踪产品发布后的运行情况。对遗留的缺陷跟踪记录并分析其影响范围，直到遗留缺陷形成解决结果。l 产品发布后发现的缺陷产品发布后的缺陷来源有：客户服务部门客户服务人员、咨询实施部项目实施工程师、客户、开发和测试人员。该类缺陷发现后需要提交给项目组，纳入缺陷管理，该类缺陷的发现阶段标识为“发布后”，便于分析原因。5.5. 缺陷分析通过缺陷的数据分析，总结缺陷出现的原因、类型和规律，采取相应措施避免该类型