概述

PolySpace是MATLAB里面代码静态检查工具。通过检查源代码，可以确定可能在哪里发生潜在的运行时错误，例如算术溢出，缓冲区溢出等等。它最大的特点是可以检查车企常用的MISRA C标准，还免费，就让各大车企爱不释手。

它有两个工具，一个是PolySpace Bug Finder和PolySpace Code Prover。

Polyspace有两个软件，一个为Polyspace Bug Finder,一个为Polyspace Code Prover。两者都能执行错误检查，代码规则检查，测量代码质量，可以共用同一个工程。Polyspace Bug Finder通过分析代码的语义来执行静态测试，可以比较快执行完测试，一般用于开发人员快速查找尽量多的问题；Polyspace Code Prover通过抽象解析执行测试，是一种噪声分析方法,检查确认每一个操作是否有问题，执行速度比较慢，一般用于出示正式报告使用。

​

Polyspace通过工程来管理测试的源文件以及测试配置项等，所以执行测试必须得建立一个工程。此外，每个工程里面分很多模块，这样大型工程就可以把大量的文件按模块执行测试，减少每次的测试耗时。

新建工程

首先要新建工程

​

或者点击这里新建工程

​

1. project name：工程名字
2. Project configuration:选择项目配置，可以选择使用模板【Use template】，Polyspace有预定义了几个模板，此外用户也可以创建自己的模板，以后我们应该是使用组内自己的模板，这样可以减少每次创建工程的配置时间。除了使用模板，用户也可以自己写脚本配置工程，这是高级功能，本文不涉及。
3. Project language：选择项目分析的文件是哪一种编程语言写的代码。
4. Location:工程路径信息，如果你不像使用默认的路径，请确保不勾选【Use default location】,并在Location里面输入期望的路径，可以点击输入栏右边的 打开文件夹并选择到对应的路径。

​

添加文件

需要给工程添加源文件和Include路径。在打工的工程界面，右击【Source】，选择【Add source】添加源文件。弹出的界面如下所示。选择对应的文件或文件夹，点击【Add Source Files】如果要把文件夹里面的文件也包含进来，需要勾选【Add recurively】。

​

需求给工程添加Include路径，在打工的工程界面，右击【Include】，选择【Add source】添加Include路径。弹出的界面如下图所示，选择对应的路径后，点击【Add Include Foloer】把路径添加到Include路径，如果需要把子目录也添加进来，请勾选【Add recurively】。

​

模块管理

用户可以创建自己的工程配置模板，在打开的工程界面，完成测试的配置后，在配置处右击弹出的下拉框里面，点击【Save As Template】即可把当前的配置（包含对应Module的配置以及Include路径）保存为模板。

保存的模块，下次创建工程时，可以使用该模板。使用前，选先导入用户模板。方法为：在选择模板界面点击【Add custom template…】选择之前报存的模板，然后在【Custom templates】下就会出现刚导入的模板，新建工程时，选择该模板就可以了。如果要删除模板，则可以在界面点击【Remove custom template】。

Polyspace Code Prover需要把一个工程的源文件放到一个Module或者几个Module分别单独测试。需要注意的是Polyspace Bug Finder不支持该功能，那么他就不支持新建Module和复制源文件到模块的功能。

源文件分模块Module的流程如下:在工程界面，点击工具栏的 开始创建模块；或者右击模块如Module_1，在弹出的界面选择【Creat New Module】开始创建模块。完成后，工程界面会出现一个新的模块【Module_x】,后面的x代表第几个Module。

Polyspace由于用Module分别单独测试，需要把对应的源文件复制到对应的Module下，这样只有在这个Module的源文件才会被这个Module测试。复制方法为：在工程界面的Source文件夹下，选择对应的文件，可以用Shift键或者Ctrl键支持多选文件，右击选择的源文件，在弹出的界面点击【Copy to】，然后选择对应的Module_x。

​

否则就会报如下图的错误提示。

​

配置测试项

每个Module模块都需要单独配置测试项，每个配置都可以有差异。在工程界面，左键单击对应的配置，就可以进入配置的设置界面。下图所示，右边的【Configuration】就是配置界面，相关测试配置内容都在这个界面配置。

Target&Compiler配置主要是配置APP运行软硬件环境以及对应的编译器特殊功能。界面如下所示，重点配置以下功能，其他功能按需配置。

【Target Operating system】：配置APP运行的操作系统

【Target Processor type】：配置APP运行的处理器

【Dialect】：配置编译器的特殊功能

【Respect C90 standard】：配置是否只支持C90标准，勾选时表示只支持C90标准，不勾选时表示支持C90和C99标准

​

Macros配置界面主要配置预处理宏定义和取消已有的宏定义，这主要是用于特定编译器内部定义了一些专有的宏定义（如某些编译器宏定义了__far关键字）。

​

Environment Settings配置界面主要配置软件的其他环境信息。如下图所示，每个配置的内容说明如下：

【Code from DOS or Windows file system】：配置文件来源是哪个文件系统，用于识别路径是否区分大小写以及路径符号

