嵌入式软件测试相关分析

最新推荐文章于 2024-07-06 11:55:17 发布

MickyCode

最新推荐文章于 2024-07-06 11:55:17 发布

阅读量782

点赞数 17

文章标签：单片机 mcu 单元测试集成测试架构

本文链接：https://blog.csdn.net/Micky613/article/details/139579634

版权

嵌入式软件测试相关分析

1. 引言

在软件发展之初，上个世纪五六十年代，软件被视为数学领域，编程是为了进行数学计算，由数学公式推导，来写函数。因此，在那个时候所编写的程序是被视为数学问题，数学的一大特征即是可证明性，可以使用数学推导的方式来证明一段程序的正确性。但是随着软件行业的发展，代码的量级越来越大，功能越来越复杂，再将编程视作数学问题，将所有的代码以数学方式来证明变得不切实际，编程由此而转为了科学问题。而科学问题的特性即是，不可证明性与可证伪性。不可证明即我们无法证明这个程序完全正确，永远不出问题。可证伪性表明我们可以通过一些特例来去验证我们的程序，当这些特例通过时，我们可以说，暂时未发现问题，但不能说程序绝对正确。当这些特例未能通过时，那么我们就可以说，这个程序绝对有问题。这样的一些特例即为软件测试的测试用例。

软件测试的意义对于软件开发来说是毋庸置疑的，正如Robert C Martin在《The Clean Coder》中所言:

I don’t think that surgeons should have to defend hand-washing, and I don’t think that programmers should have to defend TDD.

2. 测试方式

软件测试既有手动测试也有自动化测试，手动测试相信每个开发人员都有做过这样的事，我们常常写了一些功能，然后在main函数这样的地方去直接调用我们写的功能，这样的测试往往是一次性的，随着开发的进行，这些测试就会被抛弃。或者更进一步，会有个功能回调的表，然后我们手动来触发相应的功能，来验证功能的正常。而自动测试借助一些测试框架，来隔离业务代码和测试代码，并且能够一次性测试多个用例，测试代码和业务业务代码相应迭代演进。

自动化测试的意义在于快速、快捷、全面地进行软件测试。我们开发中应该尽量做到一键实现测试，只有足够便捷，才方便频繁地测试我们的代码。而且在开发过程中，应当尽量精简测试，当不涉及其他模块时，我们仅需要验证当前开发模块，编译和运行测试用例不超过10s，这样我们可以在每分钟都运行一次测试用例，直到模块开发完成。

3. 嵌入式软件测试

嵌入式软件也需要进行测试，嵌入式软件开发人员部分是硬件开发人员兼职，使用C语言来完成驱动开发。对于软件测试，嵌入式行业，尤其是mcu方面并未有足够的认识，当然这也是嵌入式开发所独特开发方式和运行环境所致，嵌入式开发通常都是需要跨平台编译，也就是说开发平台和运行平台不同，这也导致了依赖于硬件的IO会有所不同，如果仅在开发平台上运行测试用例，那无法避免地需要将设备驱动相关的部分打桩掉，使得代码运行在设备无关的平台上。所以这种方式只能测试应用层的一些代码，对于驱动部分的代码则无能为力。

在最近我们部门展开了一个新项目，将原来的mcu平台迁移到arm64的CPU平台上，运行linux内核的rtos系统。在mcu项目中，就缺乏相应的测试手段，仅能通过一些shell的方式来手动测试部分功能。缺乏自动化测试，就使得开发时不能时常测试，验证时也无法全面测试。所以最近在考虑搭建测试框架的问题，原先的意思是需要一个系统测试框架，在我看来单元测试反而更加急迫，也更贴近于开发人员。不过最后决定系统测试和单元测试框架都做，先实现较为基础的单元测试框架，然后再整合单元测试框架和必要的系统模拟组件实现系统测试框架。

单元测试是对软件微颗粒级别的测试，若被测试功能对其他模块或组件有所依赖，那么最好将依赖的部分打桩掉，以免其他模块的功能修改影响到本测试用例的检测，也就是说功能的测试应该独立化，不应有所依赖，在面向对象的开发模式中，模块和模块之间本就是解耦的，程序的可测试性相当好，然而在面向过程中，往往模块之间会有直接的依赖，使得程序的可测试性下降，要么将业务代码解耦重构，要么使用一些三方的打桩工具，在运行时使用桩函数替换掉原有的接口。

系统测试更像模拟出一套运行系统出来，来完整测试整个业务流程，根据项目的特点来设计模拟器功能，这和项目的业务强相关，这里就不过多赘述。

上述的单元测试和系统测试仅在应用层使用，在开发环境中，使用高级的测试工具来完成，自然不是问题。但我们还有一部分代码未受到测试用例覆盖，那就是和硬件高度相关的驱动代码。在之前的一篇文章中提出嵌入式软件开发应该分层设计¹，在测试方面也应当进行分层测试。驱动抽象层及应用层代码，应该在开发环境中使用高级测试框架实现。设备层代码应当使用运行环境，使用一些轻量级的测试框架集成测试设备驱动代码，这样就可以尽可能地覆盖更多的代码，以提高测试覆盖率，实现测试全面自动化测试。

4. 总结

软件作为科学问题，呈现不可证明性和证伪性，就表明了测试是永远不会停止，测试会持续存在于软件的整个生命周期内，即使再完善的测试用例覆盖和系统验证，也无法保证软件在交付之后不会问题。受限于人的有限性，无法在测试阶段就保证能覆盖所有场景，运行时暴露出问题，也可以进一步去完善我们的测试场景，在接下来的回归验证中，我们就可以覆盖更全面的场景。自动化测试的意义在于解决一些低效的测试手段，让自动化实现在开发和验证的每一个时刻，根据各自的需求，实现不同测试范围的自动化测试。在嵌入式软件开发中，有其特殊性，即非常依赖于硬件功能，使得测试情况变得复杂。不过使用测试分层是一个非常好的思路，配合软件设计时的架构分层，可以更好地解决嵌入式软件的架构问题。在有些嵌入开发中，将设备层做成BSP包，软件开发人员仅需要负责应用层代码开发，在这种情况下，BSP作为外部依赖，业务层的开发人员应该对其做验收测试，已判断外部依赖功能的有效性。