扫描发现了问题，接下来谁来判断、谁来修改、改完交给谁复查，这些事情如果只靠口头沟通，很容易在下一轮开发中被搁置。“Coverity怎么分配代码缺陷负责人Coverity缺陷指派后如何查看处理状态”涉及的就是这部分工作。Coverity Connect提供了负责人、分类、处理动作和历史记录等信息，但几个字段的含义并不相同。名字填进负责人一栏后，任务有了归属，后续进展还得结合处理记录和扫描结果来看。

　　一、Coverity怎么分配代码缺陷负责人

　　缺陷负责人通过Owner字段设置。下面按英文网页界面说明操作，具体布局以正在使用的版本为准。

　　1、找到问题所在的分支

　　同一份代码可能同时在主干和维护分支中接受分析。分配前花一点时间确认范围，可以少一次来回转交。

　　①进入目标项目，打开【Issues:By Snapshot】视图，通过【Streams】筛选需要处理的数据流。

　　②已有缺陷编号时，在【CID】中输入编号；从扫描列表开始排查时，可以按【Component】或【File】缩小范围。

　　③打开缺陷，在【Source】中查看文件路径和问题事件，确认应该交给哪个模块的维护人员。

　　2、填写负责人和交接内容

　　①在【Triage】面板找到【Owner】，选择接手人员的账号。

　　②在【Comment】中说明交给对方处理什么。例如“请确认错误返回路径是否遗漏资源释放”，比只写“请处理”更清楚。

　　③点击【Apply】保存。需要继续处理下一条时，使用【Apply+Next】。

　　④再次打开这条【CID】，查看【Owner】是否已经更新。

　　负责人可以是承担排查的人，也可以是负责修改的人，团队应提前约定。否则，审核人员把问题交出去后，开发人员可能仍以为自己只需要提供判断意见。

　　3、把同一模块的缺陷集中指派

　　①利用【Component】或【File】筛选出同一模块的问题，勾选准备交给同一人的【CID】。

　　②在支持批量处理的界面中打开【Triage】，将【Owner】设为接手账号。

　　③保留不需要调整的分类、严重程度等信息，点击【Apply】提交，再抽查几条记录。

　　批量指派适合责任范围已经明确的情况。几个问题虽然出现在同一目录，涉及的代码却可能由不同人员维护，这时逐条分配更合适。新版界面的部分项目范围视图不支持批量处理，遇到这种情况可以更换视图，或分别保存。

　　二、Coverity缺陷指派后如何查看处理状态

　　查看进度时，容易把“已经分配”“已经分类”和“已经修复”混在一起。Coverity中的负责人、处理动作与系统状态，需要分开理解。

　　1、按负责人查看待办问题

　　①回到【Issues:By Snapshot】，在【Owner】中选择需要查看的账号。

　　②在【Columns】中加入【Status】、【Classification】和【Action】，让责任归属和处理信息显示在同一张列表中。

　　③检查【Streams】及快照范围，确认查看的是任务所在分支。

　　④需要追踪某一条记录时，加入【CID】条件。如果搜索不到，放宽【Status】筛选，检查是否把已修复或已忽略的记录排除了。

　　列表里少了一条缺陷，不一定是修好了，也可能发生了转交，或者当前视图隐藏了它。跟进具体任务时，缺陷编号比列表数量更可靠。

　　2、判断开发人员处理到了哪一步

　　处理动作适合登记工作进展，系统状态则有自己的生成规则，不能直接当成工单中的“待办、处理中、已完成”。

　　①查看【Action】。显示【Fix Required】时，表示需要修复；显示【Fix Submitted】时，表示已经登记修复提交，仍需结合后续分析结果确认。

　　②查看【Classification】。尚未判断的问题可以保留【Unclassified】；确认属于代码缺陷后，按团队要求设置分类，例如【Bug】。

　　③对照【Status】。【New】与未分类有关，【Triaged】说明问题已进入相应分类，不能据此认定开发人员正在修改代码。

　　④遇到【Dismissed】，阅读分类和评论，弄清楚是误报、有意保留的行为，还是其他无需继续处理的情况。

　　3、查出指派之后有哪些变化

　　①打开缺陷的【Triage History】，查看负责人、分类、处理动作和评论的变更。

　　②如果只显示带评论的记录，取消【Show only commented entries】，再检查是否发生过负责人调整。

　　③展开【Detection History】，查看缺陷关联的检测时间、快照和数据流。

　　历史记录能解释当前字段背后的过程。例如负责人已经换人，但评论仍停留在上一次排查结论，就应补充交接情况；如果开发人员说已经提交修改，检测记录却仍来自提交前，也还不能用旧结果判断修复是否有效。

　　三、Coverity缺陷转交和修复复查怎么衔接

　　缺陷处理过程中，更费时间的往往是接手后重新理解问题，以及修复后找不到对应的分析结果。记录里留下什么，直接影响后续人员能否继续推进。

　　1、转交时保留已查明的事实

　　①修改【Owner】前，在【Comment】中补充已经查过的路径、尚未确认的条件和转交原因。

　　②如果开发工作通过外部工单管理，在【Ext.Reference】中填写对应编号或引用信息。

　　③保存后查看【Triage History】，确认负责人和交接说明都已写入。

　　评论不用写成长篇分析，但应让接手者知道从哪里继续。例如“正常返回路径已释放资源，异常退出路径仍需确认”，就能省去一部分重复检查。只有“已沟通”“待处理”这类文字，过几天再回看，很难还原当时的判断。

　　2、用包含修复的新结果验收

　　①在【Snapshots】中查看新快照的时间和版本，确认扫描使用的代码已经包含修复提交。

　　②回到原【CID】，结合【Detection History】检查问题是否继续出现，再查看【Status】。

　　③如果显示【Fixed】，核对目标文件是否仍在扫描范围内、检查器设置是否发生变化，排除因分析范围改变导致问题消失的情况。

　　④如果问题仍被检出，重新查看事件路径，并在【Comment】中记录本次复查结论，交回负责人继续处理。

　　总结

　　“Coverity怎么分配代码缺陷负责人Coverity缺陷指派后如何查看处理状态”这两个问题，最后都落在团队怎样使用缺陷记录上。负责人能说明任务交给了谁，评论能保留判断过程，扫描结果则为修复验收提供依据。几项信息各司其职，交接时就少一些猜测。项目维护时间越长，这些记录越有用：后来接手的人可以查到当初为何修改、为何保留，也能据此判断再次出现的问题是否需要重新处理。登记内容不必繁琐，但要让下一位查看的人读得明白。