一、库的测试与调试：从“能用”到“可靠”

说实话，写一个静态库或共享库并不难。难的是，你写出来的库在别人手里不出问题。我见过太多“在我机器上跑得好好的”的案例了。嗯，今天我们就聊聊怎么让库真正可靠起来。

库的测试与调试，说白了就是四件事：单元测试、内存检测、日志跟踪、性能分析。这四件事做好了，你的库就能从“能用”变成“可靠”。

核心观点：库的质量不是测出来的，是设计出来的。但测试能帮你发现设计中的漏洞。

库的测试与调试知识体系 库的质量保障 单元测试框架 内存检测 日志与跟踪 性能分析 Google Test Catch2 Mock 与桩 Valgrind AddressSanitizer 内存泄漏检测 spdlog 日志级别 跟踪与链路 gprof perf 火焰图

1.1 单元测试框架：给库穿上“防弹衣”

单元测试，说白了就是给库的每个函数、每个模块单独做体检。我个人习惯在写库代码之前，先把测试框架搭好。这不是矫情，是血的教训换来的经验。

为什么一定要做单元测试？你想想看，一个库可能被几十个、上百个项目引用。如果库里有bug，那所有引用它的项目都会遭殃。我曾经在一个项目中，就因为一个静态库里的边界条件没处理好，导致整个系统在压力测试时崩溃。从那以后，我再也不敢跳过单元测试了。

Google Test 实战

Google Test（简称gtest）是目前C++社区最流行的单元测试框架。它简单、强大，而且文档齐全。下面是一个典型的测试用例：

// math_utils.h
#pragma once
namespace math {
    int add(int a, int b);
    int divide(int a, int b);
}

// math_utils.cpp
#include "math_utils.h"
namespace math {
    int add(int a, int b) { return a + b; }
    int divide(int a, int b) { 
        if (b == 0) throw std::invalid_argument("division by zero");
        return a / b; 
    }
}

// test_math_utils.cpp
#include <gtest/gtest.h>
#include "math_utils.h"

TEST(MathUtilsTest, AddWorks) {
    EXPECT_EQ(math::add(2, 3), 5);
    EXPECT_EQ(math::add(-1, 1), 0);
    EXPECT_EQ(math::add(0, 0), 0);
}

TEST(MathUtilsTest, DivideThrowsOnZero) {
    EXPECT_THROW(math::divide(10, 0), std::invalid_argument);
}

TEST(MathUtilsTest, DivideWorks) {
    EXPECT_EQ(math::divide(10, 2), 5);
    EXPECT_EQ(math::divide(7, 3), 2);  // 整数除法
}

我的小技巧：测试用例的命名要能直接反映测试意图。比如 AddWorks 一看就知道是测加法功能。别用 Test1、Test2 这种名字，三个月后你自己都看不懂。

Mock 与桩：隔离依赖

库的单元测试有个难点：很多函数会依赖外部资源，比如文件系统、网络、数据库。这时候就需要 Mock（模拟对象）或 Stub（桩）来隔离依赖。

举个例子，你的库需要从配置文件读取参数：

// config_reader.h
class ConfigReader {
public:
    virtual ~ConfigReader() = default;
    virtual std::string getValue(const std::string& key) = 0;
};

// 生产环境实现
class FileConfigReader : public ConfigReader {
public:
    std::string getValue(const std::string& key) override {
        // 从文件读取
    }
};

// 测试时用 Mock
class MockConfigReader : public ConfigReader {
public:
    MOCK_METHOD(std::string, getValue, (const std::string&), (override));
};

TEST(ConfigTest, UsesReader) {
    MockConfigReader mock;
    EXPECT_CALL(mock, getValue("timeout"))
        .WillOnce(testing::Return("30"));
    
    // 你的库函数使用这个 mock
    int timeout = loadTimeoutFromConfig(mock);
    EXPECT_EQ(timeout, 30);
}

注意：Mock 不是万能的。过度使用 Mock 会让测试变成“自嗨”——测试通过了，但实际运行时还是崩。我建议：核心逻辑用 Mock，集成测试用真实依赖。

1.2 内存检测：Valgrind 与 AddressSanitizer

C/C++ 的内存问题，是每个工程师的噩梦。野指针、内存泄漏、越界访问……这些问题在库中尤其致命。因为库的内存错误往往不会立即崩溃，而是潜伏下来，在某个深夜突然爆发。

我遇到过最离谱的一次：一个共享库的内存泄漏，导致服务器运行72小时后 OOM 被 kill。查了两天才发现是某个回调函数里忘记 delete 了。

Valgrind：老牌工具，依然能打

Valgrind 的 Memcheck 工具可以检测内存泄漏、非法访问等问题。用法很简单：

# 编译时加 -g 保留调试信息
g++ -g -o my_test my_test.cpp -L. -lmylib

# 运行 Valgrind
valgrind --leak-check=full --show-leak-kinds=all ./my_test

输出示例：

==12345== HEAP SUMMARY:
==12345==     in use at exit: 64 bytes in 2 blocks
==12345==   total heap usage: 10 allocs, 8 frees, 1,024 bytes allocated
==12345== 
==12345== 64 bytes in 2 blocks are definitely lost in loss record 1 of 1
==12345==    at 0x4C2B0E0: operator new(unsigned long)
==12345==    by 0x400A12: createBuffer() (buffer.cpp:15)
==12345==    by 0x400B34: main (main.cpp:22)

