在完成软件的静态分析以及覆盖率测试工作之后，研究人员通常需要对质量度量结果进行分析。在实际工作中，开发人员可以使用LDRA工具链里面的Testbed和TBvision软件来做静态和动态分析，这些软件能够输出关于质量度量、代码覆盖情况以及标准符合情况的各种图表；同时，TBvision软件还可以计算代码的复杂程度、循环嵌套的层数、函数的数量等各项数据，并把这些数据和提前设置好的合格标准进行对比。

　　一、质量度量结果的查看流程

　　在面对质量度量数据时，使用者不能只关注一个最后的总分数；比较合适的方法是先观察整个项目的总体趋势，然后慢慢深入到具体的单个文件、单个函数以及具体的代码行中。

　　1.观察项目整体的质量概览

　　在质量度量报告被打开以后，使用者可以先看项目级别的总体情况，比如整体复杂度的分布状态、超过标准的函数有多少个、以及问题主要出在哪些文件里面。如果发现只有个别函数的数据明显偏高，那么需要处理的范围就会比较明确；但如果发现大面积的数据都显示不合格，这可能是因为合格标准的设置不符合当前项目，也可能是因为项目自身的代码结构本来就很杂乱。

　　2.观察函数级别的各项数据

　　当研究人员进入到具体的文件或者函数界面后，需要把注意力放在代码的分支多寡、代码的总行数、嵌套的层数、出口的数量以及参数的个数等数据上；分支数量太多的话，通常说明代码里的判断逻辑很复杂；嵌套的层数太深了，人们在阅读代码时就容易产生混乱；而函数的行数如果太长，后面的人在修改时就容易引起其他连锁问题。

在LDRA对代码质量进行评审的说明文档中，质量度量和代码的可测试性、可维护性、清晰度都是紧密相连的，其目的并不是为了展示一堆数字，而是为了帮助编程人员找到那些需要重新编写或者需要仔细检查的代码区域。

　　3.结合规则不合规情况和覆盖率进行综合分析

　　质量度量的数据是不能孤立起来进行判断的；如果某一个函数不仅复杂程度很高，而且还存在着编码规范违规、覆盖率不够、有没测试到的分支等问题，那么这类函数就需要被优先安排解决。相反的情况下，有些函数虽然行数稍微多了一点，但是它的逻辑是很直直一条线的，覆盖率也很完整，没有什么高风险的违规行为，那么它的处理顺序就可以往后排；工具生成的报告只是给人们提供一个寻找线索的入口，真正的结论还是需要结合项目具体的情况来决定。

　　二、质量度量异常项的判定依据

　　在判断质量度量的异常项时，不能简单地认为“只要超过了设定的标准就是错误的”；有些数据的超标确实说明代码不好维护，但是另外一些数据的超标则和具体的业务功能有关系。

　　1.核对判定标准是否符合项目实际情况

　　在查看质量度量判定标准的时候，研究人员需要先确认一下当前使用的标准到底是项目评审要求的指标，还是工具自带的默认数值。如果是做安全要求极高的关键软件，标准的设置通常会非常严格；而如果是写普通的业务工具代码，标准可能就会放得宽一些；如果判定标准经常变动，报告前后的说法就会不一致，后面也很难做趋势方面的对比。

　　2.观察异常部分是否处于核心代码中

　　如果这些异常项只是出现在初始化的脚本、调试用的代码或者一次性的数据迁移工具里面，那么它们带来的风险通常没有核心控制逻辑那么高；但如果异常数据集中在任务调度、通信对接、诊断策略、安全监控、状态切换这一类核心模块中，开发人员就需要认真对待了；因为这些关键位置一旦改错了，波及的范围会非常大，测试人员也很难做到完整的覆盖。

　　3.评估异常对测试设计造成的影响

　　质量度量的异常往往会给测试工作带来直接的麻烦；一个函数里面的分支如果太多，单元测试需要的用例数量就会变多；条件组合起来太复杂的话，覆盖率的缺口也很难被补齐；而且在嵌套太深的时候，一些少见的异常路径经常会被测试人员漏掉。代码的复杂程度指标本来就是用来观察代码是不是好理解、是不是好维护以及有没有潜在缺陷风险的，大家不能把它仅仅当成汇报工作时的一串数字。

　　三、质量度量结果的后续处理流程

　　质量度量这项工作的意义并不是为了拿到一份好看的报告，而是为了进行长期的观察；只有在每个版本迭代时都检查一次，人们才能发现代码是不是在变得越来越难维护；如果只是在项目交付前才急忙扫描一遍，通常就只能看到一堆超标的数据，这时候往往已经来不及去认真处理了。

　　1.建立项目的数据初始标准

　　在第一次的质量度量结果稳定下来以后，研究人员可以把这份报告当作质量的初始标准；在后续的版本开发中，大家应该把精力放在新增加的异常项上，而不是总是和历史留下来的老问题纠缠不清。对于以前就存在的旧代码，可以采取分阶段慢慢处理的办法；而对于新写出来的代码，则要尽量让他们保持在合格范围内，这样开发团队玩起来也比较容易接受。

　　2.按照风险的高低顺序来安排修改

　　在进行代码修改时，不能平均分配力气；对于那些复杂度特别高、覆盖率特别低、最近经常被改动、而且又属于核心业务路径的函数，应该把它们排在最前面去处理。至于那些普通的工具函数、不常运行的模块以及历史遗留下来的代码，大家可以结合项目的时间进度安排，在以后顺便进行清理；这样操作的话，质量度量就不会变成开发人员的额外负担，也更容易被塞进日常的开发计划里。

　　3.检查修改完成后的变化情况

　　在代码修改完毕以后，研究人员需要重新跑一遍质量度量，去看看原来的异常数据有没有降下来；在这个地方需要特别注意一件事，就是有些修改只是简单地把一个大函数劈成了几个小函数，虽然表面上看起来每一个小函数的指标都变好了，但是它们之间的调用关系却变得更乱了。所以在复查的时候，大家既要看数据有没有变好，也要亲自去读一读代码，不能只盲目追求数字上的好看。

　　结论

　　针对Testbed质量度量结果怎么看以及异常项怎么判断的问题，核心的方法就是把报告上的数据重新放回到代码的具体应用场景中去分析。在查看数据的时候，可以按照从项目宏观概览到具体文件和函数的步骤来推进，并且还要把编码规范违规、覆盖率缺口以及模块的风险大小结合在一起看；而在处理异常项的时候，需要先确认判定标准是否正确，然后再观察代码的具体位置、对测试的影响以及业务方面的真实原因。