【Continue with compile error】：勾选时，使能在编译错误时依旧继续，建议默认不勾选即可

【Command/script to apply to preprocessed files】:配置每个文件预处理后执行的脚本，没有这个需求的可以不配置

【Include】：配置编译每个文件时，自动Include的文件。该配置可用于使用的编译器支持特定关键字时，代码使用了该关键字，但是Polyspace不支持该关键字的情况。通过手动模式把关键字写到一个头文件。配置方法为：点击右边的文件夹图标，在打开的界面选择对应的头文件。

Environment Settings配置界面主要配置软件的其他环境信息。如下图所示，每个配置的内容说明如下：

【Code from DOS or Windows file system】：配置文件来源是哪个文件系统，用于识别路径是否区分大小写以及路径符号，我们是在Windows系统下使用软件的，所以此项要勾选。

【Continue with compile error】：勾选时，使能在编译错误时依旧继续，建议默认不勾选即可

【Command/script to apply to preprocessed files】:配置每个文件预处理后执行的脚本，没有这个需求的可以不配置

【Include】：配置编译每个文件时，自动Include的文件。该配置可用于使用的编译器支持特定关键字时，代码使用了该关键字，但是Polyspace不支持该关键字的情况。通过手动模式把关键字写到一个头文件。配置方法为：点击右边的文件夹图标，在打开的界面选择对应的头文件。

1. 1. Inputs &Stubbing配置

本界面用于配置全部变量、指针、函数参数的数据约束输入以及Stubbing函数（如果测试文件依赖外部实现的函数，那么测试时需要设置Stubbing函数用于模拟实现调用的函数功能）。界面如下所示，具体配置内容说明如下：

【Constraint setup】:配置全部变量、指针、函数参数的数据约束条件，通过点击【Edit】添加对应约速

【Ignore default initialization of global variables】:配置是否忽略默认C标准的含蓄初始化全局变量（没有明显的初始化变量，char 默认初始化为0，int 默认初始化为0，等等）。为了提高我们的代码安全性，我们要求所有的变量都必须明显地初始化，所以要勾选该选项，忽略C标准里面的默认初始化。

【No automatic stubbing】:配置是否不自动产生stubbing函数，可以用于发现未定义的函数，也可以用于手动定义stubbing函数。由于我们的APP使用底层的函数，这些底层函数是供应商提供的，我们没有底层函数的源文件，所以建议不勾选这个配置项，由polyspace自动产生stubbing函数。

【Functions to stub】:配置哪些函数为stubbing函数，当测试时不想再测试某一个确定的函数时，可以在此指定函数为stubbing函数。由于我们的函数都要测试，建议此次不配置任何函数。

1. 1. Multitasking配置

本配置界面用于配置多任务相关的配置，配置界面如下所示，配置项说明如下：

【Enable automatic concurrency detection】:使能自动多任务检测，用于有标准的POSIX接口的多线程创建接口函数。我们APP没有这个功能，所以不需要勾选此项

【Configure multitasking manually】:使能手动配置多任务，这些设置依赖于3.5.4 Verfication Assumptions配置为Verify whole application，但是由于我们的APP都只是一个模块，不是一个完成的应用，所以这个配置我们不需要配置。

1. 1. Coding Rules & Code Metrics配置

本配置界面配置代码规则检查和代码质量测量，如下所示，各配置说明如下：

【Check MISRA C 2004】：勾选，则可以选择检查MISRA C 2004检查，然后选择对应的规则，可以选择custom然后点击【Edit】自定义检查条例或者装载以前定好的规则。由于NDS要求不同阶段必须支持哪些条例，所以我们应该是组内定好统一的勾选规则，大家复用这个规则即可。

【Check MISRA AC AGC】：自动生成的代码的检查规则，所以我们应该是选择勾选该规则

【Check MISRA C 2012】：NDS不要求该检查，我们需要做

【Check custom rules】：检查用户定义的其他规则，按需配置即可。

【Effective Boolean types】：定义制定哪个类型的数据为boolean类型

1. 1. Code Prover Verification配置

Code Prover Verification里面及其子配置界面都是配置Code Prover 测试的相关定制行为。

Code Prover Verification界面配置代码测试整个代码还是只测试模块，由于我们开发的只是其中一个模块的APP，所以我们勾选【Verify module】。这样polyspace找不到main()函数的情况下，会自动生成一个main()函数，该main()函数会执行以下操作：

1. 初始化【Variables to initialize】里面指定的变量
2. 调【Initialization functions】里面指定的初始化函数
3. 按任意的顺序调【Functions to call】里面指定的函数

如果没有指定以上操作，main()函数会执行以下操作：

1. 初始化除了有关键字const和static以外的全局变量
2. 按任意的顺序调代码里面没有被调用的函数。

由于自动产生的main()函数里面的调度函数顺序是随机的。所以如果不想调度的函数是随机的，请自己手动写一个main函数。

在剩余的配置项说明如下：

【Verify files independently】：勾选将单独校验每个文件，我们不需要单独校验每个文件，所以不勾选。

1. 1. 1. Verification Assumptions配置

本配置界面配置测试的相关假设条件。分别为

