但是我认为在很多环境中TDD都是可以用的，所以说这个不能用的这么一个表变成了可以用的表。所以，我们应该怎么做呢？我必须要填这么一个空格，这样我就会对一些嵌入式的值，比如说我们需要对一些硬件的设施进行一些工作，我们不能做TDD。或者你可以做TDD，我说是的我可以，我们有自主性，然后我们还做了一些财务的软件，还有一些客户的数据库。然后我们还建设了一些客户的消费软件，我们还建一些网站。是的你是有这种自主性的，我们可以使用这样的一个技术来解决各种不同的问题。所以说，在回到嵌入式当中，如果刚好有一个嵌入式系统，那么我们可以通过一些展示来进行互动，这边有一个屏幕，有一些电话网络，还有一些控制板，以及与外部世界进行连接，我唯一做到的方法就是通过实质的设备来实现，我可以进行人工的测试，但它不是一个完整的测试。

　　我需要做的事情就是，我有点迷惑，我的话都乱了，我不知道怎么办？可能有几个幻灯顺序错了，这有一个盒子，这是一个灵活性的问题。我昨天提到了界面，那么这样我们可以去控制我们的成本，我们可以把这个系统去看一下它的反映。通过这点来做到，当我在低层次使用这个TDD的时候，我有一个模块去来运转这些高层次的系统。我要去意识到这些东西，如果在现实中进行手工测试的话，如果想在几秒钟内进行一个测试，你需要一个自动化，这样你就不会把整个周五晚上都浪费在实验室里面了，我也可以进行这方面的测试。在这个屏幕上大家可以看到，如果我要让这些灯亮起来，在周一5点9分的时候弄亮，有些时候我是设定在5点10分，但是过了5点10分之后我就希望这个灯没有灭掉。所以，你在现实中去设定这个时钟，去规划你的时间，只要等待就行了。

　　那么，等两分钟，他有时候灯亮或者不亮，然后你可以进行重新的测试。这个时候就比较费时间了，就是这个幻灯片。这里我想在我的系统里有一个测试的代理人，他可以去进行一些测试，我去写一下脚本，然后去进行检测他的行为。为了避免这些疑惑，我们可以进行很大量检测。我介绍了两种不同的测试方法，比如Unit Test，这种方法就是这种开发程序人员所做的，他想把这个编码让他想要做的方法进行设计，实际上这就意味着，如果我去在代码里面设计这些东西，他就会按照我的指令去办事。如果在未来的话，他也有可能去发生问题，我有哪些特性要测试呢？那么我们就进行一个Story测试，或者是聚合性测试，或者说有不同的名字，这样我们测试按照他不同的定义去进行。

　　还有其他的一些测试在各种系统里面，我们在谈到这种Unit tests，为了让你建立一个更加巩固的软件是必须的测试。如果做不了这种比较稳固的Unit tests的话，我的系统就不会稳固。如果在一个系统层面进行检测的话，这样的话有人可能告诉我，你就通过这个接口，通过这个硬件的接口来进行。那么，我们这有三个最基本的部件，可以说每一个部件里面有5个行动。如果我检查一下这个程序，我要进行多少测试呢？如果是可能的话，那可能会有1000×10×10，我需要进行1千个测试来测试一个简单系统，完成有三个组件，可能不止这三个部件，需要更多测试。

　　通过这种unit tests去测试的话，那我需要去做多少测试？我仅仅进行30次测试就可以了。或者在额外的去进行几次检查互动，所以我仅仅要进行45次就够了。现在我问你？你愿意去做成千次的测试，还是45次的测试，答案显然是清楚的。所以，unit tests并不是说测试满足了需求，我们就要用一种可执行的unit tests来进行测试。在我的网站上可以去找出我的一篇论文，这我也列出来了，同时我也会把这个演讲材料，和昨天的演讲材料都会放到我的网站上去。

　　大家可以想象一下这个使用案例，在你的规格里面也可以采用这些案例。可以说，它会指示你的系统应该会做什么，会给一个目标，一个前提条件，一系列的步骤，可以说在这个Use-Case里面有不同类型，你要有不同的表，一个发生详细事情的列表。如果能够提供同样的信息，我们要让计算机能够去运转这种方式，特别是Use-Case，你能够这么做，有不同的工具来上你做这一点，比如FitNesse这在商业上有很多应用，也可以应用到嵌入式开发里面去。

　　我们在这里看一下，在这个表里面的信息就是一些指令，针对这些检测系统的指令。第一个表说我有多少系统，你要打开你的系统就会展示出整个这些运转的程序。第二个表就是告诉这些检测系统，如何进行互动。在左边如果我们看到你脚本的名字，我们会看到很多英语的名字，特别是在第二层面，第二行里面，比如说这个打开灯亮，周一是7：30。下面这个表就检查，把这个时间改为7：30，这个灯就应该亮了。那么这个可能并不是完全可读性的，但是我们可以去采用这种方法。

　　那么有了这样的规格之后，就可以去运转它。如果我的系统是可以测试的，我就是去运用这些规格，去看一下我的系统是不是按照这些指令运行，如果是绿色就一切正常，如果不是绿色大家怎么办？我们肯定有一些故障的信息。比如说这就是我们一些嵌入式的数值，都在这列举了，它告诉你这个状态，就是说不可改变的一种状态。我可以去有很多的这些检测，我一摁这个按纽以后就可以去做很多的测试。

　　那么代码被写出之前进行检测，我的检测部门他们就会做这些迭代，他就会告诉我，这是针对新特性的检测。这个图在下面可以看到，其中一个Story是红色的，红色就意味着这个检测并没有通过。这意味着什么呢？也就是我们需要去做一些工作了，我们去进行一个失败的检测来描述它的行为，也就是在我们迭代的时候我们承诺的一些行为去做。

　　我们在开发的时候有一些不好的事情会发生，糟糕的事情会发生，我们去看一下这些红色的地方，显然我们这些新的特性会发生冲突。但是，有些特性他是发生了故障，是的。当然我们需要去进行改进，所以这一点可以说你要去进行一些工作，否则你没有什么成果，我们去看一下这些需要一些特性，然后需要一些可测试的代码。

　　那么检测主要是来发现这个Bugs，我们也可以用测试来防止Bugs和这些故障。TDD是一个比较底层，可以在高层进行，可以说这一点并不是容易的，但是为了能够可持续性地做到这一点，我们必须要做。你不想让你的产品会被一些，有一些不好的描述，好的，谢谢大家。