这个故事当然是比较高兴的结局结束了，那么这个飞行器不断地把资料发回来，发回到我们这个星球上去，从太阳系来发回来。还有一些星球沿着火星轨道来运行的飞行器，这还有一个问题，这是一个集成的问题，这个集成问题我们也谈到很多。那么，在火星探测器里面也存在一个集成问题。两个团队之间用的不同系统，有的是用的米，有的是用英尺不同系统，他没有集成。所以，在飞行器飞行的时候给不同的指令，特别是一些关键的时刻出现问题，他实际上该进入轨道的时候突然之间就出现了一个火球在火星上。

　　还有一个90年代电信行业，AT&T他也有一个灾难性失败故障，特别是长途电话出现了鼓掌。在当时的话，长途电话比较昂贵，不像今天这么便宜。所以说他们出现故障之后会有大量的损失，然后他们就发现了一些问题，这个工程师尽量优化这个系统的性能。这个系统出现了故障就完全不能工作了，还有一些故事我跟大家分享一下，然后我再给大家讲课。

　　这是在太平洋上飞行的一些飞行器，他们也收集各种各样的资料，他们也是各种智能机器，会发回各种数据。那么在第一次发出数据的时候会出现很多迷惑的问题，他们不能进行沟通，不知道处于什么位置，就像丢失一样。他们需要回到安全的位置，有时候这些故障会在模拟的时候就出现，模拟也有一个好的方面，这是一个早期的飞行器型号。那么，这个飞行器它实际上飞行员不能够很好的控制飞行器。那么，这个时候可能会出现故障，很多情况下飞行员都可能会因为故障的原因处于比较危险的境地，所以我们要去发现各种各样的缺陷。

　　我们有时候进行模拟各种各样的模拟，如果是出现问题的话，飞行员就会丧命。所以，我们要充分保障这些工作。现在我们就来考虑一下我们应该去做什么？要去避免哪些灾难性的故障。我们需要进行检测来防止这些故障，这就意味着我们必须加以自动化，我们在随时能够加以检测，一旦我们做出变化的时候，我们需要去重新地检测。

　　那么，除非检测这个编码没有问题它才是没有问题的。在美国法律上除非证明你有罪，你一直假定是清白无辜的，对于编码我们也是这样认为的，除非你认为他没有问题，那他才真正没有问题。下面我给大家介绍一个模式，为什么我认为这个人工模式是不可持续。对不起我这有一个公式，实际上在进行测试是一个新的特性，他就是为了来开发这种特性功能。所以，我们进行一个测试努力，等于和这种合作功能付出努力是相等，我们现在可以讨论一下是对还是不对，我们可能是需要这么一个这种验证，我们来假设一下这个公式是一个定量，就好象这张图上一样。如果他花10个人手才能够来开发一种新的能力，那么我们可以说我们需要2个人来测试这个新的特性，10个人来进行开发，2个人来进行测试。

　　那么，我相信这么一个比例。但是，我们可以说这是一个比较保守的估计。所以说软件是非常的脆弱，对不起我这里引入的不是非常完整，Grady先生做过一个研究，他说25%在你错误表里面的错误，都是来自于负作用，都是一些比较偶然，一些新的特性在添加的时候可以用，但是没有人知道他实际上带来其他东西。比如在你的表里面有四分之一都是来自这个来源，这是调研的一个结果。

　　同时，这意味着从而导致一个结果，那么这里有一个更加复杂的公式来解决这种情况。我们来测试这个努力，他是在Etn里面一个新的努力测试，我们需要把别的东西都在重新测试一遍。我想可能我应该写出那么好的公式，应该是一个好的作家，什么意思？一个非常简单模式，这些简单模式有时候是错误，但是可以给我们展示一个要点，如果我开发一个系统在第一次里面并没有新的现有代码，这就是我们整个世界情况。

　　我们有一些现有代码，所以这个regeession测试就是零，我们在进行测试时间，所以这就意味着在测试时间里面，在每次都要上升50%，这样我们就有一个测试方面不持续的需求。我知道很多人在中国，我们预算有限不能往里面不断加入，就算可以这么做，预算也不允许。这就意味着我们还有很多未测试代码差距，我们应该测试的代码没有进行测试。所以说，这些没有测试的代码就出现意味着我们会出现Bug，会出现一些缺陷。

　　好的，那是不是就意味着，可能我们应该不断进行再次测试，或者说我们到最后再进行这个测试是不是可以，非常有趣的一个想法。曾经有人这样试图过，试过很多次，这里是另外一系列遇到的错误。比如美国政府计算机系统保留一些犯罪记录，然后100%一些都是存在这些问题。我们大家可能也听说过一些这种美国一些机场出现的问题，比如美国有一个非常漂亮的机场，他们花一年时间才能使整个系统运转起来，他还花了一天100万美元才能把这个系统进行重建，出现了怎样一个情况，怎样一个错误呢？

　　如果我们最后来进行测试会出现非常糟的情况，我们大家可能都认识这么一个图表，它实际上是一个瀑布，我们不知道这里存在什么问题，这个问题本质又是什么呢？这个问题就是说，最后会出现一些不可确定性。我们必须要进行测试，才能够找到出现什么样的问题。这里燃起了大火，最后会出现着火紧急事情。如果在计划当中，有这种情况可能就不是问题，但是这个Bug是出现在你消除了这个Bug之后，又出现更多的Bugs。你可以告诉我说，最后这边可以一直出现什么，对一直出现，永远都不知道这些Bugs才会终止，把我们的开发在这个程序进行设计的时候，我们要发现Bugs进行测试，可能你发现Bugs并不感觉惊讶，这是我们进行测试的一个工作。

　　但是如果我们用不同的方法来工作会出现怎样一个情况呢？如果我们在测试当中，把代码进行测试可能有时候找不到，但是我们有时候把这些Bugs重新邮寄给我们开发员，如果我们进行通力合作，这些测试就变成一种需要做的工作描述，或者说是一种规格，我们应该使用什么样的测试来定义，到底我们在这样的情况下做怎样的工作，这才是一个最主要的话题。不会改变很多我们做事的方法，一个做的不好测试人员站在瀑布底下就会压死，但是在瀑布底下所有压力都压在他身上，我们使测试人员更加主动往上走一步。

　　一个非常有名计算机学家Edsger Dijkstra说过，真正获得软件他们会找到避免Bugs的方法，这是最初一步。最终整个编程过程成本最低，如果你想要更加有效程序员，你将会发现他们不应该浪费自己的时间来做调试，他们不应该来引入，在最早的时候就不应该引入Bugs。这是说起来非常简单，但是做起来却难了。我并不认为，Dijkstra先生给了我们一个该怎么做这个事情的建议，但是我建议说有这么一个可能性，就是测试和开发，可以来实现他梦想的一个主要技术。