C++ 单元测试与代码覆盖率测试方法，零基础入门到精通，收藏这篇就够了

前言

测试是软件开发过程中一个必须的环节，测试确保软件的质量符合预期。

对于工程师自己来说，单元测试也是提升自信心的一种方式。

直接交付没有经过测试的代码是不太好的，因为这很可能会浪费整个团队的时间，在一些原本早期就可以发现的问题上。而单元测试，就是发现问题一个很重要的环节。

本文以C++语言为基础，讲解如何进行单元测试并生成测试报告。

在工具上，我们会使用下面这些：

• GCC

• CMake

• Google Test

• gcov

• lcov

参考演示项目：

https://github.com/guaiguaibao/gtest-and-coverage

项目结构

演示项目的目录结构如下：

.
├── CMakeLists.txt
├── googletest-release-1.8.1.zip
├── include
│   └── utility.h
├── make\_all.sh
├── src
│   └── utility.cpp
└── test
    └── unit\_test.cpp

这里演示的内容是：以测试一个我们要提供的软件库为例，讲解如何对其进行单元测试并生成测试报告。

为了简单起见，这个软件库只有一个头文件和一个实现文件。

当然，在实际上的项目中，一个软件库会通常包含更多的文件，不过这并不影响我们要说明的问题。

关于CMake

演示项目中的CMakeLists.txt内容如下：

cmake\_minimum\_required(VERSION 2.8.11) ①
project(utility) ②
​
set(CMAKE\_CXX\_STANDARD 11) ③
​
set(GTEST googletest-release-1.8.1) ④
include\_directories("./include" "${GTEST}/googletest/include/")
link\_directories("build/gtest/googlemock/gtest/")
​
SET(CMAKE\_CXX\_FLAGS  "${CMAKE\_CXX\_FLAGS} --coverage") ⑤
​
add\_library(${CMAKE\_PROJECT\_NAME}\_lib src/utility.cpp) ⑥
​
add\_executable(unit\_test test/unit\_test.cpp) ⑦
target\_link\_libraries(unit\_test ${CMAKE\_PROJECT\_NAME}\_lib gtest gtest\_main pthread) ⑧

以编号为序，这段代码说明如下：

1. 设置使用的CMake最低版本号为2.8.11。

2. 指定项目的名称为”utility”，项目名称可以通过${CMAKE_PROJECT_NAME}进行引用。

3. 指定使用C++11。

4. 这里的三行是编译google test，并将其头文件路径和编译结果的库文件路径添加到环境中。因为后面在编译单元测试代码的时候需要用到。

5. 添加--coverage到编译器flag中，这个参数是很重要的，因为这是生成代码覆盖率所必须的。

6. 编译我们的软件库，这里将生成libutility_lib.a库文件。

7. 编译单元测试的可执行文件。

8. 单元测试的可执行文件需要链接我们开发的软件库以及google test的库。另外，google test依赖了pthread，所以这个库也需要。

关于测试

软件测试有很多种分类方式。从测试的级别来说，可以大致分为：

• 单元测试

• 集成测试

• 系统测试

这其中，单元测试是最局部和具体的。它通常需要对代码中的每一个类和函数进行测试。

单元测试通常由开发者完成，需要针对代码逻辑进行测试。所以它是一种白盒测试。

关于xUnit

xUnit是几种单元测试框架的总称。最早源于Smalltalk的单元测试框架SUnit，它是由Kent Beck开发的。

除此之外，还有针对Java语言的JUnit，针对R语言的RUnit。

在本文中，我们使用Google开发的xUnit框架：Google Test。

Google Test介绍

Google Test的项目主页在Github上。

实际上，这个项目中同时包含了GoogleTest和GoogleMock两个工具，本文中我们只会讲解第一个。

Google Test支持的操作系统包含下面这些：

• Linux

• Mac OS X

• Windows

• Cygwin

• MinGW

• Windows Mobile

• Symbian

目前有很多的项目都使用了Google Test，例如下面这些：

• Chromium projects

• LLVM

• Protocol Buffers

• OpenCV

• tiny-dnn

编译Google Test

为了便于读者使用，我们在演示项目中包含了Google Test 1.8.1的源码压缩包。并且在CMake文件中，同时包含了Google Test的编译和使用配置工作。

如果使用演示项目，读者将不需要手动处理Google Test的编译和安装工作。

使用Google Test

演示项目代码说明

为了便于下文说明，演示项目中包含了几个简单的函数。

演示项目中的软件库包含一个头文件和一个实现文件。头文件内容如下：

// utility.h
​
#ifndef INCLUDE_UTILITY_
#define INCLUDE_UTILITY_
​
enum CalcType {
    ADD,
    MINUS,
    MULTIPLE,
    DIVIDE
};
​
class Utility {
public:
    int ArithmeticCalculation(CalcType op, int a, int b);
​
    double ArithmeticCalculation(CalcType op, double a, double b);
​
    bool IsLeapYear(int year);
};
​
#endif

这个头文件说明如下：

• 头文件包含了三个函数，前两个用来做int和double类型的四则运算。最后一个判断输入的年份是否是闰年。

• 当然，在实际的工程中，前两个函数合并实现为一个泛型函数更为合适。但这里之所以分成两个，是为了查看代码覆盖率所用。

• 关于 闰年 说明如下：

• • 能被4整除但不能被100整除的年份为普通闰年。

  • 能被100整除，也同时能被400整除的为世纪闰年。

  • 其他都不是闰年。

  • 例如：1997年不是闰年，2000年是闰年，2016年是闰年，2100不是闰年。

