嵌入式软件开发测试的秘诀

1、嵌入式软件开发测试的秘诀在嵌入式软件开发过程中，一般来说，花在测试和花在编码的时间比为3:1( 实际上可能更多)。这个比例随着你的编程和测试水平的提高而不断下降，但不论怎样，软件测试对一般人来讲很重要。很多年前，一位开发人员为了对嵌入式有更深层次的理解，向oracle 询问了这样的一个问题:我怎么才能知道并懂得我的系统到底在干些什么呢 ?oracle 面对这个问题有些吃惊，因为在当时没有人这么问过，而同时代的嵌入式开发人员问的 最多的 大都围绕 “ 我怎么才能 使程序跑 的更 快” 、“ 什么编 译器最好 ” 等肤浅 的问题。 所以 ，面对这个不 同寻常却异乎成熟 的问题， oracle 感到

2、欣喜 并认真回复 了他:你的问题很有深 度很成熟 ，因为 只有不断 地去 深入理解才有可能不断 地提高水平。并 且 oracle 为了 鼓励 这位 执着的程 序员， 把 10 条关于 嵌入式软件开发测试的秘诀告诉了他: 1. 懂得 使用工具2. 尽早 发现内存 问题3. 深入理解 代码优化4. 不要 让自己大海捞针5. 重现并隔离 问题6. 以退 为进7. 确定 测试的 完整性8. 提高 代码质量意味 着节省 时间9. 发现它 ，分析它 ，解 决它10. 利用初学者 的思维这十条秘诀 在业界 广为流传 ，使很多人 受益 。本文 围绕 这十条秘诀 展开论 述。.懂得使用工具通常嵌入式系统对可 靠

3、性的要 求比较高。嵌入式系统 安全 性的失效 可能 会导致灾难 性的后果 ，即使是非安全 性系统， 由于大 批量生产也会导致严 重的 经济损失 。这 就要求对嵌入式系统， 包括 嵌入式软件 进行严格 的测试 、确认 和验证 。随着 越来越多的 领域 使用 软件和 微处 理器控制各种 嵌入式 设备 ，对 门益 复杂的嵌入式软件 进行快速有效的测试 愈加显 得重要。就象修车需 要工具 一样， 好的程 序员应该 能够熟练运 用各种 软件 工具 。不 同的工具 ，有不 同的使用 范围，有不 同的功能。 使用 这些 工具 ，你可 以看到你的系统在干些什么，它又占 用什么 资源 ，它到底和 哪些外界的东西

4、打交 道。 让你郁闷 好几天 的问题可能 通过某个工具 就能轻松搞 定，可 惜你就是 不知道。 那么为什么 那么多的人 总是 在折腾 个半死之 后才想到要 用测试 工具 呢？原 因很多， 主要有 两个。一个 是害怕 ，另一个 是惰性。害怕 是因为 加入测试 用具 或测试 模块 到代码需要技巧 同时有可能 引入新的错误 ，所以他 们总喜欢寄希望 于通过不断 地修改重编 译代 码来 消除 bug, 结果却无济于事。懒惰 是因为 他们习惯 了使用 printf之类 的简单 测试 手段 。下面来 介绍 一些嵌入式 常用 的测试 工具 。o源码级调 试器source-level debugger这种调试

5、器一般提 供单步或 多步调 试、断点设置、内存 检测、变量查看等功能， 是嵌入式 调试 最根本有效的调试方法 。比 如 vxworks tornadoii提供的 gdb 就属于这一 种。o简单 实用的打印显示工具 printfprintf 或其 它类似 的打印显示工具 估计 是最灵活 最简单 的调试工具 。 打印代码执行过程中的 各种 变量可以让 你知道 代码执行的情况 。 但是， printf 对正常的代码执行干扰比较大(一般 printf 占用 cpu比较长的时间 )，需要慎重使用 ，最好 设置打印开关来控制打 印。oice 或 jtag 调试器in-circuit emulatorice

6、 是用来仿真 cpu 核心 的设备 ，它可以在不干 扰运算器的正常运行 情况 下，实时的 检测 cpu的内部工作情况 。像桌 面调试软件 所提供的：复杂的条件断 点、先进的实时 跟踪 、性 能分析和 端口分析 这些 功能，它也都能提 供。ice 一般 都有一个比 较 特殊的 cpu ，称为外合(bond-out)cpu 。这是一种被打开了 封装 的 cpu，并 且通过特殊 的连接 ，可 以访问到 cpu 的内部信号 ，而这些 信号，在 cpu 被封装 时，是没法“ 看到” 的。当和 工作站 上强大的调试软件 联合使用 时， ice 就能提供你所能找到的 最全面的 调试功能。但 ice 同样有一

