第34章 调试与测试

程序崩溃，输出是“Segmentation fault (core dumped)”。控制台没有更多信息，你只知道程序在某个时刻突然死了。这是每个C++开发者都会遇到的场景。调试不是猜测，而是有章可循的侦查过程；测试不是写完代码后的点缀，而是保障代码行为符合预期的基石。本章将带你系统掌握这两项让代码从“能跑”到“可靠”的关键技能。

系统化调试：从崩溃现场到问题根源

调试就像侦探破案，你需要收集线索（日志、核心转储）、询问证人（变量状态）、重现案发现场（复现步骤）。现代IDE的图形化调试器很方便，但掌握命令行调试器（GDB/LLDB）是基本功，尤其在服务器或嵌入式环境。

首先，编译时必须带上调试符号。使用-g标志，并建议关闭优化（-O0），否则调试时行号可能对不上，变量可能被优化掉。

// 正确的编译命令
g++ -std=c++17 -g -O0 -o my_app main.cpp utils.cpp

我在项目中踩过一个坑：一个服务在客户环境随机崩溃，生成了core.12345文件。通过gdb ./my_server core.12345加载后，用bt命令立刻看到崩溃发生在std::vector::operator[]，原因是越界访问。如果没有核心转储和调试符号，定位这种问题将如同大海捞针。

内存问题检测：Valgrind与AddressSanitizer

C++手动管理内存，内存泄漏、越界、使用已释放内存（use-after-free）是常见问题。这些错误有时不会立即导致崩溃，而是像“慢性病”一样逐渐耗尽资源或破坏数据。

实际开发中，大部分团队会优先推荐AddressSanitizer，因为它速度比Valgrind快得多（约2倍），对性能影响较小。但Valgrind的Memcheck工具能检测未初始化内存的使用，这是ASan做不到的。我通常的流程是：开发时用ASan快速检查，发布前用Valgrind做深度扫描。

// 示例：一段有内存问题的代码
int* create_array(int size) {
    int* arr = new int[size]; // 动态分配
    return arr;
}
int main() {
    int* my_arr = create_array(10);
    my_arr[10] = 42; // 越界写入！
    // 忘记 delete[] my_arr; // 内存泄漏！
    return 0;
}

使用ASan编译并运行：g++ -fsanitize=address -g -o bad_memory bad_memory.cpp && ./bad_memory。你会立刻得到详细的错误报告，指出越界写入发生在哪一行。

单元测试：使用Google Test构建安全网

单元测试是什么？ 想象你买了一台复杂机器，你不会等整机组装完再测试，而是先检查每个齿轮、电路板是否正常工作。单元测试就是对代码中最小可测试单元（通常是函数或类）进行验证。

技术定义：单元测试是一段自动化的代码，它调用被测试单元，给定特定的输入，验证其输出或行为是否符合预期。其核心价值在于快速反馈、防止回归、并作为代码行为的活文档。

Google Test (gtest)是C++社区最流行的单元测试框架之一。首先需要安装并链接它。

// 一个简单的数学函数及其测试
// math_utils.h
#pragma once
int add(int a, int b);
double divide(double numerator, double denominator);

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

TEST(MathUtilsTest, AddPositiveNumbers) {
    EXPECT_EQ(add(2, 3), 5);
    EXPECT_EQ(add(0, 0), 0);
}

TEST(MathUtilsTest, DivideByNonZero) {
    EXPECT_DOUBLE_EQ(divide(10.0, 2.0), 5.0);
}

TEST(MathUtilsTest, DivideByZeroThrows) {
    EXPECT_THROW(divide(5.0, 0.0), std::invalid_argument);
}

int main(int argc, char **argv) {
    ::testing::InitGoogleTest(&argc, argv);
    return RUN_ALL_TESTS();
}

这里有个隐藏的坑：测试的断言分为EXPECT_*和ASSERT_*。如果EXPECT_EQ失败，测试会继续执行；如果ASSERT_EQ失败，当前测试函数会立即终止。根据是否需要后续验证来选择。

测试驱动开发(TDD)与代码覆盖率

TDD是一种开发方法论：红-绿-重构循环。你先写一个会失败的测试（红），然后写最少代码让测试通过（绿），最后优化代码结构而不改变行为（重构）。这强迫你从使用者角度思考接口设计。

// 使用gcov收集覆盖率
// 1. 编译时加入覆盖率标识
g++ -std=c++17 --coverage -g -O0 -o my_app main.cpp
// 2. 运行程序（执行测试）
./my_app
// 3. 生成报告
lcov --capture --directory . --output-file coverage.info
genhtml coverage.info --output-directory coverage_report
// 打开 coverage_report/index.html 查看可视化报告