很多团队第一次做Parasoft C/C++test基线时，容易把Baseline理解成一次性“清账”，结果后面一改规则、一批量抑制历史问题，整套对比口径就乱了。按Parasoft的文档口径，Baseline build本质上是一个用于和目标构建做对比的历史构建；真正需要管住的，不只是基线本身，还包括规则调整、抑制理由、评审动作和归档证据。

　　一、C/C++test Baseline怎么更新

　　做基线更新时，先别急着把旧结果覆盖掉，更稳妥的思路是先确认这次为什么要换基线。常见触发点有三个，一是项目进入新阶段，二是规则集或严重级别口径有调整，三是团队已经处理掉一批历史问题，准备以新的构建作为后续比较起点。Parasoft在DTP里把baseline build定义为历史比较锚点，所以更新基线更接近“换比较参照”，不是简单删旧数据。

　　1、先把准备作为新基线的构建固定下来。在【Build Administration】里给构建加描述标签，必要时执行锁定和归档。官方文档说明，锁定后DTP不再接收同一build ID的新报告，归档后才能下载XML、HTML、PDF报告，而且测试与覆盖细节默认只长期保留最近两次构建，所以要做阶段基线时，这一步不要省。

　　2、再处理规则和历史问题，不要把本该治理的噪声直接混进新基线。Parasoft的建议是先浏览结果，再更新测试配置；对永远不会修的规则可以禁用，对老代码里暂不处理但新代码仍要继续检查的问题，更推荐做suppression，而不是把checker整体关掉。并且在DTP中标记为suppression后，要等下一次分析运行才会真正落地。

　　3、基线切换完成后，用【Violations Explorer】按baseline build和target build做核对。官方说明这里可以直接按New、Fixed、Existing三种状态看变化，所以更新基线后，最关键的检查不是总数是否变小，而是新基线之上的新增问题、已修问题和遗留问题是否符合你的预期。这样做，后面做门禁和阶段汇报时口径才稳。

　　二、C/C++test基线变更如何评审留痕

　　基线变更真正容易失控的，不是操作动作本身，而是“为什么改”“谁同意改”“改完后怎么追”。Parasoft给的思路不是让团队靠截图和口头确认，而是把评审、评论、分派、抑制和报表归档都落在DTP的review与metadata体系里。

　　1、对要进入基线豁免范围的结果，先走评审动作，再做suppression。Parasoft在SAST实施指南里明确提到，DTP的Action字段可以用于抑制审计流程，默认就有Fix、Review、Suppress、Reassign等值。更实用的做法是先把action设成【Review】或【Suppress】，指派给reviewer，再由reviewer在评论里说明同意或不同意的理由，这样DTP里会形成可追溯的审计轨迹。

　　2、如果是合规项目，抑制理由一定要写实。Parasoft文档明确要求suppression的rationale要进入deviation documentation，MISRA合规页也说明，被接受的deviation需要在报表里保留理由；如果是false positive，还要在原因字段里用false positive开头，后续报表才会按对应口径处理。

　　3、基线差异评审不要脱离代码上下文做。DTP的【Change Explorer】可以按baseline build和target build打开差异视图，review绑定的是特定filter、baseline、target这一组比较关系，review finding又能直接挂在具体代码边上，附带状态、优先级、指派人和评论。这样以后回看时，不只是知道“这条被放行了”，还知道它是在哪一次基线切换里、针对哪段改动被评审过。

　　4、最后把报表固化下来。Build Audit Report能显示该构建下的静态分析、测试、覆盖与run级报告；构建锁定并归档后，可以下载完整归档包或单独报告。对需要审计的团队，建议把阶段性基线的Build Audit Report和Deviations Report一起导出后纳入版本库，这样留痕就不只停留在系统页面里。

　　三、Parasoft C/C++test留痕为什么不能只靠截图

　　截图能证明你当时看过页面，但很难证明元数据是谁改的、何时改的、改前改后差了什么。Parasoft的DTP还有更适合治理的留痕能力，例如AnalysisMetadata事件会记录Violations Explorer和Test Explorer里的元数据变更，消息体里包含字段变化、新值、时间、用户和对象ID；BuildReview事件则能记录review的创建、更新和删除。对流程要求更严的团队，这类事件和对应接口，才是把评审留痕做成制度的基础。

　　总结

　　C/C++test Baseline怎么更新，核心不是把旧结果一把清掉，而是先锁定新锚点，再整理规则和历史问题，最后用baseline对比视角核验结果。C/C++test基线变更如何评审留痕，关键也不是多写几句备注，而是把review、action、comments、suppression reason、Build Audit Report和归档动作连成一条证据链。这样你后面无论是做阶段汇报、质量门禁还是合规审查，口径都会清楚很多。