Parasoft接入Jenkins应当怎样配置，以及Jenkins构建失败时日志又该如何排查，这两个问题，是不少团队在把静态分析、单元测试和覆盖率接入CI的时候，都会碰到的。这里需要先分清楚两件事情，Parasoft这个工具，它负责的是执行分析、生成报告；而Jenkins这边，它负责的是调度任务、展示结果，还有控制流水线的状态。如果前一个环节没有生成出有效的报告，那么后面插件的配置就算再完整，Jenkins的页面上，也不会有正常的结果出来。所以在进行配置的时候，不能只盯着插件那边的界面，而是要把工具的执行、报告的输出、路径的读取，还有质量的判断标准，这几样东西连在一起去看。
Parasoft SOAtest测试接口的方法，和接口断言怎样设置，这两件事的关键，是先把接口的请求调通，然后再一步一步把需要校验的地方补上去。SOAtest这个工具，能够支持REST、SOAP、微服务、数据库这些不同的测试场景，也能够根据流量或者自然语言去生成API的测试，还可以创建那种靠数据来驱动、分好几个步骤的测试流程。所以，它的用处不只是发出一个请求然后去看返回的结果，它更适合把接口的调用、参数的准备、响应的校验，还有回归的执行这一整套东西都串在一起。
Parasoft C/C++test导入工程的方法，以及头文件路径的补齐方式，其关键并不在于仅将源码文件夹选中。C/C++项目对编译器、宏定义、头文件目录、目标平台和构建脚本都存在依赖，如果这些信息没有被一同导入，工具所看到的代码便不是项目在真实编译时的代码，后续的静态分析、单元测试和规则检查都会因此出现偏差。Parasoft的文档中也曾提到，C/C++test能够通过构建数据文件、Visual Studio工程、CMake生成的JSON等方式，来收集输入范围和构建信息。
如何设置Parasoft的静态分析，以及怎样确认它产生的误报，许多开发团队在引入代码检查的时候，都会遇到这类问题。静态分析并不是把工具装好，点一次扫描就结束了，在这之前，要去看工程的配置是否准确，挑选的规则集是否合适，在那之后，还要看扫描出来的结果，能不能被开发人员弄明白，愿不愿意去处理。如果配置与真实项目差别很大，告警就会大量出现；如果判断误报时缺少依据，后面的评审又容易反复争论。
把项目接入持续集成之后，单次的扫描结果只能说明当时那一刻的情况，真正值得持续盯着的，其实是缺陷数量、覆盖率和测试结果这几个方面，有没有随着时间在慢慢变好。要谈清楚Parasoft DTP里面的质量趋势图到底该怎样去读，以及不同团队之间如果指标的计算口径对不上，又该怎么去把它拉齐，重点就在于先要搞清楚这些趋势图背后统计的到底是哪些构建、哪些扫描任务，还有哪些代码目录，然后再来判断曲线上的那些变化可不可信。DTP这个平台会接收像C/C++test、dotTEST、Jtest这些工具上报过来的数据，然后通过仪表板上的各个组件，把分析的结果给展示出来。
测试环境一切换，页面上给出保存成功的提示，并不代表目标服务已经在按新配置运行了，这个细节很多人在排查问题时容易忽略。Parasoft CTP对测试环境的管理，主要依赖环境定义、组件实例、变量、Virtualize资源以及Provisioning Action这几个模块一起来完成。团队里常说的“策略下发”，指的就是先把环境的配置保存下来，然后再去执行Provision动作，让配置里定义好的状态真正施加到目标环境上面去。官方文档也提到过，Environment Manager的用途正是把环境通过Provision操作，调整到测试所需要的指定状态。
在项目经历过多次扫描之后，单独一份报告已经很难满足分析需求了。想要弄清楚Parasoft DTP里的质量趋势图该怎么看，以及遇到指标口径不一致的问题时如何统一，最关键的一点是得先确认图表使用的项目、筛选配置还有构建版本，然后再去解释缺陷数量、覆盖率和测试结果变动背后的含义。DTP中的筛选配置相当于一组运行时的设定，它负责从数据库里提取特定项目的数据；另外，某些组件还能按照仪表板的设置、指定的筛选配置和目标构建来获取数据。
接口用例在录制完成以后，一到回放环节就频繁报错，这通常并不是录制功能本身不能用了，而是代理、认证信息、动态参数或者请求结构没有被处理利索。Parasoft SOAtest可以借助Parasoft Recorder把接口流量采集下来，再照着流量生成Smart API Test；录制期间，SOAtest Web Proxy这个代理需要一直保持运行。着手排查的时候，不要一遍又一遍地重新去做录制，应该先看一看失败的请求和真实流量之间，究竟是在哪一个层面上出现了偏差。
Java项目在运行过程中出现空指针异常（NullPointerException），并不意味着静态分析工具一定会把它同步报告出来。Parasoft Jtest检查这类空指针问题时，需要结合规则配置、数据流路径、工程依赖还有构建信息去综合判断，如果调用链条太长、扫描范围不够完整、生成的代码没有进入分析，或者日常用的规则集比较轻量，都可能让一部分问题没有被识别出来。遇到漏报的情况，先不要急着把所有规则一股脑全打开，而是应该按照规则配置、工程范围和构建环境这几块，一项一项去检查，这样定位会更加清楚，免得把环境搞得很乱却找不到真正缺口。
在CTP里说测试策略，真正落地时通常不是单指一条规则，而是把测试场景、环境配置、变量集和执行方式绑成一套可复用的执行方案。Parasoft官方现在把这套链路放在Environment Manager里推进，核心动作包括按环境配置执行test scenario jobs，用环境变量切换同一套资产在不同环境下的取值，以及在新版里为单个测试选择test configuration或为场景映射variable set。所以测试策略要想下发得稳，重点不是手工通知，而是把策略做成环境和作业层面的可执行对象。
C/C++test
C/C++test CT
Jtest
dotTEST
Insure++
DTP
CTP
Selenic
SOAtest
Virtualize