QAC基线怎么建立，还有QAC基线更新以后，历史问题要怎么去做对比，这在使用静态分析的时候，是经常会遇到的问题。很多项目头一回接入QAC的时候，会看到历史代码里面诊断出来的结果特别多，要是要求这一次就全部改干净，开发那边的压力会非常大，实际上也不太容易做得到。基线的用处，就是把现在已经有的那些诊断结果先固定下来，往后再把精力主要放在新增的问题、有变化的问题，还有那些必须得去改的问题上面。Perforce QAC官方文档里面也提到过，基线的诊断抑制功能，是可以在新开发周期刚开始的时候，拿来把旧的诊断警告给抑制掉的。

　　一、QAC基线怎么建立

　　QAC基线在建立以前，得先认准当前的代码版本是一个能拿来当起点的版本。基线不是说随便找一次扫描的结果，把它存下来就行了，它需要跟代码分支、规则的配置、工具的版本，还有项目正处在什么阶段，这些东西互相对应上。不然到了后面再去比对的时候，就会发现问题的数量是变了，可到底是代码变了引起的，还是配置变了引起的，就很难讲清楚了。

　　1、先确定基线的代码版本

　　建立基线之前，要先把一个代码版本给冻结或者标记下来，比如某一次发布用的分支、一个里程碑的版本，再或者就是接入QAC之后的头一个稳定版本。这个版本往后要能从代码仓库里面重新拿出来，要不然基线结果就没有了复现的基础。不要拿那种开发当中随时都在变的分支直接去做基线，那样的话，以后那些历史问题就很难去解释了。

　　2、固定规则配置和分析环境

　　在【QAC项目配置】里面，要把规则集、编译器的配置、包含路径、宏定义，还有分析的那些选项，都确认好。这一步是比较关键的，QAC诊断出来的结果，跟项目的配置关系很大，宏定义、头文件的路径、规则的版本这些东西，只要有一个变了，结果就可能跟着一起变。基线的记录里面，最好是能把工具的版本、规则包的版本、分析的范围，还有扫描的时间，都一块儿留下来，这样后面复查的时候才方便。

　　3、保存首次分析结果

　　头一回完整分析做完了以后，要把诊断的结果、违规的统计，还有需要的报告都导出来。Perforce QAC的产品说明里面也提到过，这个工具可以通过过滤器、抑制和基线这些手段，来帮着团队把注意力放到那些关键的缺陷上面。这里的基线结果，可以把它看成是一个“历史问题池”，后面的新开发工作，就不应该再往里面去增加新的高风险问题了。

　　二、QAC基线更新后历史问题怎么对比

　　基线更新了以后，重点不是光盯着总数是变少了还是变多了，而是要把那些历史上留下来的、新加进来的、已经改好了的，还有又重新冒出来的问题，给区分开。总数的变化有时候是会让人看走眼的，比如说修掉了二十个老问题，可同时又多出来了五个高风险的新问题，这种时候就不能光说“总数往下降了，所以质量就变好了”。

　　1、先区分新旧问题

　　做对比的时候，要看某一个问题，它在旧的基线里面是不是就已经出现过了。如果旧基线里面有，那就可以把它归到历史问题里面去；如果旧基线里面没有，而新的扫描里面它又出来了，那就要把它当成新增的问题来对待。QAC跟Validate联动的时候，相关的文档也提到过，同步之后，服务器里面已经有的那些诊断，是可以在QAC项目里面自动抑制掉的，这就是用来区分已有诊断状态的。

　　2、查看问题状态的变化

　　在【分析结果报告】里面，要把问题的编号、文件的路径、规则的编号、代码的位置，还有状态的变化，去进行比对。有一些问题，它只是因为代码行挪了地方，导致位置变了，这种就不能随随便便就判定为新增；也有一些问题，虽然规则的编号是同一个，可它出现在了新的函数或者新的模块里面，那这种就要按新增问题去对待。做比对的时候，要把文件、函数，还有诊断的信息，结合在一块儿去看。

　　3、关注基线更新的原因

　　基线是不能老是频繁地、由着性子去更新的。要是更新基线，只是为了把新冒出来的问题再给压回到“历史问题”那个筐里去，那基线控制的这点意思就全没了。比较说得过去的更新场景，是项目走到了一个新阶段、规则集做过了调整、工具的版本往上升了级、历史问题完成了成批的整改，再要不就是代码的架构发生了比较大的变化。每一次更新，都要把原因和审批的结论给记下来。

　　三、QAC基线管理怎么避免失控

　　QAC的基线管理，比较怕的就是弄成了“旧问题永远搁在那儿不管，新问题也慢慢地熬成了旧问题”。基线说到底，只不过是一种过渡阶段的管理法子，它可不算是一个长期的豁免理由。项目一方，要把新冒出来的问题给管住，同时还要一步一步地，去把那些历史问题给消化掉。

　　1、给新增问题设置门禁

　　新增的、严重程度高的问题，应当尽可能地在当前这个版本里面就把它处理掉，不要让它轻轻松松地就滚到下一轮的基线里面去。不然的话，基线就会越滚越大，到了最后，静态分析就光剩下一份报告，再也没有什么实际的约束劲儿了。

　　2、给历史问题分批整改

　　历史问题可以照着风险的等级、模块的重要程度，还有改起来的成本，分拨去处理。比方说，跟安全相关的模块、改得比较勤的模块、客户那边比较看重的模块，可以放在前头先改；那些风险低的、年代久的老代码，可以排到后面的版本里头去，但是手上得有个计划。

　　3、保留对比和审批记录

　　每一次基线的建立、更新，还有比对，都要把代码的版本、扫描的报告、规则的配置、问题变化的那个单子，还有审批的记录，全都给留下来。这么一来，往后做审查的时候，才能讲得清楚，哪些问题是历史上遗留下来的，哪些问题已经被关掉了，又有哪些问题是这一轮新冒出来的。

　　总结

　　QAC基线怎么建立，QAC基线更新后历史问题怎么对比，这里头最关键的地方，就是把代码的版本、规则的配置、分析的结果，还有问题的状态，都给固定下来。建基线的时候，要挑一个稳当的代码版本，把完整的配置和头一回扫描的结果都留好；更新基线以后，要把历史问题、新增问题、已经修复的问题，还有位置挪动过的问题，都分开来看。基线这东西，可不是为了把问题给藏起来，它是为了让团队能先管住新增的风险，然后再按着计划，去把那些历史上堆下来的问题，一点儿一点儿地收拾干净。