在Coverity里做项目管理时，很多人会把分析流当成一个普通目录来理解，结果前面流已经建了，后面提交、归类和结果查看却总对不上。官方文档对stream的定位其实很明确，它是用来承载某一部分代码基线和缺陷数据的单位，而且必须先有stream，后面才能把分析结果提交到Coverity Connect。也正因为这样，分析流设置和结果查看本来就是一条线，前面流挂错了，后面看到的缺陷、趋势和筛选结果都会跟着偏。

　　一、Coverity怎么设置分析流

　　Coverity怎么设置分析流，关键不是先想着怎么看结果，而是先把流和项目的关系搭顺。官方文档说明，stream是按项目来组织的，而且创建stream的过程和创建project很相似，所以这一步最好先按代码边界和交付节奏拆清楚，再去落UI或命令行配置。

　　1、先到【Configuration】→【Projects&Streams】建立分析流

　　官方搜索结果已经给出标准入口，创建stream时先进入【Configuration】→【Projects&Streams】。如果你先选中了某个project，再去创建stream，新的分析流就会直接挂到这个项目下面，这样后面项目视角和流视角才不会散。

　　2、先按代码边界拆stream，不要按人拆

　　官方说明里，stream用来承载某一部分code base的issue data，所以更适合按主干、分支、产品线或版本线去拆，而不是按开发人员或测试人员去拆。前者能稳定承接分析结果，后者很容易把同一套代码切碎，后面查看时也不容易收口。这个结论是基于官方对stream用途的定义得出的。

　　3、需要的话把issue categorization map一起挂上

　　官方在stream设置页的结果摘要里提到，如果Coverity Connect里已经配置了issue categorization map，可以在创建stream时直接应用到该流上。这样做的意义是把问题分类口径提前固定下来，后面同一条流里的缺陷就不会因为分类规则不一致而越看越乱。

　　4、分析提交前先确认结果就是往这个stream里写

　　官方对【cov-commit-defects】的说明写得很清楚，这个命令会把中间目录里的分析输出写入Coverity Connect，而且前提就是目标stream已经存在。也就是说，分析流不是只在平台里建一个名字就结束了，后面提交链路也要明确指向它。

　　5、命令行管理时可以用【cov-manage-im】做核对

　　如果你不想只靠界面确认，官方命令文档摘要里已经说明，【cov-manage-im】可以管理和查询defects、projects和streams。实际项目里，建完流以后再用命令行做一次列表和属性核对，往往比直接开始提交更稳。

　　二、Coverity分析流切换后结果怎么查看

　　Coverity分析流切换后结果怎么查看，重点不在于找一个单独叫“切换流”的按钮，而是看你现在是在Coverity Connect里看项目结果，还是在Coverity Desktop里拉远端问题。官方文档把这两种查看方式分开了，所以切流以后结果怎么看，也要按入口分开处理。

　　1、在Coverity Desktop里先选对streams

　　官方搜索结果对【Streams】页面的说明很直接，它用于指定你想查看和想triage的streams。也就是说，如果你是在IDE或Desktop侧切换分析流，先到stream配置页把目标流选对，再去看issues，不然你拉回来的远端问题可能还是上一条流的数据。

　　2、再用【Coverity】→【View Issues from Coverity Server】查看远端结果

　　官方文档说明，这个入口会把【Issues】视图切到Remote Issues mode，并下载Coverity Connect上与当前配置相关的issues。切换stream后若想确认结果有没有跟着切过来，这一步是最直接的查看方法。

　　3、在Coverity Connect里优先用views看结果

　　官方对views的定义写得很明确，Coverity Connect可以用saved search criteria，也就是view，来组织CIDs和其他数据。所以在平台侧切换到不同stream后，更稳的做法不是靠肉眼翻全量缺陷，而是先进入对应的view，再看这个流当前有哪些outstanding issues、new defects或triage结果。

　　4、项目级趋势和流级结果要分开读

　　官方对dashboards的说明表明，Coverity Connect有项目层的Quality和Security图表。这意味着你在切换stream后，如果看到的还是project级dashboard，结果可能是聚合后的视角，不一定只代表当前一个流。所以真正要核流切换是否生效，最好先看流关联的issues视图，再回头看dashboard。

　　5、查看时顺手核对triage属性

　　官方关于triaging issues的文档摘要里说明，问题打开后可以在Triage pane修改一个或多个属性。放到“切换流后看结果”这个场景里，真正要确认的不只是有没有看到问题，还要看这些问题的状态、分类和责任人是不是当前流里应该看到的那一套。这样更容易判断你看到的是不是正确流的数据。

　　三、Coverity结果口径为什么会变

　　Coverity结果口径为什么会变，这一步不是在重复前两段，而是在解释为什么很多人明明切了流，却觉得结果还是不对。真正常见的问题，不是软件没切过去，而是你前后看的根本不是同一个口径。有时看的是stream级issue列表，有时看的是project聚合视图，有时又是Desktop拉下来的remote issues，这几层一混，结果当然会觉得不一致。这个判断和官方对streams、views、dashboards以及remote issues的分层说明是一致的。

　　1、同一个project下多个stream本来就会分开承接结果

　　官方说明里，project可以支持多个streams。也就是说，只要你的项目本身是多流结构，切换stream后看到的缺陷集发生变化，本来就是正常现象。问题不在于结果变了，而在于你要先确认自己现在看的到底是哪个流。

　　2、view保存的是筛选口径，不是自动跟着你切流的直觉

　　官方对views的定义是saved search criteria，这说明view里保存的是一套查询条件。若你切了stream，但还在用旧view，看见的结果可能仍然受旧筛选条件约束，所以视角没变不一定代表流没切，更多时候是筛选口径没跟上。

　　3、Desktop远端问题和Connect平台列表不一定同时刷新

　　官方说明里，【View Issues from Coverity Server】是一次下载并填充【Issues】视图的动作。这意味着你切了流以后，如果没有重新执行拉取，Desktop端看到的remote issues可能还是上一次下载下来的结果，所以切流和刷新结果不是同一个动作。

　　4、提交流和查看流不一致时最容易误判

　　官方对【cov-commit-defects】的定义已经说明，分析输出是写入某个目标stream的。若前面提交时指向的是A流，后面查看时却切到了B流，看不到预期结果并不奇怪。所以一旦出现“切流后结果不对”，最该先核对的就是提交目标和查看目标是不是同一条流。

　　总结

　　Coverity怎么设置分析流，重点是先在【Configuration】→【Projects&Streams】里把stream和project关系搭好，再确保提交链路真正指向这条流。Coverity分析流切换后结果怎么查看，重点则是分清自己是在Desktop里看remote issues，还是在Connect里看views和dashboards，再按对应入口刷新和核对。把流设置、结果入口和查看口径这三层分开以后，很多原本看起来像“切流失败”的问题，通常都会变得更容易定位。