【Respect types in fields】：详细见帮助文档

【Respect types in global variables】：详细见帮助文档

【Ignore float rounding】：详细见帮助文档

【Green absolute address checks】：使能绝对地址检查有效果，由于我们APP不需要操作绝对地址，所以不勾选此项

1. 1. 1. Precision配置

本配置主要配置测试的精度，如下所示，每个配置说明如下：

【Precision level】：指定测试精度等级，精度越高，耗时越久，目前使用默认的等级2即可

【Verification level】:指定源代码的测试次数，等级越高，耗时越久，目前使用默认等级level 2即可

【Verfication time limit】:指定测试超时时间，如果超时，测试停止，以小时为单位，如5.75表示5小时45分

【Retype variables of pointer types】：勾选时使能允许把指针强制转换为别的类型。为了防止指针越界，建议不要勾选该选项

【Retype symbols of integer types】：勾选时使能允许把一个整数强制转换为指针。由于我们APP一般不操作底层地址，所以建议不要勾选该选项。

1. 1. Reporting配置

本配置配置测试结束后是否自动产生报告以及报告的内容模板和报告文档格式，由于每次测试都产生报告，会消耗很多时间，建议不勾选【Generate report】。等测试没问题后，再在菜单栏里面的【Reporting】生成报告，详细操作后面的【5 生成报告】章节有介绍。

1. 1. Distributed Computing配置

本配置配置分布式计算的内容，目前我们软件不支持分布式计算功能，此配置界面内容默认不勾选即可。

1. 1. Advanced Settings配置

本配置配置一些高级功能，说明如下：

【Command/script to apply after the end of the code verification】：选择测试结束后执行一个脚本，如果需要该功能，输入对应的脚本路径即可

【Automatic Orange Tester】：是否使能在代码测试结束后，针对Orange的结果执行动态测试以查找运行时错误。

【Number of automatic tests】：设置在代码测试结束后，Orange动态测试的次数

【Maximum loop iterations】：设置在代码测试结束后，Orange动态测试最大循环次数

【Maximum test time】：设置在代码测试结束后，Orange动态测试最长时间

【other】：可以输入其他的polyspace option

还有需要检查的标准

​

执行检查

配置后测试项后，就可以执行测试了，步骤为：在工程界面，先点击对应的Module的对应配置,然后点击工具栏的 执行测试，同时会增加一个结果Result并且后面有个文件表示当前的测试状态[Running],表示进行中。测试正常结束时，状态会切换为[Completed]；测试异常失败时，状态会切换为[Failed]。

点击Run Bug Finder就能开始查找Bug，并且生成检查结果。

​

生成的时候可以选择使用的是PolySpace Bug Finder或者PolySpace Code Prover，run all modules是将所有模块都运行一遍。

​

1. Review评审每个测试结果

测试结束后，在工程界面双击对应的测试结果，可以打开对应的测试结果界面【Result Summary】和【Result Details】。前者主要是罗列了结果的大纲，在【Result Summary】点击每条测试结果，可以在【Result Details】显示每条结果的详细说明。我们可以在【Result Details】界面添加相关内容，如：

【Severity】：为该Result分配一个风险等级

【Status】：为该Result分配一个状态

【Enter comment here】：添加注解信息

运行完毕之后，就能在Dashboard里面看到检查的结果。有风险错误数量比例饼状图，颜色越深风险越高。分析覆盖度柱状图，检查了多少个源文件，里面有多少个函数，通过的有多少个，不通过的有多少个。风险错误在各个文件的数量分布，不符合代码规范的地方在各个文件的标准分布。

​

想要看具体的每个错误可以进入到result list，里面列举出具体风险类型项，位置，数量等信息。点击进去，可以在Source窗口对照源代码分析问题。

Red checks ： 指示代码包含一个确定的错误，里面显示了一个  图标

Gray checks：指示有不可到达的代码，里面显示了一个  图标

Orange checks：指示在部分情况下，可能存在错误，里面显示了一个   图标

Green checks ：指示在任何情况下，代码都不存在错误，里面显示了一个   图标

Coding rule violations：指示有违反了选定的代码规则，   显示违反了预定义的规则，  显示违反了客户自定义的规则

Code metrics ：指示代码质量，如果违反了选择的代码质量阈值，会显示一个   图标

Global variables:显示发现的全局变量，带有 一个  图标。对于可能没有保护措施的全局变量，带有一个  图标，对于没有使用的全局变量，带有一个    图标。

譬如我故意写错一个地方，检查之后可以通过点击跳转，看到第9行的前面，第8行那里少了个分号。

​

检查终止问题

如果你的文件错误实在是太多，它会检查到中途便终止。

​

生成报告

你可以根据需求生成自己想要的报告

1. 生成报告

Review完每个结果后，就可以生成测试报告了，点击菜单栏的【Reporting】→【Run Report…】打开生成报告界面。相关配置内容如下：

【Select Reports】:选择输出报告的模板

【Output folder】:选择输出报告存放到哪一个路径

【Output format】:选择输出的文件格式，如WORD、PDF等