7、些 缺点： 昂贵； 不能 全速 工作；同样，并不是所有的 cpu 都可以作为外合 cpu 的， 从另一个 角度说，这些 外合 cpu 也不大可能 及时的 被新出的 cpu 所更换。jtag(joint test action group)虽然 它最初 开发 出来是为了 监测 ic 和电路连接 ，但 是这种串行接口 扩展了用途，包括 对调试的 支持 。ad 公司 为 blackfin 设计的 visual dsp+ 就支持 高速的 jtag 调试。orom 监视 器rom monitorrom 监控器是一小程序，驻留 在嵌入系统rom 中，通过串行的或网络 的连接 和运行 在工作站 上的调试软件

8、 通信。这 是一种便宜 的方式，当 然也是 最低端的技术。它除了要 求一个 通信端口 和 少量的内存 空间外，不需要其它任何专 门的硬件。并提 供了如下功能：下载代码、运行控制 、断点、单步步 进、以 及观察 、修改寄 存器 和内存 。因为 rom 监控器是操作软件的一 部分，只有当你的应用程序运行 时， 它才会工作。如果你想检查 cpu 和应用程序的状态 ，你 就必须停 下应用程序，再次进入 rom 监控器。odata 监视器data monitor这种监视 器在不 停止 cpu 运行 的情况 下不 仅可以显示指定变量内 容， 还可以收集 并以图形形 式显示各个变量的变化过程。oos 监视

9、器operating system monitor操作系统 监视 器可以显示诸如任务切换 、信号 量收发、中断 等事件。一 方面，这些 监视 器能够为你呈现事件之间的 关系和时间 联系；另一方面， 还可以提供对信号 量优 先级 反转 、死锁和中断 延时等问题的 诊断。o性能分析工具 profiler可以用 来测试 cpu 到底 耗在那里。profiler 工具 可以让 你知道系统的 瓶颈 在那里、cpu 的使用 率以及需要优化 的地方。o内存 测试 工具 memory teseter可以找到内存使用 的问题 所在，比 如内存 泄露 、内存 碎片 、内存 崩溃 等问题。 如果发现系统出 现一些不

10、可 预知的 或间歇性的问题， 就应该 使用内存 测试 工具 测测 看。o运行 跟踪 器execution tracer可以显示 cpu 执行了哪些函数 、谁在调用、参数 是什么 、何时调用等 情况 。这种工具 主要用于 测试代码逻辑 ，可 以在大量 的事件中发 现异常 的那些。o覆盖 工具 coverage tester主要显示 cpu 具体执行了那些代码，并让你知道 那些代码分支没有被执行到。这样有 助于提高 代码质量 并消除无 用代 码。ogui 测试 工具 gui tester很多嵌入式 应用带有某种 形式的 图形 用户界面进行交 互，有些系统 性能测试 足根掘用户输入响应时间 进行的。

11、 gui 测试 工具 可以作为脚本工具 有开发 环境 中运行 测试 用例， 其功能包括 对操作的记录 和回放、抓取屏幕 显示供 以后分析 和比 较、设置和管理测试过程 (rational 公司 的 robot 和mercury 的 loadrunner工具是 杰出的代表)。很多嵌入式 设备没有 gui ，但 常常可以对嵌入式 设备进行插装来运行 gui 测试 脚本，虽然 这种方式可能要 求对被测代码进行更改，但是节省 了功能测试和 回归测试的时间。o自制工具 home-made tester在嵌入式 应用中，有时 候为了 特定的目的， 需要自行编写一些 工具 来达到某种 测试 目的。 本人曾经

12、编写的视频流录显工具 在测试 视频会议数据流向和 变化上帮了大忙,帮公司找 到了 几个隐藏 很深的 bug。.尽早发现内存问题内存 问题 危害很大，不容易排 查，主要有 三种类型:内存 泄露 、内存 碎片 和内存 崩溃 。对于内存 问题 态度必须 要明确，那就是 早发现早 “ 治疗 ” 。在软件 设 计中， 内存 泄露 的“ 名气 ” 最大 ，主要由于不断 分配的内存无法 及时地被释放 ，久而久之，系统的 内存 耗尽。即使细心的编程 老手有时 后也会 遭遇 内存 泄露 问题。有测试过 内存 泄露 的朋友 估计 都有深 刻地体验，那就是 内存 泄露 问题一般 隐藏 很深，很 难通 过代码阅读来发