这三个函数的实现也不复杂：

// utility.cpp
​
#include "utility.h"
​
#include <iostream>
#include <limits>
​
using namespace std;
​
int Utility::ArithmeticCalculation(CalcType op, int a, int b) {
    if (op == ADD) {
        return a + b;
    } else if (op == MINUS) {
        return a - b;
    } else if (op == MULTIPLE) {
        return a * b;
    } else {
        if (b == 0) {
            cout << "CANNO Divided by 0" << endl;
            return std::numeric_limits<int>::max();
        }
        return a / b;
    }
}
​
double Utility::ArithmeticCalculation(CalcType op, double a, double b) {
    if (op == ADD) {
        return a + b;
    } else if (op == MINUS) {
        return a - b;
    } else if (op == MULTIPLE) {
        return a * b;
    } else {
        if (b == 0) {
            cout << "CANNO Divided by 0" << endl;
            return std::numeric_limits<double>::max();
        }
        return a / b;
    }
}
​
bool Utility::IsLeapYear(int year) {
    if (year % 100 == 0 && year % 400 == 0) {
        return true;
    }
    if (year % 100 != 0 && year % 4 == 0) {
        return true;
    }
    return false;
}

开始测试

接下来我们就要对上面这些代码进行测试了。

要使用Google Test进行测试，整个过程也非常的简单。只要进行下面三部：

1. 创建一个测试用的cpp文件

2. 为上面这个测试用的cpp文件编写Makefile（或者CMake文件）。同时链接：

• 待测试的软件库

• gtest库

• gtest_main库

• pthread库（Google Test使用了这个库所以需要）

编写测试代码，编译并运行测试的可执行程序。

并且，测试代码写起来也非常的简单，像下面这样：

#include "utility.h"
​
#include "gtest/gtest.h"
​
TEST(TestCalculationInt, ArithmeticCalculationInt) {
    Utility util;
    EXPECT_EQ(util.ArithmeticCalculation(ADD, 1, 1), 2);
    EXPECT_EQ(util.ArithmeticCalculation(MINUS, 2, 1), 1);
    EXPECT_EQ(util.ArithmeticCalculation(MULTIPLE, 3, 3), 9);
    EXPECT_EQ(util.ArithmeticCalculation(DIVIDE, 10, 2), 5);
    EXPECT_GT(util.ArithmeticCalculation(DIVIDE, 10, 0), 999999999);
}

是的，就是这么简单的几行代码，就对整数四则运算的函数进行了测试。

TEST后面所包含的内容称之为一条case，通常我们会为每个函数创建一个独立的case来进行测试。一个测试文件中可以包含很多条case。同时，一条case中会包含很多的判断（例如EXPECT_EQ...）。

注意：在做单元测试的时候，保证每条case是独立的，case之间没有前后依赖关系是非常重要的。

当然，测试代码中包含的判断的多少将影响测试结果的覆盖率。所以在编写每条case的时候，我们需要仔细思考待测试函数的可能性，有针对性的进行测试代码的编写。

这段代码应该很好理解，它分别进行了下面这些测试：

• 1 + 1 = 2

• 2 - 1 = 1

• 3 x 3 = 9

• 10 / 2 = 5

• 10 / 0 > 999999999

你可能会发现，这段代码里面甚至没有main函数。它也依然可以生成一个可执行文件。这就是我们链接gtest_main所起的作用。

在实际的测试过程中，你想判断的情况可能不止上面这么简单。下面我们来看看Google Test还能做哪些测试。

测试判断

Google Test对于结果的判断，有两种形式：

• ASSERT_*：这类判断是Fatal的。一旦这个判断出错，则直接从测试函数中返回，不会再继续后面的测试。

• EXPECT_*：这类判断是Nonfatal的。它的效果是，如果某个判断出错，则输出一个错误信息，但是接下来仍然会继续执行后面的测试。

可以进行的判断方法主要有下面这些：

对于条件判断可以使用：

ASSERT\_TRUE(condition);  // 判断条件是否为真
ASSERT\_FALSE(condition); // 判断条件是否为假

对于数值比较可以使用：

ASSERT\_EQ(val1, val2); // 判断是否相等
ASSERT\_NE(val1, val2); // 判断是否不相等
ASSERT\_LT(val1, val2); // 判断是否小于
ASSERT\_LE(val1, val2); // 判断是否小于等于
ASSERT\_GT(val1, val2); // 判断是否大于
ASSERT\_GE(val1, val2); // 判断是否大于等于

说明：

• EQ：EQual

• NE：Not Equal

• LT：Less Than

• LE：Less Equal

• GT：Greater Than

• GE：Greater Equal

对于字符串比较可以使用：

ASSERT\_STREQ(str1,str2); // 判断字符串是否相等
ASSERT\_STRNE(str1,str2); // 判断字符串是否不相等
ASSERT\_STRCASEEQ(str1,str2); // 判断字符串是否相等，忽视大小写
ASSERT\_STRCASENE(str1,str2); // 判断字符串是否不相等，忽视大小写

对于浮点数判断可以使用:

//期待GetValueFloat 返回值等于3.1
EXPECT\_FLOAT\_EQ(GetValueFloat(),3.1); 
EXPECT\_DOUBLE\_EQ(GetValueDouble(),3.1);
//期待GetValueFloat返回值，在2.9和3.9之间
EXPECT\_NEAR(GetValueFloat(1),3.4,0.5); 

Test Fixture

