查找嵌入式C语言程序/软件中的缺陷的多种技术

上述技术中的每一种都能查找出某一类特定的错误。 即使如此， 假设用户仅采用上述技术中的一种或者几种来进行验证， 这样的验证方法很有能够会漏过对顺序中的一些缺陷的反省。 解决此类效果的一种安全和无效的战略就是同时使用上述软件验证中的所有互补技术。 这样就能建立起一个牢固的框架来帮助用户反省出能够会避开某种特定技术的缺陷。 与此同时， 　　本文将详尽阐述基于模式的静态代码剖析、运转时内存错误检测、单元测试以及数据流剖析等自动化技术共同使用时是如何查找出嵌入式C言语顺序/软件中的缺陷的。 本文中将以ParasoftC++test为例来演示上述各项技术。 C++teST是一个经广泛的最佳实践证明能提升软件开发团队开发效率以及软件质量的自动化集成解决方案。 　　当读者在阅读本文以及任何时分思考察找到的缺陷时， 关注文中的截图是很重要的。 毫无疑问对任何开发团队都是一项必不可少的任务。 　　情形简介　　为了给出一个详细的示例， 我们没有在LCD屏上看到所预期的输出。 　　我们尚不明确系统不能正常任务的缘由， 因此我们设法对系统进行调试， 但是在目标板上进行调试是一件耗时而且烦人的事。 因为我们不得不手动剖析调试器的结果并试图人工判别出效果的真正缘由。 或者我们使用一些被证明能自动定位出错误的工具或技术来帮助我们减轻负担。 那么我们不得不回到使用调试器作为最后的方法。 　　基于模式的静态代码剖析　　这里， 我们假定仅在绝对必要的状况下才使用调试器进行调试， 因此我们从运转基于模式的静态代码剖析末尾。 它将查找到如下图所示的效果：　　这是违犯了MISRA的一个规则， 确实， 编程者此处的本意是使用比较运算符而不是赋值运算符。 因此我们将C言语此处检测到的冲突修正掉， 并重新运转顺序。 　　我们发现有了一些改善：一些输出被显示在了LCD屏上了。 但是， 由于一次拜访违规， 顺序解体掉了。 我们是应该使用调试器还是继续使用自动化的错误检测技术。 　　整个顺序的运转时内存监测　　为了进行运转时内存监测， 这样的插装是轻量级的， 当我们把顺序上载到目标板上并运转经过插装的顺序后， 我们将结果下载到PC上， 如下的错误将被报告出来：