13、现。有些 内存 泄露 甚至 可能 出现在库当中。有可能这本身是库中的 bug ，也有可能 是因为程 序 员没有正确理解 它们的接口 说明文档造 成错用。在很多时 候，大多数的内存 泄露 问题 无法 探测，但可能 表现为随 机的故障 。程 序员们往往 会把这种 现象怪罪 于硬件问题。 如果用户对系统 稳定性 不是很高， 那么重 启系统问题 也不大；但， 如果用户对系统 稳定很高， 那么这 种故障 就有可能 使用 户对产品失去信心 ，同时也意味 着你的 项目 是个失败的项目 。由于内存泄露 危害巨大，现在已经有许多工具 来解 决这个问题。 这些 工具 通过查找没有引用或重复使用 的代码块、垃圾 内

14、存 收集 、库跟踪 等技术来发 现内存 泄露 的问题。 每个工具都 有利有弊，不过 总的来说， 用要比不 用好。总之，负责 的开发人员 应该 去测试 内存 泄露 的问题， 做到防患 于未然。内存 碎片 比内存 泄露 隐藏 还要深。随着 内存 的不断 分配并释放 ，大块内存 不断 分解为 小块内存 ，从 而形成碎片 ，久而久之，当 需要申请 大块内存 是，有可能 就会失 败。如果系统 内存 够大，那么坚持的时间 会长一些，但 最终还是逃不出分配失败的厄运。在 使用 动态分配的系统中， 内存 碎片 经常发生。目前，解 决这个问题 最效的方法 就是 使用工具 通过显示系统中 内存 的使用 情况 来发

15、 现谁是导致 内存 碎片 的罪魁祸首 ，然后改进相应的部分。由于动态内存 管理的 种种 问题，在嵌入式 应用中，很多 公司 干脆就禁用 malloc/free的以绝后患。内存 崩溃 是内存使用最 严重的 结果，主要原因有 数组访问越界、 写已 经释放 的内存、 指针计算错误 、访问堆栈 地址越界等等 。这 种内存 崩溃 造成系统 故障 是随机的，而 且很难查找，目前提 供用于 排查的工具也很少。总之，如果要使用内存 管理单元的话，必须 要小心，并严格 遵守 它们的使用 规则 ，比如谁分配谁释放 。.深入理解代码优化讲到系统 稳定性 ，人 们更多 地会想到实时 性和速度，因为 代码效率对嵌入式系

16、统来说太重要了。知道怎么 优化代 码是每个嵌入式软件开发人员必须 具备的技能。 就象 女孩子减肥 一样， 起码知道 她哪个地方 最需要减，才能 去购买减肥药 或器材来减掉 它。可 见，代码优化 的前提 是找到真正需要优化 的地方，然后 对症下药，优化 相应部分的代码。前面提到的profile( 性能分析工具 ，一些 功能齐全 ide 都提供这种内置的工具)能够记录 各种 情况 比如各个任务 的 cpu 占用率、各个任务 的优先级 是否分配妥当、某个数据被拷贝 了多少次、访问磁盘 多少次、是否调用了网络收 发的程 序、 测试 代码是否已经关闭等等 。但是，profile 工具 在分析 实时系统

17、性能方面还是有不 够的地方。一方面，人 们使用 profile 工具 往往 是在系统 出现问题 即 cpu 耗尽之后，而 profile 工具 本身对 cpu 占用较大，所以 profile 对这 种情况 很可能不起作用。根据 heisenberg效应 ，任何 测试 手段或 多或少都会改变 系统 运行 ，这个对profiler 同样适用！总之，提高 运行效 率的前提 是你必须 要知道 cpu 到底干了些什么干的怎么样。.不要让自己大海捞针大海捞针只 是对调试的一 种生 动比喻。经常听到组里有人对 自己 正在调试的 代码说 shit ！可以理解，因为 代码不 是他写的， 他有足够的理 由去 sh

