软件缺陷的预防方法

1).评审

软件缺陷很大一部分是来自于对需求的定义和理解不正确，包括需求或设计本身是否有风险或疏漏、是否存在与既有系统冲突之处、是否存在描述不清等情况。在软件实现之前，评审是最有效地去除缺陷的手段，而越早去除这些潜在的缺陷，所需的代价也会越小。

案例：2011年7月23日20时30分05秒，甬温线浙江省温州市境内，由北京南站开往福州站的D301次列车与杭州站开往福州南站的D3115次列车发生动车组列车追尾事故，造成40人死亡、172人受伤，中断行车32小时35分，直接经济损失19371.65万元。事故是由于温州南站信号设备在设计上存在严重缺陷，遭雷击发生故障后，导致本应显示为红灯的区间信号机错误显示为绿灯。

分析：这起事故既暴露出信号系统设计上的缺陷：没有设计应急情况下备份控制系统，也没有设计应急情况紧急通信系统。同时也反映出故障发生之后，应急处置不力以及安全管理上存在的漏洞。如果在需求设计时想到这种突发事件的情况，这起事故确实是一起不该发生的、可以避免和防范的责任事故。

2).重构

当开始代码实现之后，程序员会发现随着对业务需求更深入的理解，代码的结构可能会变得不合时宜；或者代码的结构有些臃肿，这时就需要对代码进行重构。因为重构是在测试之前，程序员主动地重构，就会预防因为代码变坏而产生更多的缺陷。

案例：千年虫（千年问题）是计算机系统的编码问题，在从1999年12月31号过渡到2000年1月1号时，这个错误将在计算机网络和软件中引发一场浩劫，损失5000亿美元。

分析：为了节省计算机存储空间，大多数传统软件使用两位数字来存储日期中的年份，例如，用“97”来代表1997年。这导致了2000年1月之后日期相关程序的错误操作。此外，有些程序没有考虑到2000年是闰年。甚至在2000年到来之前，人们都在担心一些软件可能在1999年9月9号（表示为9/9/99）无法工作，因为早期的开发人员常使用一系列的9来表示一段程序代码的结束。

3).功能测试：多轮测试
形式上，应该进行多轮测试，注意，功能应该覆盖完全，确保可以实现正确的流程；但与此同时，应该确定错误，并不断保证缺陷尽可能少。

案例：1996年6月4日，阿丽亚娜5型运载火箭的首航，原计划将运送4颗太阳风观察卫星到预定轨道，但因软件引发的问题导致火箭在发射39秒后偏轨，从而激活了火箭的自我摧毁装置。阿丽亚娜5型火箭和其他卫星在瞬间灰飞烟灭。此次事故损失3.7亿美元。
分析：事故原因是代码重用。阿5型的发射系统代码直接重用了阿4型的相应代码，而阿4型的飞行条件和阿5型的飞行条件截然不同。在4型火箭系统中，对一个水平速率的测量值使用了16位的变量及内存，因为在4型火箭系统中反复验证过，这一值不会超过16位的变量，而5型火箭的开发人员简单复制了这部分程序，而没有对新火箭进行数值的验证，结果发生了致命的数值溢出。因此，飞行器在发射后37秒便从原始路径偏移，最终不得不启动了火箭自毁程序。

4).极限测试
对网络访问压力、系统最大限制压力等各种极端情况，进行极限测试。极限测试不一定要确定最后系统可以完成极限测试，但一定要摸清楚自己系统可以承受的极限，以及整个系统遇到极限压力的时候的恢复情况。
案例：在IE4.0的开发期间，微软为了打败Netscape而汇集了一流的开发人员和测试人员。测试人员搭建起测试环境，让IE在数台计算机上持续运行一个星期，而且要保障IE在几秒钟以内可以访问数千个网站，在无数次的试验以后，测试人员证明了IE在多次运行以后依然可以保障它的运行速度。而且，为了快速完成IE4.0的开发，测试人员每天都要对新版本进行测试，不仅要发现问题，而且要找到问题是哪一行代码造成的，让开发人员专心于代码的编写和修改，最终IE取得了很大的成功。

5).复用

软件复用的前提，是已经有了经过验证和确认正确的可复用的构件。如果软件都是由这些构件组成的，那么这些功能模块本身是没有缺陷的，从而就会使集成起来的软件的缺陷也大大降低。

6).原因分析

对于软件开发来说，把软件研制过程中发现的问题进行统计分析，找出问题产生的根本原因，制定出对应的纠正措施，可以使新开发的软件避免出现重复的问题。

我们应当要求所有新开发的软件在开发之前先去查找同类软件之前发生过的问题，对应的解决措施，在软件设计和实现时，吸取教训，完善设计，以达到预防缺陷的目的。

7).主动异常测试
应该主动进行异常功能或异常值测试，确保软件系统可以应对各种异常情况。

8).紧急情况预案和方案
应该有应对紧急情况的预案和方案。预案和方案应该包括如下：
1）数据安全预案和方案，包括数据库的备份，以及应急数据库；
2）网络访问预案和方案，包括如何应对访问压力，以及均衡方案；
3）应急小组责任人方案，确定应急小组的责任人，以及权力责任。

来源：m0_56532936