cppcheck 自定义规则_单测生成技术在召回异常问题中的应用实践

二 问题分析

带着上面的疑问，本文对业界内现有异常测试手段在高成本、低召回这两个问题维度上进行了对比分析，对比结果如下表2.1所示。

表2.1 业界常用异常测试手段缺点对比分析

整体上看，当前的召回手段存在滞后性或成本高的问题，像基于压力测试的异常召回手段资源消耗较高，基于功能测试的异常召回手段除开发成本较高外，还存在异常场景不易构造等滞后性问题。基于单元测试和静态检查来发现代码问题已是这些手段中缺点相对较少的，接下来更详细地对比下单元测试和静态检查这两种召回异常的手段。

如今，静态检查已是最常见的异常发现手段，其接入成本低，轻量级。以静态扫描方式来检查，不需要编译运行、不占用资源。但其存在以下问题：

滞后性：线上出了问题后才能转化为规则规避同类问题复发。

准召低：规则靠人来设计，对某些场景会存在漏掉或者误报的问题，需要case by case的解决。

不可持续：缺少围绕规则的生态建设，可能出现规则重复开发、缺少规则贡献者、规则上线后无法有效评估等问题。

基于单元测试来召回异常问题有两个缺点：开发成本高、依赖人的意识。开发人员针对本次功能中的重要函数，编写其对应的单元测试代码来进行测试。选择哪些函数，验证哪些异常场景都依赖开发人员的经验和主动程度。但它也有以下优点：

测试最小单元，易于构造数据，验证正确性

便于后续功能回归

资源消耗小

能更早发现问题，定位和解决成本低

经过上述分析后，可以得出基于单元测试的优势远大于其缺点的结论，于是大胆假设：能否最大化它的优势，解决依赖『写』和『经验』的问题。——即自动撰写异常的单元测试代码，主动发现代码健壮性问题。

在这一设想下，提出一种可持续的、主被动结合、高ROI的稳定性问题召回漏斗，智能UT作为静态代码检查环节后的主动召回手段，动态分析召回问题。

图2.1 稳定性召回漏斗图

三 解决思路

19年初，在对生成用例代码的强诉求下，调研了C/C++语言业界中比较通用且优秀的单测生成工具：C++ test和Wings，在开发成本、召回能力和是否开源三方面进行了对比，对比结果如下表3.1所示。显然，无论是C++ test还是Wings，都无法满足业务线在复杂业务场景下完全自动化对复杂类型函数生成单测代码的诉求以及扩展，因此需要自建单测代码生成能力。

表3.1 业界C/C++单测生成工具调研对比

将开发人员对一个函数撰写单元测试代码的过程进行拆解，各关键步骤如图3.1所示，将整个过程抽象为确认待测试函数->分析代码->构造测试数据->生成测试代码这4个过程。

确认待测试函数：本次提交的代码中，并非所有的变更或新增函数都需要测试，可以结合函数属性(如构造函数、析构函数等)、修改内容(如测试相关的代码、日志逻辑等无风险函数)。

分析代码：汇总被测函数的代码，如参数(输入参数、内部依赖其它依赖参数)、返回值等信息。

构造测试数据：主动构造被测函数所需的用例数据，无需人工参与。

生成测试代码：主动生成测试被测函数的代码，无需人工参与。

解决思路的关键是通过代码分析等白盒技术来实现一键异常单元测试代码的能力，真实模拟开发人员撰写单元测试代码。

图3.1开发人员实现单测代码编写的过程

四 实现方案

基于上一节分析，整个技术方案设计如下图所示，本节重点介绍代码分析、测试用例生成、代码生成能力和执行分析的实现思路。

图4.1 技术方案设计图

4.1 代码分析能力

代码分析的目标是期望能通过静态代码扫描的手段，将复杂的函数代码抽象成结构化的函数特征数据，可以类比编译符号表。基于这份结构化数据能直接感知函数调用方式、变量声明和赋值方式等行为。

4.1.1 代码特征

C/C++语言中，尤其是C++这类面向对象的语言，函数调用和类的声明创建方式和普通变量不同，存在更丰富的