在某些情况下，我们可能希望多条测试case使用相同的测试数据。例如，我们的演示项目中，每条case都会需要创建Utility对象。

有些时候，我们要测试的对象可能很大，或者创建的过程非常的慢。这时，如果每条case反复创建这个对象就显得浪费资源和时间了。此时，我们可以使用Test Fixture来共享测试的对象。

要使用Test Fixture我们需要创建一个类继承自Google Test中的::testing::Test。

还记得我们前面说过，我们要尽可能的保证每条测试case是互相独立的。但是，当我们在多条case之间共享有状态的对象时，就可能出现问题。

例如，我们要测试的是一个队列数据结构。有的case会向队列中添加数据，有的case会从队列中删除数据。case执行的顺序不同，则会导致Queue中的数据不一样，这就可能会影响case的结果。

为了保证每条case是独立的，我们可以在每条case的执行前后分别完成准备工作和清理工作，例如，准备工作是向队列中添加三个数据，而清理工作是将队列置空。

这两项重复性的工作可以由::testing::Test类中的Setup和TearDown两个函数来完成。

我们演示用的Utility类是无状态的，所以不存在这个问题。因此，这里我们仅仅在Setup和TearDown两个函数中打印了一句日志。

使用Test Fixture后，我们的代码如下所示：

class UtilityTest : public ::testing::Test {

protected:

void SetUp() override {
    cout << "SetUp runs before each case." << endl;
}

void TearDown() override {
    cout << "TearDown runs after each case." << endl;
}

Utility util;

};

这段代码说明如下：

1. Setup和TearDown两个函数标记了override以确认是重写父类中的方法，这是C++11新增的语法。

2. 我们的Utility类是无状态的，因此Setup和TearDown两个函数中我们仅仅打印日志以便确认。

3. 将Utility util设置为protected以便测试代码中可以访问。（从实现上来说，测试case的代码是从这个类继承的子类，当然，这个关系是由Google Test工具完成的）。

要使用这里定义的Test Fixture，测试case的代码需要将开头的TEST变更为TEST_F。

这里_F就是Fixture的意思。

使用TEST_F的case的代码结构如下：

TEST\_F(TestCaseName, TestName) {
  ... test body ...
}

这里的TestCaseName必须是Test Fixture的类名。

所以我们的测试代码写起来是这样：

TEST_F(UtilityTest, ArithmeticCalculationDouble) {
    EXPECT_EQ(util.ArithmeticCalculation(ADD, 1.1, 1.1), 2.2);
}

TEST_F(UtilityTest, ArithmeticCalculationIsLeapYear) {
    EXPECT_FALSE(util.IsLeapYear(1997));
    EXPECT_TRUE(util.IsLeapYear(2000));
    EXPECT_TRUE(util.IsLeapYear(2016));
    EXPECT_FALSE(util.IsLeapYear(2100));
}

运行测试

编写完单元测试之后，再执行编译工作便可以运行测试程序以查看测试结果了。

测试的结果像下面这样

如果测试中包含了失败的case，则会以红色的形式输出。同时，会看到失败的case所处的源码行数，这样可以很方便的知道哪一个测试失败了，像下面这样：

如果只想有选择性的跑部分case，可以通过--gtest_filter参数进行过滤，这个参数支持*通配符。

像下面这样：

$ ./build/unit\_test --gtest\_filter=\*ArithmeticCalculationInt
Running main() from googletest/src/gtest\_main.cc
Note: Google Test filter = \*ArithmeticCalculationInt
\[==========\] Running 1 test from 1 test case.
\[----------\] Global test environment set-up.
\[----------\] 1 test from TestCalculationInt
\[ RUN      \] TestCalculationInt.ArithmeticCalculationInt
CANNO Divided by 0
\[       OK \] TestCalculationInt.ArithmeticCalculationInt (0 ms)
\[----------\] 1 test from TestCalculationInt (0 ms total)

\[----------\] Global test environment tear-down
\[==========\] 1 test from 1 test case ran. (0 ms total)
\[  PASSED  \] 1 test.

进阶语法

• ASSERT_PRED1

使用场景: 自定义判断函数 对函数进行的值进行测试 在这个场景里，我们要测试add函数，但是判断条件比较复杂，所以用函数的形式写了一个判定条件 isGreaterThan10。

EXPECT_PRED2 的下标是2，代表自定义的判定函数有2个参数。当自定义函数有3个 参数时，则用ASSERT_PRED3,以此类推。

//  EXPECT\_PRED2, 使用场景: 自定义判断函数 对函数进行的值进行测试
bool isGreaterThan10(short a ,short b)
{
    return add(a,b)>=10;
}
TEST(HelloGtest, case\_EXPECT\_PRED2\_success)
{
    EXPECT\_PRED2(isGreaterThan10,5,5);
}

使用返回值为布尔类型的函数进行判定

• AssertionResult

使用场景: 自定义判断函数,并输出额外信息 AssertionResult 作为返回值是 自定义函数的另外一种用法，当判定出错时，则可以通过AssertionFailure输出额外的信息。

// AssertionResult, 使用场景: 自定义判断函数,并输出额外信息
 
AssertionResult  isGreaterThan10\_result(short a ,short b)
{
    if (add(a,b)>=10)
    {
        return AssertionSuccess() ;
    }
    return AssertionFailure() << "add " <<a<< '+'<<b<< "<10";
}
TEST(HelloGtest, case\_AssertionResult)
{
    EXPECT\_TRUE(isGreaterThan10\_result(5,1));
}
 

AssertionResult 作为返回值，正确时，返回 AssertionSuccess();

