Coverity缺陷状态怎么流转，Coverity缺陷状态和修复进度怎么同步，这类问题，是代码静态扫描被接入到研发流程以后，必须得理清楚的。Coverity把缺陷给找出来，这只是头一步，真正会拽住团队效率的，是后面怎么去分派、怎么去确认、怎么去修、怎么再扫一遍，还有怎么去关上。缺陷的那些状态，要是就只在工具自己的页面里头变来变去，那研发、测试、安全，还有项目管理，这几边的人看见的进度，就很容易凑不到一块儿去。一个比较稳当的搞法，是把扫描的状态、人手工判定的状态、修完的最后期限，还有外头工单上的状态，都给分开来管，然后再靠一套规矩，把它们给串起来。

　　一、Coverity缺陷状态怎么流转

　　在Coverity缺陷的状态流转起来以前，得先把两个东西给分分清楚：一个是工具扫出来的那个发现的状态，另一个是团队的人手工处理过以后，给出来的那个处置的状态。前头那个，一般是跟着扫描的结果自己变的，后头那个，就得靠管安全的人、写代码的人，或者是代码的负责人来下判断。在跟Polaris有关的那些缺陷策略里面，它是会用到像Detection Status、Triage Status，还有Fix-By Status这些个字段，去把缺陷管理的那些规矩给组起来的。

　　1、从新蹦出来的缺陷，进到还没确认的那个状态去

　　新扫出来的那些问题，一般来讲，是先跑到一个没确认，或者还没分诊的状态里头。到了这个阶段，先别忙着去要求开发的人，把所有的东西全给修了，得先去瞧一瞧，这个缺陷它是个什么类型、严重到什么级别、待在哪个模块里面、是不是新冒出来的，还有，它会不会把眼下这个版本的发布给耽误了。要是这头一回不筛，扫描一开，所有的毛病一股脑儿全压给研发那边，那这东西，是很容易就给变成一张“谁也不去看”的清单的。

　　2、经过分诊这一道手续以后，再定下来怎么去对付它

　　在【Triage】这个处理的过程里面，是能把这些个缺陷，给标成是需要去修的、是暂时先不去管的、是误报，或者是就这么留着也没事儿，这些个不一样的路子的。

　　就比方说，那种真的代码上的毛病，就进到等着去修的那个状态；看着就很清楚的误报，就按着误报的那个缘由给关上；那种在设计上头，就是让这么写的，那就要把说明的话给注上。有那么一部分的流程，还会要求，对那种被丢开的、定下来要去修的，或者是那个修完的截止日子有变动的，去做一个审批，这么一来，也能防着缺陷被人随随便便地就给关掉了。

　　3、修完了以后，靠着再扫一遍的确认，去把它给关上

　　开发那头把修复的代码给交上来了，这时候，是不太建议光靠嘴说一声，就把缺陷给关了的。Coverity的这个缺陷，它是不是真的不见了，一般是要等下一回的扫描结果出来了，才能把事儿给坐实。要是再扫一遍以后，那个缺陷没再往外蹦，那它就能进到已经解决了，或者是已经关掉了的状态；要是还在那儿，那就得倒回到等着去修的那个状态，接着去看代码改的那些东西，是不是把正确的路径都给盖住了。

　　二、Coverity缺陷状态和修复进度怎么同步

　　缺陷的状态，和修到哪儿了的那个进度，这两下里要是对不上，一个挺常见的模样，就是Coverity里面还亮着没修好呢，可Jira或者是禅道里面，单子都已经给合上了；再不然，就是代码明明已经给传上去了，可扫描出来的那一栏，还是说这个缺陷还杵在那儿。这毛病，它往往是出在，两边对状态的那个说法，没给弄到一块儿去，倒不一定是工具自己有什么岔子。

　　1、把两边状态的那个对应关系给统一了

　　是能去把Coverity那边的，没分诊的、等着修的、给略过去的、是误报的、已经弄好了的，跟外头工单那边的，等着处理的、正在弄的、等着验证的、已经合上了的，给它们搭上一一对应的桥的。可别叫每一个项目，都自己闷着头去琢磨这些个状态是啥意思，要不然，就同一个“等着去修”的牌子，有人觉着这是已经认下了，有人又觉着这是都开始动手修了，那到了进度统计的那个时候，事儿就全乱了。