18、it bug 百出的代码， 只要他自己 不要 写出这种代码， 否则 有一 天同组的其它人可能 同样会 shit 他写的代码。为 何会有大海捞针 呢？肯定是有人 把针 掉到海里咯；那针为何会掉在海里呢？肯定是有人不 小心或草率呗。所以 当你在 抱怨 针那么难找的时 候，你 是否想过是你自己 草率地丢掉 的。 同样，当你 调试个 半死的时 候，你 是否想过你要 好好 反省一下当 初为了 寻求捷径 可能 没有严格 地遵守 好的编码 设计规范、没 有检测一些 假设条件或算法 的正确性、没 有将一些可能 存在问题的 代码打上记号呢？关于 如何写高质量 请参考林锐 的高质量 c+/c 编程 指南 或关于

19、c 的 0 x8 本“ 经书” (http:/ 掉在海里是，为了 防止在找到之前刺到自己 ，你 必须 要做一些 防范工作，比 如戴上安全 手套。同样，为了 尽能地暴露和捕捉 问题 根源，我 们可以设计比较全 面的 错误跟踪 代码。怎么来 做呢？尽可能对 每个函数 调用失败作出处理， 尽可能 检测每个参数 输入输出的有 效性包括 指针以 及检测是否过多 或过少地调用某个过程。 错误跟踪 能够让你知道你 大概把针 掉在哪个位 置。.重现并隔离问题如果你不 是把针 掉在大海 了，而 是掉在草堆 里，那要好办写。因为 至少我们可以把 草堆 分成 很多 块，一块一块的找。对 于模块 独立 的大型项目 ，

20、使用隔离 方法 往往 是对付那些隐藏 极深 bug 的最后方法 。如果问题的 出现是间歇性的,我们有必要设法去重现它 并记录 使其重现的整个过程 以备在下一次可 以利用 这些条件去重现问题。 如果你确信可以使用 记录 的那些条件去重现问题， 那么我 们就可以着手去隔离 问题。怎么隔离 呢？我们可以用 #ifdef 把一些可能和问题 无关的代码关闭，把系统 最小化到仍能够重现问题的 地步。如果还是无法 定位问题 所在， 那么有 必要打开“ 工具 箱” 了。可 以试着 用 ice 或数据监视 器去 查看某 个可 疑变量的变化；可以使用 跟踪 工具 获得函数 调用的情况 包括 参数 的传递；检查 内

21、存 是否崩溃 以及堆栈溢 出 的问题。.以退为进猎人为了不 使自己 在森林 里迷路，他常常 会在树木 上流下一些 标记，以备自己 将来有一 天迷路时可 以根据这些 标记找到出路 。对过 去代 码的 修改进行跟踪 记录 对将来出现问题 之后的调试很有 帮助。假如有一天，你最近一次 修改的程 序跑 了很 久之后忽然死掉了，那么你这时的 第一反映就是 我到底 改动了些什么呢，因为上次 修改之 前是好的。那么如何检测这次 相对于上次的 修改呢？没错，代码控制 系统 scs 或称 版本控制系统 vcs (concurrent version control,cvs是 vcs 的演化版本)。将上个 版本

22、check in 下来 后和当前测试 版本比较。比 较的工具 可以是 scs/vcs/cvs自带的 diff 工具 或其 它功能更 强的比 较工具 ，比 如beyondcompare和 examdiff 。通过比 较，记录 所有改动的代码， 分析所 有可能 导致 问题的可 疑代码。.确定测试的完整性你怎么知道你的测试有多全面呢 ？覆盖 测试 (coverage testing)可以回 答这个问题。 覆盖 测试 工具 可以告诉 你 cpu 到底 执行了那些代码。 好的覆盖 工具 通常可以告诉 你大概 20% 到 40% 代码没有问题，而 其余的可能 存在 bug。覆盖 工具 有不 同的测试 级别

23、，用户可以根据自己 的需要选择 某个级别。即使 你很确信你的单元测试 已经很全面并 且没 有 dead code, 覆盖 工具 还是可以为你 指出 一些 潜在的问题， 看下面的 代码: if (i = 0 & (almostalwayszero = 0 | (last = i) 如果 almostalwayszero为非,那么 last=i 赋值语 句就被跳过，这可能不 是你所期望的。这 种问题 通过覆盖工具 的条件测试 功能可 以轻松 的被发现。总之，覆盖 测试对 于提高 代码质量 很有 帮助。.提高代码质量意味着节省时间有研究 表明 软件开发的时间 超过 80% 被用在下面 几个方面: