很多嵌入式软件团队在刚开始用静态分析工具的时候，通常都会碰到两个头疼的问题，那就是Testbed编码规范检查怎么开启，以及Testbed编码规范检查结果怎么筛选；这里提到的Testbed软件，一般就是指LDRA Testbed和TBvision相关的工具环境。TBvision这个工具能够让操作人员在源代码的上下文里面去查看违反编码标准的地方，而且还能在这些违规项、源代码以及软件支持的编码标准之间，来回切换着进行查看。

　　一、Testbed编码规范检查怎么开启

　　在真正去开启Testbed编码规范检查之前，最重要的事情其实不是着急去运行分析，而是要先把工具的各种配置弄好，让工具能够“看懂”这个项目；因为很多时候检查失败，原因并不是代码写得有错误，而是因为头文件的路径、宏定义、编译器选项还有目标平台的信息没有配全，结果导致工具在解析代码的阶段就走偏了。

　　1、导入工程并确认源文件范围

　　大家在打开Testbed或者TBvision软件以后，要先建立一个对应的项目，然后把需要检查的C、C++源文件都加到这个工程的范围里面去；如果说这个项目的目录特别大，那不建议在刚开始的时候就把所有的代码全都拉进去，可以先挑出来一个单独的模块去进行试跑，比方说只选驱动层、或者BSW模块、或者应用层里面的某一个功能包。

　　2、补齐头文件路径和宏定义

　　因为编码规范检查主要是靠静态解析来做的，所以工具必须要能在项目里面找到对应的头文件，而且还得认识那些条件编译的宏；可以结合着之前用的IDE、Makefile、CMake、或者是编译脚本和构建日志，把【include path】、【predefined macro】、还有编译器的类型、语言标准这些内容都手动补充进去；LDRA工具套件里面的静态分析功能，它的原理本身就是在不运行程序的情况下去检查源代码，以此来执行编码标准、找出那些可能存在的错误，并且对可维护性、复杂度这些质量指标进行评估。

　　3、选择编码标准和规则集

　　在进入到规则配置的页面之后，根据自己项目的具体要求，去勾选MISRA C、MISRA C++、CERT、CWE、或者是AUTOSAR C++等规则集；LDRA这个工具支持的常见规则有很多，像是AUTOSAR C++、CERT C/C++、CWE、MISRA C:2023、MISRA C:2012、以及MISRA C++:2008这些都在里面，而且企业也能根据自己行业的标准来做自定义的规则。

　　4、执行静态分析检查

　　把所有的配置都弄完以后，就可以去选择【Static Analysis】或者对应的编码标准检查入口了，在设置好检查范围之后，就能启动分析。

　　二、Testbed编码规范检查结果怎么筛选

　　在检查结果出来之后，大家的筛选思路一定要保持清晰，更实用的干活方法，其实是先把“必须马上处理的问题”和“需要后面再确认的问题”给区分开，然后再按照模块的负责人，一步一步地去推进修改。

　　1、先按严重程度筛选

　　在结果的列表里面，大家可以优先去查看Error、Mandatory、Required、或者是高风险和安全相关的那些问题；因为MISRA规则里面通常都会把问题分成mandatory、required、advisory等不同的类别，这里的mandatory类规则一般是绝对不能违反的，而required类的规则要是发生了偏离，也得写一份正式的说明才行，至于advisory类的规则，就更偏向于建议性的控制；TI公司在他们自己的C2000 MISRA-C策略里面，也是把规则和指令、mandatory、required、advisory这些分类，拿来当成合规判断的依据。

　　2、再按规则编号筛选

　　如果说某一类的违规问题，全都集中在某一个特定的规则编号上面，那通常就说明这个项目在统一的写法上出了问题；比方说常见的有函数返回值没有检查、隐式的类型转换、宏定义写得不规范、走不到的不可达代码、或者是标识符命名冲突等等；大家先按照规则的编号把问题聚合在一起，然后再挑出来几个典型的代码位置去查看，这样干要比一条一条去翻结果省下很多时间。

　　3、按文件和模块定位责任范围

　　要是项目很大的话，大家可以按照目录、文件名、组件名字或者模块的负责人来进行筛选；比方说只看某一个驱动的目录，或者只看这次新写出来的代码；这样操作的好处就是，问题能被直接分派到具体的维护人员头上，省得最后变成一个谁也不认领的大列表；因为TBvision支持在报告项、源代码还有编码标准之间来回切换着看，这种界面查看的方式，其实更适合开发人员一边定位问题一边顺手修改。

　　三、Testbed编码规范检查结果怎样形成复查闭环

　　编码规范检查真正能发挥价值的地方，其实并不在于最后能生成一份多么好看的报告，而是要让发现的问题能够经历确认、修改、重新测试和最后的归档；如果每次做检查都得从零开始看一遍，团队用不了多久就会觉得这个工具是个累赘、增加了负担。

　　1、建立基线结果

　　在第一次做完完整的检查以后，大家可以把现在查出来的问题当成基线保存下来；以后更新了版本，就重点去查看新增加的违规、已经修好的违规、还有那些反复出现的问题；老代码如果一次性改起来成本太高、改不动，那可以先把它冻结在基线里，只要新写的代码严格去执行规则就行，这样工具才更容易在项目里面真正用起来。

　　2、给问题设置处理状态

　　筛选出来的这些结果，建议大家把它们分成待修改、已修改、误报待确认、偏离已批准、还有第三方代码不处理等几种状态；状态的分类千万别写得太复杂了，只要够项目评审的时候用就可以；等状态都理清楚之后，开发人员、测试人员和质量人员看到的都是同一批问题，大家就不会各自去维护一套乱七八糟的结果表了。

　　3、复查时只看变化部分

　　在代码修改完并且重新运行了静态分析以后，大家要先对比一下同一个规则、同一个文件、或者同一行代码附近的问题是不是真的消失了；这时候不能光看问题总数有没有下降，因为新加的代码也有可能会带来新的违规；更稳当的做法是把报告按照日期存好、归档，然后手头再留出来一份差异的说明。

　　总结

　　Testbed编码规范检查怎么开启，以及Testbed编码规范检查结果怎么筛选，这两个关键问题其实可以拆成两步来看。在开启检查的时候，要把工程源文件、头文件路径、宏定义、编译环境和规则集都配置全，然后再去运行静态分析；而在看结果的时候，不要只盯着违规的总数瞧，而是要按照严重程度、规则编号、文件模块和处理状态一层一层地去筛选。后面要是再配合上基线、复查还有偏离说明，Testbed的编码规范检查就不会只停留在“生成报告”这种表面工作上，而是能真正融入到项目的开发和质量评审流程里去了。