错误时，返回AssertionFailure(); 同时通过重载符 <<输出错误信息

• EXPECT_PRED_FORMAT2

使用场景: 错误时，完全自定义错误消息 如果你已经厌倦gtest一层不变的输出，想加一些自定义的中文输出，就请用EXPECT_PRED_FORMAT2 来彻底改写gtest的输出风格吧

// EXPECT\_PRED\_FORMAT2, 使用场景: 错误时，完全自定义错误消息
 
AssertionResult  isGreaterThan10\_format(const char\* a\_expr,const char\* b\_expr,int a ,int b) 
{
     if (add(a,b)>=10)
        return AssertionSuccess() ;
    return AssertionFailure() << "添加 " <<a\_expr <<"("<<a<< ")+"<< b\_expr<<"("<<b<< ")小于10";
}
TEST(HelloGtest, case\_EXPECT\_PRED\_FORMAT2\_fail)
{
    int a=5;
    int b=1;
    EXPECT\_PRED\_FORMAT2(isGreaterThan10\_format,a,b);
}

如果你对(ASSERT|EXPECT)PRED*?and?(ASSERT|EXPECT)(TRUE|FALSE) 输出格式不满意, 你可以自定义输出的消息格式

EXPECT_PRED_FORMAT2的语法格式

AssertionResult PredicateFormattern(const char\* expr1,
                                    const char\* expr2,
                                    const char\* exprn,
                                    T1 val1,   
                                    T2 val2,
                                    Tn valn);

• ADD_FAILURE

使用场景: 显示地申明错误 本例中，对default情况，主动报错。

//显示得错误申明
void checkValue(int value)
{
    switch(value)
    {
        case 1: SUCCEED();break;
        case 0: SUCCEED();break;
        case -1:SUCCEED();break;
        default:ADD\_FAILURE();
    }
}
TEST(HelloGtest, case\_ADD\_FAILURE)
{
   int value=compare(2,1);
   checkValue(value);
}

显示申明成功或失败，

SUCCEED();
FAIL();  
ADD\_FAILURE();  
ADD\_FAILURE\_AT("file\_path", line\_number);

SUCCEED表示执行到当前位置时，状态是正确的。不会产生其他消息 FAIL() 会触发致命错误，整个case会终止, ADD_FAILURE() and ADD_FAILURE_AT() 只是触发一般错误，case不会终止 注意: 你只能在返回值为void的函数里使用FAIL().

• EXPECT_DEATH

使用场景: 检验程序的退出码，退出信号，退出时打印的字符串 有人问，程序的异常退出码可以用gtest测试吗？回答当然是可以的。case_EXPECT_DEATH 里，GetNullPointer 获取空指针，程序异常退出前输出 Pointer XX is null，则可以被gtest框架捕捉到。并进行判定。 要注意的是 EXPECT_DEATH 第二个参数是一个 matcher,是可以对字符串进行正则表达式 匹配。

EXPECT_DEATH(statement, matcher);

TEST(DeathTest, case\_EXPECT\_DEATH)
{
   EXPECT\_DEATH(
   {
        const char \* p=GetNullPointer(2);
        fprintf(stderr,"Pointer %d is null",&p);
        fflush(stderr);
        if (p\[0\]=='T')
            printf("Should not enter here");
   },
   "\\\\d is null");
}

NormalExit 则是另外一个例子，当程序通过exit退出的错误码，也可以通过gtest 进行验证。

TEST(DeathTest, NormalExit) 
{
  EXPECT\_EXIT( exit(456) ,ExitedWithCode(456), "");
}

• SCOPED_TRACE

_使用场景：判断失败时，显示帮助信息，包括文件和行_号 本例中，如果case失败时，则在子函数SubFunction里，通过SCOPED_TRACE输出额外信息，便于跟踪调试

void SubFunction()
{
    SCOPED\_TRACE("TEST: SubFunction");
    ASSERT\_TRUE(0);
}
TEST(HelloGtest, case\_SCOPED\_TRACE)
{
    int flag  = 0;
    int \*p= UC::GetIntData(flag);
    SubFunction();
}

SCOPED_TRACE 可以添加到子函数中，用来补充错误时的信息

SCOPED_TRACE(message);

代码覆盖率

在进行单元测试之后，我们当然希望能够直观的看到我们的测试都覆盖了哪些代码。

理论上，如果我们能做到100%的覆盖我们的所有代码，则可以说我们的代码是没有Bug的。

但实际上，100%的覆盖率要比想象得困难。对于大型项目来说，能够达到80% ~ 90%的语句覆盖率就已经很不错了。

众所周知，测试可以提高软件版本的质量和可预测性。但是，你知道你的单元测试甚至是你的功能测试实际测试代码的效果如何吗？是否还需要更多的测试？

这些是代码覆盖率可以试图回答的问题。总之，出于以下原因我们需要测量代码覆盖率：

• 了解我们的测试用例对源代码的测试效果

• 了解我们是否进行了足够的测试

• 在软件的整个生命周期内保持测试质量

注：代码覆盖率不是灵丹妙药，覆盖率测量不能替代良好的代码审查和优秀的编程实践。

通常，我们应该采用合理的覆盖目标，力求在代码覆盖率在所有模块中实现均匀覆盖，而不是只看最终数字的是否高到令人满意。

举例：假设代码覆盖率只在某一些模块代码覆盖率很高，但在一些关键模块并没有足够的测试用例覆盖，那样虽然代码覆盖率很高，但并不能说明产品质量就很高。

覆盖率的类型

