文字显示结果
组合搜索  计算机图书分类目录
 
 
新闻首页 > IT新闻 > 其它 > 敏捷宣言创始人James Grenning:测试不是寻找Bug的游戏
 
敏捷宣言创始人James Grenning:测试不是寻找Bug的游戏
作者:black_butterfly 【转载】 2010-10-17 12:58:53   来源:CSDN.NET


由ThoughtWorks主办,CSDN承办,InfoQ提供票务支持的第五届敏捷软件开发大会“敏捷中国2010”在北京新世纪日航酒店隆重举行。15日上午,敏捷宣言创始人、全球知名讲师、过程教练及咨询师James Grenning与参会者分享了主题为"测试不是寻找Bug的游戏"的精彩演讲。



James Grenning


他表示软件是非常脆弱的,新开发的程序代码可能会引入25%的Bug,修复了某个Bug也可能会引入其他更多的Bug,所以要伴随着开发进行不断的测试。如果在项目的最后再进行测试,结果可能会很糟。


James Grenning的演讲实录如下:


大家好,谢谢。非常高兴能够跟大家进行交流,谢谢大家。在我开始之前,我昨天在酒吧碰到一些人,主要是一些嵌入式工程师,他们说为什么敏捷是不可能?特别从一个嵌入式角度来说是可能的。所以,今天我要做一些不同的做法。


敏捷可以说,或者说我们不可以使用敏捷,我们没有硬件,硬件是这样一个形象,他是混乱一团,它的内存比较小,就像一个小的手表一样。其实另外一个来说呢,我的这个嵌入式系统内存比较大,像一个IPhone,或者是一个开关一样,我们不能够使用敏捷,我们有限制,有一些死的限制,我们不能够满足这些需求,满足这些时间最后的期限。我们也不能够特别是用嵌入式的角度来做,那么IO是专业化,就像一个洗衣机,或者一个IPhone,或者像一个机器人,选择器一样,有特定的问题。类型也是各不一样,而且比较昂贵,还有一些Bug,但是这些Bug是谁的问题呢?大家互相指责。


我们有特定的UI,剩下IPhone你的TDD是怎么样用于起搏器,或者监测器里面。所以,这个软件必须得到检测,只有人才能进行这些测试。有很多人他没有时间,我们在这里的话,也要在实验室里面见到这个软件在运行它,那么我们要去考虑机器人,或者是开关,或者是起搏器,我们不能够使用这些故事,没有一些选择性的这种选择,都是第一位,然后我们就迟到了,我们就没做到。我们需要规格,这些规格必须要被写的很清楚,我们不能够用迭代,你怎么样能够提交一个洗衣机呢?或者是一个电机系统,或者是一个起搏器。


那么通过一个增量来提交这些东西,那什么是敏捷呢?这个Agile是一个小A还是一个大A,我们使用了一个Agile,但是它不行,不能起作用?我们应该怎么做?我们都已经非常敏捷了,但是我们应该怎么去做?你们是做了两周的迭代吗?你是做了这种基于测试的开发了吗?你做了这种自动化的检测了吗?你有一个发布的计划吗?你有没有一个对等的项目?有没有把你的编码进行处理?那么,有你的客户吗,你是不是不断在整合,是不是在分享这个编码的所有权,你怎么来回答这些问题?你是否用了一个编码的标准,你做了什么?


我们并没有写了任何文献,现在我理解了,这是极限,但并不是一个极限的项目。我们为什么需要敏捷呢?实际上一切都是正常没有问题,一切都好,我们不要去注意这方面的火了,因为就像我说的一切都好,我们已经90%都完成我们的工作了,可能只有一点存在的Bug。是的,可能我完全不同意你的意见。所以,我们就没有时间在开玩笑了,我们就谢谢大家。


当我在高中的时候,电脑当时比较糟糕,一个同学高中就开始编程,他向我展示了他打洞的卡,给我显示机器的工作,我认为计算机非常糟糕不应该碰它,我几年之内没有碰他,我开始学习工程学,在我们计算机当中必须要使用电脑,否则没有办法完成任务。当时我想作为一个年轻人要赶日程不得不去熬夜做一些编程,实际上我就开始喜欢上这个专业。现在我不再年轻了,但是我依然做这方面工作,可以说我在生活中获得很多有益事件,我和参加这个会议有很多敏捷大师们进行了沟通,我得到很多。


我告诉大家很多秘密,我当时是去滑雪,那是一个在美国的滑雪圣地,在美国这是一个最佳的滑雪圣地,是在那里进行一个软件开发的会议。但是,软件确实有了很大的变化,我们就看一下时间很短,这些软件现在到了一个什么程度?如果回到15年前我看到我自己的这些电子作品,可能大家都意识不到这些,左边它是一个把CD放到播放器里面去。现在我们可以直接嵌入到你手机里面去,大约6年时间非常短暂,我们现在有了iPod,iPod确实是非常疯狂的,还有成千上万的东西取决于你的下载。那么,计算机还在你的洗衣机里面,还有很多电子工件里面。实际上我们还不用自动吸尘器手动,我们可以把机器人定好可以自己使用,还有心脏起搏器人类也都使用这些工具软件,可以说在整个宇宙里面都在采用我们的软件,这个软件无处不在。


