我们称它们为BIST：内置自检。

从我们的角度来看，主要的“客户”是制造业。他们需要一套可以运行的测试来验证来自生产线末端的硬件是否良好。开发团队负责实施测试，制造负责定义和运行测试。

您说它们接近单元测试，并在设备上运行，但大多数周边功能都被禁用。所以我称它们为单元测试。

您已经尽可能多地隔离了嵌入式设备，并且如果您使用尽可能多的模拟和存根来单独测试每个类和方法，那么它们就是单元测试。

您使用嵌入式设备的事实并不重要。与为 PC 编写代码和在 PC 上运行单元测试相比。所以呢？它们仍然是单元测试。

开发人员负责编写和维护单元测试。它们应该可由任何人运行，理想情况下，如果可能的话，您应该将其作为持续集成的一部分来完成，但这可能是一个挑战，因为将设备连接到 CI 并不总是那么容易。否则，您应该让开发人员负责运行它们以确保他们的新/更改的功能不会破坏任何东西。QA/测试人员应负责在接受新代码之前确认单元测试全部通过。

我们处于类似的情况（使用 Symbian）。我们使用在设备上运行的单元测试框架，并尽可能地模拟和存根。起初，我们在实际设备上运行单元测试，在正常启动后运行。我们的 CI 为我们制作了安装文件。

接下来，在完全启动后，我们开始在模拟器上运行它们。这意味着我们可以将运行和结果作为每次提交的 CI 循环的一部分（它还计算代码覆盖率）。

接下来，我们在模拟器直接启动到 textshell 模式的情况下运行它们，因此大多数环境都没有启动和运行。这样也快很多。事实上，当我们第一次在 textshell 中运行时，一些单元测试失败了，因为我们发现了一些没有被存根的依赖项；在 textshell 中它们不可用。

根据我从事的项目，这些测试称为Unit Tests on Target或HW/SW Integration Tests。它们的目的是测试看门狗或 ISR 等硬件功能。一些测试值得拥有自己的类别，例如Boot Tests。