Parasoft静态代码分析可以帮助开发团队检查代码中的潜在缺陷、安全风险以及编码规范问题,通过配置不同规则集,可以满足MISRA、CERT、CWE等不同项目标准要求。但在实际使用过程中,规则启用后没有检测结果、修改严重等级未变化、规则配置无法同步等情况较为常见。造成这些问题的原因可能来自测试配置选择、规则状态、分析范围、项目环境以及规则库版本等多个方面。本文介绍Parasoft静态分析规则配置方法,以及规则设置后未生效时的排查方式。
Parasoft Virtualize可以通过Message Proxy截获真实系统之间的请求与响应,再根据录制流量生成Message Responder和Data Repository。录制完成后,如果同一个请求拿到了错误响应,或者请求参数变化后Virtualize仍返回上一组数据,通常要检查Responder分组方式、Request Matching和Data Source Correlation。录制数据只是生成虚拟服务的基础,最终返回哪条响应仍取决于请求匹配条件和数据关联规则。
Parasoft SOAtest可以把CSV、Excel、数据库、Data Repository或内部Table中的数据绑定到SOAP、REST和其他测试工具,让同一条Test Case按照多组输入重复执行。数据驱动已经配置,但请求中仍然出现固定值、上一轮数据或空值时,通常要检查Data Source是否挂在正确的Test Suite、字段是否真正切换为Parameterized,以及Data Bank或变量有没有在运行时覆盖原来的数据源值。
接口测试经常会卡在依赖服务未完成、测试数据难准备,或者第三方接口不稳定上。Virtualize可以把这些依赖做成可调用的虚拟资产。分析Parasoft旗下Virtualize怎么模拟依赖服务Virtualize模拟服务响应异常如何调整,重点要看请求怎么匹配、响应怎么生成,以及虚拟资产部署到了哪个端点。
ISO 26262合规测试并不是跑一遍静态分析、导出几张覆盖率报表就结束。项目需要先明确ASIL等级、软件安全需求和验证方法,再用Parasoft把编码规范、单元测试、覆盖率及需求追踪串起来。这样到了评审阶段,测试结果才能和具体安全要求对应。
Selenium脚本平时跑得好好的,页面一改版,按钮定位和等待条件就开始报错。Selenic可以在运行时处理部分定位器和同步问题,但它并不会把所有失败都强行改成通过。弄清它能修什么、修复结果有没有写回源码,维护起来会省事很多。
Parasoft的变更影响分析通常需要与DTP、代码覆盖率和测试执行结果配合使用。系统会比较基线构建与目标构建,识别发生变化的文件,再根据历史覆盖关系判断哪些测试需要重新执行。处理“Parasoft怎么进行变更影响分析Parasoft变更影响分析结果不完整怎么办”时,不能只检查分析开关,还要确认构建编号、覆盖率标识、测试明细和DTP过滤器是否对应。
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等方式,来收集输入范围和构建信息。