目前用于测试固件的可用软件工具有哪些？
我是一名软件工程师，将/可能被聘为固件测试工程师。我只是想了解市场上用于测试固件的一些软件工具。您能否介绍一下它们并解释一下它们为固件提供的测试类型？提前致谢。
I'm a software engineer who will/may be hired as a firmware test engineer. I just want to get an idea of some software tools available in the market used in testing firmware. Can you state them and explain a little about what type of testing they provide to the firmware? Thanks in advance.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
测试有多种形式，可以在不同阶段进行。除了编写代码之前的设计验证之外，代码测试还可以分为单元测试、集成测试、系统测试和验收测试（尽管确切的术语和阶段数量可能非常不同）。在 V 模型中，这些将与需求和设计开发的阶段水平对应。此外，在开发和维护中，您可能会执行回归测试 - 确保已修复的错误在应用其他更改时保持固定状态。
就工具而言，可分为静态分析和动态分析。静态工具在不执行的情况下分析源代码，而动态分析则关注代码在执行期间的行为。一些（昂贵的）工具执行“抽象执行”，这是一种静态分析技术，可以确定代码在执行过程中如何在没有实际执行的情况下失败，这种方法的计算成本很高，但可以比传统的动态分析处理更多的执行路径和变量状态。
静态分析最简单的形式是代码审查；让人类阅读您的代码。即使是这种表面上手动的过程，也有一些工具可以提供帮助，例如 SmartBear 的 Code Collaborator。同样，动态分析的最简单形式是在调试器中简单地单步执行代码，甚至仅使用各种测试场景运行代码。第一个可能由程序员在单元开发和调试期间完成，而后者更适合验收或集成测试。
虽然做得好的代码审查可以消除大量错误，尤其是设计错误，但它在查找由编程语言的微妙或神秘语义引起的某些类型的错误方面可能并不那么有效。这种错误适合使用静态分析工具自动检测，例如 Gimpel 的 PC-Lint 和 FlexeLint 工具，或者Programming Research 的 QA 工具，尽管成本较低的方法，例如将编译器的警告级别设置为高并使用多个编译器进行编译也很有用。
动态分析工具有多种形式，例如代码覆盖率分析、代码性能分析、内存管理分析和边界检查。
高端工具/供应商包括 Coverity、PolySpace（抽象分析工具），康塔塔、LDRA 和 Klocwork。处于较低端（价格方面，不一定有效）的是 PC-Lint 和 Tessy，甚至开源的splint（仅限 C），以及大量单元测试工具
Testing comes in a number of forms and can be performed at different stages. Apart from design validation before code is even written, code testing may be divided into unit testing, integration testing, system testing and acceptance testing (though exact terms and number of stages may very). In the V model, these would correspond horizontally with stages in requirements and design development. Also in development and maintenance you might perform regression testing - ensuring that fixed bugs remain fixed when other changes are applied.
As far as tools are concerned, these can be divided into static analysis and dynamic analysis. Static tools analyse the source code without execution, whereas dynamic analysis is concerned with the behaviour of the code during execution. Some (expensive) tools perform "abstract execution" which is a static analysis technique that determines how the code may fail during execution without actual execution, this approach is computationally expensive but can process far more execution paths and variable states than traditional dynamic analysis.
The simplest form of static analysis is code review; getting a human to read your code. There are tools to assist even with this ostensibly manual process such as SmartBear's Code Collaborator. Likewise the simplest form of dynamic analysis is to simply step through your code in your debugger or even to just run your code with various test scenarios. The first may be done by a programmer during unit development and debugging, while the latter is more suited to acceptance or integration testing.
While code review done well can remove a large amount of errors, especially design errors, it is not so efficient perhaps at finding certain types of errors caused by subtle or arcane semantics of programming languages. This kind of error lends itself to automatic detection using static analysis tools such as Gimpel's PC-Lint and FlexeLint tools, or Programming Research's QA tools, though lower cost approaches such as setting your compiler's warning level high and compiling with more than one compiler are also useful.
Dynamic analysis tools come in a number of forms such as code coverage analysis, code performance profiling, memory management analysis, and bounds checking.
Higher-end tools/vendors include the likes of Coverity, PolySpace (an abstract analysis tool), Cantata, LDRA, and Klocwork. At the lower end (in price, not necessarily effectiveness) are tools such as PC-Lint and Tessy, or even the open-source splint (C only), and a large number of unit testing tools
以下是我发现有用的一些固件测试技术...
PC 上的单元测试；即从固件中提取一个功能，并在更快的平台上编译和测试它。例如，这可以让您详尽地测试一个功能，而这在现场会非常耗时。
使用自由运行的硬件计时器来检测固件中断处理程序：进入和退出时的滴答声以及中断计数。跟踪每个中断处理程序的最小和最大频率以及周期。该数据可用于进行速率单调分析或截止时间单调分析。
使用标准协议（例如 Modbus RTU）来按需提供一系列状态数据。这可用于配置和验证数据。
使用自动构建过程将固件版本号构建到代码中，例如，通过从源代码存储库获取版本信息。使用#3 使版本号可用。
使用 lint 或其他静态分析工具。使用 -Wall 要求 lint 和编译器发出零警告。
通过将固件的 CRC 嵌入到代码中并在运行时检查它的方法来增强您的构建工具
Here are some firmware testing techniques I've found useful...
Unit test on the PC; i.e., extract a function from the firmware, and compile and test it on a faster platform. This will let you, for example, exhaustively test a function whereas this would be prohibitively time consuming in situ.
Instrument the firmware interrupt handlers using a free running hardware timer: ticks at entry and exit, and count of interrupts. Keep track of min and max frequency and period for each interrupt handler. This data can be used to do Rate Monotonic Analysis or Deadline Monotonic Analysis.
Use a standard protocol, like Modbus RTU, to make an array of status data available on demand. This can be used for configuration and verification data.
Build the firmware version number into the code using an automated build process, e.g., by getting the version info from the source code repository. Make the version number available using #3.
Use lint or another static analysis tool. Demand zero warnings from lint and from the compiler with -Wall.
Augment your build tools with a means to embed the firmware's CRC into the code and check it at runtime.
我发现压力测试很有用。这通常意味着在短时间内给系统大量输入，然后看看它如何处理它。输入可能是
这些类型的测试可以消除许多错误（特别是在性能至关重要且有限的系统中）。一个好的日志系统也有利于追踪压力测试引发的错误的原因。
I have found stress tests useful. This usually means giving the a system a lot of input in a short time and see how it handles it. Input could be
These types of tests can shake out a lot of bugs (particularly in systems where performance is critical as well as limited). A good logging system is also good to have to track down the causes of the errors raised by a stress test.
我们结合使用单元测试、集成测试和系统测试。
这三种类型的测试共同满足了嵌入式固件质量保证的绝大多数要求。如果您需要示例和更多代码来帮助您在 Zephyr RTOS 上实现所有这些，那么您可以随时查看瑞典嵌入式平台 SDK 存储库中提供的代码：https://github.com/swedishembedded/sdk
We use a combination of unit testing, integration testing and system testing.
Together, these three types of testing cover vast majority of requirements for quality assurance of embedded firmware. If you would like examples and more code that can help you implement all of these on Zephyr RTOS then you can always go through the code provided in the Swedish Embedded Platform SDK repository here: https://github.com/swedishembedded/sdk