先来看一下，当我们在说“覆盖率”的时候我们到底是指的什么。

实际上，代码覆盖率有下面几种类型：

• 函数覆盖率：描述有多少比例的函数经过了测试。

• 语句覆盖率：描述有多少比例的语句经过了测试。

• 分支覆盖率：描述有多少比例的分支（例如：if-else，case语句）经过了测试。

• 条件覆盖率：描述有多少比例的可能性经过了测试。

这其中，函数覆盖率最为简单，就不做说明了。

语句覆盖率是我们最常用的。因为它很直观的对应到我们写的每一行代码。

而分支覆盖率和条件覆盖率可能不太好理解，需要做一下说明。

以下面这个C语言函数为例：

int foo (int x, int y) {
    int z = 0;
    if ((x > 0) && (y > 0)) {
        z = x;
    }
    return z;
}

这个函数中包含了一个if语句，因此if语句成立或者不成立构成了两个分支。所以如果只测试了if成立或者不成立的其中之一，其分支覆盖率只有 1/2 = 50%。

而条件覆盖率需要考虑每种可能性的情况。

对于if (a && b)这样的语句，其一共有四种可能的情况：

1. a = true, b = true

2. a = true, b = false

3. a = false, b = true

4. a = false, b = false

请读者思考一下：对于三层if嵌套，每个if语句包含三个布尔变量的代码，如果要做到100%的条件覆盖率，一共要测试多少种情况。 很显示，在编写代码的时候，尽可能的减少代码嵌套，并且简化逻辑运算是一项很好的习惯。 便于测试的代码也是便于理解和维护的，反之则反。

有了这些概念之后，我们就可以看懂测试报告中的覆盖率了。

工作原理

代码覆盖率测量主要有以下三种方式：

1. Source code instrumentation - 源代码检测

将检测语句添加到源代码中，并使用正常的编译工具链编译代码以生成检测的程序集。这是我们常说的插桩，Gcov 是属于这一类的代码覆盖率工具。

2. Runtime instrumentation - 运行时收集

这种方法在代码执行时从运行时环境收集信息以确定覆盖率信息。以我的理解 JaCoCo 和 Coverage 这两个工具的原理属于这一类别。

3. Intermediate code instrumentation - 中间代码检测

通过添加新的字节码来检测编译后的类文件，并生成一个新的检测类。说实话，我 Google 了很多文章并找到确定的说明哪个工具是属于这一类的。

了解这些工具的基本原理，结合现有的测试用例，有助于正确的选择代码覆盖率工具。比如：

• 产品的源代码只有 E2E（端到端）测试用例，通常只能选择第一类工具，即通过插桩编译出的可执行文件，然后进行测试和结果收集。

• 产品的源代码有单元测试用例，通常选择第二类工具，即运行时收集。这类工具的执行效率高，易于做持续集成。

主流工具

代码覆盖率的工具有很多，以下是我用过的不同编程语言的代码覆盖率工具。在选择工具时，力求去选择那些开源、流行（活跃）、好用的工具。

gcov

gcov是由GCC工具链提供的代码覆盖率生成工具。它可以很方便的和GCC编译器配合使用。

通常情况下，安装好GCC工具链，也就同时包含了gcov命令行工具。

对于代码覆盖率工具所做的工作，可以简单的理解为：标记一次运行过程中，哪些代码被执行过，哪些没有执行。 因此，即便没有测试代码，直接运行编译产物也可以得到代码的覆盖率。只不过，通常情况下这样得到的覆盖率较低罢了

工作流程

主要分三步：

1. 在 GCC 编译的时加入特殊的编译选项，生成可执行文件，和 *.gcno；

2. 运行（测试）生成的可执行文件，生成了 *.gcda 数据文件；

3. 有了 *.gcno 和 *.gcda，通过源码生成 gcov 文件，最后生成代码覆盖率报告。

使用

这里我们以另外一个简单的代码示例来说明gcov的使用。

这段代码如下：

// test.c

#include <stdio.h>

int main (void) {

  for (int i = 1; i < 10; i++) {
      if (i % 3 == 0)
        printf ("%d is divisible by 3\n", i);
      if (i % 11 == 0)
        printf ("%d is divisible by 11\n", i);
  }

  return 0;
}

这是一个仅仅包含了main函数的c语言代码，main函数的逻辑也很简单。

我们将这段代码保存到文件test.c。

要通过gcov生成代码覆盖率。需要在编译时，增加参数--coverage：

gcc --coverage test.c

--coverage等同于编译参数-fprofile-arcs -ftest-coverage以及在链接时增加-lgcov。

此处的编译结果除了得到可执行文件a.out，还会得到一个test.gcno文件。该文件包含了代码与行号的信息，在生成覆盖率时会需要这个文件。

很显然，带--coverage编译参数得到的编译产物会比不带这个参数要包含更多的信息，因此编译产物会更大。所以这个参数只适合在需要生成代码覆盖率的时候才加上。对于正式发布的编译产物，不应该添加这个编译参数。

当我们执行上面编译出来的可执行文件a.out时，我们还会得到每个源码文件对应的gcda后缀的文件。由test.gcno和test.gcda这两个文件，便可以得到代码的覆盖率结果了。

只需要通过gcov指定源文件的名称（不需要带后缀）：gcov test，便可以得到包含覆盖率的结果文件 test.c.gcov了。

回顾一下我们刚刚的操作内容：

