问如何对stm32编程进行单元测试

EN

我知道有两种常见的策略：

1. 确保您有一个良好的软件组件架构，包括一个定义良好的接口，用于只负责访问HW端口寄存器的硬件/驱动程序组件。为低级硬件访问组件设计单独的验证方法，从而避免单元测试工具。要建立这样的验证概念，请确保

- to avoid any processing logic in HAL/driver components as far as possible.
- to avoid any HW dependencies and any non-portable code in the remaining parts of your SW.

现在，您可以将代码的无硬件部分转移到一些PC架构(x86或其他任何架构)，并使用传统的UT工具进行所有的单元测试。当然，您的UT会忽略与STM32和您的PC之间的差异有关的任何错误。请注意，这通常不是一个太大的问题，因为特定于硬件的功能已经被“推入”到HAL中，而在代码的其他部分中，您只寻找与硬件/体系结构无关的逻辑错误。

我知道答案的这一部分是围绕你的主题进行讨论的，而不是提供你所要求的解决方案。尽管如此，许多项目都是这样做的。

1. (为您的单元测试框架开发一个STM32集成，或者)购买一个支持您的硬件架构的商业单元测试工具。现在STM32非常流行，所以有很多商业工具(Tessy，VectorCast等)。提供适合您系统的集成。请注意，您还必须选择与此工具选择一致的构建工具链(可能还有调试适配器)，因此您必须检查一些额外的约束。

为了在这两种策略之间做出决定，您应该考虑执行单元测试的目的是什么这个问题：

• 您将通过这种方式查找哪些类型的错误？您已经在应用哪些其他验证方法？您的应用程序必须实现/保证哪种健壮性-您的应用程序有多重要？

通常，某种类型/级别的关键程度对应于一定的工作量，以便将软件/系统中残留错误的概率降低到合理可行的最低水平()。您应该确保以平衡的方式“花费”这些努力，以便您在每次添加验证时都能找到尽可能多的错误。低级代码的单元测试更加单调乏味，并且通常比其他类型的测试发现更少的错误(每个测试用例或每个工作小时)。

• 为了满足安全标准(例如IEC 61508-3及其衍生标准)、公司内部标准等过程标准，您是否必须证明一定程度的UT覆盖率？然后，您必须检查这些标准对您的应用程序的要求，并与相应的评估人员讨论您的策略。

如果这些要求适用于您的情况，您将必须说服评估员，所应用的验证措施是足够的。为了提高专业效率，在项目开始时决定(并开始讨论)遵循哪种策略是至关重要的。

编辑：我刚刚遇到了a good discussion of this topic at SoftwareEngineeringStackExchange。看一下那里。

我建议Unity测试框架只是添加到项目中的几个头文件。您可以使用Cmock和Ceedling来增强此功能，以便在主机上构建您的单元测试。您还可以使用platformio来收集集成测试结果，如here所示。我还没有弄清楚Cmock是否可以在stm32板上工作，但我可能会在不久的将来尝试。

我已经使用cmock和ceedling (在Linux上)对STM32代码进行了单元测试，然后在target上进行了一些集成测试。