软件缺陷

Posted 2022-12-03 眰恦ღ

软件缺陷

IEEE 1983 of IEEE Standard 729中对软件缺陷作了一个标准的定义：从产品内部看，软件缺陷是软件产品开发或维护过程中所存在的错误、毛病等各种问题；从外部看，软件缺陷是系统所需要实现的某种功能的失效或违背。因此软件缺陷就是软件产品中所存在的问题，最终表现为用户所需要的功能没有完全实现，没有满足用户的需求。

软件缺陷是指存在于软件（程序、数据、文档）中的那些不符合用户需求的问题。

1、软件未达到需求表明的功能

计算器说明书一般声称该计算器将准确无误地进行加、减、乘、除运算。如果测试人员或用户选定了两个数值后，随意按下了“+”号键，结果没有任何反应。

2、软件出现了需求指明不会出现的错误、

假如计算器说明书指明计算器不会出现崩溃、死锁或者停止反应，而在用户随意按、敲键盘后，计算器停止接受输入或没有了反应。

3、软件的功能超出了需求指明的范围

若在进行测试时，发现除了规定的加、减、乘、除功能之外，还能够进行求平方根的运算，而这一功能并没有在说明书的功能中规定。

4、软件未达到需求虽未指明，但应该达到的目标

若在测试过程中发现，因为电池没电而导致了计算不正确，但软件需求规格说明书未能指出在此情况下应如何进行处理。

5、软件测试人员认为软件难以理解、不易使用、运行速度慢、或者最终用户认为不好

测试人员或最终用户发现计算器某些地方不好用，比如，按键太小、显示屏在亮光下无法看清等。

软件缺陷的表现形式

• 功能、特性没有实现或部分实现。
• 设计不合理，功能特性不明确，逻辑不清楚或存在矛盾。
• 产品实际结果和所期望的结果不一致。
• 没有达到需求规格说明书所规定的性能指标等。
• 运行出错，包括运行中断、系统崩溃、界面混乱等。
• 数据不正确、精度不够、不完整或格式不统一。
• 用户不能接受的其他问题，如存取时间过长、界面不美观。
• 硬件或系统软件上存在的其他问题

软件缺陷的产生的原因

软件缺陷产生是不可避免的，造成软件缺陷产生的原因主要归纳如下：

1. 需求解释或者记录错误
2. 用户需求定义错误
3. 设计说明存在错误
4. 编码说明、程序代码有误
5. 硬件或者软件系统上存在错误
6. 其他，如文档错误、内容不正确或拼写错误1
   

软件缺陷的根源

交流不充分——客户与开发人员、开发人员与测试人员等
软件的复杂性——功能复杂、开发复杂、测试复杂
开发人员的错误——对需求的理解、开发压力、能力与经验
需求的变化——需求说明书、设计文档、程序的变更
进度压力——项目周期比较紧

软件缺陷的信息

为了便于缺陷的定位、跟踪和修改，要对所发现的缺陷，按照缺陷的严重程度、优先级、发现阶段、修复阶段、缺陷的性质、所属功能模块、系统环境等方面进行分类和统计。

缺陷状态

缺陷状态	描述
提交（Submited）	已提交的缺陷
打开（Open）	确认“提交的缺陷”，等待处理
拒绝（Rejected）	拒绝“提交的缺陷”，不需要修复或不是缺陷、重复缺陷、无法重现
修复（Resolved）	缺陷被修复
关闭（Closed）	确认修复的缺陷，将其关闭
推迟（Later）	可在以后解决，但要确定修复日期或版本

缺陷信息