$ gcc --coverage test.c
$ ll
total 72
-rwxr-xr-x  1 Paul  staff    26K 11 10 14:41 a.out
-rw-r--r--  1 Paul  staff   240B 11 10 14:41 test.c
-rw-r--r--  1 Paul  staff   720B 11 10 14:41 test.gcno
$ ./a.out 
3 is divisible by 3
6 is divisible by 3
9 is divisible by 3
$ ll
total 80
-rwxr-xr-x  1 Paul  staff    26K 11 10 14:41 a.out
-rw-r--r--  1 Paul  staff   240B 11 10 14:41 test.c
-rw-r--r--  1 Paul  staff   212B 11 10 14:42 test.gcda
-rw-r--r--  1 Paul  staff   720B 11 10 14:41 test.gcno
$ gcov test
File 'test.c'
Lines executed:85.71% of 7
test.c:creating 'test.c.gcov'

$ ll
total 88
-rwxr-xr-x  1 Paul  staff    26K 11 10 14:41 a.out
-rw-r--r--  1 Paul  staff   240B 11 10 14:41 test.c
-rw-r--r--  1 Paul  staff   623B 11 10 14:42 test.c.gcov
-rw-r--r--  1 Paul  staff   212B 11 10 14:42 test.gcda
-rw-r--r--  1 Paul  staff   720B 11 10 14:41 test.gcno

我们可以cat test.c.gcov一下，查看覆盖率的结果：

        -:    0:Source:test.c
        -:    0:Graph:test.gcno
        -:    0:Data:test.gcda
        -:    0:Runs:1
        -:    0:Programs:1
        -:    1:// test.c
        -:    2:
        -:    3:#include <stdio.h>
        -:    4:
        -:    5:int main (void) {
        -:    6:
       20:    7:  for (int i = 1; i < 10; i++) {
        9:    8:      if (i % 3 == 0)
        3:    9:        printf ("%d is divisible by 3\\n", i);
        9:   10:      if (i % 11 == 0)
    #####:   11:        printf ("%d is divisible by 11\\n", i);
        9:   12:  }
        -:   13:
        1:   14:  return 0;
        -:   15:}

这个结果应该还是很容易理解的，最左边一列描述了代码的覆盖情况：

• -：表示该行代码被覆盖了

• 整数：表示被执行的次数

• #####：表示该行没有被覆盖

lcov

gcov得到的结果是本文形式的。但很多时候，我们可能希望得到更加美观和便于浏览的结果。

此时就可以使用lcov了。

lcov是gcov工具的图形前端。它收集多个源文件的gcov数据，并生成描述覆盖率的HTML页面。生成的结果中会包含概述页面，以方便浏览。

lcov支持我们前面提到的所有四种覆盖率。

安装

lcov并非包含在GCC中，因此需要单独安装。

• Ubuntu系统

sudo apt install lcov

使用

对于lcov的使用方法可以通过下面这条命令查询：

lcov --help

通过输出我们可以看到，这个命令的参数有简短（例如-c）和完整（例如--capture)两种形式，其作用是一样的。

这里主要关注的下面这几个参数：

• -c 或者 --capture 指定从编译产物中收集覆盖率信息。

• -d DIR 或者 --directory DIR 指定编译产物的路径。

• -e FILE PATTERN 或者 --extract FILE PATTERN 从指定的文件中根据PATTERN过滤结果。

• -o FILENAME 或者 --output-file FILENAME 指定覆盖率输出的文件名称。

另外还有需要说明的是：

• lcov默认不会打开分支覆盖率，因此我们还需要增加这个参数来打开分支覆盖率的计算：--rc lcov_branch_coverage=1

• lcov输出的仍然是一个中间产物，我们还需要通过lcov软件包提供的另外一个命令genhtml来生成最终需要的html格式的覆盖率报告文件。同样的，为了打开分支覆盖率的计算，我们也要为这个命令增加--rc lcov_branch_coverage=1参数

最后，make_all.sh脚本中包含的相关内容如下：

COVERAGE\_FILE=coverage.info
REPORT\_FOLDER=coverage\_report
lcov --rc lcov\_branch\_coverage=1 -c -d build -o ${COVERAGE\_FILE}\_tmp
lcov --rc lcov\_branch\_coverage=1  -e ${COVERAGE\_FILE}\_tmp "\*src\*" -o ${COVERAGE\_FILE}
genhtml --rc genhtml\_branch\_coverage=1 ${COVERAGE\_FILE} -o ${REPORT\_FOLDER}

这段代码从我们前面编译的结果中收集覆盖率结果，并将结果输出到coverage.info_tmp文件中。但是这里面会包含非项目源码的覆盖率（例如google test），所以我们又通过另外一条命令来指定”src”文件夹进行过滤。最后，通过genhtml得到html格式的报告。

可以通过浏览器查看覆盖率报告的结果，像下面这样：

从这个报告的首页，我们已经可以看到代码的语句覆盖率（Lines），函数覆盖率（Functions）以及分支覆盖率（Branches）。而对于条件覆盖率可以从详细页面中看到。如下图所示：

在上面这张图中，我们可以看到哪些代码被覆盖了，哪些没有。而对于对于if-else之类的语句，也能很清楚的看到条件覆盖率的覆盖情况。例如，对于代码的27行，只覆盖了if成立时的情况，没有覆盖if不成立时的情况。

使用Google Mock

Google Mock是Google Test的扩展，用于编写和使用C++ Mock类。

在面向对象的编程中，Mock对象是模拟对象，它们以预先设定的方式模仿真实对象的行为。程序员通常会创建一个Mock对象来测试某个其他对象的行为，这与汽车设计师使用碰撞测试假人来模拟人类在车辆碰撞中的动态行为的方式非常相似。

