我有一种情况需要为嵌入式硬件的某些设备驱动程序编写一些单元测试.代码很老很大,很遗憾没有很多测试.现在,唯一可能的测试是完全编译操作系统,将其加载到设备上,在现实场景中使用它并说"它有效".没有办法测试单个组件.
我在这里遇到了一个很好的线程,它讨论了嵌入式设备的单元测试,我从中获得了大量信息.我想更具体一点,并询问是否有人在这种情况下测试设备驱动程序是否有任何"最佳实践".我不希望能够模拟有问题的电路板正在与之交谈的任何设备,因此可能必须在实际硬件本身上测试它们.
通过这样做,我希望能够获得驱动程序的单元测试覆盖率数据,并诱使开发人员编写测试以增加其驱动程序的覆盖范围.
我遇到的一件事是编写在操作系统上运行的嵌入式应用程序并运行驱动程序代码,然后将结果传回测试工具.该设备有几个接口,我可以使用它来从我的测试PC驱动应用程序,以便我可以运用代码.
任何其他建议或见解将非常感谢.
更新:虽然它可能不是确切的术语,但当我说单元测试时,我的意思是能够测试/练习代码而无需编译整个OS +驱动程序并将其加载到设备上.如果我必须这样做,我会称之为集成/系统测试.
问题是我们所拥有的硬件是有限的,开发人员经常使用它们来修复错误等.要保持一个专用的并连接到CI服务器和自动化测试的机器可能是不可能的这个阶段.这就是为什么我正在寻找测试驱动程序的方法,而无需实际构建整个程序并将其上传到设备上.
基于下面的优秀答案,我认为解决问题的合理方法是使用IOCTL公开驱动程序功能,然后在嵌入式设备的应用程序空间中编写测试以实际运行驱动程序代码.
让一个小程序驻留在设备的应用程序空间中也是有意义的,它暴露了一个可以通过串行或USB运行驱动程序的API,这样单元测试的内容就可以写在PC上了,它将与PC通信.硬件并运行测试.
如果项目刚刚启动,我认为我们可以更好地控制组件的隔离方式,以便主要在PC级别进行测试.鉴于编码已经完成并且我们正在尝试将测试工具和案例改装到系统上,我认为上述方法更实用.
谢谢大家的回答.
在过去,这就是我们测试和调试设备驱动程序的方式.调试这种系统的最佳方法是让工程师将嵌入式系统用作开发系统,并且一旦达到足够的系统成熟度,就可以取消原有的交叉开发系统!
根据您的情况,我想到了几种方法:
添加ioctl处理程序:每个代码执行特定的单元测试
使用条件编译,将main()添加到驱动程序中,该驱动程序在驱动程序中执行功能单元测试并将结果输出到stdout
.
为了便于调试,可能可以将其设置为多平台可操作,这样您就不必在目标硬件上进行调试.
也许条件代码也可以模拟环回式设备.