在测试人员使用C/C++test这个工具去进行静态分析或者做单元测试之前，大家总会碰到一些比较头疼的问题，比如C/C++test扫描范围怎么设置，还有C/C++test扫描范围排除第三方代码怎么处理。比较安全、稳妥的做法并不是直接把整个项目文件夹一股脑地丢给软件去跑，而是测试人员应该提前把“我们自己写的代码、别人写的第三方代码、机器自动生成的代码、还有用来测试的代码”这四个东西给分得清清楚楚的，然后再通过改动项目属性、调整测试选项或者去写命令行的一些参数，从而把检查的区域给控制住。

　　一、C/C++test扫描范围怎么设置更合理

　　测试人员在调节检查区域的时候，最核心的原则并不是说一次性查的代码越多就越好，而是应该让最后查出来的错和现在阶段的质量要求能够对得上。在这个软件里，系统默认会去查测试人员在运行配置时鼠标点中的那些文件，当然，大家也可以在配置里找到那个叫Scope的地方，通过它去把检查的区域进一步缩小。

　　1、先确定本次扫描的对象

　　当测试人员把工程在软件里打开之后，大家可以先在左边那个项目树的列表里面，用鼠标选中需要测试的工程名字、或者是某个文件夹和具体的文件，然后再去点击运行对应的测试配置。

　　2、通过【Test Configuration】控制范围

　　测试人员先用鼠标点击进入到【Parasoft】里面的【Test Configurations】菜单，在这里面可以对现在正在使用的测试配置进行修改，然后再找到Scope相关的页面，在里面去写一些文件的过滤条件。这个地方非常适合用来解决“今天这次检查只想看哪些代码”的问题，比如测试人员可以设置成只去查某一类的源文件、或者只去查某一个具体路径底下的代码，甚至还可以结合版本控制工具，让它只去查我们在本地电脑上修改过的那些文件。

　　在Scope这个地方，常见的过滤想法大概有三种：

　　第一种是按照修改的时间来过滤，比如让系统只去检查最近这几天被改动过的文件；

　　第二种是按照路径来过滤，比如设置成只包含src目录底下的东西，但是不包含test或者vendor目录底下的东西；

　　第三种是按照代码里面的内容标记来过滤，比如发现文件里面写着是自动生成的标记，系统就会把这些文件给跳过去。这个软件的Scope设置既可以用路径来过滤，也能够根据文件里面的内容标记去把那些自动生成的代码给避开。

　　3、命令行扫描要把范围写清楚

　　如果这个项目已经被大家接到了Jenkins、或者GitLab CI之类的自动化构建系统里面，那么就不建议只靠人工在软件界面上用鼠标去点选目录了，而是应该把要查的区域写到命令行或者是配置文件里面去。比较常见的写法就是利用-resource这个参数来指定要查的东西，然后再用-include还有-exclude这两个参数来一起配合，从而控制哪些该要、哪些该扔。

　　二、C/C++test扫描范围排除第三方代码怎么处理

在绝大多数情况下，第三方库并不是我们自己的团队去负责维护的，如果测试人员直接把它放进静态分析里面去查，就会让最后出来的报告变得密密麻麻、非常混乱，而且这也会影响到后面缺陷数量的统计。但是，要是这些第三方代码被我们自己的人给二次修改过了，或者它本来就已经变成我们要交付的源码的一部分了，那大家就不能简简单单地把它全部都给排除在外了。

　　1、把第三方目录单独归类

　　这里比较推荐大家在建工程的时候，把目录结构设计成将第三方代码集中放到一些固定的文件夹里面，后面大家在写排除规则的时候就会感觉特别清楚。相反，要是那些第三方代码东一个西一个地散落在src目录底下的各个地方，虽然这个软件也能够通过文件名或者路径的规则去把它们挑出来并排除掉，但是这样做的维护成本会变得高很多。比如src/common/zlib、src/module1/openssl、还有src/module2/libxml这些地方都有，要是以后一改目录，测试人员就非常容易把它们给漏掉。

　　2、在项目级设置排除资源

　　要是测试人员使用的是有界面的图形软件，大家就可以在项目树那个列表里，用鼠标右键点击工程的名字，然后进入到【Properties】→【Parasoft】→【C++test】→【Scope Settings】这些菜单里。

接着通过添加资源或者添加模式的方法，去把不需要检查的目录给扔掉。这个软件是支持在项目级别去排除资源的，而且在这里设置好了之后，不管是用图形界面还是用命令行去跑测试，这些设置都是能够派上用场的。

　　3、命令行里用-exclude固定排除规则

　　在自动化测试的场景下面，大家更习惯直接在命令长串里面加上排除的选项，就比如下面这个样子：

　　-data"C:/workspace"

　　-resource"MyProject"

　　-config"user://MISRA Check"

　　-exclude"**/third_party/**"

　　-exclude"**/external/**"

　　-exclude"**/vendor/**"

　　-report"C:/report"

　　三、排除第三方代码后还要检查哪些问题

　　虽然大家把第三方代码给排除掉了，但这并不意味着现在设定的检查区域就一定是百分之百正确的了。

　　1、保留适配层和封装层

　　虽然第三方库的那些目录可以被测试人员给排除在外，但是我们自己为了项目需要所写的那些包装代码、适配代码或者是驱动胶水代码，我是不建议也一起排除掉的。就比如下面这种情况：

　　third_party/openssl/

　　src/security/openssl_adapter.c

　　src/security/crypto_wrapper.cpp

　　在这种结构底下，third_party/openssl目录是可以不要的，但是openssl_adapter.c还有crypto_wrapper.cpp这两个文件必须要留下来跟着一起查。因为那些真正容易把事情搞砸掉的地方，往往不是第三方库本身写得不好，反而是我们在传参数、释放内存、处理错误码、或者是检查边界长度的时候，在这些调用细节上出了错。

　　2、不要把生成代码和业务代码混在一起排除

　　那些自动生成的代码，我们经常可以在搞通信协议、模型生成、界面代码或者是配置表转换这些地方看到。这类代码和第三方代码有点类似，通常也不太适合让我们去一条一条地修改静态分析报出来的警告。但是测试人员也要把事情给分清楚：自动生成的代码本身确实可以不要，但是去调用这些生成代码的逻辑代码，大家是绝对不能随便扔掉的。

　　3、定期做一次完整范围扫描

　　等到版本要发布之前，或者是到了比较重要的代码基线之前，我是建议大家一定要安排一次全面完整的检查。这里的道理很简单，因为有些检查规则是需要依赖更加完整的项目上下文关系的，比如去算执行路径、做度量统计、或者是检查有没有重复的代码。要是排除的区域弄得太大了，最后查出来的结果就很有可能会出现报错不准或者是该报的不报的情况。

　　总结

　　对于C/C++test扫描范围怎么设置这件事，大家千万不能简简单单地把它理解成“只是选哪几个文件夹去查”这么一个操作。在具体去配置的时候，测试人员可以先利用项目的目录结构，把src、third_party、generated、还有test这几个东西给划分得清清楚楚，然后再通过【Scope Settings】、【Test Configuration】或者是cpptestcli的各种参数去把范围给死死控住。