这两年，IT行业面临经济周期波动与AI产业结构调整的双重压力，确实有很多运维与网络工程师因企业缩编或技术迭代而暂时失业。

很多人都在提运维网工失业后就只能去跑滴滴送外卖了，但我想分享的是，对于运维人员来说，即便失业以后仍然有很多副业可以尝试。

网工/运维/测试副业方向

运维网工，千万不要再错过这些副业机会！

第一个是知识付费类副业：输出经验打造个人IP

在线教育平台讲师

操作路径：在慕课网、极客时间等平台开设《CCNA实战》《Linux运维从入门到精通》等课程，或与培训机构合作录制专题课。
收益模式：课程销售分成、企业内训。

技术博客与公众号运营

操作路径：撰写网络协议解析、故障排查案例、设备评测等深度文章，通过公众号广告、付费专栏及企业合作变现。
收益关键：每周更新2-3篇原创，结合SEO优化与社群运营。

第二个是技术类副业：深耕专业领域变现

企业网络设备配置与优化服务

操作路径：为中小型企业提供路由器、交换机、防火墙等设备的配置调试、性能优化及故障排查服务。可通过本地IT服务公司合作或自建线上接单平台获客。
收益模式：按项目收费或签订年度维护合同。

远程IT基础设施代维

操作路径：通过承接服务器监控、日志分析、备份恢复等远程代维任务。适合熟悉Zabbix、ELK等技术栈的工程师。
收益模式：按工时计费或包月服务。

网络安全顾问与渗透测试

操作路径：利用OWASP Top 10漏洞分析、Nmap/BurpSuite等工具，为企业提供漏洞扫描、渗透测试及安全加固方案。需考取CISP等认证提升资质。
收益模式：单次渗透测试报告收费；长期安全顾问年费。

比如不久前跟我一起聊天的一个粉丝，他自己之前是大四实习的时候做的运维，发现运维7*24小时待命受不了，就准备转网安，学了差不多2个月，然后开始挖漏洞，光是补天的漏洞奖励也有个四五千，他说自己每个月的房租和饭钱就够了。

为什么我会推荐你网安是运维和网工测试人员的绝佳副业&转型方向?

1.你的经验是巨大优势: 你比任何人都懂系统、网络和架构。漏洞挖掘、内网渗透、应急响应，这些核心安全能力本质上是“攻击视角下的运维”。你的运维背景不是从零开始，而是降维打击。

2.越老越吃香，规避年龄危机: 安全行业极度依赖经验。你的排查思路、风险意识和对复杂系统的理解能力，会随着项目积累而愈发珍贵，真正做到“姜还是老的辣”。

3.职业选择极其灵活: 你可以加入企业成为安全专家，可以兼职“挖洞“获取丰厚奖金，甚至可以成为自由顾问。这种多样性为你提供了前所未有的抗风险能力。

4.市场需求爆发，前景广阔: 在国家级政策的推动下，从一线城市到二三线地区，安全人才缺口正在急剧扩大。现在布局，正是抢占未来先机的黄金时刻。

网工运维测试转行学习网络安全路线

（一）第一阶段：网络安全筑基

1. 阶段目标

你已经有运维经验了，所以操作系统、网络协议这些你不是零基础。但要学安全，得重新过一遍——只不过这次我们是带着“安全视角”去学。

2. 学习内容

**操作系统强化：**你需要重点学习 Windows、Linux 操作系统安全配置，对比运维工作中常规配置与安全配置的差异，深化系统安全认知（比如说日志审计配置，为应急响应日志分析打基础）。

**网络协议深化：**结合过往网络协议应用经验，聚焦 TCP/IP 协议簇中的安全漏洞及防护机制，如 ARP 欺骗、TCP 三次握手漏洞等（为 SRC 漏扫中协议层漏洞识别铺垫）。

**Web 与数据库基础：**补充 Web 架构、HTTP 协议及 MySQL、SQL Server 等数据库安全相关知识，了解 Web 应用与数据库在网安中的作用。

**编程语言入门：**学习 Python 基础语法，掌握简单脚本编写，为后续 SRC 漏扫自动化脚本开发及应急响应工具使用打基础。

**工具实战：**集中训练抓包工具（Wireshark）、渗透测试工具（Nmap）、漏洞扫描工具（Nessus 基础版）的使用，结合模拟场景练习工具应用（掌握基础扫描逻辑，为 SRC 漏扫工具进阶做准备）。

（二）第二阶段：漏洞挖掘与 SRC 漏扫实战

1. 阶段目标

这阶段是真正开始“动手”了。信息收集、漏洞分析、工具联动，一样不能少。

熟练运用漏洞挖掘及 SRC 漏扫工具，具备独立挖掘常见漏洞及 SRC 平台漏扫实战能力，尝试通过 SRC 挖洞搞钱，不管是低危漏洞还是高危漏洞，先挖到一个。

2. 学习内容

信息收集实战：结合运维中对网络拓扑、设备信息的了解，强化基本信息收集、网络空间搜索引擎（Shodan、ZoomEye）、域名及端口信息收集技巧，针对企业级网络场景开展信息收集练习（为 SRC 漏扫目标筛选提供支撑）。

漏洞原理与分析：深入学习 SQL 注入、CSRF、文件上传等常见漏洞的原理、危害及利用方法，结合运维工作中遇到的类似问题进行关联分析（明确 SRC 漏扫重点漏洞类型）。

工具进阶与 SRC 漏扫应用：

