测试 – 嵌入式C项目的代码覆盖率分析[已结束]

我最近开始研究一个非常大的C项目,在完成90％的实施后,确定他们需要在测试期间展示100％的分支覆盖率.该项目托管在一个嵌入式平台(Green Hills Integrity)上.我正在寻找StackOverflow上其他人在类似环境中使用代码覆盖产品的建议和经验.我对这些类型的工具的正面和负面评论感兴趣.

解决方法

100％分支机构覆盖？这是非常必要的,特别是因为某些分支(例如状态机的case语句中的默认值)不可能运行.我希望有一些例外情况,如果没有,你可能需要了解覆盖测试在开始之前可以做什么和不能完成 – 否则你最终会把你的头发拉出来,或者更糟糕的是 – 提供不正确的数据.

嵌入式系统的大多数覆盖测试实际上是在PC上执行的.代码被移植,微控制器的某些方面在软件中模拟,并且运行Bullseye或其他类似的PC代码覆盖实用程序.这样做的原因是,有太多的微控制器和编译器/调试器/测试环境为每个工具开发代码覆盖工具.

当针对特定嵌入式平台存在代码覆盖工具时,它们不像PC平台那样强大,可配置,易于使用和无错误.处理器通常不具备执行良好代码覆盖所需的跟踪功能(没有高端仿真硬件),而无需在固件中插入额外的调试代码,从而产生难以控制的后果和副作用,尤其是在时序问题中实时系统.

只要您可以抽象出特定于硬件的代码(并且因为您正确使用C,这应该很容易,对吗？ – D),移植代码并不是非常困难.你将遇到的最大问题是类型,虽然在C中比在C中更好地指定但仍然存在一些问题.确保使用types.h或类似的设置来专门告诉编译器您使用的每种类型以及如何解释它.

之后,你可以到镇上测试PC上的核心逻辑.如果您有兴趣开发所需的软件仿真,您甚至可以测试低级硬件驱动程序,尽管时序问题可能有点麻烦.

诸如MxVDev之类的软件测试工具为您执行了大量的微控制器仿真,并帮助解决了时序问题,但即使有这样的帮助,您仍然可以进行一些工作.

如果您必须在系统本身上执行此操作,则需要为具有覆盖功能的处理器购买仿真器 – 这不是一个便宜的命题(许多仿真器对于整套工具和仿真硬件的成本高达3万美元),但它是高可靠性环境中使用的众多工具之一,如汽车和航空航天工业.

-亚当

免责声明：我为生产MxVDev的公司工作.

原文地址：https://www.jb51.cc/c/111052.html