代码修改后，测试窗口仍显示绿色，容易让人以为历史用例已经重新跑过。可窗口中的状态可能来自上次执行，也可能只更新了选中的几个用例。要确认本次修改有没有经过回归，需要把执行范围、测试配置和本轮结果对应起来。以下以C/C++test Professional的Eclipse集成环境为例，具体界面名称以安装版本为准。

　　一、C/C++test如何配置代码修改后的回归测试

　　已有测试套件可以继续用于回归，不必每次修改代码都重新生成。配置时应保留原有断言、桩函数和数据文件，再确定本轮执行范围。

　　1、确认历史套件仍能被识别

　　代码通过版本管理更新后，测试套件可能已经移动，界面却还保留着旧目录。执行前刷新一次，可以减少选错对象的情况。

　　①保存修改后的【源文件】、【测试套件】和【桩文件】，核对当前工程所在目录。

　　②依次点击【Parasoft】→【Show View】→【Test Case Explorer】，右键目标【项目】，选择【Refresh】。

　　③展开【测试套件】，双击代表性的【历史用例】，核对调用函数、输入数据和断言。

　　2、建立用于回归的执行配置

　　①打开【Parasoft】→【Test Configurations】，找到【Built-in】→【Unit Testing】→【Run Unit Tests】。

　　②右键【Run Unit Tests】，选择【Duplicate】，在【User-defined】中为副本设置便于识别的名称。

　　③打开【Execution】，确认启用【Enable Test Execution】，在【General】中选择【Unit Testing】，点击【Apply】。

　　只生成测试、只构建测试程序与实际执行用例是不同操作。日常回归应采用执行配置，不能把构建成功当作用例已经通过。

　　3、设置套件搜索范围并启动

　　修改公共头文件、共享函数或全局数据时，影响可能跨越多个源文件，仅选当前文件容易漏掉相关套件。

　　①在配置的【Execution】→【General】中检查【Test suite file search patterns】，使其覆盖历史套件实际保存位置。

　　②返回【Test Case Explorer】，选中本轮需要执行的【项目】或多个【测试套件】。

　　③右键所选对象，通过【Test Using】选择刚保存的【回归配置】并运行。

　　④打开【Console】，检查测试程序的构建、启动和结果收集信息。

　　二、C/C++test修改后历史用例未重新执行如何确认

　　判断是否执行，不能只看绿色图标。应查到本轮运行中的具体用例记录，再区分未选入、被跳过和执行中断。

　　1、排除界面筛选和旧状态干扰

　　①在【Test Case Explorer】中点击【Filter】，取消可能隐藏目标用例的筛选条件。

　　②点击【Find】，输入目标【用例名称】，展开其所属【测试套件】。

　　③在视图菜单中启用【Show】→【Details】，查看该用例的执行信息。

　　用例能在列表中找到，只说明它被识别到了。界面也可能保留已有统计，刷新套件列表本身不会执行测试，更不能证明记录属于当前修改。

　　2、对照本轮执行名单

　　总数相同，也可能是执行了另一组用例。检查时可以挑出几条历史关键用例，按名称逐一核对。

　　①在回归配置的【Execution】→【Runtime】中启用【Report unit test execution details】，按需启用【Include tasks details】。

　　②重新运行【回归配置】，打开本轮生成的【测试报告】，查找目标【测试套件】和【用例名称】。

　　③对照【执行数量】、【通过数量】、【失败数量】和【跳过数量】，记录缺少的用例。

　　3、检查是否停在构建或启动阶段

　　①打开【Console】，查看本轮【编译】、【链接】及【测试程序启动】信息。

　　②打开【Quality Tasks】，检查与本轮运行有关的【断言失败】、【运行异常】和【超时】任务。

　　如果日志停在编译或链接错误处，尚不能期待出现新的执行结果。远程目标没有启动、运行中断，也可能使部分用例没有完成。此时窗口里的旧通过状态不能作为本轮证据。

　　4、单独重跑可疑用例

　　当项目回归中找不到某条历史用例时，单独执行一次，有助于区分范围配置问题和用例本身的问题。

　　①在【Test Case Explorer】中选中可疑【用例】，右键通过【Test Using】运行同一份【回归配置】。

　　②查看【Console】及该用例的【Details】，记录本次执行结果。

　　③返回原【项目】或【测试套件】，重新执行原范围，对照两次结果。

　　三、C/C++test怎样核对回归结果是否覆盖本次修改

　　查到历史用例重新执行，还需要判断它有没有验证修改后的行为。用例运行过，与修改内容得到检查，仍有区别。

　　1、检查断言和桩函数是否仍适用

　　①双击目标【测试用例】，核对修改分支对应的【输入参数】、【断言】及【预期结果】。

　　②打开相关【桩文件】，检查【返回值】和调用设置；涉及数据驱动测试时，核对【数据源】内容。

　　③在【Test Case Explorer】中启用【Show】→【Data source tests】，检查各轮数据的执行结果。

　　例如，新增了错误返回分支，但旧桩函数始终返回成功，历史用例即使全部通过，也没有验证新增分支。预期行为发生变化时，应依据需求调整断言，不能为了消除失败直接接受当前输出。

　　2、保留能够复查的运行记录

　　①在【Parasoft】→【Preferences】→【Reports】中启用【Overview of checked files and executed tests】，按需选择【HTML(C++test's Unit Testing details)】报告格式。

　　②生成本轮【测试报告】，与对应的【代码提交标识】、【测试配置】、【数据文件】及【桩文件】一起保存。

　　③对缺少执行依据的【历史用例】补跑，并保存补跑后的【报告】。

　　记录中还应注明本轮执行范围。局部回归可以用于开发中的快速检查，但不能让后续查看报告的人误以为整个项目都已完成验证。

　　总结

　　回归测试的价值，在于让代码修改前后可以按相同要求比较。历史用例需要维护，执行记录也需要与代码版本对应，否则一片绿色仍可能留下未验证的功能。日常检查时，保留几条关键用例作为核对对象，往往比只盯着通过率更有帮助。希望这些内容能帮助大家确认回归执行情况，如有相关需求，欢迎联系咨询。