属性名称	描述
缺陷ID	唯一的缺陷ID，可以根据该ID追踪缺陷
缺陷状态	缺陷状态指缺陷通过一个跟踪修复过程的进展情况
缺陷标题	描述缺陷的标题
缺陷的严重程度	对软件产品的影响程度，分致命、较严重、严重、一般、低
缺陷的优先级	缺陷修复的先后顺序，即哪些缺陷优先修正，哪些稍后修正
缺陷所属模块	缺陷所属的项目和模块，要能较精确的定位至模块
缺陷记录者	提交缺陷的人员姓名
缺陷提交时间	缺陷提交的时间
缺陷处理人	处理缺陷的处理人
处理结果描述	对处理结果的描述，描述处理情况和代码修改说明
缺陷处理时间	缺陷处理的时间
缺陷验证人	对被处理缺陷验证的验证人（回测者
验证结果描述	对验证结果的描述（通过、不通过）
缺陷详细描述	缺陷的重现步骤
缺陷环境说明	对测试环境的描述
必要的附件	如涉及到附件的或错误现象的图片等。

缺陷分类

Bug类型

系统缺陷

1、由于程序所引起的死机，异常退出  

2、程序死循环  

3、程序错误，不能执行正常工作或重要功能，使系统崩溃或资源不足

不能执行正常工作或重要功能，使系统崩溃或资源不足

数据缺陷

1、数据计算错误

2、数据约束错误

3、数据输入、输出错误

严重地影响系统要求或基本功能的实现，且没有办法更正（重新安装或重新启不属更正方法）

数据库缺陷

1、数据库发生死锁

2、数据库的表、缺省值未加约束条件

3、数据库连接错误

4、数据库中的表有过多的空字段

接口缺陷

1、数据通信错误

2、程序接口错误

功能缺陷

1、功能无法实现

2、功能实现错误

严重地影响系统要求或基本功能的实现，但有合理的办法更正（重新安装或重新启动不属更正方法）

安全性缺陷

1、用户权限无法实现

2、超时限制错误

3、访问控制错误

4、加密错误

兼容缺陷

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

性能缺陷

1、未达到预期的性能目标

2、性能测试中出错，导致无法继续进行测试

界面缺陷

1、操作界面错误

2、打印内容、格式错误

3、删除操作未给出提示

4、长时间操作未给出提示

5、界面不规范

操作者不方便或遇到麻烦，但不影响执行工作功能的实现

建议

1、功能建议

2、操作建议

建议性的改进要求

严重程度

严重等级	描述
5-Critical	系统瘫痪、异常退出、死循环、严重的计算错误等
4-VeryHigh	频繁的死机，系统大部分功能不可用
3-High	a.功能点没有实现，或不符合用户需求b.数据丢失
2-Medium	a.影响一个相对独立的功能　　b.仅仅在特定条件上发生c.与产品需求定义不一致　　　d.断断续续的出现问题
1-Low	表面性错误（如错别字）

优先级

优先级别	描述
5-Urgent	最高优先级。在这个错误影响下，系统几乎不可用。
4-VeryHigh	高优先级。错误对这套系统的能力产生严重的影响。
3-High	中优先级。如果这个错误存在与系统中，会制约开发和测试的活动的进行，如果先前没有修复它，那么需要在发布前修复它。
2-Medium	低优先级。不会延迟发布，但是会在以后修正这个错误。
1-Low	最低优先级。时间和资源允许时修正。

开发人员拒绝修改的缺陷

• 程序员无法重现或者现象难以捕捉

• 没有明确的报告以说明重现缺陷的步骤

• 程序员无法读懂的缺陷报告

• 用户很少使用或者不符合用户使用习惯的操作出错

• 由不受信任的测试人员提出

缺陷修改说明

不是所有缺陷都会修改

1. 市场的压力使得产品最终发行有时间限制
2. 测试人员错误理解或者不正确操作引出的缺陷(FAQ)
3. 错误的修改影响的模块较多，带来的风险较大(遗留)
4. 修改性价比太低
5. 缺陷报告中提出的问题很难重现

缺陷报告

·软件缺陷的描述是软件缺陷报告的基础部分，需要使用简单、准确、专业的术语来描述缺陷。否则，它就会含糊不清，可能会误导开发人员，影响开发人员的效率，也会影响测试人员自身的声誉，准确报告缺陷是非常重要的。

清晰准确的软件缺陷描述可以减少开发人员退回来的缺陷数量，可以节省开发人员和测试人员的时间。

