在项目里去看QAC的历史趋势，还有当趋势图上的波动变得不正常了，要怎么去判断，这件事的重点，并不是去盯着某一次扫描的结果在那里看，而是要去观察同一个项目，在不同的构建版本、不同的软件版本，还有用了不同的规则集的情况下，它的质量到底是怎么一步一步发生变化的，Perforce的那个QAC仪表板，它就是被拿来集中地汇总，然后展示QAC分析出来的那些结果的，每一次，你往上面上传了不同的分析结果，它都会形成一个新的快照，有了这些快照，后面才能按照时间，或者是按照构建的记录，去观察趋势是怎么变的，要是一个项目，只是在本地去生成那种一次性的HTML报告，那一般就只能看到当前这独一份的结果了，至于历史的趋势，那是需要靠着持续不断地往上传结果、把配置给统一好，还有一条稳稳当当的基线，这些条件都给凑齐了，才能够看到的。

　　一、怎么去查看历史趋势

　　在着手去查看QAC的历史趋势以前，得先去确认一件事，那就是之前那些跑完的分析结果，到底有没有被持续地保留下来，好多项目嘴上说着看不到趋势，其实倒不是工具没有画图的能耐，而是每一次跑分析，都只是在本地用新的结果，把旧的结果给严严实实地盖掉了，并没有把每一个版本的扫描结果，都当成一条可以被拿来比较的记录，去好好地存起来。

　　1、先去确认一下，那个仪表板到底有没有被部署好

　　要是团队已经在用Perforce QAC的那个仪表板了，那就可以通过浏览器，去访问它的地址，在进到了对应的项目里面以后，就能去查看像质量、合规、缺陷，还有复杂度，这些数据是怎么变化了的，这个仪表板，它本身就是一个集中存放分析结果的地方，很适合让项目组的人、质量的负责人，还有来做审核的人，一起聚到这块儿去看。

　　2、去把每一次分析出来的结果，都上传成一个快照

　　在本地把QAC的分析给跑完了以后，是需要去把那个结果，给上传到仪表板上面去的，在官方给出的上传说明里，是这么提到的，QAC的分析结果，是可以被上传到外部的应用里面去的，拿它去做缺陷趋势的分析、代码结构和复杂度的分析，这些场景都能用，当把它上传到仪表板的时候，这些结果就会以快照的形式，被妥当地保存下来，每一次在上传的时候，最好是能把构建的编号、版本的号码，或者是日期，也都一块儿给带上，这么做，等到后面再回过头去看趋势的时候，才不至于乱成一团。

　　3、去按照构建的版本或者是日期，来筛选趋势

　　等进到了仪表板里面以后，去把对应的那个项目给选中，然后再去按照构建的范围、日期的范围、模块、严重的级别，还有规则的类型，去一层一层地做筛选，可不要一上来，就直愣愣地去看整个项目的那个总数，要先去看交付分支那边的、核心模块里头的，还有新增代码区域里面的，这么一层层看下来，你看到的那个趋势，才会更贴近实际开发时候的情况。

　　4、要结合着报告的类型，去一起查看

　　要是你用到的是验证，或者是跟它关联着的那些报告页面，在质量的报告和安全的报告里面，是会包含着规则的走势、不同严重级别的分布，还有新增出来的那些问题，这些内容的，在文档里头，是这么写的，排行前几的质量问题的趋势图，会把它选定的那个日期范围，或者是那一批构建版本里，出问题比较多的那些规则的趋势，给展示出来；而那个问题的统计图，也能从好几次的构建版本上，去把问题大概的情况，给一眼看过来。

　　二、历史趋势图波动不正常了要怎么去判断

　　当你看到趋势图的波动，变得不太正常的时候，可别只是看着那根折线，觉得它突然一下蹿上去了，或者是猛地跌下来了，就觉得不对劲，要先去判断一下，这到底是不是，由真实的代码质量变化，给引起来的，然后再去看一看，它是不是因为扫描的配置、规则集、文件的范围，或者是基线发生了变化，才造成的。

　　1、先去瞅一眼，扫描的范围，是不是被改动过了

　　要是你发现，某一次的扫描趋势，是突然之间就往上涨了，那就要先去查一查，这一次的扫描，是不是哗啦一下新加进来了好多的文件、是不是切换到了别的分支上、是不是导入了第三方的代码，又或者是，把之前已经排除掉的那些目录，又给重新放回了分析的范围内，当扫描的范围被扩大了以后，问题的数量往上升，这是一件很自然的事情，可不能就这么直接地，就断定是代码的质量变差了。

　　2、去检查一下，规则集是不是被调整过了

