报告变少，可能是工具更好了，而不是缺陷更少了
缺陷数量看起来变少的一个原因，是检测和诊断的成本降低了。一项关于开源软件缺陷特征的实证研究发现，缺陷检测工具能有效减少诊断工作量，这意味着问题在被堆积成可见报告之前就被识别和处理了 [3]。当工具能精确定位出错的代码时，一个缺陷可能一次就被修好，而不是一直挂在那里成为未关闭的工单。
代码仓库的记录也显示处理速度在加快。一项对软件缺陷仓库长达15年的分析报告称，缺陷解决时间有所缩短，在所评估的系统中平均每个缺陷少用4.3天 [1]。解决速度加快缩短了缺陷处于开放、可被计数状态的时间窗口，所以即使引入的缺陷数量相同，积压看起来也更少。
趋势线统计的是报告，而报告是一种选择
缺陷趋势通常是根据缺陷报告构建的，而只有有人提交，报告才会存在。分析缺陷报告的工具明确以识别薄弱环节为目标，以便团队采取预防措施、减少未来的缺陷 [4]。这个目标很合理，但这也意味着被追踪的指标——报告——会响应分诊策略、去重和预防工作，而不只是反映底层的缺陷率。
学生项目的数据在更小的规模上说明了同样的道理：研究人员量化了缺陷随时间开启和关闭的趋势，而不是把原始计数当作固定的事实 [2]。一条下降的曲线可能反映更健康的流程、更严格的报告门槛，或者两者兼有。单看数字并不能告诉你到底是哪一种。
有些类型的缺陷确实变得更少见了
这种下降并不纯粹是统计口径造成的。那项开源研究发现内存相关缺陷有所减少，这类缺陷历史上会导致崩溃和内存泄漏 [3]。这是缺陷类型构成上的真实变化，与针对这类问题的检测和预防手段的改进是一致的。
不过并非所有类别都走同一条路。同一项研究指出，并发缺陷——涉及时序和并行执行的缺陷——的趋势并不符合普遍认知，这说明某些棘手的缺陷类型并未随大趋势下降 [3]。所以答案取决于你在数的是哪些缺陷。
这些证据能说明什么，不能说明什么
现有证据支持的结论比“缺陷正在消失”要窄：解决速度更快了，某些缺陷类别更少见了，工具帮助团队更早地发现和预防问题 [1][3][4]。但它并不能证明软件中缺陷的总数下降了，因为这些研究追踪的是仓库活动和缺陷特征，而不是真实的缺陷总体。
对普通读者来说，实用的启示是把一个安静的缺陷跟踪器当作流程的信号，而不是质量的证明。可见缺陷变少，既符合工具更好、修复更快的情况 [1][3]，也符合依据缺陷报告分析来指导预防工作的情况 [4]——但它也可能意味着问题在被报告之前就被捕获了，或者根本没有被报告。
本文引用的文献
挖掘软件缺陷仓库：缺陷定位、分类、分诊与解决的趋势、技术和局限的15年分析（2010 …
一项对软件缺陷仓库长达15年的分析报告称，缺陷解决时间有所缩短，在所评估的系统中平均每个缺陷少用4.3天。
从本科软件工程课程的学生项目中挖掘软件仓库流程
挖掘本科软件工程课程的学生项目仓库数据，产出了量化缺陷随时间开启和关闭趋势的指标。
现在情况变了吗？对现代开源软件缺陷特征的实证研究
一项对现代开源软件缺陷特征的实证研究发现内存相关缺陷有所减少，并指出并发缺陷的趋势并不符合普遍认知。
MultiDimEr：一个多维缺陷分析器
一个多维缺陷分析工具能识别产生最多缺陷的组件，并分析缺陷报告趋势以指导预防措施。