　　2、拿工单去把修缺陷的这个活儿给接住

　　对着那些个得要修掉的缺陷，是可以在【Issue Tracker】，或者是外头的那种缺陷平台里面，去给它生出来一个对着的工单的。这个工单的里面，要把Coverity的那个缺陷的ID、文件在哪儿、是哪个函数、严重到什么级别、谁来担这个责任、修好的截止日子，还有扫描的是哪个分支，这些个信息全给带进去。这么一弄，研发那边在处理的时候，就用不着来来回回地跑回到扫描的那个平台，再去翻前翻后的；管项目的人，也能瞧见修到哪一步的那个实在的进度。

　　3、拿着再扫一遍的结果，去把合上的那个状态给更新了

　　看修到哪儿了，这个进度，可不能光是盯着代码有没有并进去，还得去瞧瞧再扫的那一步，是不是真给认下来了。一个比较合辙的节奏是：开发那把代码交上去了，工单就进到等着验证的那一步；CI那头把Coverity的扫描给触发了以后，要是那个缺陷就这么没了，再去把工单给合上；要是那个缺陷还赖在那儿，那就给退回到还在弄的那一步。这么着，工具上的状态，和项目上的进度，才不会各说各话。

　　三、Coverity缺陷流转怎么管理更清楚

　　Coverity的缺陷要管，可不光是把毛病给修掉就拉倒了，还得叫团队里面的人都闹明白，哪些毛病是死活得去对付的，哪些是能往后先放一放的，哪些又是已经有了个明白说法的。缺陷那个数一多起来，规矩，可就比人拿眼珠子去盯那个页面，要来得要紧多了。

　　1、得照着那个严重级别，去把修好的时限给设上

　　那种风险高的问题，还有把发布给截住的问题，是要有一个明明白白的Fix-By Date的。那个Fix-By Status，一般就是拿来把过了期的、眼看就要到日子了、正推着往前走的，还有连日子都没给设的，这些个不一样的情况给分开的，这类字段，就很合适拿来做项目上的看板，还有安全治理的那些个统计。

　　2、把为什么关掉的缘由，还有备注的那些话，都给留下来

　　要是一个缺陷，给标成了是误报、是设计上就这么许的，或者是就先不修了，那是要把里头的原因给写写清楚的。可别就这么光光点一个关上的状态，就觉着完事了。到了后面，做审计、做复盘，或者是交付版本的那阵子，别人家，得能闹明白，这个问题当时为什么没去动它，到底是规条报错了，是代码压根儿就跑不到那儿，还是业务上就这么认了这个风险了。

　　3、定期的，去把扫描的分支和版本给对齐了

　　同一个缺陷，搁在不一样的分支里面，它可能是挂着不一样的状态的。主干的，是已经修好了，这可不一定说，要发的那个分支也给修了；开发分支上瞧着是没毛病了，那也不代表，以前的老版本里头，就没那个风险。在同步修复进度的时候，是要把是哪个项目、哪个分支、哪一回扫描的，还有是哪个版本范围的，这些都给交代清楚了，也好躲开，拿着一个分支的结果，就当成了是全项目的那么一个论断。

　　总结

　　Coverity缺陷状态怎么流转，Coverity缺陷状态和修复进度又该怎么去同步，这里头最核心的东西，是把“扫描出来”“人工去分诊”“开发动手修”“再扫一遍验证”“合上归档”这么几个步子，给掰开来去管。新冒出来的缺陷，先是进到还没确认的那一档，分诊过了再去定下来要不要修，等修完了，再靠再扫一回的确认，去把它给合上。在跟外头的工单同步的那个当口，要叫两边状态的对应是齐整的、把缺陷的ID和负责的人给拴在一块儿，还得拿扫描出来的结果，去验一验那个修复是不是真的生了效。这些状态的说法都给弄清爽了，Coverity才不会就只是一份干巴巴的扫描单子，而是能实实在在地，被接到研发质量管起来的那个流程里面去。