软件测试|软件缺陷管理——测试人员必会

软件缺陷定义

软件缺陷（Defect），常常又被叫做Bug。 所谓软件缺陷，即为计算机软件或程序中存在的某种破坏正常运行能力的问题、错误，或者隐藏的功能缺陷。缺陷的存在会导致软件产品在某种程度上不能满足用户的需要。IEEE729-1983对缺陷有一个标准的定义：从产品内部看，缺陷是软件产品开发或维护过程中存在的错误、毛病等各种问题；从产品外部看，缺陷是系统所需要实现的某种功能的失效或违背。

产生原因以及根

在软件开发的过程中，软件缺陷的产生是不可避免的。那么造成软件缺陷的主要原因有哪些？从软件本身、团队工作和技术问题等角度分析，就可以了解造成软件缺陷的主要因素。

软件缺陷的产生主要是由软件产品的特点和开发过程决定的。

软件本身

1.需求不清晰，导致设计目标偏离客户的需求，从而引起功能或产品特征上的缺陷。

2.系统结构非常复杂，而又无法设计成一个很好的层次结构或组件结构，结果导致意想不到的问题或系统维护、扩充上的困难；即使设计成良好的面向对象的系统，由于对象、类太多，很难完成对各种对象、类相互作用的组合测试，而隐藏着一些参数传递、方法调用、对象状态变化等方面问题。

3.对程序逻辑路径或数据范围的边界考虑不够周全，漏掉某些边界条件，造成容量或边界错误。

4.对一些实时应用，要进行精心设计和技术处理，保证精确的时间同步，否则容易引起时间上不协调，不一致性带来的问题。

5.没有考虑系统崩溃后的自我恢复或数据的异地备份、灾难性恢复等问题，从而存在系统安全性、可靠性的隐患。

6.系统运行环境的复杂，不仅用户使用的计算机环境千变万化，包括用户的各种操作方式或各种不同的输入数据，容易引起一些特定用户环境下的问题；在系统实际应用中，数据量很大。从而会引起强度或负载问题。

7.由于通信端口多、存取和加密手段的矛盾性等，会造成系统的安全性或适用性等问题。

8.新技术的采用，可能涉及技术或系统兼容的问题，事先没有考虑到。

团队工作

1.系统需求分析时对客户的需求理解不清楚，或者和用户的沟通存在一些困难。

2.不同阶段的开发人员相互理解不一致。例如，软件设计人员对需求分析的理解有偏差，编程人员对系统设计规格说明书某些内容重视不够，或存在误解。

3.对于设计或编程上的一些假定或依赖性，相关人员没有充分沟通。

4.项目组成员技术水平参差不齐，新员工较多，或培训不够等原因也容易引起问题。

技术问题

1.算法错误：在给定条件下没能给出正确或准确的结果。

2.语法错误：对于编译性语言程序，编译器可以发现这类问题；但对于解释性语言程序，只能在测试运行时发现。

3.计算和精度问题：计算的结果没有满足所需要的精度。

4.系统结构不合理、算法选择不科学，造成系统性能低下。

5.接口参数传递不匹配，导致模块集成出现问题。

项目管理的问题

1.缺乏质量文化，不重视质量计划，对质量、资源、任务、成本等的平衡性把握不好，容易挤掉需求分析、评审、测试、等时间，遗留的缺陷会比较多。

2.系统分析时对客户的需求不是十分清楚，或者和用户的沟通存在一些困难。

3.开发周期短，需求分析、设计、编程、测试等各项工作不能完全按照定义好的流程来进行，工作不够充分，结果也就不完整、不准确，错误较多；周期短，还给各类开发人员造成太大的压力，引起一些人为的错误。

4.开发流程不够完善，存在太多的随机性和缺乏严谨的内审或评审机制，容易产生问题。

5.文档不完善，风险估计不足等。

缺陷状态

1.Submitted: 已提交的缺陷

2.Open :确认“提交的缺陷”，等待处理

3.Rejected: 拒绝“提交的缺陷”，不需要修复或不是缺陷

4.Resolved :缺陷被修复

5.Closed :确认被修复的缺陷，将其关闭

缺陷的严重程度等级划分

1.Critical：不能执行正常工作功能或重要功能。或者危及人身安全。

2.Major：严重地影响系统要求或基本功能的实现，且没有办法更正。（重新安装或重新启动该软件不属于更正办法）

3.Minor：严重地影响系统要求或基本功能的实现，但存在合理的更正办法。（重新安装或重新启动该软件不属于更正办法）

4.Cosmetic：使操作者不方便或遇到麻烦，但它不影响执行工作功能或重要功能。

5.Other：其它错误。

缺陷的优先级

1.Resolve Immediately：缺陷必须被立即解决。

2.Normal Queue：缺陷需要正常排队等待修复或列入软件发布清单。

3.Not Urgent：缺陷可以在方便时被纠正。