嵌入C语言的测试驱动开发：为什么要调试？ 开发, 测试, C语言

wxg1988

Zune bug

TDD可能有助于避免恼人的Zunebug。微软公司的Zune是为了与苹果公司的iPod竞争。2008年12月31日，Zune变成了“专为一天的程序块(abrick for a day)”。12月31日是新年前夜，是一个闰年的最后一天，这是30G Zune要经历的第一个闰年。很多人都将Zune错误归因于时钟驱动程序中的一个函数。虽然列表1中的代码并非实际的驱动程序码，但它有相同的效果。你可以从列表1中Zune的无限循环中找到一些端倪吗？





图4，TDD对于设计以及时间的使用有深远的影响。与调试居后的编程模式比较，TDD
没有回溯追踪bug的风险与不确定性







图5，对快速反馈的需求使TDD微循环离开目标硬件，而原生地运行在开发系统上。一个TDD循环包括双重目标的风险，但提供了快速TDD反馈回路的好处




很多代码阅读专家审查了这个代码，并得出了可能与您一样的错误结论。闫年的最后一天是该年第366天，而Zune对这种情况的处理是错误的。在这一天，该函数永远不会返回！我编写了设定年份以及年中天数的代码，看是否像90%的Zune bug专家预测的那样，将天数的布尔代码设定为等于或大于366就能解决问题。代码放入测试装置后，我编写了测试用例(列表2)。和Zune一样，测试进入了一个无限循环。我采用了经过数千名程序员审核的适当修复方法。出乎我的意料，测试失败了；设定年份与天数的测试认为日期是2009年1月0日。新年前夜，人们仍会拥有自己的音乐，但Zune仍有个bug。







一次测试就可以防止Zune bug。可你怎么知道要去写这样一个测试？只有知道bug在哪里才会写测试。问题是，你并不知道bug在哪里；它们可以在任何地方。所以，这意味着你必须为所有的部分写测试，至少是所有可能中断的地方。难以想象要考虑到所有需要测试的东西。但不必担心，你不需要针对全年每一天做测试。你只需要一个针对有关天数的测试。

计算机编程很复杂，TDD能够系统化地让你的代码按本意运行起来，并提供能使代码工作的自动化测试用例。

嵌入设计

当我首次使用TDD时，我认识到，它可能有助于解决一个问题：目标硬件的瓶颈，这是令很多嵌入软件开发人员头疼的事情。瓶颈有多种形式，你可以使用TDD，在严格的TDD反馈循环期间避免瓶颈的出现。很多嵌入开发工作都已实现了软硬件的并行开发。如果软件只能在目标硬件上运行，则可能浪费至少一次的时间。例如，目标硬件可能迟至交付期还不可用，推迟了软件的测试；硬件可能昂贵且稀少；或者它本身就有问题。目标硬件还可能有长的建立时间或长的上传时间。大多数嵌入开发团队都遇到过这些问题，它们会减缓进度，并减少了建立今天复杂系统的反馈。

为避免目标硬件的瓶颈，可以采用“双重目标”法，即设计自己的生产代码与测试，使之大部分运行在标准PC上。但双重目标有自己的风险。开发系统中测试代码的信任度是建立在交付给目标以前的代码上。大多数双重目标风险是源于开发环境与目标环境之间的差异。这些差异包括对语言特性支持的改变量、不同编译器的bug、运行时库的差异、文件名差异，以及不同的字长等。由于这些风险，你会发现，在一个环境下能无错运行的代码，可能在另一个环境下出现测试错误。