测试缺陷管理标准规范.doc

测试缺点管理规范 目标 缺点是产品和要求要求不相符部分，会存在于软件产品整个生命周期中，本文规范软件测试过程中出现缺点，经过测试活动及早发觉软件系统中缺点，并确保缺点被有效标识、跟踪、和修改，确保软件系统能够达成要求质量。 适用范围 适适用于软件整个生命周期。 不限于测试过程发觉缺点。评审，用户使用等过程中发觉缺点全部是应该根据本步骤进行登记跟踪管理。 术语和定义 软件缺点：软件或程序中存在某种破坏正常运行能力问题、错误，或隐藏功效缺点。 严重程度：缺点严重程度是指因缺点引发故障对 软件产品影响程度。 优先级：缺点必需被修复紧急程度。 职责 技术部 测试工程师：关键是指发觉缺点和汇报缺点测试人员。在通常步骤中，需要对这个缺点后续相关状态负责：包含相关人员对这个缺点相关信息问询回复，和验证测试。 开发工程师：关键是指对这个缺点进行研究和修改开发人员。同时，需要对修改后缺点在提交测试人员正式测试验证之前需要进行验证测试。 其它参与人员：项目责任人、用户组等，她们对缺点进行优先级划分，责任人进行确定并调整争议。 配置管理员：负责缺点库创建和权限管理，并监督指导缺点库定制。 缺点步骤 登记 缺点发觉后，由测试人员或其它发觉缺点人员登记到缺点库。 缺点登记后，提交前能够反复编辑，补充缺点统计信息。 登记缺点描述要求为分类正确、叙述简练、步骤清楚、有实例、可再现、复杂问题有据可查（截图或上传附件形式） 具体要求为： 单一：尽可能一个汇报只针对一个软件缺点。 简练： 每个步骤描述应简练明了。 再现：描述重现步骤和条件，比如具体输入参数值，方便进行回归验证。应提供截图。 期望结果。 实际结果。 其它信息，可依实际情况增加。 提交 测试人员确定缺点已经表述清楚，能够提交缺点。 提交后缺点状态时“已提交”。 缺点提交前必需分配一个具体开发人员负责，假如测试人员不确定谁负责，能够把缺点分配给开发责任人，由开发责任人重新分配责任人。 处理 开发人员确定缺点是自己负责后，开始着手处理，并修改缺点状态为“打开”，表示缺点正在处理中。 开发人员对缺点处理完成后，需做处理统计： 原因：说明缺点产生原因，比如：设计考虑不周，边界处理不严密，逻辑判定不合理。要求描述具体简练，方便总结经验。 处理方法：修改稿包含文件、源代码、配置、脚本等。 概括：缺点是否可能存在于其它位置，或引发其它问题。 已打开缺点也能够修改责任人。 处理 问题处理后，填写处理处理统计，写明造成缺点原因和处理方案，改变缺点状态为“已处理”。 假如开发人员发觉以下情况，能够把缺点驳回给测试人员： 缺点不可再现 和先前登记缺点反复 不是缺点，是测试人员了解错误 缺点轻微，且修改困难、或修改易造成更大潜在问题 假如根据开发计划，缺点发生功效不属于目前开发阶段必需完成（需和项目责任人确定）。 验证 测试人员对“已处理”状态缺点进行重新测试，测试步骤应该根据等级可重现步骤进行。 关闭 测试人员确定缺点已经处理后，关闭缺点。 对于被开发人员驳回缺点，测试人员需和项目责任人讨论，项目责任人同意能够关闭，不然需驳回给开发人员； 驳回开发人员重新修改 验证测试不经过缺点，应该驳回给开发人员，状态为“重新打开”。 关闭了缺点再次出现时（通常因为处理缺点方法造成相同位置出现不一样形式缺点时），测试人员重新打开缺点，开发人员需要继续处理。 附件 缺点严重程度 严重程度 标示 含义 1 致命 造成软件无法使用问题，比如整个程序瓦解，造成无法使用，测试阻塞。1.问题会自发影响整个系统。2.用户使用正常操作步骤，就会影响整个系统提供服务。3.含有操作前后次序功效，已开始步骤出现故障，造成后续步骤无法使用。 2 严重 某个功效未实现或造成一个特征或造成一个特征不能运行而且没有替换方案 3 通常 错误造成了一个特征不能运行但可有一个替换方案。功效特征设计不符合系统需求，不影响系统业务，而且有对应补救方法。 4 轻微 错误是表面化或微小（提醒信息不太正确友好、不正确、误导、错别字、界面布局或罕见故障等），对功效几乎没有影响，产品及属性仍可使用。 5 提议 建设性意见或提议。需求文档没有要求特征，假如实现会对系统功效或易用性有所提升。 缺点优先级 优先级 含义 1 紧急 假如故障妨碍开发人员深入开发活动，应立即修复。假如阻塞测试，应立即修复。 2 必需 必需修改，版本公布前必需修正 3 应该 必需修改，不一定立即修改，但需确定在某个特定版本公布前必需修正 4 可选 假如时间许可应该修改 5 不需要 许可不修改 缺点状态 缺点状态 描述 初始状态 测试或开发人员提交一个新缺点，等候开发人员或项目经理分配修改责任人 驳回 要求缺点提交者再次对缺点进行说明 已分配 已分配给开发人员，待修改状态 已处理 缺点已被开发人员