为什么软件会出现缺陷

软件为什么会出现缺陷呢？程序的世界只有对和错两种逻辑，遇到分歧时只能选择一条路走，这就需要开发人员考虑所有情况并为程序指明道路，但由于时间、精力、成本等限制因素，开发人员不可能穷举所有情况，这就像出工作方案一样，要考虑的因素无穷无尽只能择优选取，没考虑到的地方就是安全隐患。

当然，问题不全出在开发人员身上，还存在与代码逻辑无关的问题，比如设计不合理，产品没有需求文档或者产品与研发沟通不充足出现理解偏差，再比如某些配置类平台，运营配置不当引发了软件缺陷。

经过对近 400条缺陷进行分类统计，对造成缺陷原因分为以下几类：

1. 代码逻辑问题引入缺陷 50%
   1. 迭代变更引发的缺陷 40%
   2. 旧代码隐藏的缺陷 10%
2. 产品设计引发的缺陷 25%
3. 其他缺陷 25%
   1. 配置不当造成的缺陷 20%
   2. 上下游平台不兼容造成的缺陷 5%

代码逻辑错综复杂，开发人员不可避免地会引入缺陷，逻辑缺陷根据代码修改的时间，还可以细分为迭代变更引发的缺陷和旧代码隐藏的缺陷。迭代变更引发的缺陷是指由于最近代码变更引入了新的缺陷，对近 2 年的缺陷数据进行统计发现，这类缺陷占比 40%，是名副其实的问题大头。比如最近有个新平台要交付，交付到运营后问题频发了 5 次，全是开发人员拆东墙补西墙造成，西墙好了东墙塌，站会天天拉问题天天有！ 再拿线上问题止血举例，若线上出了问题，最快最有效的止血方案是回滚新迭代，能解决 95% 以上的问题。第 2 类代码逻辑缺陷是旧代码隐藏的缺陷，这类缺陷的占比与平台的存活时间和用户使用量成正相关，比如一个稳定运行了 10 年的平台，这类缺陷占比远低于 10%，而一个刚上线不到 1 周的平台，这类缺陷占比远高于 10%。再比如平台仅开量 1%，用户使用量并不大，旧代码引发的缺陷能维持在 10% 以内，但若平台 100% 开量，甚至用户量发生爆发式增长（200%），引代码引发的缺陷量一定会大于 10%。

产品设计引发的缺陷占比 25%，是否还记得上一节提到的图片上传按钮，用户看到上传按钮就想当然地认为支持所有图片格式，于是引发了格式不兼容的缺陷，这种问题本质上可通过优化设计来避免。为什么设计问题占比这么高？因为产品设计好坏没有一个硬性标准，功能的优劣完全靠主观进行判定，甚至有些产品没有写需求文档，平台功能靠口头相传，研发也常常因新功能上线为由拒绝优化设计问题，难用的功能用久了就习惯了，危险也就孕育而生，设计引发的问题不容小觑。

其他缺陷占比 25%，其中配置不当造成的缺陷占比 20%，开发为方便操作，将一些常用功能做成配置，修改配置会立即生效到上线。配置不像代码，代码修改后要进行 CodeReview，上线前要进行预发、测试、灰度等一系列监管流程，任一环节出问题都会停止上线，而修改配置没有有效的监管，甚至不需要审批，改完即生效！过去一年里，自己团队因配置引发的重大问题至少 3 起，配置问题也不容小觑。最后一类问题是上下游不兼容造成的缺陷，仅占比 5%，不做过多介绍。

更多内容请关注公众号：测试员。