测试缺陷跟踪处理规程-906.doc

密级机密记录 文件会签页文件标题测试缺陷跟踪处理规程文件编号会签分发清单 霍生 张工集团综合办公室 集团人力资源部 采购中心 制造中心 供应商管理 生技部 生产物料采购 部件部 工程物料采购 机加工 整机一部 运营中心 整机二部 无优运营部 整机三部 天馈运营部 整机四部 射频部件运营部 天线一部 无线传输与接入 天线二部运营部 天线三部 物控中心 功放生产部 射频部件部 供应链体系质检部 无线传输与 新产品导入办公室 接入生产部 广州研究部 功放研发部 南京研究所 天馈事业部 覆盖接入产品研发部 无线优化产品事业部 无线传输与接入事业部 无线解决方案部 网管业务中心 企业合作部 质量技术中心 信息中心 系统公司 京信国际 加盖受控章签名签名编制审核部门部门签名签名审核审核部门部门签名签名审核审核部门部门签名签名审核审核部门部门签名签名审核审核部门部门签名签名审核审核部门部门签名签名审核审核部门部门审批签名批准签名生效日期：文件历史记录文件编号现行版本A文件标题测试缺陷跟踪处理规程文件履历版本编制日期更改内容（条款）A陈玉案2011-3-22首发记录编号：06QMGC-02-013E 第 2 页 共2页密级 机密 目录 目 录1.目的12.范围13.术语和定义14.角色与职责15.缺陷定义和属性25.1 缺陷定义25.2 缺陷属性25.3 缺陷类型35.4 缺陷等级35.5 缺陷状态55.6 缺陷完成度56.缺陷管理工具67.测试缺陷跟踪处理流程67.1 准入67.2 输入67.3 测试缺陷跟踪处理流程图67.4 流程说明77.5 输出97.6 准出9I密级机密作业指导书缺陷跟踪处理规程1. 目的规范测试过程中的缺陷跟踪处理活动、确保发现缺陷得到有效及时处理。2. 范围适用于公司范围内所有测试活动的缺陷跟踪处理。3. 术语和定义3.1 业务需求用户实现业务显性的、明示的需求（含功能性和非功能性需求），开发产品实现用户业务应提供的功能和性能要求。3.2 产品需求产品需求是指产品满足标准、法律法规、社会文化、客户、用户需求及干系人对产品所期望的等集合，为产品开发和测试提供依据。3.3 派生性需求为实现业务需求或产品需求而产生的需求。常见的派生性需求为系统分解所产生的新的软件、硬件子系统的接口需求。4. 角色与职责4.1 测试工程师1) 上报验收测试过程中出现的缺陷，并指派给项目经理；2) 在回归测试中对已解决的缺陷进行关闭处理。4.2 项目经理1) 判断并分配测试工程师指派过来的缺陷；2) 对于不是缺陷和是缺陷但不做修改的缺陷进行分析和处理；3) 研发工程师修改缺陷后重新提交测试。4.3 开发工程师1) 对验收测试过程中出现的问题进行解决和分析；2) 对不能改进的缺陷进行分析和处理。4.4 产品经理1) 对项目经理指派过来不做改进的缺陷进行审核；2) 对由于技术问题不做修改的缺陷进行公认；3) 对不做修改的遗留问题进行确认。4.5 评审小组在发布评审会上对缺陷进行总结评审。4.6 质量工程师1) 定期导出已公认和已确认的缺陷；2) 组织技术专家组对缺陷进行评估和处理；3) 发布测试缺陷评估和处理意见；4) 对缺陷的处理进行跟踪。4.7 技术专家组1) 由缺陷相关的产品经理、项目经理和技术经理组成；2) 对缺陷进行评估和处理，给出决策。4.8 测试负责人1) 负责测试过程中缺陷的审核和处理跟踪工作；2) 对误报的缺陷进行删除；3) 执行缺陷评估处理意见。5. 缺陷定义和属性5.1 缺陷定义1）没有达到需求表明的功能；2）出现了与需求中不一致的表现；3）功能超出需求的范围；4）没有达到用户期望的目标；5）测试人员或用户认为软件的易用性差。5.2 缺陷属性缺陷属性见表1。表1缺陷属性描述缺陷编号识别缺陷的标识，缺陷标识用一组数字表示，由缺陷管理工具自动分配。每个缺陷都有一个唯一标识。缺陷类型缺陷类型是根据缺陷自然属性的缺陷种类。缺陷的严重级别指因缺陷引起故障对产品的影响程度。缺陷的优先级指缺陷必须被修复的紧急程度。缺陷的状态指缺陷在缺陷生命周期中的状态。缺陷原因分类指引起缺陷的起因。缺陷的完成度缺陷指派到各人员的完成情况。5.3 缺陷类型根据各个产品的特点可自行定义缺陷的类型。直放站产品缺陷类型的举例：监控功能、射频性能、产品应用性、稳定性、结构工艺、文档错误、环境适应性、电气性能、电磁兼容特性等。5.4 缺陷等级5.4.1 软件缺陷等级定义软件缺陷等级定义见表2。表2缺陷等级定义说明致命缺陷系统任何一个主要功能完全丧失、用户数据受到破坏、系统崩溃、悬挂、死机，或者危及人身安全。l 可重现的系统崩溃（死机、重启等），不可自动恢复；l 软件缺陷持续影响射频工作，不可自动恢复；l 软件缺陷的存在导致测试无法继续进行；l 数据受到破坏或丢失，无法恢复，导致用户无法使用。严重缺陷系统的主要功能部分丧失、数据不能保存，系统的次要功能完全丧失，系统所提供的功能或服务受到明显的影响。l 在特定条件下，影响射频工作，可立即自动恢复；l 可重现的系统重启，可自动恢复；l 主要功能突然丧失，不可自动恢复；l 正常操作或工作时，系统重复出现不稳定、不可靠的现象；l 设置非法数据，导致射频或监控（系统）工作异常，无法恢复；l 次要功能没有实现、主要功能实现不完整或不符合需求；l 软件缺陷的存在严重影响了正常功能的执行（无论是否波及其他功能）；l 软件缺陷的存在影响了一个正常功能，而且这个影响波及了其他功能。一般缺陷系统的次要功能没有完全实现，但不影响用户的正常使用。l 难以重现的异常，可自动恢复；l 设置非法数据，导致射频或监控（系统）工作异常，可以恢复；l 数据的精度或范围不满足系统要求；l 次要功能没有完全实现，但影响不会波及其他功能；l 系统响应时间长，超出客户承受范围；l 文字描述或提示信息不准确，对用户操作增加了障碍。建议改进不便于操作或操作过程中易出现异常现象，但它不影响功能的操作和执行。l 系统无明确要求且不影响系统正常工作；l 能满足需求，但欠缺易用性；l 系统指标之外出现的异常；l 设置非法数据，不会导致射频或监控（系统）工作异常，但显示异常；l 不符合编码规范要求；l 软件设计不甚合理，对用户使用或心理产生了较大影响；l 个别的不影响理解的文字语句错误。5.4.2 硬件缺陷等级定义硬件缺陷等级定义见表3。表3缺陷等级定义说明致命缺陷1、缺陷直接导致设备不能正常使用；2、由于设计问题，使系统存在严重质量隐患。l 电源无法开启；l 无功率输出；l 无增益；l 不能正常通话；l 自激；l 检测过程中出现非人为操作原因的部件故障。严重缺陷1、缺陷严重影响设备正常使用；2、关键性能指标差或工艺结构严重影响工程应用；3、对于客户送检或认证的项目性能指标不满足相关标准或客户需求指标。l 带内出现较严重杂散；l 通话质量三级以下；l 交调指标不达标导致影响主信号的正常使用；l 结构试验后的部件损坏或指标恶化；l 端口标识错误、功耗超标；l 客户送检或认证项目出现的性能指标不满足标准要求。一般缺陷1、非客户送检项目性能指标不满足相关标准要求；2、性能指标差或工艺结构对操作者不方便或遇到麻烦，但它不影响执行工作功能或重要功能。l 高低温的增益变化量超标；l 射频参数读取误差不合格；l 波动不合格；l 结构工艺不合理：如数据线和电源线捆绑一起、MODEM摆放造成工程维护不方便。建议改进测试建议。l 如部分指标余量不大可能影响生产调试周期；l 增加防护标识。5.5 缺陷状态缺陷状态定义见表4。表4缺陷状态定义新建新报告的缺陷已指派该缺陷已指派给相关负责人，但还未得到回复已反馈重新打开的缺陷已解决缺陷已修改完成的状态已关闭测试人员对已解决的缺陷再次验收通过的状态已公认由产品经理确认该缺陷是因公司公认的技术问题无法改进，只能维持现有处理方式的状态已确认缺陷已经确认存在，但还未改进5.6 缺陷完成度缺陷完成度定义见表5。表5缺陷完成度定义未处理对缺陷还未进行处理。已修正缺陷已经修正。重新打开开发人员已修改，但测试人员检测后发现问题仍然存在或又产生了新的问题。不是Bug由项目经理确认不是缺陷。不做修改由产品经理确认该问题因技术上的问题，维持现有处理方式，以后也不做修改。暂不改进由产品经理确认该问题在此版本暂不改进，留待下一版本改进。无法重现只出现过一次，不能重现的缺陷。6. 缺陷管理工具公司软件缺陷发布和管理使用Mantis 工具，并通过使用它跟踪缺陷的变更过程。7. 测试缺陷跟踪处理流程7.1 准入测试过程发现缺陷。7.2 输入测试过程发现的缺陷。 7.3 测试缺陷跟踪处理流程图测试缺陷跟踪处理流程见图1。图17.4 流程说明7.4.1 上报和分配缺陷1) 测试工程师在测试过程中发现缺陷，将缺陷上报缺陷管理平台,并将指派给项目经理（Bug状态为“已指派”）；2) 项目经理接到Mantis发过来的Bug,进行缺陷分析，确认是否缺陷；对于建议改进项，由项目经理判断是否修改，不修改则填写分析后指派给测试负责人,修改则指派给相应的责任人。7.4.2 不是缺陷,或建议改进项不修改的处理流程：1) 测试工程师指派过来的不是缺陷，项目经理填写分析后指派给测试负责人；2) 测试负责人接收到项目经理指派过来的缺陷后，对于误报的缺陷进行删除，将不做修改的建议改进项置为“已关闭”,完成度为“不是Bug”。7.4.3 是缺陷,或建议改进项要修改的处理流程：1) 测试工程师指派过来的是缺陷，要修改，由项目经理指派给相应的责任人进行处理；2) 研发工程师接收到项目经理指派过来的缺陷后，判断是否能修改，如果不能修改，由项目经理填写原因分析后指派给产品经理；3) 研发工程师修改项目经理指派过的缺陷后，填写原因和措施后，置缺陷的状态为“已解决”完成度置为“已修正”；4) 研发工程师缺陷修改完成后，由项目经理重新提交测试；5) 测试工程师进行回归测试，判断缺陷是否解决，如果缺陷仍存在则重新打开缺陷，此时状态为“已反馈”,研发工程师修改缺陷后,由项目经理重新提交测试；6) 测试工程师将研发工程师已解决缺陷的状态置为“已关闭”。7.4.4 是缺陷,但不修改的处理流程：1) 测试工程师指派过来的是缺陷，但不修改，由项目经理填写分析，并指派给产品经理；2) 产品经理接收到项目经理指派过来不修改的缺陷后，进行是否改进的审核；3) 产品经理对由于技术限制无法修改或需求无明确要求的缺陷进行公认，填写分析后置状态为“已公认”，完成度为“不做修改”；4) 产品经理对由于项目进度或资源原因而暂不改进的的缺陷进行确认，填写分析后置状态为“已确认”，完成度为“暂不改进”。7.4.5 发布评审在项目经理发起的发布评审会上，由评审小组对项目在验收测试过程中出现的缺陷进行总结评审。7.4.6 缺陷有效分析1) 质量工程师定期(1个月或者1个季度)从缺陷平台上导出状态为“已公认