Parasoft Jtest为什么会漏掉空指针问题 Parasoft Jtest空指针规则怎么补齐

Java项目在运行过程中出现空指针异常（NullPointerException），并不意味着静态分析工具一定会把它同步报告出来。Parasoft Jtest检查这类空指针问题时，需要结合规则配置、数据流路径、工程依赖还有构建信息去综合判断，如果调用链条太长、扫描范围不够完整、生成的代码没有进入分析，或者日常用的规则集比较轻量，都可能让一部分问题没有被识别出来。遇到漏报的情况，先不要急着把所有规则一股脑全打开，而是应该按照规则配置、工程范围和构建环境这几块，一项一项去检查，这样定位会更加清楚，免得把环境搞得很乱却找不到真正缺口。

一、Parasoft Jtest为什么会漏掉空指针问题

Jtest在识别空指针风险的时候，不光是简单地看某一行代码有没有做空值判断，它还需要继续去追踪这个对象是在哪里被创建出来的，中间经过了哪些方法的传递，最终在哪个条件分支里被用到，一旦工程配置不完整，数据流的分析就很容易在中途断掉，后面的风险自然也就看不到了。

1、使用的规则集偏轻量。很多团队在日常扫描时都是直接使用推荐规则，也就是Recommended Rules，这套配置更适合做快速的例行检查，但如果一个对象需要经过多层方法调用、从工厂方法里返回、通过集合取出，或者穿越了比较复杂的条件分支之后才变成空值，较轻的分析配置就可能没有跟着继续往下追。要是项目里已经出现过空指针漏报，那就可以单独把Flow Analysis Standard规则加进来，再做一轮专门的复查，针对性会更强一些。

2、公共模块没有被纳入扫描范围。空指针的来源不一定就藏在当前这个业务模块里面，很多问题其实是出在公共工具类、基础组件、接口封装层或者第三方适配层里。当扫描任务只分析当前目录的时候，Jtest能看到的仅仅是对外部方法的调用，没有能力继续去判断那个外部方法的返回值是不是可能为空。对于多模块的项目，就需要在扫描之前先确认父工程、子模块以及公共依赖，是不是都已经一起被拉进分析范围了，否则数据流就会在模块边界那里断掉。

3、生成代码和构建信息不齐全。部分Java项目在构建的过程中会生成一些源码、代理类或者接口的实现类，如果扫描任务刚好在生成步骤之前就执行了，那么Jtest拿到的工程结构就是不完整的，后续的分析也就无从谈起。对于Maven项目，可以先执行【mvn test-compile】把生成代码和测试编译都准备好，然后再去运行Jtest分析，这样就能让依赖信息和生成的类先就位了。

二、Parasoft Jtest空指针规则怎么补齐

补充空指针相关规则的时候，不要想着把整套规则全部拉满，而是要围绕实际出现过的漏报场景来调整。因为规则一旦开得太多，报告里很容易混进来大量价值不高的提示，反而让开发人员抓不住真正的重点，排查效率反而会下降。

1、增加Flow Analysis Standard规则。在Jtest的测试配置里把Flow Analysis Standard启用起来，用它来补充数据流分析的深度，这套规则更适合检查跨方法传递、分支条件判断、对象初始化遗漏，以及方法返回值为空这一类的问题。如果项目本身的规模比较大，比较合适的做法是把这套深度分析放到夜间构建、合并前的检查，或者版本发布之前的扫描里去跑，这样既不会拖慢日常的开发节奏，又能把深度检查覆盖到。

2、确认空指针规则已经真正启用。在自定义的规则集里面搜索CWE.476.NP，确认这条规则当前是处于启用状态的；一些规则包里可能还会出现CWE.476.DEREF，可以顺手一起核对一下。规则配置完之后，不要只盯着规则列表看，最好先准备一小段能够稳定复现空指针异常的示例代码，重新跑一遍扫描，看看最终的检查报告里是不是能出现对应的空指针问题，用实战来验证配置是否生效会更稳妥。

3、检查扫描范围的设置情况。去查看一下CI脚本和Jtest任务里有关include、exclude的配置，确认业务源码、公共模块，还有项目自己那部分生成代码，并没有被错误地排除在外。像node_modules、构建缓存、测试输出和第三方源码这些，可以按照项目的实际需要排除掉，但项目自身维护的公共封装层就不要随手去掉了，否则数据流的链路会在边界处被截断，漏报的问题就会反反复复出现。

三、Parasoft Jtest空指针检查怎么减少漏报

规则补齐之后，还要把整个检查的方式给固定下来。如果每次都只是等到问题出现了才临时去修改配置，那么下一次换分支、换构建机器，或者切换到另一个项目模块的时候，同样的漏报情况多半还会再回来，排查的精力就白费了。

1、准备一批历史问题的样例。把项目里曾经真实出现过的空指针问题，整理成一组小型的回归样例，覆盖住直接解引用、跨方法返回、集合取值、条件分支、对象初始化遗漏以及接口返回值为空这些常见的场景。每当Jtest版本升级、规则集做了调整，或者构建脚本发生过改动之后，先跑一遍这些准备好的样例，看看有没有问题被漏掉，这样心里会更有底。

2、保留两套扫描配置搭配使用。日常的代码提交可以使用较轻量的一套扫描配置，把扫描时间控制下来，保证开发流程不被拖慢；而到了夜间构建和版本发布前的阶段，再启用Flow Analysis Standard来做一次深度检查。这样两套配置一前一后互相配合，既不会影响平时的节奏，又能在交付之前补上完整的一轮排查。

3、结合单元测试一起验证。静态分析虽然能提前发现其中的一部分空指针风险，但它并不能代替单元测试和接口回归，Jtest负责把可疑的路径给找出来，测试用例则负责去覆盖真实的输入、空值的边界以及异常分支。这两边配合着使用，空指针问题就更容易在代码提交阶段被尽早暴露出来，不至于拖到线上才被发现。

总结

Parasoft Jtest为什么会漏掉空指针问题、空指针规则又该怎么补齐，排查的时候可以先从规则配置入手，再去看工程范围和构建数据是否完整。如果平时使用的规则集比较轻量，就可以增加Flow Analysis Standard并确认CWE.476.NP已经启用；对于多模块项目，还要留意公共依赖、生成代码以及排除目录这些地方。最后，把历史问题样例拿来做回归验证，这比单独盯着规则开关去看要更加稳定可靠。