嵌入式软件测试与普通软件测试的目的一样，都是为了发现软件缺陷，而后修正缺陷以提高软件的可靠性。嵌入式系统安全性的失效可能会导致灾难性后果，即使非安全性失效，由于其应用场合特殊也会导致重大经济损失。因此，往往嵌入式软件对可靠性的要求比普通软件高。这就要求对嵌入式软件进行严格的测试、确认和验证，以提高产品的可靠性。
不过由于嵌入式软件的多样性，基于的操作系统，使用的开发环境，微控制器都是日益繁多，完整规范的测试实现起来比较困难，一般企业都是直接进行系统测试。单元测试，集成测试由于测试执行的运行环境建立困难，执行效率低下，或者维护困难就往往被忽略。
实际上，只要时间上做好安排，确立测试方案，根据情况建立单元测试环境，还是可以顺利实施单元测试，尽早发现软件缺陷，整体上获得时效，提高了系统可靠性。文中笔者就根据多年工作实践，将嵌入式软件单元测试相关的一些经验与大家分享，同时抛砖引玉。
测试环境
单元测试首先需要动态运行代码的环境，嵌入式软件开发环境往往是交叉开发环境，我们希望将代码移植到开发主机上运行（比如Windows系统），这样做有几个好处：
1 可以利用高速的主机提高代码运行效率；
2 有利于测试管理，便于测试用例输入和形成测试结果报表和维护；
3 充分利用Windows系统的测试工具，实现自动化测试。
不过移植代码至Windows系统需要将嵌入式软件的API都移植到Windows，形成虚拟系统接口层，这种方法往往是长期使用这一嵌入式系统，一劳永逸的长远性方案。
当然还可以通过购买使用一些商用的工具，比如CodeTest，VcTester，使用这些工具在嵌入式系统上直接开展单元测试工作。
这两种方案对于一些中小企业来说，由于不愿投入这么大人力物力，不能建立长期有效的开发方案而无法实施。对于这种条件还可以采用一种投入较小的短时方案，直接在程序中加入测试代码，直接在目标板上运行查看结果，测试用例也可以直接在代码中，或者通过接口从主机获得测试输入及输出测试结果。这一方案对于测试硬件驱动也是相当适用的，比如测试某设备读写做了以下c语言代码(详见本刊网站)：
在实际平台上运行该代码执行测试，这种方法主要用于单元的功能测试。虽然需要在单元测试阶段编写额外的代码，但是由上面例子可见，被测单元接口定义清晰，测试代码很容易完成，至于测试用例的编写是无法避免的。正式发布代码时通过条件编译将这些代码屏蔽即可。
测试策略
从测试效果上看，当然是花费越多的时间、人力，发现的问题越多，产品的质量控制得更好。但实际上，彻底做好软件单元测试几乎是不可能的，我们需要综合考虑成本和效率，这是实际产品开发中经常遇到的问题，都面对这样两难的境地——上市时间延误而没有及时占领市场；或是时间上抢先，不过测试不充分导致出厂的产品质量不高。如果测试时间不充足，如何在限定时间内更好地完成测试工作呢？
1 我们需要强调对隐藏缺陷多的模块进行测试：问题是怎么在测试计划之前确定哪些模块缺陷多，容易出错呢？根据经验，出错率大的地方往往是以下几种情况：
1）时间压力大的情况下完成的模块；
2）经验不足的员工编写的模块；
3）前期发现过大量bug的模块；
4）接口关系复杂的模块；
5）技术难度大，处于行业领先地位的模块；
6）从未做过测试或缺乏底层测试的模块。
2 对于重要的模块加强测试：“重要”这个概念在这里往往也不是轻易评估的，实际实施中应该需要测试评审小组商议决定。这里就根据经验列出以下几点作为参考：
1）和安全相关的模块，比如产生辐射，高温，高压等威胁人身安全的模块，这是最为关键的一点；
2）从经济利益角度考虑，出现故障将造成较大经济损失的模块；
3）从使用角度看，用户操作的模块优先级要高于服务操作模块，因为用户的优先级高于客服人员；
4）基本功能模块优先级高于扩展功能模块，试想基本功能都不能使用，那扩展功能岂不是空中楼阁；
5）执行概率高的模块，因为执行概率高的代码在运行中暴露缺陷的几率也大。
编码注意事项
以上是从测试角度讨论如何建立单元测试执行环境的几种方案和测试策略的制定，不过，为单元测试的实施奠定坚实的基础的还是良好的程序设计。接下来从代码编写角度列举提高嵌入式软件的可测性的几点经验教训：
1 与硬件设备操作相关的需要与硬件操作无关的代码分离，这样与硬件操作相关的驱动代码可以独立在目标板上测试，当然逻辑简单也可不作测试；大部分与硬件操作无关的代码就容易实现跨平台移植测试。
2 中断响应函数功能尽量简单，这是因为中断响应相对不好测试，如果代码复杂，也不易定位错误，因为很多的开发环境或操作系统难以支持中断响应函数的断点调试。
3 系统调用及操作系统相关的操作做到与应用层分离，可以通过中间函数实现，比如虚拟操作系统函数，这样跨平台移植测试的时候只需将这些中间层函数修改就可以实现。
4对数据类型的差异性也可通过宏定义来实现统一，对于库文件的差异也通过宏定义来实现上层代码的一致性。
5 使用静态代码检测工具，比如PC-Lint，以尽早发现代码缺陷。PC-Lint是在代码产生初期静态查找代码缺陷，更有利用错误定位和修改，因为软件开发阶段越早发现问题，解决问题花费的代价越小。因此，一般应该是静态检查通过后再实施动态测试。
嵌入式软件单元测试也是基于普通软件单元测试的理论，仍需遵守，以上是对嵌入式软件单元测试特别之处的经验总结，希望能对初涉嵌入式软件开发的朋友有所帮助，重视软件质量，提高嵌入式系统的可靠性。
- {
- typedef struct _TEST_CASE // 测试用例结构体
- {
- UINT8* pBuf; //读写缓冲区指针
- int len; //读写数据长度
- STATUS result; // 测试结果，OK或ERROR
- } TESTCASE;
- #define TEST_NUM 4 // 测试用例数
- UINT8* rBuf;
- TESTCASE testCase[TEST_NUM]={
- {0,DATA_MAX_LEN+1,ERROR}, // DATA_MAX_LEN指允许读写的***长度
- {"a",1,OK},
- {"12",2,OK},
- {0,DATA_MAX_LEN,OK}
- };
- for (int i=0;i< TEST_NUM;i++)
- {
- if(write(testCase[i].pBuf,testCase[i].len) != testCase[i].result) // 写测试
- LOG ("test write failed!");
- if(read(rBuf,testCase[i].len) != testCase[i].result) // 读测试
- LOG ("test read failed! ");
- if(bcmp(testCase[i].pBuf,rBuf,testCase[i].len) != 0) // 比较读写数据
- LOG ("compare data failed! ");
- }
- }
其实大多数软件测试方法都可以直接或间接地用于嵌入式软件的测试，但是由于操作系统的实时和嵌入式特性，嵌入式软件测试也面临一些特殊的问题。虽然日前已经有一些针对嵌入式软件的测试和调试工具，但是在有些方面仍存在不足，包括许多任务操作系统的并发、非侵入式的测试和凋试、嵌入式系统的软件抽象等。对于嵌入式软件测试技术的研究人选测试工具有待开发，仍须要做很多进一步的工作。
【编辑推荐】
