3

我正在使用Microchip的MPLAB X 1.60中的XC8 C编译器1.12开发引导加载程序。目标芯片是PIC18F87J60。我的引导加载程序做了一些引导加载程序通常不会做的额外事情。它将应用程序映像从服务器下载到闪存，并通过计算MD5哈希和来验证其完整性。此外，它必须通过特定于该项目的服务器上的身份验证测试。为了使所有这些工作，我使用 Microchip 的 TCP/IP 堆栈v5.42。

我现在要做的是彻底测试引导加载程序，但我在选择正确的方法和工具时遇到了一些麻烦。我可以使用Pickit 3 ICD，但不能使用任何其他专用硬件，例如逻辑分析仪等（示波器除外）。引导加载程序被实现为分层FSM，它可能（或可能不会）使事情变得更加复杂。

我在考虑至少对引导加载程序的所有不同部分进行单元测试/模块测试，并将 FSM 的所有状态视为单独的功能。互联网上有一些单元测试框架，其中一些声称可以在像我这样的嵌入式和受限环境中使用。

问题在于，大多数都是作为某种 C 库实现的，可以与程序的其余部分一起编译，但他们都希望编译器遵循一些标准。XC8编译器实际上确实遵循C90标准，但没有完全扩展（显然是文档中的“与 ANSI C 标准的分歧”一章）。这给编译框架带来了麻烦。

我可以通过模拟所有硬件和注册访问并在我的 Windows 7 开发机器上测试来解决这个问题，但这将是大量的工作，因为我使用引导加载程序严重依赖的 TCP/IP 库。另一个缺点是最终我想在芯片上进行测试，因为 C 代码在 PIC 芯片上的行为可能与我的intel i7上的行为不同。

有人对如何正确安装unit-/moduletest我的引导加载程序有任何想法吗？在这样的平台上对这样的程序进行单元测试甚至是一个好主意吗？还有其他我可能使用的测试方法吗？

要求/预/注释：

  • 我说的是白盒测试方法。黑盒测试目前并不痛苦。此外，从功能上讲，引导加载程序没有被编译，所有功能要求都是可测量的。
  • 我想尽可能地自动化测试，甚至在我按下“编译”时自动触发测试。
  • 没有任何严格的性能要求，而且我有一些备用 ROM 内存，因此像放入大量探针这样的代码检测应该不是什么大问题。
  • 我远不是一个测试大师。我上面使用的任何花哨的词都来自几个小时的研究，但我没有任何实际的测试经验。

提前感谢您的任何想法和建议。

比特垃圾，

4

2 回答 2

2

我发现嵌入式系统中的单元测试非常困难。外围设备的副作用非常繁重。最难处理的是读取内存位置触发的副作用（例如读取清除标志）。您能做的最好的事情就是隔离硬件访问。即使在一个模块内限制访问也是一个好主意。单元测试是值得的，但在嵌入式空间中可以比其他测试更快地达到收益递减点。

我在seatest上运气不错。这是非常基本的；它不提供Unity等人提供的更高级的功能（没有自动模拟），但它是可移植的、直接的 C 语言，并支持测试所需的核心功能。

我的第二个建议是创建一个文件，其中包含以 MCU 拥有的所有可用寄存器命名的变量。很容易从 Microchip 的链接描述文件中获取寄存器名称并将它们粘贴到 ac 文件中。这使得在 PC 平台上编译所有代码变得更加容易。这可以让您更快地启动和运行，也使测试更容易。

于 2013-07-01T03:13:52.330 回答
2

Microchip 的 XC8 / PIC16有一个Unity的分支，它不使用 setjmp/longjmp，这里：https ://github.com/jwalkerbg/Unity

使用单元测试意味着您的代码应该是可测试的。根据此要求组织代码可以帮助您更好地定义每个功能的责任和前置/后置条件。

尝试隔离不依赖于硬件状态的代码（如 md5 计算），以便您可以在您的开发环境中测试它（在您的 intel i7 中运行）。这段代码的测试很容易实现自动化（您可以在构建脚本中添加测试作业，也可以在持续集成服务器中运行所有内容）。

对于依赖于硬件状态的代码，您可以(1)模拟硬件或使用模拟器（并且仍然在您的开发或持续集成服务器环境中运行它），或者(2)运行将其嵌入到您的实际硬件中的测试。选项2可能不容易自动化。您甚至可能必须手动部署和运行每个测试。此外，获得测试结果可能并不简单，因为控制台或文件系统在您的嵌入式环境中可能不可用。

于 2014-01-14T18:18:08.077 回答