《Design by Contract for Embedded Software》翻译( 八 ) _生活百科

Assertions and Testing断言和测试
At GE Medical Systems, I once got involved in developing an automatic testing suite for diagnostics X-ray machines, which we called “cycler.” The cycler was essentially a random monkey program that emulated activating soft keys on our touch screen and depressing the foot switch to initiate X-ray exposures. The idea was to let the cycler exercise the system at night and on weekends. Indeed, the cycler helped us to catch quite a few problems, mostly those that left entries in the error log. However, because our software was programmed mostly defensively, in absence of errors in the log we didn’t know if the “cycler” run was truly successful, or perhaps, the code just wandered around all weekend long silently “taking care” of various problems.

在通用电气医疗系统公司，我曾经参与过为诊断用 X 光机开发一个自动测试套件，我们称之为 "循环器" 。循环器基本上是一个随机的 Mock 程序，模拟激活我们触摸屏上的软键和按下脚踏开关来启动 X 射线曝光。我们的想法是在晚上和周末让循环器不间断地测试系统。事实上，循环器帮助我们发现了不少问题，主要是那些在错误日志中留下的条目。然而，由于我们的软件主要是防御性编程，在日志中没有错误的情况下，我们不知道 "循环器 "的运行是否真的成功，或者也许，代码只是在整个周末默默地 "照顾 "各种问题而徘徊。

In contrast, every successful test run of code peppered with assertions builds much more confidence in the software. I don’t know exactly what the critical density of assertions must be, but at some point the tests stop producing undefined behavior, segmentation faults, or system hangs—all bugs manifest themselves as assertion failures. This effect of DbC is truly amazing. The integrity checks embodied in assertions prevent the code from “wandering around” and even broken builds don’t crash-and-burn but rather end up hitting an assertion.

相比之下，每一次成功的代码测试运行都掺杂着断言，在软件中建立了更大的信心。我不知道断言的临界密度是多少，但在某些时候，测试不再产生未定义的行为、分段故障或系统挂起，所有的错误都表现为断言失败。DbC 的这种效果确实令人惊讶。体现在断言中的完整性检查防止了代码的 "四处游荡"，即使是坏了的构建也不会崩溃和燃烧，而是最终击中断言。

Testing code developed according to DbC principles has an immense psychological impact on programmers. Because assertions escalate every asserted condition to a fatal error, all bugs require attention. DbC makes it so much harder to dismiss an intermittent bug as a “glitch”—after all, you have a record in the form of the filename and the line number where the assertion fired. Once you know where in the code to start your investigations, most bugs are more transparent.

测试根据 DbC 原则开发的代码对程序员有巨大的心理影响。因为断言将每一个断言条件升级为致命的错误，所有的错误都需要关注。DbC 使得将一个间歇性的错误当作 "小故障 "来处理变得非常困难--毕竟，你有一个文件名和断言发生的行号的记录。一旦你知道从代码的哪个地方开始调查，大多数错误就会更加透明。

DbC also encourages testing to be accommodated by the system architecture. In the embedded systems domain, the days of logic analyzers or in-circuit emulators having direct access to all of the CPU’s state information are long gone. Even if you had access to all the CPU’s address and data signals (which you typically don’t, because there are simply not enough pins to go around), the multistage pipelines and cache memories make it impossible to figure out what’s going on in there. The solution requires the testing instrumentation (assertions) integrated directly into the system’s firmware. You can no longer design a system without accounting for testing overhead right from the start. Assuming that all the CPU cycles, the RAM, and all the ROM will be devoted strictly to the job at hand simply won’t get the job done.