云计算 频道

嵌入式开发下的单元测试问题--框架解析

  1.单元测试的必要性

  单元测试是软件开发的重要一环,尤其对嵌入式开发。因为嵌入式开发受限于开发环境、调试工具等因素,不能和纯PC软件开发一样使用很多先进的工具。这就需要开发者在开发过程中,进行更细的模块划分,更明确的接口,更详尽的测试。

  传统的开发先出设计方案,然后跟着写出代码,最后在做测试---常被叫做bug调试,所以在代码“写完”之后,还有一半左右的开发量。人都会犯错,在设计和编码中也会犯错,如果后期调试编程去解决设计和编码中引入的错误,那么可能已经过了几天几周几个月,反馈如此只晚,已经不能从错误中吸取经验了,下次还会犯同样的错误。此外根据软件工程理论,1个bug越是在后期越是花费巨大的成本去修复,并且随着系统复杂度的增长,在一个大的系统中去查找某一个细节具体的问题,相比于在小的模块中去查找问题会花费多倍的时间成本。

  2.单元测试框架解剖

  一般地单元测试需要实现以下几个基本功能:

  1. assert

  各种assert,比如AssertTrue、比如AssertFail、AssertStrEquals、AssertIntEquals......

  条条大路通罗马,这些Assert有各种功能,其实就是包装了断言的函数。比如AssertStrEquals(str, "open"),进行str和字符串“open”的比较,如果不相同则会报错。

  根据框架的结构,在assert失败时候,有的进行长跳转longjmp,有的对类似failCount的全局的变量进行加1并记录错误位置。

  2. 错误位置记录

  得益于C语言的LINE、FILE宏,这是2个ANSI C标志支持的内置宏定义,可以得到当前的的行数和文件名。 在断言失败的地方,记录文件名和行号,以供用户查询错误的位置。

  3. 测试case管理

  这是测试框架区别于自己写的assert测试函数最根本的地方。 测试框架为了提高函数利用率,减少重复,方便测试例程汇总等,都会进行各种封装。比如以下几条。

  1)setup和teardown

  大部分的测试框架都提供这两个函数,主要是因为有些测试case,有大量重复的代码,比如准备输入数据,测试完毕后清理现场等通用的功能。

  2)测试例子汇总

  有的叫做TestSuit,有的叫做TestFixtures。把一类相似功能的测试case进行汇总,方便更高层次的调用,也方便用户管理测试例程。

  3)测试的调用

  多个测试例程汇总后,构成一个数组(表格),启动运行,一般由xxxRun函数负责。

  在嵌入式c中,一般都有一个函数指针来操作,这也是为什么所有的测试case的函数名称都使用相同的声明,test_case需要和调用该测试的指针同类型。

  4. 测试的执行

  测试的执行本质就是函数的长跳转。可以看做在父函数中调用子函数,这个子函数如果是测试例程的话,子函数就会包含assert相关的语句,而assert语句在出错后,会记录错位位置和错误消息,然后进行长跳转(longjmp),longjmp和setjmp(buf)成对出现,返回到调用的位置,然后进行下一个测试case。

  for (i = 0 ; i < testSuite->count ; ++i)

      {

          Test* testCase = testSuite->list[i];

          TestRun(testCase);

          if (testCase->failed) {

          testSuite->failCount += 1; 

          }

      }

  3. 测试框架的本质

  1)为了更好的组织测试,提供的测试组的批量处理功能,一般由for循环遍历一个table数组实现;

  2)为了减少重复进行测公用函数提取,比如准备测试环境和清理现场;

  3)测试需要的各种断言;

  4)断言失败后的跳转、记录错误位置-FILE-, -LINE-宏的使用;

  5)测试case运行的监控和结果的汇总。

  综上,如果你实现了上面的几个功能,那么也就自己完成了一个测试框架。

  其实测试框架是一个很简单的事情,如今测试框架有很多,像VS这样的IDE已经集成了单体测试,所以对于一个开发者怎么规划测试才是测试工作的第一要务。

  如何恰当的写测试用例,既不延误开发又不会造成工程臃肿,还能尽可能的覆盖测试范围,这才是测试中最花费功夫的地方。

  本文作者:啊哈彭

  原文链接:https://www.cnblogs.com/pingwen/p/9206406.html

0
相关文章