测试缺陷管理规范.pdfVIP

。 测试缺陷管理规范 1. 目的 1.1. 缺陷是产品与规定要求不相符的部分，会存在于软件产品的整个生命周期中，本文规范 软件测试过程中的出现的缺陷，通过测试活动及早发现软件系统中的缺陷，并确保缺陷 被有效标识、跟踪、和修改，保证软件系统能够达到要求的质量。 2. 适用范围 2.1. 适用于软件的整个生命周期。 2.2. 不限于测试过程发现的缺陷。评审，用户使用等过程中发现的缺陷都是应当按照本流程 进行登记跟踪管理。 3. 术语和定义 3.1. 软件缺陷：软件或程序中存在的某种破坏正常运行能力的问题、错误，或者隐藏的功能 缺陷。 3.2. 严重程度：缺陷严重程度是指因缺陷引起的故障对软件产品的影响程度。 3.3. 优先级：缺陷必须被修复的紧急程度。 4. 职责 4.1. 技术部 4.1.1. 测试工程师： 主要是指发现缺陷和报告缺陷的测试人员。 在一般流程中， 需要对这个缺 陷后续相关的状态负责： 包括相关人员对这个缺陷相关信息的询问回答， 以及验证测试。 4.1.2. 开发工程师： 主要是指对这个缺陷进行研究和修改的开发人员。 同时， 需要对修改后的 缺陷在提交测试人员正式测试验证之前需要进行验证测试。 4.1.3. 其他参与人员： 项目负责人、用户组等， 他们对缺陷进行优先级划分， 负责人进行确认 并调节争议。 4.1.4. 配置管理员：负责缺陷库的创建和权限管理，并监督指导缺陷库的定制。 5. 缺陷流程 5.1. 登记 5.1.1. 缺陷发现后，由测试人员或者其他发现缺陷的人员登记到缺陷库。 5.1.2. 缺陷登记后，提交前可以反复编辑，补充缺陷记录的信息。 5.1.3. 登记缺陷描述的要求为分类准确、叙述简洁、步骤清楚、有实例、可再现、复杂问题有 。 1 。 据可查（截图或上传附件的形式） 具体要求为： 单一：尽量一个报告只针对一个软件缺陷。 简洁： 每个步骤的描述应简洁明了。 再现：描述重现的步骤和条件， 比如具体输入参数值， 以便进行回归验证。 应提供截图。 期望结果。 实际结果。 其它信息，可依实际情况增加。 5.2. 提交 5.2.1. 测试人员确认缺陷已经表述清楚，可以提交缺陷。 5.2.2. 提交后的缺陷状态时“已提交” 。 5.2.3. 缺陷提交前必须分配一个具体的开发人员负责， 如果测试人员不确定谁负责， 可以把缺 陷分配给开发负责人，由开发负责人重新分配责任人。 5.3. 处置 5.3.1. 开发人员确认缺陷是自己负责后，开始着手处理，并修改缺陷的状态为“打开” ，表示 缺陷正在处理中。 5.3.2. 开发人员对缺陷处置完成后，需做处置记录： 原因：说明缺陷产生的原因， 比如：设计考虑不周， 边界处理不严密， 逻辑判断不合理。 要求描述具体简洁，以便总结经验。 解决方法：修改稿涉及的文件、源代码、配置、脚本等。 概括：缺陷是否可能存在于其他位置，或引起其他问题。 5.3.3. 已打开的缺陷也可以修改负责人。 5.4. 解决 5.4.1. 问题解决后， 填写解决处理记录， 写明造成缺陷的原因和解决方案， 改变缺陷状态为 “已 解决”。 5.4.2. 如果开发人员发现如下情况，可以把缺陷驳回给测试人员： 缺陷不可再现 与先前登记的缺陷重复 不是缺陷，是测试人员理解错误