软件缺陷管理

1 缺陷定义

从产品内部看，软件缺陷是软件产品开发或维护过程中所存在的错误、毛病等各种问题；从外部看，软件缺陷是系统所需要实现的某种功能的失效或违背。—IEEE 1983 of IEEE Standard 729

软件缺陷就是软件产品中所存在的问题，最终表现为用户所需要的功能没有完全实现，没有满足用户的需求。

2 缺陷的判定标准

（1）少功能：软件未实现需求规格说明书中明确要求的功能

（2）多功能：软件实现的功能超出需求规格说明书指明的范围

（3）功能错误：软件出现了需求规格说明书中指明不应该出现的错误

（4）不易使用：软件难以理解，运行缓慢，不易使用，用户体验不好

（5）隐形功能错误：软件未实现需求规格说明书中虽未指明，但应该实现的要求

3 缺陷产生的原因

（1）需求阶段：需求描述不易理解，有歧义、错误等
（2）设计阶段：设计文档存在错误或缺陷
（3）编码阶段：代码出现错误
（4）运行系统：软硬件本身故障导致软件缺陷

4 缺陷产生的根源

需求变更、交流不充分、软件复杂性、进度压力

5 缺陷信息

缺陷ID、缺陷的状态、缺陷标题、严重程度、优先级、所属模块、缺陷的详细描述

6 缺陷状态

（1）新建：已提交的缺陷
（2）打开：确认“提交的缺陷”，等待处理
（3）拒绝：拒绝“提交的缺陷”，不需要修复或不是缺陷、重复缺陷、无法重现
（4）修复：缺陷被修复
（5）关闭：确认修复的缺陷，将其关闭
（6）推迟：可在以后解决，但要确定修复日期或版本

7 BUG类型

（1）系统缺陷

• 由于程序所引起的死机，异常退出
• 程序死循环

（2）数据缺陷

• 数据计算错误
• 数据约束错误
• 数据输入、输出错误

（3）数据库缺陷

• 数据库发生死锁
• 数据库的表、缺省值未加约束条件
• 数据库连接错误
• 数据库中的表有过多的空字段

（4）接口缺陷

• 数据通信错误
• 程序接口错误

（5）功能缺陷

• 功能无法实现
• 功能实现错误

（6）安全性缺陷

• 用户权限无法实现
• 超时限制错误
• 访问控制错误
• 加密错误

（7）兼容性缺陷

• 与需求规定配置兼容性不符合

（8）性能缺陷

• 未达到预期的性能目标
• 性能测试中出错，导致无法继续进行测试

（9）界面缺陷

• 操作界面错误
• 打印内容、格式错误
• 删除操作未给出提示
• 长时间操作未给出提示
• 界面不规范

8 严重程度

• 致命：系统主要功能不可用、系统崩溃、闪退、无法启动等
• 严重：系统次要功能不可用、边界、异常未进行处理等
• 一般：易用性问题、界面显示、小的性能问题等
• 提示：建议性问题

9 优先级

• priority 0：必须在24小时内解决
• priority 1：产品发布前必须修复
• priority 2：可以在下一个版本中修复

10 缺陷跟踪

新提交的缺陷为新建状态，确认有效后为打开状态，经开发人员修改后，缺陷变为已修复（待验证）状态。此时就需要测试人员对缺陷进行回归测试，验证问题是否修复。

• 如果问题仍然存在，则测试人员将该缺陷的状态修改为重新打开；
• 如果问题已经修复，则测试人员将该缺陷的状态置为关闭状态（验证通过）。

还有一种情况：开发人员认为缺陷在当前版本可以暂不修改，而考虑在后续版本中再做修正，缺陷的对应状态为延期。
对于这种情况，项目负责人应召集开发人员、测试人员和其他项目相关人员进行讨论，如果讨论结果为同意则延期，如果不同意，则重新打开缺陷。

11 缺陷密度

基本的缺陷测量是以每千行代码的缺陷数(个/KLOC)来测量的。称为缺陷密度，其测量单位是defects／KLOC。可按照以下步骤来计算一个程序的缺陷密度：

• 累计开发过程中每个阶段发现的缺陷总数。
• 统计程序中新开发的和修改的代码行数。
• 计算每千行的缺陷数=1000*缺陷总数/代码行数。

12 缺陷数据分析

12.1 关注的问题

• 正在测试的软件哪个模块的问题最多
• 测试人员中谁报告的软件缺陷最多
• 各类缺陷所占的数量百分比分别是多少
• 开发人员能及时修复软件缺陷吗
• 开发人员一次正确修复缺陷的百分比是多少
• 正在开发的软件能否在计划的时间内正常发布

12.2 重要性

• 统计未修复的缺陷数目（特别是严重性高的缺陷），预计软件是否可以如期发布。
• 分析缺陷的类型分布，发现存在较多缺陷的程序模块，找出原因，进行软件开发过程改进。
• 根据测试人员报告缺陷的数量和准确性，评估测试有效性和测试技能。
• 根据报告的缺陷修复是否及时，改进软件开发与测试的关系，使测试与开发更有机的配合。

12.3 数据指标

• 每天/周报告的新缺陷数目；
• 每天/周修复的缺陷数；
• 累计报告的缺陷数目；
• 累计修复的缺陷数；
• 不同严重性类型的缺陷数；
• 程序模块与发现的缺陷的对应关系；

13 寻找缺陷的方法

（1）UI用户界面

• 色彩： 色彩的搭配无序、混乱是软件图形界面设计的大忌，图形界面应尽量设计得温和些。这类缺陷主观类强，个人美感占据主动，所提交的缺陷一般严重程度不可定得太高。
• 功能结构布局： 功能结构布局主要从界面的功能区域划分来考虑。相同的、类似的功能应该放在邻近的区域。
• 图片： 图片选用不合理，与当前软件类型不符，无法正确体现当前界面功能性含义。图片不规范、不清晰。
• 页面大小： 在B/S结构的软件系统中，当一个页面元素太多，未作精简时，在打开该页面时可能需要较长的加载时间，这对于软件性能是一个不小的影响，既增加了服务器的压力，又容易引起用户的反感。（图片未经压缩、格式不正确。比如采用BMP；代码冗余，存在太多无用代码；页面元素太多，太过复杂；）
• 字体： 字体在软件界面中尤其重要，字体的使用要符合软件开发规范
• 窗体大小： 窗体的设计要有层次感，父窗口、子窗口应该有所区别。窗口不应该有太多空白处，功能区域充实。
• 界面文字： 页面信息描述不清楚，有语病，错别字。简单语言复杂化，描述不正确，不符合当前页面。错误的帮助信息，乱码等。

（2）容错处理（功能缺陷）： 容错处理在软件系统中占据十分重要的地位。所谓容错，就是容忍错误的能力。当用户在使用软件过程中发生错误后，软件应该能给出引导信息，指应用户进行正确的操作。

（3）数据转换

• 无法增加记录，比如点击新增，页面自动关闭。
• 增加记录后无显示，但提示增加成功；
• 增加记录后显示不正确，显示为乱码，信息显示不全。
• 增加记录后多出记录；
• 无法修改记录；
• 修改后不能自动更新，需手工更新；
• 无法删除记录，无法全部删除；
• 删除不成功，但相应的记录已被删除；
• 无法查询、查询结果错误；

（4）性能缺陷

• 打开文档，10秒应该可以完成的，却花了3分钟；
• 启动软件，CPU长时间100%，内存消耗过多；
• 5个用户可以正常使用，20个用户使用时系统崩溃；
• 打开一个登录页面花了1分钟；
• 完成一个查询功能，花了2分钟；