售前问题

很多团队上了Parasoft之后，扫描是跑起来了，但真正到了研发链路里，常见问题还是两类。一类是规则、项目、构建口径没统一，导致流水线每次跑出来的结果都能看，却很难直接拿来卡版本；另一类是漏洞结果停在平台里，没有顺着责任人、动作、参考编号继续往缺陷系统和整改闭环里走。Parasoft官方文档里其实已经把这条链路拆开了，工具侧负责执行静态分析和测试，DTP负责汇总、比较、筛选、追踪，并提供和缺陷系统做双向追踪的能力。

很多人第一次用SOAtest做接口测试，容易把录制和断言拆成两件完全独立的事。前面只顾着把流量抓进来，后面才发现生成出来的用例不是太重，就是断言写得太死，接口一改一点点就全红。Parasoft官方资料里其实把这条路讲得很清楚，录制接口一般是先启动SOAtest Web Proxy，再通过Parasoft Recorder打开API Traffic for Parasoft SOAtest开始抓流量；断言这边则更推荐用JSON Assertor或XML Assertor去盯关键字段，而不是把整包响应都按回归快照硬比。

很多团队做虚拟服务，前期最常见的问题不是做不出来，而是做完以后越用越散。一个接口改一次，就复制一份虚拟服务；一个响应多一个字段，又单独改出一个新分支，时间一长，服务能跑，但维护成本会越来越高。Parasoft Virtualize本身并不是按“多复制几份响应”来设计的，它把responder、data source、variables和performance profiles都放在responder suite和.pva里统一组织，目的就是让资产能复用、响应能持续维护。

很多团队做dotTEST门禁时，表面上已经把扫描接进流水线了，真正到版本评审时却还是会出现口径不一的问题。根子通常不在工具没跑，而在于测试配置、规则映射、目标构建和基线构建没有先统一，导致同样一批结果在不同人眼里会变成不同结论。Parasoft官方文档里对这条链路写得很清楚，规则来自test configuration，严重级别和分类可以通过rule map调整，结果进入DTP后又要结合Filter、Build和Baseline Build才能做稳定比较。

很多团队把Jtest接进项目后，第一反应都是先跑一遍规则，可真正到了空指针这一类运行时风险上，常见问题并不是工具没能力，而是配置没选对、规则没单独收口、结果出来后又不会顺着路径往回找。Parasoft官方文档已经把这条链路拆得很清楚，空指针问题主要落在Flow Analysis这一层，内置配置里【Flow Analysis Fast】、【Flow Analysis Standard】和【Flow Analysis Aggressive】都围绕运行时缺陷展开，而【Recommended Rules】和【Critical Rules】又默认带了【Flow Analysis Fast】的规则，所以想把空指针检查跑起来，关键是先选对配置，再决定要不要把规则单独拎出来。

很多人第一次把项目接进Parasoft C/C++test，卡的不是规则集，而是编译器信息这一层。表面上看像是“项目没导进来”，实际更常见的是构建信息没带全、编译器版本没对上，或者工具链名字和C/C++test默认识别模式不一致。Parasoft官方文档写得很明确，做静态分析和运行时测试前，必须先把具体编译器和版本配置好；如果要拿到完整能力，运行C/C++test的机器上也要有完整的开发环境和编译器工具链。