避坑指南：Valgrind 会让程序运行速度慢 10-20 倍。别在生产环境跑，也别在压力测试时跑。我一般是在单元测试阶段跑一遍 Valgrind，确保没有内存问题后再提交代码。

AddressSanitizer：更快、更准

AddressSanitizer（ASan）是 GCC 和 Clang 内置的检测工具。它比 Valgrind 快得多，而且能检测出更多类型的内存错误。

# 编译时加 -fsanitize=address
g++ -g -fsanitize=address -o my_test my_test.cpp -L. -lmylib

# 直接运行即可
./my_test

ASan 能检测的问题包括：

  • 堆内存越界（out-of-bounds）
  • 栈内存越界
  • 全局变量越界
  • 释放后使用（use-after-free）
  • 双重释放（double-free）
  • 内存泄漏
特性 Valgrind AddressSanitizer
运行速度 慢（10-20x） 较快（2-3x）
检测范围 内存泄漏、非法访问 越界、释放后使用、泄漏等
是否需要重新编译 不需要 需要
适用场景 已有二进制、第三方库 自己维护的代码

我的建议：开发阶段用 ASan，因为它快，能快速反馈。发布前再用 Valgrind 扫一遍，确保没有遗漏。两个工具互补，不是替代关系。

1.3 库的日志与跟踪：让问题“看得见”

日志，是库的“黑匣子”。当用户报告问题时，你第一件事就是看日志。如果日志写得不好，排查问题就像大海捞针。

我个人习惯在库中内置日志系统，而不是依赖调用方去打日志。这样能保证日志格式统一，而且不会因为调用方忘记打日志而丢失关键信息。

spdlog：现代 C++ 日志库

spdlog 是我最常用的日志库。它快、头文件只有几个、支持格式化输出。下面是一个在库中使用 spdlog 的例子：

#include <spdlog/spdlog.h>
#include <spdlog/sinks/basic_file_sink.h>

class MyLibrary {
public:
    MyLibrary() {
        // 初始化日志，输出到文件
        auto file_sink = std::make_shared<spdlog::sinks::basic_file_sink_mt>("mylib.log");
        logger_ = std::make_shared<spdlog::logger>("mylib", file_sink);
        spdlog::register_logger(logger_);
        logger_->set_level(spdlog::level::info);
    }

    void doSomething(int value) {
        logger_->info("doSomething called with value={}", value);
        // 业务逻辑
        if (value < 0) {
            logger_->warn("negative value detected: {}", value);
        }
        // 如果出错
        if (value > 1000) {
            logger_->error("value out of range: {}", value);
            throw std::out_of_range("value too large");
        }
    }

private:
    std::shared_ptr<spdlog::logger> logger_;
};

日志级别建议：

  • TRACE：最详细的调试信息，只在开发阶段开启
  • DEBUG：调试信息，比如函数入口、参数值
  • INFO：正常运行时的重要事件，比如初始化完成、连接建立
  • WARN：潜在问题，比如参数异常但还能继续运行
  • ERROR：错误事件，比如操作失败但程序还能继续
  • CRITICAL：严重错误，程序可能无法继续运行

注意：不要在日志中记录敏感信息，比如密码、密钥。我曾经见过一个库把数据库密码直接打到了日志里，结果日志文件被上传到公共仓库……嗯，那场面很尴尬。

1.4 性能分析：找到真正的瓶颈

性能优化有个铁律：不要猜测，要测量。你以为的瓶颈，往往不是真正的瓶颈。我见过太多人花了一周优化一个函数，结果发现整个程序 90% 的时间花在另一个地方。

gprof：入门级性能分析

gprof 是 GNU 的工具，使用简单：

# 编译时加 -pg
g++ -pg -o my_program my_program.cpp -L. -lmylib

# 运行程序
./my_program

# 生成分析报告
gprof my_program gmon.out > analysis.txt

输出会告诉你每个函数被调用了多少次、花费了多少时间。但 gprof 有个缺点：它只能分析函数级别的性能，而且对多线程支持不好。

perf：Linux 性能分析利器

perf 是 Linux 内核自带的性能分析工具，功能强大：

# 采样分析
perf record -g ./my_program

# 生成报告
perf report

# 生成火焰图（需要 FlameGraph 工具）
perf script | stackcollapse-perf.pl | flamegraph.pl > flame.svg

火焰图是性能分析的“可视化神器”。它把函数调用栈和耗时直观地展示出来。哪个函数占用的 CPU 时间最多，火焰图上的“火焰”就越高。

我的经验：性能分析不是一次性的工作。我习惯在每次重大版本发布前，都跑一遍性能分析。把结果保存下来，下次发布时对比。这样能及时发现性能退化。

总结

库的测试与调试，是一个系统工程。单元测试保证功能正确，内存检测保证内存安全，日志跟踪保证问题可追溯，性能分析保证运行效率。这四者缺一不可。

记住一句话：库的质量，决定了整个系统的下限。花在测试和调试上的时间，永远不会白费。

公众号:蓝海资料掘金营，微信deep3321

← 上一章 📖 返回目录 下一章 →