我们公司为微控制器开发裸机嵌入式软件。到目前为止，我们一直在目标或模拟器上使用手动单元测试，特别是针对瑞萨微控制器(RL78和RX系列)。我们现在计划进入自动单元测试。我们的想法是将它们集成到我们现有的CI系统中。
在这一点上，我们陷入了一个两难的境地。到目前为止，我们一直在使用相同的编译器和目标(或模拟器)运行单元测试，这些编译器和目标(或模拟器)稍后将用于将软件部署到生产环境中。我们希望保持这种方法，因为开发人员(和每个人)特别喜欢使用相同的条件进行测试和部署。因此，我们的想法是采用C语言编程的测试工具/库，允许我们在使用模拟器的嵌入式环境中编译和运行测试。(例如http://www.throwtheswitch.org/unity)但是，另一方面，我们应对两种即将到来的情况，使困境出现:
我们越来越多地使用Cortex uC，在那里很难获得特定的模拟器来实现自动化。(如瑞萨RA系列)
许多先进的测试工具都是用c++开发的，并且考虑在x86架构下使用gcc/g++编译器用于PC环境，这与我们预期使用arm-none-eabi-gcc编译的Cortex目标不匹配。
因此，在这一点上，我们想知道，这将是我的问题，如果我们的最终目标将是Cortex uC，并且最终将使用arm-none-eabi-gcc生成二进制文件，那么使用gcc运行单元测试的可靠性如何。当为不同的目标编译时，我将间接地询问gcc和arm-none-eabi-gcc之间的差异。
我很感激那些了解gcc内部结构的人的反馈，他们可以处理类似的问题。
提前感谢，
Ignasi Villagrasa
一般来说，模拟器是无用的，但对于生产测试尤其如此。因为它是一个嵌入式系统，你想测试软件和硬件-测试软件没有预期的MCU和硬件到位只是无稽之谈。
如果你坚持使用像模拟器或PC"测试套件"这样的软件;然后意识到:
- 这是一个不完整的测试，没有测试你的产品的核心功能。
- 它不能用于测试驱动程序/硬件相关代码，它只能测试抽象算法。
- 只能用于开发测试，不能用于生产测试。
至于如何正确地测试您的特定嵌入式系统，这取决于应用程序和产品应该做什么。如果你按照书本来做你的项目，那么你有:规范，导致实现，导致测试。测试的唯一目的是验证实现是否遵循规范。
因此，如果规格说明产品应激活10个继电器，则需要将软件闪存到实际PCB上的实时MCU上，然后正确执行测试，然后验证所有10个继电器都应激活。
这个完整和正确的产品测试不能用任何其他方法来完成。所以问问你自己，你是否真的需要不正确和不完整的模拟测试。也许你的开发相关测试应该集中在更有意义的事情上，比如设计审查、编码标准、静态分析、代码审查等。