软件缺陷管理

软件缺陷与缺陷管理：

软件缺陷的定义：至少满足下列5个规则之一才称之为发生了一个软件缺陷。
软件未实现需求说明书要求的功能。
软件出现了需求说明书指明不应该出现的错误。
软件出现了需求说明书未提到的功能
软件未实现需求说明书虽未明确提及但应该实现的目标
软件难以理解、不易使用、运行缓慢或者——从测试员的角度看——最终用户会认为不好。

通俗理解的缺陷：执行测试用例时，实际结果与预期结果不一致。

缺陷产生的原因：
需求文档错误或不清晰
概要设计、详细设计、数据库设计文档等存在错误或不清晰
代码错误
硬件或软件存在错误

缺陷产生的根本原因：
需求变更
沟通不畅，信息不同步
软件复杂度
进度压力

缺陷的十大要素：
缺陷编号（ID）：唯一性
模块
缺陷标题【见名知意；尽可能的站在开发的角度去提缺陷；唯一性】
严重程度
严重（S1）——主功能不可用、crash 问题、闪退、不能启动
一般（S2）——次要功能不可用，边界、异常未处理处理等
微小（S3）——易用性问题、界面展示，小的性能问题等
建议（S4）——建议性问题
优先级
Priority0——必须在24小时内被解决
Priority1——产品发布前必须修复
Priority2——可以在下一个版本中修复
复现步骤——参照测试用例的操作步骤
预期结果——测试用例的预期结果
实际结果——测试执行时系统给出的结果
缺陷类型
代码错误
功能错误
界面错误
兼容性错误
易用性
改进依据
缺陷状态
新建：New
打开：Open
修复（已解决）：Fixed
拒绝：Rejuct
延期：Postponed
再次打开：Reopen
完成：Closed
测试用例：ID、模块、优先级、标题、测试数据、前置条件、预期结果、测试步骤
缺陷：ID、模块、缺陷标题、严重程度、优先级、复现步骤、预期结果、实际结果、缺陷类型、缺陷状态

编写缺陷报告注意事项：
近了确保缺陷可以重现
简介、准确、完整
一个缺陷一个报告

缺陷的统计：

统计难度

统计数据用途：
相关数据需要整理到测试报告中，方便项目相关负责人知悉当前测试版本的整体质量。