• 系统学习 SQLMap、BurpSuite、AWVS 等工具的高级功能，开展工具联用实战训练；

• 专项学习 SRC 漏扫流程：包括 SRC 平台规则解读（如漏洞提交规范、奖励机制）、漏扫目标范围界定、漏扫策略制定（全量扫描 vs 定向扫描）、漏扫结果验证与复现；

• 实战训练：使用 AWVS+BurpSuite 组合开展 SRC 平台目标漏扫，练习 “扫描 - 验证 - 漏洞报告撰写 - 平台提交” 全流程。
  SRC 实战演练：选择合适的 SRC 平台（如补天、CNVD）进行漏洞挖掘与漏扫实战，积累实战经验，尝试获取挖洞收益。

恭喜你，如果学到这里，你基本可以下班搞搞副业创收了，并且具备渗透测试工程师必备的「渗透技巧」、「溯源能力」，让你在黑客盛行的年代别背锅，工作实现升职加薪的同时也能开创副业创收！

如果你想要入坑黑客&网络安全，笔者给大家准备了一份：全网最全的网络安全资料包需要保存下方图片，微信扫码即可前往获取!

因篇幅有限，仅展示部分资料，需要点击下方链接即可前往获取

优快云大礼包：《黑客&网络安全入门&进阶学习资源包》免费分享

（三）第三阶段：渗透测试技能学习

1. 阶段目标

全面掌握渗透测试理论与实战技能，能够独立完成渗透测试项目，编写规范的渗透测试报告，具备渗透测试工程师岗位能力，为护网红蓝对抗及应急响应提供技术支撑。

2. 学习内容

渗透测试核心理论：系统学习渗透测试流程、方法论及法律法规知识，明确渗透测试边界与规范（与红蓝对抗攻击边界要求一致）。

实战技能训练：开展漏洞扫描、漏洞利用、电商系统渗透测试、内网渗透、权限提升（Windows、Linux）、代码审计等实战训练，结合运维中熟悉的系统环境设计测试场景（强化红蓝对抗攻击端技术能力）。

工具开发实践：基于 Python 编程基础，学习渗透测试工具开发技巧，开发简单的自动化测试脚本（可拓展用于 SRC 漏扫自动化及应急响应辅助工具）。

报告编写指导：学习渗透测试报告的结构与编写规范，完成多个不同场景的渗透测试报告撰写练习（与 SRC 漏洞报告、应急响应报告撰写逻辑互通）。

（四）第四阶段：企业级安全攻防（含红蓝对抗）、应急响应

1. 阶段目标

掌握企业级安全攻防、护网红蓝对抗及应急响应核心技能，考取网安行业相关证书。

2. 学习内容

护网红蓝对抗专项：

• 红蓝对抗基础：学习护网行动背景、红蓝对抗规则（攻击范围、禁止行为）、红蓝双方角色职责（红队：模拟攻击；蓝队：防御检测与应急处置）；

• 红队实战技能：强化内网渗透、横向移动、权限维持、免杀攻击等高级技巧，模拟护网中常见攻击场景；

• 蓝队实战技能：学习安全设备（防火墙、IDS/IPS、WAF）联动防御配置、安全监控平台（SOC）使用、攻击行为研判与溯源方法；

• 模拟护网演练：参与团队式红蓝对抗演练，完整体验 “攻击 - 检测 - 防御 - 处置” 全流程。
  应急响应专项：

• 应急响应流程：学习应急响应 6 步流程（准备 - 检测 - 遏制 - 根除 - 恢复 - 总结），掌握各环节核心任务；

• 实战技能：开展操作系统入侵响应（如病毒木马清除、异常进程终止）、数据泄露应急处置、漏洞应急修补等实战训练；

• 工具应用：学习应急响应工具（如 Autoruns、Process Monitor、病毒分析工具）的使用，提升处置效率；

• 案例复盘：分析真实网络安全事件应急响应案例（如勒索病毒事件），总结处置经验。
  其他企业级攻防技能：学习社工与钓鱼、CTF 夺旗赛解析等内容，结合运维中企业安全防护需求深化理解。

证书备考：针对网安行业相关证书考试内容（含红蓝对抗、应急响应考点）进行专项复习，参加模拟考试，查漏补缺。

运维网工测试转行网络攻防知识库分享

网络安全这行，不是会几个工具就能搞定的。你得有体系，懂原理，能实战。尤其是从运维转过来的，别浪费你原来的经验——你比纯新人强多了。

但也要沉得住气，别学了两天Web安全就觉得自己是黑客了。内网、域渗透、代码审计、应急响应，要学的还多着呢。

如果你真的想转，按这个路子一步步走，没问题。如果你只是好奇，我劝你再想想——这行要持续学习，挺累的，但也是真有意思。

关于如何学习网络安全，笔者也给大家整理好了全套网络安全知识库，需要的可以扫码获取！

因篇幅有限，仅展示部分资料，需要点击下方链接即可前往获取

优快云大礼包：《黑客&网络安全入门&进阶学习资源包》免费分享

1、网络安全意识

2、Linux操作系统

3、WEB架构基础与HTTP协议

4、Web渗透测试

5、渗透测试案例分享

6、渗透测试实战技巧

7、攻防对战实战

8、CTF之MISC实战讲解

关于如何学习网络安全，笔者也给大家整理好了全套网络安全知识库，需要的可以扫码获取！

因篇幅有限，仅展示部分资料，需要点击下方链接即可前往获取

*****优快云大礼包：《黑客&网络安全入门&进阶学习资源包》免费分享