要点
1.为什么你会遇上这些bug?因为它们是你放的。
2.在TDD(测试驱动的开发)中,你会在一个严格的反馈循环中,开发测试与生产代码。
3.TDD可能有助于避免恼人的Zune bug。
4.目标硬件瓶颈有多种形式,你可以在严格的TDD反馈循环中,用TDD来避开瓶颈。
5.TDD帮助你确保自己的代码如期望那样运行。但如果不是这样,你该如何建立一个可靠的系统?
6.TDD快速地发现小的和大的逻辑错误,防止出现bug,使最终得到较少的bug。
我们的工作方式都是编写代码,然后努力让它运行起来。先建立,然后改错。测试是以后的事,即写完代码后才要做的事。在不可预期的调试工作上,大概要花掉我们一半的时间。在日程表上,调试工作都穿着测试与集成的外衣。它是风险与不确定性的一个来源。修正了一个bug可能会产生另一个bug,有时甚至是一连串的bug。
保持调试的统计有助于预测要花多少时间才能消除bug。你要度量和管理bug。看曲线的拐点,拐点表示了趋势,告诉你最后修正的bug要比产生的多。拐点表示的是已经做的事,但你永远不知道是否在代码的某个阴暗角落还躲藏着其它的致命bug。
可制造性设计的一个方面是确定为什么你会有这些bug。答案很简单:错误是我们放进去的。这就是我们的工作方式。在开发以后的测试时,就会发现问题(图1和参考文献1)。我们在开发时会制造错误,测试的工作就是找到这些问题。只要仔细地测试,就会发现错误。开发后的测试工作意味着必须找到、修复和管理大量的错误。
图1,在开发以后做测试时,会发现缺陷
这种调试居后的编程程序是当今最常见的编程方式。先写代码,再调试它。调试居后的编程方式有风险。人都会犯错误。你既不能确定bug将在何时现身,也不能确定会花多长时间才能发现它们(图2)。
图2,人都会犯错误。你无法确定bug何时出现,以及要花多少时间才能找到它们
当发现一个bug的时间(TD)增加时,寻找bug根源的时间(TFIND)也会增加,通常增加得更多。如果从错误的引入到发现要花数小时、数天、数周,甚至数月时间,你已忘掉了当时的背景,必须开始做bug大扫荡。当你在开发周期以外发现缺陷时,就必须管理bug。对于有些bug,发现的时间不会影响修复的时间(TFIX),但有些代码的运行也可能依赖于bug,修改这些bug会造成其它bug。
短周期以及主动的测试自动化可节省时间和工作量。这时,你再不需要重复繁重而易错的手工测试。有了测试自动化,重复测试几乎不会增加额外工作量。测试自动化快速地探测出副作用,避免了对调试事务的需求。
声明:本文内容及配图由入驻作者撰写或者入驻合作网站授权转载。文章观点仅代表作者本人,不代表电子发烧友网立场。文章及其配图仅供工程师学习之用,如有内容侵权或者其他违规问题,请联系本站处理。 举报投诉