如何使用TCP/IP堆栈在PIC18上对引导加载器进行单元测试？

Question

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

我现在要做的是彻底测试引导程序，但是我在选择正确的方法和工具时遇到了一些困难。我可以使用Pickit 3 ICD，但没有任何其他专用硬件，如逻辑分析器等(听诊器除外)。引导加载器是作为一个分层的FSM实现的，它可能(或不可能)使事情更加复杂。

我考虑过至少单元测试/模块测试--引导加载器的所有不同部分--并将FSM的所有状态作为单独的功能。在互联网上有一些单元测试框架，其中一些声称可以在嵌入式和受限环境中使用，比如我的。

这些程序的问题是，大多数是作为某种C库来实现的，这些库将与程序的其余部分一起编译，但他们都希望编译器遵循某种标准。XC8编译器实际上确实遵循C90标准，但并没有完全扩展(很明显，这是因为文档中的“与ANSI标准的差异”一章)。这在编译框架时造成了麻烦。

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

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

要求/pre/说明：

• 我说的是白盒测试方法。目前，黑匣子测试并不痛苦。此外，在功能上，引导加载程序没有编译，而且所有的功能需求都是可测量的。
• 我希望尽可能多地自动化测试，甚至在我按“编译”时自动触发测试。
• 没有任何严格的性能要求，我有一些空闲的ROM内存，所以代码工具，比如放很多探针，应该不是什么大问题。
• 我远不是一个测试大师。我上面使用的任何花言巧语都来自于几个小时的研究，但我没有任何实际的测试经验。

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

比特人，

Answer 1

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

我和seatest相处得很好。它是非常基本的；它不提供统一等人提供的更高级的特性(没有自动模拟)，但是它是可移植的、直接的C，并且支持测试所需的核心特性。

我的第二个建议是在您的MCU拥有所有可用的寄存器之后，创建一个带有变量的文件。这是很容易刮刮微芯片的链接脚本的注册名称，并把他们放在一个c文件。这使得在PC平台上编译所有代码变得更加容易。这可以使您的启动和运行更快，也使测试更容易。

Answer 2

微芯片的XC8 / PIC16有一个分叉，它不使用setjmp/longjmp，这里是：https://github.com/jwalkerbg/Unity

使用单元测试意味着代码应该是可测试的。将您的代码组织到这个需求中可能有助于您获得每个功能的职责和前后条件，从而更好地定义。

尝试隔离不依赖于硬件状态的代码(如md5计算)，以便在您的开发环境(在您的英特尔i7中运行)上测试它。此代码的测试可以很容易地自动化(您可以将测试作业添加到您的构建脚本中，还可以在一个连续集成服务器中运行所有内容)。

对于依赖于硬件状态的代码，您可以(1)模拟硬件或使用模拟器(并且仍然在您的开发或持续集成服务器环境中运行它)，或者(2)在实际的恶意软件中运行嵌入它的测试。备选案文2可能不易自动化。您甚至可能需要手动部署和运行每个测试。而且，获得测试结果可能并不简单，因为控制台或文件系统可能无法在您的嵌入式环境中使用。