很多团队上C/C++test以后，前期最容易卡住的不是工具能不能跑起来，而是单元测试到底该先自动生成，还是先手工补，后面测试套件到底按文件放还是按函数拆。Parasoft官方文档其实把这件事讲得很清楚，C/C++test既支持自动生成测试，也支持用【Test Case Editor】和【Test Case Wizard】补用户自定义用例，同时还把测试套件、测试用例和数据源都集中放在【Test Case Explorer】里管理。只要先把“怎么建”和“怎么统一”两件事定住，后面的回归、覆盖率和团队协作都会顺很多。

　　一、C/C++test单元测试怎么建

　　C/C++test建单元测试，比较稳的方式不是直接手写一堆测试文件，而是先按工具推荐顺序把基础框架搭起来。官方在GUI测试流程里给出的单元测试顺序很明确，通常建议先跑【Generate Unit Tests】，再跑【Generate Stubs】，然后【Build Test Executable】，最后【Run Unit Tests】。这样做的好处是，先把测试骨架、依赖替身和可执行测试体都补齐，再进入实际执行，过程不容易断。

　　1、先把测试入口放到项目资源上

　　先确认代码已经加入C/C++test项目，然后在项目树里选中要测的项目、目录或源文件，再从【Parasoft】里的测试菜单启动对应配置。官方说明里提到，C/C++test的测试是围绕Test Configuration运行的，资源先选准，再选配置，后面的生成范围、执行范围和结果归属才不会乱。

　　2、先用【Generate Unit Tests】起第一版测试

　　如果你面对的是已有代码，最省时间的做法通常是先自动生成第一版单元测试。官方文档说明，自动生成测试会根据【Generation】页签的参数生成CppUnit风格的测试代码，而且生成完以后还可以继续扩展成用户自定义测试。对于新功能验证，官方甚至建议先按函数生成少量起步测试，再逐步补强。

　　3、要补手工用例时，先建测试套件再加测试用例

　　如果自动生成不够用，可以先在【Test Case Explorer】里为项目生成空测试套件。官方给出的路径是从【Parasoft】里运行【Built-in】下的【Unit Testing】里的【Generate Test Suites】，或者在【Test Case Explorer】里右键项目或文件夹，新建测试套件。之后再右键测试套件，选择用编辑器创建测试用例，输入测试用例名，选定目标函数，再补变量、调用和断言。这个流程更适合补充业务上很明确的检查点。

　　4、黑盒补测和批量生成不要混成一种方式

　　官方把用户自定义测试拆成几种路线。用【Test Case Editor】时，适合无代码方式补结构化用例；用【Test Case Wizard】时，更适合新代码的黑盒测试，输入和期望输出配置更直观，但一次只能做一个；自动生成则更适合大批量旧代码的特性化测试和回归基线。实际落地时，把这三种方式分工清楚，比全团队都只用一种入口更稳。

　　二、C/C++test用例组织与命名怎么统一

　　很多团队后期难维护，不是因为测试数量多，而是因为一部分套件按文件建，一部分按函数建，文件名规则也不一样。C/C++test在【Generation】里的【Test Suite】页签其实已经把测试套件的粒度、位置和命名模式都开放出来了，所以统一规则时，应该先统一生成口径，再谈命名口径。

　　1、先统一测试套件粒度

　　官方说明里写得很直接，默认情况下C/C++test是每个文件生成一个测试套件，也可以改成每个函数生成一个测试套件，还支持按源文件或源文件加头文件的粒度组织。团队如果想让【Test Case Explorer】看起来干净，通常要先做一个决定，到底全组按文件管理，还是全组按函数管理，不要项目里两种模式并存。

　　2、再统一测试套件文件名和输出位置

　　在【Generation】下的【Test Suite】页签里，官方允许用一组变量控制测试套件文件名、输出路径和布局，比如`${file_base_name}`、`${function_name}`、`${src_file_base_name}`、`${function_uid}`等。如果团队想统一命名，比较实用的思路是把“文件名维度”和“函数名维度”固定下来，再统一输出到同一测试目录。这里要特别注意，官方也提示过，变量删得太随意会让输出模式变得模糊，进而报出模式歧义错误。

　　3、已有套件怎么处理也要统一

　　很多人只关心怎么新建，却忽略了重生成时是追加还是替换。C/C++test在同一页签里已经提供了三种策略，只给没有测试的函数补测试、给所有函数继续追加、或者直接替换整个现有测试套件。这个选项要是团队里每个人都自己改，最后最容易出现同名套件内容不一致的问题，所以它也应该算组织规则的一部分。

　　4、测试资产要按项目统一存和统一管

　　官方文档说明，测试用例和测试套件数据都保存在C/C++test Project目录下的测试套件文件里，并建议把这些测试成果物纳入软件配置管理系统。换句话说，测试命名能不能长期稳定，和它是不是跟代码一起入库、是不是放在统一目录里，其实是一回事。只靠口头约定，后面基本守不住。

　　三、C/C++test团队落地时先定什么规则

　　真正想把命名和组织统一下来，不能只写一句“请大家按规范来”。更有效的做法，是把规则提前固化到测试配置和测试入口里，让工具默认就往统一方向走。下面这几条不属于官方硬性命名规范，但都是根据官方能力边界倒推出来的更稳妥做法。

　　1、先复制一套团队共用配置，不要每个人各改一份

　　官方示例里就是从内置的【Generate Unit Tests】复制出一份用户自定义配置再修改。团队落地时，最好也这样做，先复制一套统一配置，把测试套件粒度、输出目录和追加策略都锁定，再给团队共用。这样后续每个人跑出来的套件结构会天然接近，不会今天按文件生成，明天又按函数生成。

　　2、手工补的测试用例名要按一套模板来

　　因为用编辑器新建测试用例时，工具会让你手动输入测试用例名，所以名称风格本身就是团队要管的事。更实用的办法，是统一成“模块名_函数名_场景名_期望结果”这一类可读模式，至少保证看到名字就知道它测什么、在什么条件下测、预期是什么。这个命名规则不是工具强制要求的，但它和手工录入入口是天然匹配的。

　　3、同一函数多组输入时，优先用参数化，不要堆很多近似重名用例

　　官方支持在项目级或测试套件级管理数据源，也支持把测试用例做成参数化测试。团队里如果一个函数经常要喂多组边界值、异常值和业务值，通常更适合用一条参数化测试配数据源，而不是写很多只差一个数字的近似重名用例。这样【Test Case Explorer】更清爽，后期维护也更省事。

　　4、需要全团队统一时，把配置放到DTP或共享设置里

　　官方提供了把团队偏好导出、放到DTP，再自动分发给各桌面和服务器安装的方式。对“用例组织与命名怎么统一”这类规则来说，这一点很关键，因为真正能长久生效的不是文档，而是共享配置本身。把统一的测试配置和相关偏好收进DTP或共享localsettings后，新成员进组也更容易直接对齐。

　　总结

　　C/C++test单元测试怎么建，核心不是先手工还是先自动，而是先用统一配置把测试框架搭出来，再根据场景选择自动生成、编辑器补测或向导补测。C/C++test用例组织与命名怎么统一，重点也不是单独规定一个名字格式，而是把测试套件粒度、输出模式、已有套件处理策略和团队共享配置一起定下来。这样做之后，测试文件会更好找，回归执行也更容易接续，团队里不同人生成出来的测试资产才会真正往一个方向收。