提高软件缺陷修复的速度，使项目组能够有效地工作。

提高测试人员的可信任程度，可以得到开发人员对有效缺陷的及时响应。

加强开发人员、测试人员和管理人员的协同工作，让他们更好的工作。

注意事项

• 尽量确保缺陷可以重现。

  • 如果提交的缺陷无法重现，会影响开发人员的工作效率。

• 简洁、准确、完整。

  • 测试人员在提交缺陷报告时，要站在开发人员的角度上思考问题，要确保开发人员能迅速定位问题，而不会产生理解上的歧义。

• 一个缺陷一个报告

  • 有的测试人员喜欢在一个缺陷报告里提交多个缺陷，这种习惯不提倡，原因有以下两点：

    • 不便于分配。

      比如缺陷报告有2个缺陷，分别属于不同的开发人员，到底该分配给谁呢？

    • 不便于验证。

      比如一个缺陷报告里面有2个缺陷，缺陷1已经解决，缺陷2还没有解决，那么这个缺陷报告该不该关闭呢？

书写规范

标题–应保持简短、准确，提供缺陷的本质信息；尽量按缺陷发生的原因与结果的方式书写；避免使用模糊不清的词语，例如：“功能中断，功能不正确，行为不起作用”等。应该使用具体文字说明缺陷的症状；为了便于他人理解，避免使用俚语或过分具体的测试细节。

复现步骤–应包含如何使别人能够很容易的复现该缺陷的完整步骤。为了达到这个要求，复现步骤的信息必须是完整的、准确的、简明的、可复现的。

常见问题：包含了过多的多余步骤，且句子结构混乱，可读性差，难以理解；包含的信息过少，丢失了操作的必要步骤。

期望结果–描述应与实际结果的描述方式相同。通常需要列出期望的结果是什么。

附件–对缺陷描述的补充说明，可以是以下一些类型：缺陷症状的截图、测试使用的数据文件。

其它–选择合适的缺陷严重性属性；按相应的规定，填写相应的字段信息。

避免常见的错误

• 避免使用我、你等人称代词，可以直接使用动词或必要时使用“用户”代替
• 避免使用情绪化的语言和强调符号；
• 避免使用诸如“似乎”、“看上去可能”等含义模糊的词汇，而需要报告确定的缺陷结果；
• 避免使用自认为比较幽默的语句，只需客观地描述缺陷的信息；
• 避免提交不确定的测试问题，自己至少需要重现一次再提交。

反面的示例：

上海人：哪能查询到的结果和查询条件不搭噶的。

北京人：哥们好不容易输入一堆个人详细信息后，点击保存后全瞎了。

---

缺陷处理流程

缺陷跟踪

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

如果问题仍然存在，则测试人员将该缺陷的状态修改为重新打开；

如果问题已经修复，则测试人员将该缺陷的状态置为关闭状态（验证通过），同时添加回测说明如“该缺陷已解决”。

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

缺陷统计

对软件问题的功能域分布进行分析，找出系统的薄弱环节。要详细采集每个功能模块或系统构件的缺陷数据，并按功能、错误类型、严重程度等分类。二八定理：80%的软件问题总是发生在大约20%的功能模块中。对缺陷的注入阶段的分布进行分析，并与历史数据相比较。应按不同的开发阶段详细采集缺陷的数据。应对软件缺陷类型进行分析，以便针对各自的特点，先修复严重缺陷。应动态采集每个测试周期中发现的缺陷数，并有效地控制缺陷的修复率。应密切观察缺陷的状态，并及时跟踪其状态的变化，以检查测试和开发人员的工作情况。

Bug统计

缺陷按活动分布

缺陷按严重程度分布

缺陷按引入源分布

缺陷密度

基本的缺陷测量是以每千行代码的缺陷数(个/KLOC)来测量的。称为缺陷密度，其测量单位是defects／KLOC。

