一、Testbed项目基线怎么建立
1、要把项目配置先调到稳定状态
【Testbed项目】建立好了以后，人员需要先去确认源文件、头文件路径，还有宏定义、编译器选项以及规则集，这些内容都基本稳定了才行。至少在项目里，不能还存在大量的“类型找不到”或者“宏未定义”，还有“头文件缺失”这一类的情况。
如果人员在前期没有把这些基础的配置给处理好，很多假问题就会被塞进基线里面，导致后面每次进行对比的时候，人员都会受到这些错误信息的干扰。
2、要把完整分析报告跑一次
等到配置都稳定下来了，人员就要去执行一次完整的分析，把静态分析、质量度量，或者是需要管理的规则检查都跑一遍。在这里需要注意到，基线并不是只去查看某一个单独的页面，项目评审真正关心的那些报告，最好都由人员给跑出来，这里面包括规则违规、复杂度、没有使用过的代码，以及严重等级分布等等。
3、要把明显无效的项清掉再定基线
等到报告被跑出来以后，明显属于配置类的误报，还有不属于管理范围的第三方代码，人员都要先去处理掉。像SDK源码、编译器的库文件，还有自动生成的代码，如果项目的规则并没有要求对它们进行整改，这些代码就不要被混进基线里了。
剩下的一些问题，如果团队在短期内没办法把它们全部改完，这些问题可以作为历史遗留的部分被保留下来，但是人员要把原因给写清楚。
4、要把版本信息加到基线上面
基线的名字不可以被随便写成“baseline1”这种样子。基线名称建议由人员带上项目版本、代码的分支、规则集的版本还有具体的日期，写成类似于“V1.2_Release_MISRA基线_20260623”的形式。
名字被写得详细一点，后面人员在查阅的时候就能省掉很多事情；否则要是过了几个星期再去查看，人员就会很容易搞不清楚，这份基线到底对应的是哪一次的扫描结果。
二、Testbed基线更新后历史问题怎么对比
1、要先把新增问题和历史问题给区分开
新的报告被生成出来以后，人员要把重点放在新增项上面。历史问题在上一版的基线里面就已经存在了，在短期之内，它们可能不会对本次的提交评审产生影响；但是新增的问题就不太一样，最近的代码改动、规则的调整，或者是配置的改变，通常都会导致新问题的出现。
如果团队在过程当中只去盯着问题的总数看，误判就很容发生；比如总数虽然没有发生变化，但是旧的问题减少了10个，同时新的问题又增加了10个，像这一种情况，其实不能被算作是稳定的状态。
2、要看关闭的问题是不是真的被修复了
有一些问题在报告里面消失了，这并不一定就代表着代码已经被修好了。文件没有被纳入到扫描范围里，或者规则被关闭了，还有宏定义被切换到了另外的分支，甚至路径配置发生了改变，这些情况都会导致问题消失。
所以对于那些“已经关闭的问题”，人员也需要去抽查其中的几项，要回到代码的具体位置去进行确认；不要只看到状态变成绿色了，就直接认定整改工作已经完成了。
3、要对持续存在的问题去重新分级
历史问题留在那边，并不代表着永远都可以不用去管它们。一个旧的问题如果连续在好几个版本里面都存在，而且它还正好位于核心的模块，有着很高的复杂度，覆盖率也很低，那么它的优先级就应该被人员重新调高。
有一些老的问题，在以前看起来好像不怎么着急，但是代码一旦被频繁地修改，这些老问题带来的风险就会跟着一起变大。
4、更新基线的时候要把说明保留下来
每次在对基线进行更新的时候，一段简短的说明都建议由人员写下来：比如这次分析所使用的代码版本是什么，规则有没有发生变化，新增了多少问题，关闭了多少问题，还有遗留的问题要怎么去处理。
三、基线管理时容易忽略的几个细节
1、规则集发生变化需要被单独记录
如果在这一次更新基线的时候，MISRA规则被增加了，或者是严重等级被调整了，那么问题数量的变化情况，就不能被直接拿来和上一版进行对比了；因为规则发生了改变，报告的统计口径也就跟着一起变了。
2、不要把所有的遗留项都看成是正常项
基线的作用，只是让项目暂时去承认历史的状态，它并不是给所有的问题发放“免改通行证”。特别像是空指针、数组越界、没有初始化的变量，还有死代码这一类的问题，即使它们属于历史遗留，人员也应该要有计划地去进行解决。
3、每次进行对比都需要回到代码的位置
基线对比产生的结果，其实只是一个入口而已。人员在看到新增的问题以后，还要把位置定位到具体的文件、函数以及具体的行上面，去看看它到底是由新代码引入进来的，还是旧的代码因为配置变更而重新暴露出来的。
结论
关于Testbed项目基线怎么建立，以及Testbed基线更新后历史问题怎么对比，它的核心逻辑就是先把当前的代码质量状态给固定下来，然后再利用后续跑出来的报告，和它去进行差异方面的判断。在建立基线之前，配置需要先被稳定下来，明显无效的项也要被清理掉，并且版本信息要被写清楚；而在更新了基线以后，新增的问题、关闭的问题，还有持续遗留的问题，都需要被人员重点地区分开来。
