近几天被单元测试发现的问题是不是缺陷给困扰了，我一直在想单元测试发现的问题为什么不记录到缺陷管理系统？记录的缺陷管理系统有什么用，会有什么影响？为什么要记录缺陷，到底什么是软件缺陷？

缺陷

《宋史·李沆传》：“身食厚禄，时有横赐，计囊装亦可以治第。但念内典以此世界为缺陷，安得安满如意，自求称足？”

缺陷，汉语词汇，拼音是quē xiàn，本意指欠缺；缺失；不完美。  在晶体学、质检等不同领域又有着不同的含义。出自《宋史·李沆传》。

这么看来，缺陷就是一个不好的点，在软件交付过程中的任何部分，只要是不完美，都可以称之为缺陷，业务不完美、需求缺失、开发设计欠缺，测试不完美、运维欠缺等等，如果依据这个定义，那么缺陷就是一个贯穿全部软件交付生命周期的概念了。 但是，在IT行业，软件缺陷却不是这样定义，在下面是三个队软件缺陷的定义：

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

从上面三部分的定义可以看出，软件缺陷都是响运行后影响某些正常或者预设行为的情况，在从开发阶段开始就有可能引入了缺陷。

为什么要缺陷管理

从上面的定义我们可以看出，大部分的软件缺陷的约束都是在运行态之下的定义了。那么再反过来讨论一下，单元测试发现的问题要不要记录到缺陷系统里，要讨论这个问题我们就看一下我们为什么要统记录缺陷、管理缺陷呢？

• 百度百科：缺陷管理是在软件生命周期中识别、管理、沟通任何缺陷的过程（从缺陷的识别到缺陷的解决关闭），确保缺陷被跟踪管理而不丢失。一般的，需要跟踪管理工具来帮助进行缺陷全流程管理。

说白了，就是在发现缺陷后，要记录缺陷的是怎么产生的、是怎么修复的以及确认是不是这的没有了。那么这里就会涉及到好几个人，有开发工程师、测试工程师、产品经理甚至有时候还有运维工程师，每个人做了上面这个缺陷生命周期的不同部分的工作，因此我们需要管理缺陷，确定每一个缺陷都经由缺陷生命周期的全流程，最后验证通过而关闭。

上面是一个中典型的缺陷处理流程，有缺陷发现人员提交缺陷，并分配给有能力修复这个缺陷的人，然后有对应人员确定是不是一个缺陷，如果不是就拒绝，这样缺陷就关闭了。如果是一个缺陷就来确定是不是可以修复，可以修复就修复完后将缺陷设置已修复状态，有缺陷发现人员再次验证没有问题后关闭该缺陷，至此一个缺陷的生命周期就结束了。这个流程往往要经过前面说的多个角色的多个人。这么多人如果坐在一起，靠口口相传也是可以的，但是后来发现这些角色之间往往是多对多的关系，因此必须有一种工具记录着缺陷的流转状态，这就是缺陷管理系统的出现，当然有些人非要用电子表格我也不能说不对。

有了缺陷管理系统我们就可以衡量很多和缺陷相关的指标，例如缺陷修复时长，千行BUG率（虽然被很多人唾弃）等等。

单元测试部分的问题要不要记录缺陷管理系统

上面我们说了为什么要管理缺陷和为什么有缺陷管理系统。那么下面我们再看看开发的工作过程，开发在写代码的时候会不断的调试，那么开发的工作产出包含两类代码，一类是实现业务的代码，一类是单元测试，那么单元测试的开发也是在不断的调试中完善的。按照正常做法开发工程师本地调试成功、单元测试测试通过，就可以push 代码到代码仓库的feature分支了，因此如果本地单元测试是fail，开发会继续调试单元测试代码然后去修改这种情况并不能算是软件缺陷，只能算是开发调试。

如果合并feature分支到开发主干的时候单元测试失败了，那么持续集成流水线就失效了，开发会讲对应的问题修改掉然后在继续持续集成，这个时候还是处于开发调试阶段，被测系统还没有运行，因此也不是软件缺陷。但是这个时候我们绝大部分会衡量流水线恢复的时间来作为研发效能的一个度量指标。只有走完持续集成后进入持续交付、持续部署的过程中发现的问题才叫缺陷，部署后有损失（这里的损失很多公司是以资损衡量的，但是这却不是唯一的划分方法，具体还应该以系统影响的根本考核点为准）一般称为故障。

换个角度，如果我们将单元测试问题也算缺陷，那么开发从发现到修复时间会很短，这样也为我们度量团队研发效能的缺陷修复时长指标带来很多的噪音。

因此无论从合理使用还是从合理度量的角度，绝大部分情况不把单元测试的问题叫做缺陷，因为也就没有必要记录的缺陷管理系统了。但是这并不是一概而论的，如果有自己的度量的需求或者其他的需求，也是可以通过自动化手段将单元测试发现的问题自动的提交到缺陷管理系统的。