本书写的Bug来自各个领域，如军方导弹、科研火星探测器、医疗仪器、网络、汽车行业等，错误来源各有不同，小到数据类型不匹配、数据转换错误，大到复杂度超过50的代码，Bug造成巨大的经济影响、危害生命，每个类子都值得铭记，避免类似功能时出现同样的错误。
　　1、“爱国者”导弹拦截系统因0.000000095的误差拦截导弹失败，造成28人因此丧命。
　　“爱国者”雷达系统工作流程：探索阶段、验证阶段、跟踪阶段，在跟踪阶段会等对方的导弹进行拦截，“爱国者”导弹系统如果连续工作超过8小时，射程就会偏离正常位置20%，这是个已知的软件缺陷，但美国军方不认为“爱国者”导弹会持续工作超过8小时，而实际情况是持续运行了100小时。
　　系统每1/10秒就进行一次乘以1/10的运算，运算通过24位的固定小数点寄存器进行的，计算机是二进制而非十进制，1/10转换成二进制就是0.00011001100110011001100...，无穷尽，但系统会舍去25位以下的数字，只保存24位，那么每计算一次，就会舍去0.0000000000000000000000011001100（按照十进制的话约为0.000000095）的误差
　　运行100小时的误差=0.000000095 x 100（小时）x 60（分） x 60（秒）x 10（每秒进行的除法运算）=0.34秒的误差
　　导弹飞行时速是非常快的，0.34秒的误差拦截的扫描则偏离目标687米，拦截功能形同虚设。
　　程序明确有错时，应该找到错误，并修复，而不是假设使用者能遵循某个规定。
　　2、火星探测化为尘埃，数亿美元在太空中打了水漂。
　　起因为计量单位不一致，MCO和SM_FORCE程序之间，一个使用的是牛顿，一个使用的是磅力（1bf，约等于4.45牛顿）
　　统一单位是多么重要呀，是在需求时就需要明确规定的。
　　3、AT&T长途电话系统瘫痪，数千万美元损失和公司形象荡然无存。
　　起因是一行代码导致，交换机内部掌握着相邻交换机的状态信息，当交换机遇到错误时是有自动重启功能的，相邻的交换机会知道它正在修复，但问问恰恰是相邻交换机1/100秒就会收到2个消息，第一次消息还没有处理完，第二次就消息就来了，导致软件故障产生，故障慢慢蔓延的整个网络。
　　事件需要个全过程，一个未处理完时，新来的需要等待。
　　一件事情，如果不能测试，那就不要开始。
　　4、大停电事件
　　起因是多个进程访问同个共享资源，数据结构遭到破坏，预警处理陷入无限循环，无警告则人们无法得知实际情况，导致情况越来越严重，而预警队列越来越长，内存耗尽而机器宕机，备用机器同样因这个原因出现故障
　　数据需要保持一致性，读写时需要加锁和回滚功能
　　5、战舰“约克城”
　　起因是Divided by Zero错误，没有哪个数字可以被0整除，操作员输入0后部分程序就无法工作啦。
　　在执行功能前，需先做数据合法性进行校验
　　6、好奇心的“莫里斯蠕虫”
　　莫里斯想知道互联网有多大，有多少机器在连接着，于是设计了一个程序，程序中有个致命的漏洞，入侵其他计算机前，程序会先询问是否已运行了莫里斯的程序，得到响应为yes 则不执行。莫里斯为了防止系统管理员使计算机假装响应“yes” 拦截自己程序的扩散，莫里斯将程序改成即使得到“yes”响应，仍按1/7概率进行复制。
　　1/7的概率使得1台机器上运行N个蠕虫程序，导致计算机超负荷而崩溃。
　　运行一次可能不会碰到1/7的概率，但是运行多次后总会碰到的，写程序不要只考虑一次运行情况，而是考虑多次运行情况，不测试不能上线。
　　7、战机坠毁
　　同一个飞行员两次试飞失败，这是坑飞行员呀！
　　8、70亿美元的烟花秀：阿丽亚娜5号
　　起因：沿用旧软件（SRI），该软件在阿丽亚娜4号成功发射过113次火箭，而阿丽亚娜5号认为旧的软件已经是OK，实践已经证明，不用在测试啦。
　　阿丽亚娜4号往SRI输入的是16位元整数数据，阿丽亚娜5号往SRI输入的是64位元浮点数数据，数据转换时溢出啦。
　　接口是需要测试的，不能盲目重复软件模块
　　9、软件可用性差，军用战舰击毁民用客机
　　在软件界面上 如不能形象表示，也应该和平常习惯保持一致，而不是等使用者看到数据后再进行转换。客机明明在向上爬升，但战舰上的操作员却认为客机在下降位置，被战舰以为是降低高度以便作战。
　　软件无法使用 和 软件错误 是没有区别的。
　　10、时间的计算
　　无法计算闰年，年份只算了四位中后两位，16位数据结构-从1900年1月1日到1989年9月19日是32768天-程序无法处理。

　　11、游戏的Bug
　　"哈卡"的“堕落之血” 在一定范围内具有传染性，接触者会以250-300点的速度不断消耗体会，玩家自己是不能解除这一魔法的，好些玩家召回在“哈卡”作战区的宠物，被传染的宠物继而传染其他人，事情变得无法控制，被传染越来越多，弱小的玩家纷纷死去。
　　只能说游戏设计的很真实
　　12、核武器
　　软件有缺陷，但幸好有佩特罗夫，一位冷静爱好和平的人，值得全世界人尊敬
　　13、医疗仪器杀人事件
　　当遇到故障时人们往往根据经验去判断，然后得出无法解释现象的解释。遇到错误时需要将流程中可能影响的环节都检查一次，就不会出现Therac-25连续出现6次事故后才去找原因。
　　软件过程中内部错误代码不应该直接显示给使用者看，需要翻译成使用者能懂的语言（错误提示需要明确易懂）
　　14、消失的火星探测器
　　原因同13事情类似。电池管理软件将电池过热认为是电源已满，主动切断了充电电流。真实原因是：电池正面向太阳 造成的过热。最后因电量不足电子仪器停止了工作。
　　一个现象可能是由N个原因引起的，需要做多一层的判断来做验证确认。
　　15、金融软件bug
　　四舍五入惹得祸
　　16、软件本可以阻止的飞行事故
　　对飞机来说低于多少米还没有找到跑道是件非常危险的事情，这类情况 就应该有软件强制行为，人可以操作机器，但机器也需要设计的更加智能化，而不是一味让人来控制。
　　17、153亿美元的彩票：数字预算会计系统
　　我一直坚信机器不会撒谎，当遇到很妖孽的现象时就会变得非常的兴奋，里面一定隐藏了问题，要把它挖出来，挖出来。我已习惯用打开计算器或打开Excel表格去计算一切关于数据的事情。
　　18、丰田汽车“踏板门”事件与软件
　　当商品已对人身造成伤害时 就需要被列为特级关注，从头到尾的仔细调查取证，而不是简单定义为 人为操作错误。
　　读完这本书 心情变得很沉重，受不了那么多投入（人力、物力、财力）换回来的是一场烟火，更甚至是好些人的生命。
　　软件测试在没有错误面前总是显得无足轻重，可一旦错了，调查、赔偿、责任这些和前面的投入算得了什么呢？
　　找出一个致命Bug，它的价值是无价的，做为软件测试的一员需要时刻怀着无比的敬畏精神，为之前项目投入的时间不被浪费，为之前项目投入的资源不被浪费，为之前项目投入的财力不被浪费，为之后项目能真正被使用，为做的事情变得有意义...