我们的想法是编写一个通用单元测试函数，该函数将使用外部生成的测试输入参数(例如来自通信)在嵌入式目标mcu端执行任意被测函数。因此，远程mcu的单元测试函数只需编写一次，通过某种通信方式发送已知的函数地址和输入参数，在主机PC上生成测试用例。
以为例，如果在远程MCU上有一个功能int sumftwpoints (int, int)要测试，主机pc将传递给这个unitTestFcn指针sumftwpoints的地址(由链接器知道)和在主机pc上生成的两个随机int，然后通过uart发送到嵌入目标。嵌入目标调用";"通过函数指针接收提供的参数数，并返回结果发送回主机PC进行结果检查。
如果这是合理的，或者在这个测试方案中存在根本缺陷，有什么反馈吗?好处是将单元测试从嵌入式端移动到主机PC端，从而具有无限的测试用例可扩展性。
如果我要做一个这样的系统，我会让它由3部分组成:
- 以函数地址和参数的形式指定测试的pc端软件。
- 在PC和MCU之间实现某种通信的接收器/发射器对，例如通过串行，Wifi或任何可用的。
- 运行在MCU上的测试执行器，执行函数并返回结果(如果有的话)。
pc端软件可以读取你的构建过程中产生的一些工件来简化事情，例如，你可以使用实际的函数名，而不必在测试中指定实际的地址。
通信协议应该是基于文本的，依赖于接收方根据接收平台转换合适的值。
执行器必须实现特定于MCU体系结构的ABI。这是你遇到的第一个主要障碍。首先，abi变化很大。从Arm的一些参数在一个或多个寄存器中传递，一些作为指向实际参数的指针，一些在堆栈上传递，到x86的所有参数都是基于堆栈的。
你的下一个主要障碍将是结构。如果你要允许调用带有结构参数或返回值的函数，你必须知道编译器是如何为每个特定结构选择打包字段的。
总而言之，创造这样的东西将是一项不平凡的任务，可能最终没有那么有用，除非你投入了大量的工作，就像把它变成一个商业产品一样。
另一种选择是您在设备上留下一些刮擦空间，然后在PC上交叉编译您的测试，然后将它们逐个或分组发送到MCU，安装在刮擦空间并执行。
在任何情况下，由于明显的安全问题，这种功能不应该包含在发货的产品中。