　　像MISRA、CERT、AUTOSAR，还有项目自己定义的那些规则，它们一旦发生了什么变化，历史趋势这个东西，就会立马受到影响，就比如说，在新增加了一批规则以后，问题的数量，是有可能会猛地往上涨的；而在关掉了某一部分规则以后，那根曲线，又会跟着往下降，所以，在你去判断这种波动的时候，是要把规则配置的那个版本，也给一块儿记录下来的，不然的话，等到了后面，是很难去解释得清楚的。

　　3、去检查一下，基线是不是被重新设置过了

　　要是项目那边，去重新设定了基线，那么，那些历史遗留下来的问题，就有可能被藏起来，或者是被换了一种计算的方式，这就会让趋势图，也跟着出现很明显的变化，这种变化，它可不一定就代表着，代码真的被修好了，它可能仅仅是，统计的那个口径，发生了变化而已，基线的调整，是必须在项目的记录里面，去把原因给说明白的。

　　4、去把新增出来的问题，和已经被关闭掉的问题，分开来看

　　光是盯着那个问题的总数，在那里看，是很容易做出错误的判断的，总数往下掉了，这有可能是因为修复真的起了作用，但同样也有可能，是因为相关的文件被排除出去了；而总数往上跑了，这有可能是新冒出来的缺陷，但也说不定，是扫描覆盖的范围，这一次总算是把它给弄完整了，所以，你得要把新增的问题、已经修好了的问题、还赖在那里的遗留问题，还有不同严重级别的变化，都放在一起去，同时看一看。

　　三、怎么把趋势的数据，给用到项目的评审里面去

　　QAC的历史趋势图，它真正能发挥作用的地方，是在于帮着项目组，去判断产品的质量，是不是还处在一个能被控制住的范围内，而不是简简单单地，就拿那么一根曲线，摆在那里给别人看，趋势图这个东西，是要跟版本的计划、代码的变更、规则的调整，还有问题的闭环，这些东西放在一块儿，捆起来看的。

　　1、去把趋势上的关键点，跟版本的节点，给它一一对应起来

　　在趋势图上面，每一个看着很明显的波动点，都应该是能对应到，一次版本的合入、规则集的调整、目录范围的变动，或者是那种大规模的代码重构上去的，在评审的时候，不要光是去说一句“问题变多了”，就完事了，你得去说明白，是哪一次构建以后发生的变化、它都影响到了哪一些模块、还有，是不是已经有一个处理它的计划了。

　　2、要去重点地关注，那些严重级别很高的告警

　　当那些严重级别比较低的问题，在数量上波动得很厉害的时候，倒是不一定就会影响到，你对版本能不能交付的判断；可要是那些严重级别很高的问题、会阻断合规的事情、还有跟安全扯上关系的问题，一旦出现了上升的趋势，那就要把它给拎出来，优先去分析一下，趋势图这东西，它应该是先去服务于你对风险的判断，然后，再去服务于你对数量的统计。

　　3、把那些看着不正常的波动，给它形成一条条记录下来

　　一旦发现了趋势有不正常的地方，就要去把构建的编号、是什么原因引起了这种变化、该由哪一个模块来负责、最后是怎么处理的，还有计划在什么时候去复查它，这些东西，全给记下来，要是这种变化，是因为配置的调整才带来的，那就要去把统计的口径给交代清楚；要是它真的是因为，实际的缺陷数量变多了，那就要让它进到问题的闭环里面去，这样做了以后，到了后面再做审核的时候，这张趋势图，它就不是一张孤零零的截图了，而是有了能拿来解释的依据。

　　4、去定期地，把查看趋势的那个口径，给固定下来

　　比较建议的是，让项目组的人，每周去固定地看一次，或者是每一个版本的节点，去固定地看一次趋势，并且，在筛选条件上，要保持住前后一致，要是今天看的是全量的数据，明天又跑去看核心模块的，后天干脆连规则集都给换掉了，那画出来的曲线，就没有什么放在一起比较的意义了，趋势管理这件事，它的基础，就是口径的稳定。

　　总结

　　要去查看QAC的历史趋势，这里面的关键，就是要把每一次分析得到的结果，都上传到仪表板上面去，让它形成一个个的快照，然后再去按照构建的版本、日期、模块，还有规则的类型，去查看那些数据发生的变化，而当QAC的历史趋势图，出现了波动异常的时候，又要怎么去判断它呢，这个时候，就不能光是盯着那根曲线的高高低低去看了，要先去把扫描的范围、规则集、基线、分支，还有构建的记录，是不是发生了什么变化，都给排查一遍，然后，再去分析新增的、已经修好的，还有那些遗留的问题，一张趋势图，只有把它跟版本的节点、配置的记录，还有问题的闭环，这些东西给紧紧地绑在一起去看的时候，它才真正能够说明白，这个项目的质量，到底是不是还处在受控之中。