那么,25年前,30年前电信是什么样子?现在我们有很多各种各样的磁开关,电话里面这些系统也都是一样的,过去我们在中国打球打高尔夫。美国我们会称为它是一个针对目标的活动,现在我们有很多人同时参与,我们在玩这种线上游戏。过去我们用纸来记录各种各样数据,现在我们有各种各样的电子数据。


我们再看一个例子,当时有很多飞机上,航空航天也用到电脑,可以说有很多工程师参与进来设计飞机和软件,可以说这是一个最新急性,也有很多高科技。大约80%的努力都在开发这些软件,可以说具有巨大不同,我们现在不是硬件,针对于软件,而且对于我们来说都是比较激动人心的消息。但是也让人非常可怕,因为这些软件他也是会出问题的,一切都会出现问题,出现故障。


那么一个软件可以对任何一个系统进行毁灭,这是第一个电脑的Bug,实际上不是一个真正的Bug,实际上是一个Modes(音译)的,他就使转换器出现问题,比如IPhone里面有多少软件,可以说有10-20个缺陷会导致故障。可以说,在大家这里讲个故事,在80年代的时候,我和一个实验室的人吃饭,他是一个科学家,是在航空航天业工作。这就是一个飞行器,对不起我现在有些激动了,我都无法讲话了,我慢一点吧。我请你举起那个牌子让我慢一点,我太激动了。


那次我和一个科学家去吃了吃饭,他是从事航空设备,今天Voyager还在发挥作用,他们要确保他们发的指令,这个编码是能够起作用,和他们在实验室进行测试一样的。那么,这个飞行器的任务之一,就是去到那个土星,也就是说在太阳系里进行旅行,他们也访问了各种各样有趣目标,他们还有一个飞行器机器,也去很多地方进行访问,比如木星和其他的一些星球。他们要把这个软件发到Voyager确保没有缺陷,这个要按光速的速度去进行发射,要持续几个小时,甚至几天进行一个信号传输。


当他们去发这个软件荷载的时候,他还要去获得一些数据反馈。比如说气侯变冷了,飞行器就告诉这些控制台,出现什么问题了,软件怎么样了,他们在内存里面也发现一些问题。那么,里面有一个催化剂,如果他要是缺少这个催化剂一切都完了,所以最终他们发现这些问题,他们后来就改正这个问题,挽救了这个飞行器。这个时候的话,他们要把编码发到一些飞行器上去。


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


还有一个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先生给了我们一个该怎么做这个事情的建议,但是我建议说有这么一个可能性,就是测试和开发,可以来实现他梦想的一个主要技术。


我们看另外一个案例分析,大家可能曾经有这么一个设备,也就是Zune30G,这是微软对于IPod的一个回应,Zune30G,它是存在一个问题,在2008年12月31号,昨天我和一些人谈过,你们也听说过这么一个故事。但是抱歉了我又说要一遍,在12月31号Zune就变成了旨在消耗电池的设备,因为它不能在用了,不能在播放任何音乐了,只是在不断消耗电池,如果你给他充电也是不断消耗电池,这里有两个问题,第一这是一年最后一天,在西方世界他们在庆祝自己新年的时候,大家会开很多庆祝,在最后一年的时候却不能用了,你不能看成简单的问题,最重要一天坏掉了,有一些人可能意识到了,这是一个只拥有闰年的最后一天,我们在这些问题上进行了研究。但是他们找到了这么一个函数,然后就看到这个问题出现了,究竟这个问题是说在1980年开始,然后他们就需要来计算这个年、日、月,所以说这些代码是独立的。


如果你对这个代码进行一些改变的话,你可能就能解决这么一个问题。我们可以看到,实际上在把这个代码进行一个重新检测就能够发现这些问题。我看了一下,这个代码也得到这么一个结论,我认为这个公式是正确的。但是,我认为我可能应该写一个测试才对,所以我做了这么一个测试。然后在线的一些平面当中,通过这种变化这个测试实际上是失败。第一个在这,是关于这个系统的时钟认为有多少天,2008年是闰年的最后一天。第二行就是生产的代码,第三行来检测检测结果是不是星期三。所以说最受欢迎的一种解决方案,他实际上变成2009年的1月0号,实际上这是一个假设的日期不存在。但还是一个Bugs,虽然不是一个开放的Bugs。


所以说我们应该怎么做呢?我们需要知道这些Bugs在哪,然后为他们写一个测试。如果在这个测试当中,我们能够发现这个Bugs就能够预防这个Bugs,现在你知道这个Bugs在哪吗?你直接可以把Bug取出来就可以了。那么,这给我们怎样的启示呢?这个启示就是,它的意义就是如果我们想为所有的东西写测试的时候,我们就要把所有的情况都考虑在内,立刻我们在做的一半的人就会说,好的可能我应该这么做。但是,却太难了。但是,只要有了智能一切都可以成为现实,我们可以测试有可能出现错误的问题。


