软件缺陷管理制度

软件缺点管理制度软件项目测试组文档编号：编写人：编写日期：3月20日审核人：审核日期：审批人：审批日期：修订历史统计日期版本阐明作者目录软件缺点管理制度 1修订历史统计 1目录 1第1章总则 1第2章职责 1第3章缺点类型 13.1文档缺点 13.2设计缺点 23.3配备缺点 23.4界面交互缺点 23.5数据校验缺点 33.6查询统计缺点 33.7功效缺点 33.8性能缺点 33.9安全性缺点 4第4章缺点管理流程 44.1新增（提交） 44.2定位 44.4解决 44.5否决 44.6推迟解决 44.7回归验证 54.8再打开 54.9关闭 5第5章缺点统计 55.1编号 55.2项目 55.3公布版本 55.4功效模块 55.5缺点描述 55.6重现环节 55.7严重程度 65.8优先级 65.9状态 65.10负责人 65.11解决意见 75.12解决统计（解决的方法） 7第6章附录 7第1章总则为了加强部门管理工作，建立规范的缺点管理制度，提高工作水平，根据公司和部门的有关规定，制订缺点管理制度。本缺点管理制度合用于工程技术部。各测试，研发人员应当根据本制度的规定，规范工作，确保软件质量。软件缺点又被叫做Bug。所谓软件缺点，即为软件中存在的某种破坏正常运行能力的问题、错误，或者隐藏的功效缺点。缺点的存在会造成软件产品在某种程度上不能满足顾客的需要。IEEE729-1983对缺点有一种原则的定义：从产品内部看，缺点是软件产品开发或维护过程中存在的错误、毛病等多个问题；从产品外部看，缺点是系统所需要实现的某种功效的失效或违反。软件缺点的管理分为四个阶段。涉及：缺点提交、明确指明缺点类型、缺点修复、缺点回归验证。第2章职责项目人员应对各阶段测试发现的缺点进行跟踪管理，以确保各级缺点的修复率达成一定原则。包含内容以下：2.1测试人员在提供的缺点模板中新建或重新打开缺点。2.2测试人员提交的缺点将反馈给项目负责人，由项目负责人安排开发人员修复缺点。2.3开发人员修复缺点后，统计解决时间及解决成果，并将文档及时反馈给测试人员验证。2.4测试人员验证缺点后，统计验证时间及验证成果，并提交给项目负责人。第3章缺点类型缺点类型是指根据缺点的自然属性划分的缺点种类。共分为九类，涉及：文档缺点、设计缺点、配备缺点、界面交互缺点、数据校验缺点、查询统计缺点、功效缺点、性能缺点、安全性缺点。3.1文档缺点文档缺点是指软件有关文档不满足其完整性、对的性、一致性、易理解性、易浏览性的规定。满足下列一或多个状况：（1）影响公布和维护，其中涉及注释。（2）文档中术语不一致。（3）文档中词语、语句体现不清晰，产生歧义。（4）文档内容缺失，构造不完整。（5）文档编制过程中产生的错误。（6）文档中发现的其它错误。3.2设计缺点设计缺点是指软件在最初设计时由于未考虑全方面，而使软件在使用中存在的某些潜在的缺点。满足下列一或多个状况：（1）需求分析阶段没有考虑和挖掘到的隐式需求，造成的需求缺失。（2）操作便捷性设计不符合大众操作习惯。（3）控件功效设计不符合大众使用习惯。（4）错误提示内容不符合大众阅读习惯。（5）其它设计不合理引发的缺点。3.3配备缺点配备缺点是指由于配备库、变更管理或版本控制引发的错误。满足下列一或多个状况：（1）独立安装布署不成功。（2）配备文献或初始化数据错误。（3）不同运行环境产生的错误。3.4界面交互缺点界面交互缺点是指接口通信和人机交互时产生的缺点。满足下列一或多个状况：（1）组件、模块之间数据通信错误。（2）程序接口错误。（3）硬件接口通信错误。（4）界面不存在，界面不满足易用性规定，界面难以被顾客理解，界面不协调不美观，提示信息没有使用用业务词汇或者容易被顾客理解的词汇而是使用计算机专业术语。（5）界面风格不相对一致，不符合操作习惯。（6）提示、警告、错误阐明等和谐信息体现含糊、失当。（7）没有区别不同操作（增加、删除、修改、查询）对应界面的性质。（8）没有提供辅助输入手段。3.5数据校验缺点数据校验缺点是指提示的错误信息，不适宜的数据验证等缺点。满足下列一或多个状况：（1）数据计算错误。（2）数据约束错误。（3）不同操作之间数据逻辑校验错误。（4）数据库发生死锁。（5）数据库的表、缺省值未加完整性等约束条件。（6）数据库连接错误。（7）数据库中得表有过多空字段。3.6查询统计缺点查询统计缺点是指条件设立不精确引发的查询统计成果不对的。满足下列一或多个状况：（1）查询条件设立不精确。（2）查询成果列表异常。（3）同一查询条件得到的成果不一致。3.7功效缺点功效缺点是指影响软件规定或基本功效实现的缺点。满足下列一或多个状况： （1）功效无法实现。（2）功效实现错误。（3）业务流程错误。（4）功效操作与数据库存储不一致。（5）功效与辅助协助不吻合。3.8性能缺点性能缺点是指产品性能不能满足需求规格阐明书中对性能需求的规定。满足下列一或多个状况：（1）业务解决效率低。（2）查询统计效率低。（3）响应速度不能满足需求规格阐明书中的规定。3.9安全性缺点安全性缺点是指产品不能满足需求规格阐明书中对安全性需求的规定。满足下列一或多个状况：（1）顾客登录顾客名/口令校验不对的。（2）口令没有掩码显示。（3）顾客权限分派错误。（4）顾客功效超权限。第4章缺点管理流程4.1新增（提交）缺点提交阶段需要提交缺点报告，测试人员必须确保登记的缺点信息能够被处置负责人员理解，因此缺点报告必须具体描述缺点内容。具体内容参见缺点统计。4.2定位缺点分析定位阶段需要根据缺点报告的内容对缺点进行分析和定位。缺点分析和定位是有关人员根据缺点报告中对缺点的具体描述查找重现缺点，拟定缺点产生的因素，明确缺点所处的位置，方便修改缺点。4.4解决缺点修复阶段需要对已经定位的缺点进行修改。缺点修复是开发人员对已经分析定位的缺点进行修改并更改缺点状态，修改后的软件需要实现预期的成果（缺点报告中的预期成果）。4.5否决如果开发人员发现该缺点不可再现、重复、不是问题等状况，能够把缺点状态设立成“否决”。4.6推迟解决如果按照开发计划，缺点发生的功效不属于现在开发阶段必须的完毕的，可将缺点状态设立为“推迟解决”。4.7回归验证缺点回归验证阶段需要对已经修改的缺点进行验证和回归测试。缺点回归验证是测试人人员对已经修改的缺点进行回归测试，根据缺点报告中的操作环节对缺点重新进行测试，并对缺点修改正程中可能影响到的组件、模块或功效进行重新测试，验证修改后的缺点能够实现预期成果并对其它组件、模块或功效无影响。同时，根据验证成果修改对应的缺点状态，提交新产生的缺点。4.8再打开验证测试不通过的缺点，应当重新打开，状态变为“重新打开”。关闭了的缺点再次出现时(普通由于解决缺点的办法造成相似位置出现不同形式的缺点时)，测试人员重新打开缺点，开发人员需要继续解决。项目负责人应当关注“重新打开”的缺点。4.9关闭测试人员确认缺点已经解决后，关闭缺点。对于否决的缺点，测试人员需要和项目负责人讨论，项目负责人同意的能够关闭，项目负责人不同意的需要“重新打开”。第5章缺点统计5.1编号缺点的唯一标记，能够方便对特定缺点统计的引用。5.2项目5.3公布版本即缺点是在什么公布版本中发现。5.4功效模块5.5缺点描述对该缺点进行简短的描述，尽量使负责人能够理解。5.6重现环节描述该缺点出现的具体环节，尽量做到环节清晰、有实例、可再现。5.7严重程度缺点严重程度是指因缺点引发的故障对软件产品的影响程度。分为五类，涉及：致命、严重、普通、轻微、提示。（1）致命：不能执行正常工作功效或重要功效。（2）严重：严重影响系统规定或基本功效的实现造成系统出错或关闭进程，且没有方法改正。（重新安装或重新启动该软件不属于改正方法）（3）普通：严重影响系统规定或基本功效的实现造成系统提示错误，但存在合理的改正方法。（重新安装或重新启动该软件不属于改正方法）（4）轻微：使操作者不方便或碰到麻烦，但它不影响执行工作功效或重要功效。（5）提示：其它错误。5.8优先级缺点优先级指缺点必须被修复的紧急程度。分为四类，涉及：紧急、严重、普通、轻微。（1）紧急：缺点不被修改将无法继续测试。（2）严重：缺点必须被立刻解决。（3）普通：缺点需要正常排队等待修复或列入软件公布清单。（4）建议：缺点能够在方便时被纠正。5.9状态缺点状态指缺点在跟踪修复过程中的进展状态。分为五类，涉及：新建、打开、重现打开、否决、解决、延迟、关闭。（1）新建：已提交的缺点。（2）打开：确认“提交的缺点”，等待解决。（3）重新打开：验证后发现未修复的缺点。（4）否决：否决“提交的缺点”，不需要修复或不是缺点。（5）解决：缺点被修复。（6）延迟：缺点暂缓修复。（7）关闭：确认被修复的缺点，将其关闭。5.10负责人负责处置解决缺点的负责人，对于功效缺点，负责人应当具体开发人员；对于文档缺点，负责人应当是具体文档的作者。缺点登记者不明确负责人时，能够指定项目负责人为负责人，由他重新分派负责人。5.11解决意见处置