可按照以下步骤来计算一个程序的缺陷密度：累计开发过程中每个阶段发现的缺陷总数。统计程序中新开发的和修改的代码行数。
$$计算每千行的缺陷数=1000\ast 缺陷总数/代码行数$$

例如：一个29.6万行的源程序总共有145个缺陷，则缺陷密度为：

缺陷密度 ＝ 1000*145/296000 = 0.49个／KLOC

缺陷数据分析

1、缺陷数据分析关注的问题

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

2、缺陷数据分析的重要性

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

3、缺陷数据分析的数据指标

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

常用的寻找缺陷的方法

页面大小

在B/S结构的软件系统中，当一个页面元素太多，未作精简时，在打开该页面时可能需要较长的加载时间，这对于软件性能是一个不小的影响，既增加了服务器的压力，又容易引起用户的反感。
例如：

• 图片未经压缩、格式不正确。比如采用BMP；
• 代码冗余，存在太多无用代码；
• 页面元素太多，太过复杂；

---

界面文字

页面信息描述不清楚，有语病，错别字。简单语言复杂化，描述不正确，不符合当前页面。错误的帮助信息，乱码等。

---

容错处理（功能缺陷）

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

• 用户输入错误，系统无提示，无响应，用户不能清晰知道系统不处理的原因；
• 给出信息提示，用户接受后无法继续操作，不给用户“改过自新”的机会；
• 用户输入不合法的信息后，系统给出提示，用户确定后，系统仍能处理错误的信息。
• 取消功能不能取消，比如删除，系统给出提示，是否确定删除，用户否认后仍执行了删除。

---

性能缺陷

这里所说的性能问题不需专业的工具就能发现的问题，这类问题在平常做黑盒测试的时候就能发现。
例如：

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

---

不同软件组织的缺陷管理过程

个体行为

处于CMM第一级（或称为初始级）的软件组织，对软件缺陷的管理无章可循。工程师们只是在发现缺陷后，修改相应的软件。通常，没有人会去记录自己发现的缺陷。也没有人知道在新的软件版本里，究竟纠正了哪些缺陷，还有哪些缺陷未被纠正。而且，只有在下一轮测试中才有可能知道那些所谓已被纠正了的缺陷是否真的被纠正了，更重要的是纠正过程是否引入了新的缺陷。
所以这样的软件组织的项目交货期（Release Date）表现出强烈的不可预测性。并且， 为了获得一个高质量的软件产品（如果能够的话），通常要在测试上花费大量的人力。

项目行为

在CMM第二级（或称为可重复级）的软件组织中，软件项目会从自身的需要出发，制定本项目的缺陷管理过程。一个完备软件缺陷管理过程通常会包括如下几个方面：
（1）提交缺陷
（2）分析和定位缺陷
（3）提请修改相应的软件
（4）修改相应的软件
（5）验证修改
项目组会完整地记录开发过程中的缺陷，监控缺陷的修改过程，并验证修改缺陷的结果。

组织行为

CMM第三级（或称为已定义级）的软件组织会汇集组织内部以前项目的经验教训，制定组织级的缺陷管理过程。并且，要求项目根据组织级的缺陷管理过程定制本项目的缺陷管理过程。
从而，整个软件组织中的项目都遵循类似的过程来管理缺陷。好的缺陷管理实践成为所有项目的实践，而教训也为所有项目所了解。更重要的是，随着组织的不断发展完善，组织的过程会得到持续性的改进，所有项目的过程也都会相应的改进。

持续优化

与CMM第四级相比，CMM第五级（或称为持续优化级）更强调对组织的过程进行持续性改进，从而使过程能力得到不断的提升。
就缺陷管理而言，软件组织应当在量化理解其过程能力的基础上，持续地改进组织级的开发过程、缺陷发现过程，引入新方法、新工具，加强经验交流，从而实现缺陷预防（Defect Prevention）。
缺陷预防的着眼点在于缺陷的共性原因（Common Cause）。通过找寻、分析和处理缺陷的共性原因，实现缺陷预防。
http://www.jira.cn/secure/Dashboard.jspa