那么对于程序员来讲呢?他知道这个闰年最后一天是特别,但是他还是犯了这么一个错误,在实践当中他虽然是知道特别一天,但是他不需要写前一天测试,和后一天的测试,闰年最后一天是特别,他需要写这么一个测试,因为他是写生产代码,在TDD当中你需要在生产代码之前就写这个代码,你才能真正能不能正确来使用。


在TDD当中我们遵循Uncle Bob's三条原则,他现在给我们三个方法好的建议,如果这个测试不能够使得你单位能够顺利的过,那你就不要写这么一个生产代码。所以说你可以说,让我改变这个代码,不行,你要想改这个代码要先写测试。第二条原则你不允许写任何的单元测试,除非他最后有可能出现失败,或者你写的这一个问题,比如说在C++,C语言当中会出现这样的情况,你要写足够的代码。第三部分是最困难的,除非你能够通过这一个failing unit才行,不见得放入你需要的所有代码。


大家如果昨天去过我的演讲,我这里再给大家介绍一下Satate Machine,用这张图给大家介绍一下不同的步骤。我们如何来帮助这个程序按照他应该走的程序走下去。世界上大部分的国家,他们都使用这么一项技术来进行编程,也就是DeBug,然后再进行程序的编程,这实际上不是所谈的一个理想,这里面有一个很大的问题。我们必须在这里边拿一个激光笔指一指,我们看一下左边这个,如果我犯了一个错误没有被发现,后来有人发现了这个错误,找到这个Bug,然后我们就需要看一下大家每天有多少专门找Bug的会议来发现这些Bug。或者我会问你花多长时间找到这些Bug,可以是5分钟,也可以是5年,也永远是找不到这些Bugs。


所以说实际上这种先进行调试,再进行编程的方法,在测试驱动发展是怎样的呢?我们都是人,所以我们会犯错,我们先发现这个测试,然后立刻的我们就知道了这么一个问题,我们就知道我们到底哪做错了,然后把它进行修复。所以说,原来调试这个问题就消失掉了。好的,在现实当中是这样的,不见得你还会有孩子的Bugs,但是很多的Bugs会立刻消除,单位就不会进入Bug表里面了。在TDD当中,我们先进行调试,我这里有效性强调太多了,但是我写所有的代码会更加有效率,我非常关注这些代码,如果你能够让我同时进行测试可能就没有这么有效率了,因为这是评论界这么说的。


那么在做好代码之后,他就做好了。真是这样吗?代码其实并没有完全的完成,我们需要找到这么一个通路,他是来通过调试的。我这里要在问一次,当然我不指望在你那里答案,但是我们需要调试花多长时间,我们还不知道,因为Bugs有可能藏在任何地方,我们也不知道。所以,这种TDD情况,它是一个研究的过程,我们这里有一系列需要进行测试的表,然后我们选择一次做一个测试。所以说,随着我们的发展,开发,我们可以把设计进行一个演进来解决当前的问题。当我们结束的时候,我们可以看到测试过的属性代码,这样不需要做太多的调试了。


我并不是说这里没有所有的调试过程了,但是这意味着什么呢?是不是写一个测试要花很长的时间呢?是不是就使得你的工作减缓了,我怎么能够让我的老板来支持我呢?我怎么能够让我的工程师来试这样的方法呢,如果我是老板的话?所以说这是双向的。


另外一个简单的模式,如果不是进行人工代码测试我来进行自动化的话?因为在人工的测试之后,我在做这种自动的测试,实际上他比人工测试有时候要多花两倍的时间。如果是这种情况的话,那我就会有一个可持续性的流程,如果是真的话,看起来好象花费更多时间和金钱,但是有一点没有考虑到,就是你过去没有做到的一些工作。


我们待会还要进行一些测试,把这些Bugs拿出来,我们不但要进行测试,还要保证我们产品质量,还有要保证一些有可能非常常见的这种产品的故障会减少,这是一种可持续性的方法。但是,对我们来讲不见得能用的上,因为我们这里有一个特殊的问题。我们有这种火警系统,还有家用自动化系统,还有银行系统等等,这些都认为是比较特别的问题,对我们来讲可能用不上。当然,这些问题是特别的,在这个会议当中你们大家可能有意识到,你必须要逐渐的适应这么一个过程。


但是我认为在很多环境中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是一个比较底层,可以在高层进行,可以说这一点并不是容易的,但是为了能够可持续性地做到这一点,我们必须要做。你不想让你的产品会被一些,有一些不好的描述,好的,谢谢大家。







迎接万亿移动应用大时代——2010中国移动开发者大会即将举行


大会官网:http://cmdc.csdn.net/


最后席位 抢票中!


提交应用作品,还可以380元超低价购买大会门票!

 
 
 热点新闻
 
 经典回顾
 
 相关图书
 
 新闻关键字
 
 
Copyright © 2010 TianMei Technology All rights reserved. To comment on this site
  辽B-2-4-20100065