以缺陷的角度理解开发过程

平时我们提到软件开发生命周期，或开发模型，通常指的是软件开发的每个阶段需要完成的活动，以及这些活动是按照什么逻辑和时间顺序与其他活动进行关联的。本文将从另外一个角度：错误、缺陷、失效、根本原因和影响等方面解释整个过程。

每个人都会犯错误，例如：假如你在学习需求过程中，发现这么一条需求：if X no more than 10, then do S1。根据你掌握的英语知识，你认为变量X应该是小于10。基于这个理解，你通过代码实现该需求（仅供理解）：

if (X < 10) {

S1;

}

大家知道上面的需求中，正确的理解应该是X小于等于10。由于你在理解过程中犯了一个错误，导致在对应的软件代码中引入了缺陷。由于代码中存在缺陷，在运行过程中就有可能出现实际结果与期望结果不一致的情况，此时就会导致失效的出现。再延伸一下，写代码之前，由于对需求的理解错误，也有可能会在架构设计和详细设计中继续引入缺陷。简单总结一下，由于你的英语理解错误，导致在架构文档、详细设计文档和代码中引入了缺陷，而在执行过程中导致失效。即通过静态测试可以发现缺陷，而通过动态测试发现的是失效。

除了输出的软件工作产品中的缺陷会导致失效之外，环境条件也可能导致失效，例如：辐射、电磁场和污染等都有可能引起固件中的失效， 或者由于硬件环境的改变而影响软件的执行。

另外，代码中存在缺陷，运行带有缺陷代码时并不代表失效一定会出现。例如：上面的代码中前面添加一行“X = 11”，而这行代码也是一个缺陷（实际代码应该是X = 9），假如S1语句也是一个缺陷。那么由于存在“X = 9”这个缺陷，导致S1中的缺陷完全没有办法发现，这就是缺陷屏蔽。假如通过测试发现了“X = 11”这个缺陷，修改完这个缺陷之后，那么S1中的缺陷也可能被发现。这也可以解释为什么在修复缺陷之后进行的回归测试过程中，可能会发现新的缺陷。这个新的缺陷除了可能是由于变更导致而引入之外，也有可能是发现了被屏蔽的缺陷。

测试执行过程中发现了失效，接下来开发人员需要定位和修复该问题，此时开发人员需要找出是什么缺陷导致了失效的发生，并在对应的文档中进行修复。而后测试人员进行再测试和回归测试。那么，从整个开发过程而言，是否再测试和回归测试之后就结束了呢？答案是否定的，因为我们还需要找到引入缺陷的根本原因。缺陷的根本原因是导致缺陷产生的最早的行为或条件，通过分析缺陷并找出其根本原因，以减少类似的缺陷以后再发生。通过将关注点放在最重要的根本原因，根本原因的分析可以促进过程的改进，从而防止将来引入大量的类似缺陷。在本案例中，根本原因是英语知识的不够踏实。为了在将来的开发过程中不再犯同样的错误，过程改进的措施是对我进行针对性的英语培训。

错误、缺陷和失效的关系，可以通过下图表示，从图中你会发现从引入缺陷再到发现失效，然后查找、定位和修复缺陷，再找到出现的缺陷的直接原因，整个过程形成了可以不断得到改进的闭环。

但是，动态测试过程中发现的异常行为，并不一定都是失效。由于测试执行方式的原因，或者由于测试数据、测试环境或其他测试件的问题，可能会出现假阳性结果False - Positive （误报），即将测试结果中报告了被测对象中实际不存在的缺陷。相反的情况也会发生，由于测试人员技能方面的不足，可能会导致假阴性结果False - Negative（漏测），即测试结果中未能发现被测对象中存在的缺陷。假阴性结果指的是没有发现测试应该要发现的缺陷；假阳性结果记录为缺陷，但实际上并不是缺陷。

再举个例子，假设由于一行不正确的代码，银行支付了错误的利息，导致了客户投诉。由于产品所有者对如何计算利息有误解，所以为模糊的用户故事编写了有缺陷的代码。如果在利息计算中存在很大比例的同类缺陷，并且引发这些缺陷的根本原因来源于类似的误解，那么需要为产品所有者进行利息计算相关主题的培训，以便在未来减少这类缺陷。

下图是针对上述场景的图形描述，你能分别找到错误、缺陷、失效、根本原因和影响是什么吗？大家可以尝试理解一下，在评论区告诉我你的理解。