性能剖析内存管理开发工具【免费下载链接】gperftoolsMain gperftools repository项目地址https://gitcode.com/gh_mirrors/gp/gperftools点击查看免费下载本文以 gperftools 仓库中随附的 GoogleTest 入门文档vendor/googletest/docs/primer.md为主线系统讲解 GoogleTest 的核心概念、断言体系、简单测试与 Test Fixture 的写法、测试入口与 main() 函数的组织方式并结合本仓库的 vendored 源码与 gperftools 自身测试用例给出源码级佐证。读完本文你将掌握用TEST()/TEST_F()编写可维护、可隔离、可复用的 C 单元测试的完整方法并理解 gperftools 如何借助 GoogleTest 构建其庞大的测试矩阵。为什么选择 GoogleTest一个好的测试框架应该做到什么GoogleTest是 Google Testing Technology 团队针对 Google 自身的工程要求与约束开发的 C 测试框架。它基于业界流行的 xUnit 架构如果你用过 JUnit 或 PyUnit上手 GoogleTest 会非常自然即使是新手也只需约 10 分钟即可掌握基础并开始写测试。GoogleTest 不仅支持单元测试还支持任何类型的测试且在 Linux、Windows、Mac 上均可运行。官方文档给出了六条测试设计理念这也是 GoogleTest 的六大核心设计目标测试应当独立且可重复independent repeatableGoogleTest 让每个测试运行在不同的对象上从而隔离测试之间的相互影响。当某个测试失败时你可以单独运行它以便快速调试。测试应当组织良好并反映被测代码的结构well organizedGoogleTest 用 test suite测试套件将相关测试分组测试套件内可以共享数据与子程序。这种一致性对切换项目、接手新代码库的开发者尤其友好。测试应当可移植、可复用portable reusableGoogleTest 支持不同操作系统、不同编译器有无异常exceptions支持均可工作测试可适配多种配置。失败时应提供尽可能多的信息GoogleTest 不会在第一个断言失败时就停下而是只终止当前测试继续执行后续测试同时支持非致命失败nonfatal failure——失败后当前测试仍继续执行。这样可以在一次编辑-编译-运行周期内发现并修复多个 bug。框架应把测试作者从杂务中解放出来GoogleTest 自动跟踪所有已定义的测试不需要用户手工枚举测试列表。测试应当快fast你可以在测试之间复用共享资源只为 set-up/tear-down 付一次代价同时又不让测试互相依赖。需要说明的是本仓库gperftools将 GoogleTest 以 vendored 方式随附在 vendor/googletest 目录下。根据 vendor/README.vendor 的记录googletest 以 release-1.8.0-3576-ga05c0915 版本通过 git archive 原样拷贝进仓库因此下文涉及的源码路径均可在本仓库内直接查阅无需联网。术语辨析Test、Test Case 与 Test SuiteGoogleTest 历史上用Test Case来指代一组相关测试但当前业界包括 ISTQB 术语体系与多数软件质量教材将这一概念称为Test Suite。两者含义对照如下含义GoogleTest 术语ISTQB 术语用特定输入执行特定程序路径并验证结果TEST()Test Case为避免歧义GoogleTest 正在逐步用Test Suite取代Test Case首选 API 是TestSuite旧的TestCaseAPI 正在缓慢弃用并重构。理解这一命名差异在阅读旧文档、旧代码时会避免不少困惑。基本概念断言、测试、测试套件与测试夹具使用 GoogleTest 时你首先编写的是断言assertions——检查某个条件是否为真的语句。断言的结果有三种成功success非致命失败nonfatal failure报告失败但程序继续运行致命失败fatal failure中止当前函数测试用断言来验证被测代码的行为如果测试崩溃或存在失败的断言则测试失败fails否则成功succeeds。测试套件test suite包含一个或多个测试。你应该按照被测代码的结构把相关测试归入同一个测试套件。当套件内多个测试需要共享公共对象与子程序时可以把它们放进一个测试夹具test fixture类。一个测试程序test program可以包含多个测试套件。从下一节开始我们按断言 → 测试 → 测试套件的顺序逐层讲解如何编写一个完整的测试程序。断言体系EXPECT_* 与 ASSERT_* 的取舍GoogleTest 的断言是形似函数调用的宏。断言失败时GoogleTest 会打印断言所在源文件与行号并附带失败信息你也可以通过运算符流式追加自定义失败信息。例如ASSERT_EQ(x.size(), y.size()) Vectors x and y are of unequal length; for (int i 0; i x.size(); i) { EXPECT_EQ(x[i], y[i]) Vectors x and y differ at index i; }任何可以流式输出到ostream的值都可以输出到断言宏中——特别是 C 字符串与string对象。宽字符串wchar_t*、WindowsUNICODE模式下的TCHAR*、std::wstring输出到断言时会被转换为 UTF-8 打印。断言宏以成对形式出现二者测试同一件事但对当前函数的影响不同ASSERT_*系列失败时产生致命失败立即中止当前函数。如果断言失败后继续执行没有意义例如后续要解引用一个可能为空的指针应使用ASSERT_*。EXPECT_*系列失败时产生非致命失败不中止当前函数。通常优先使用EXPECT_*因为它允许一个测试内报告多个失败。一个需要特别注意的副作用失败的ASSERT_*会立即从当前函数返回可能跳过其后本应执行的清理代码从而造成资源泄漏。官方文档特别提醒如果在断言错误之外还收到 heap checker 报错可能就是这个原因——这一点对 gperftools 用户尤为重要因为本仓库正是以堆检查heap checking能力著称的。常用断言速查结合 vendor/googletest/docs/reference/assertions.md类别宏EXPECT_* / ASSERT_*验证内容布尔条件EXPECT_TRUE/EXPECT_FALSE条件为真 / 为假二元比较EXPECT_EQ/EXPECT_NE/EXPECT_LT/EXPECT_LE/EXPECT_GT/EXPECT_GE/!////C 字符串EXPECT_STREQ/EXPECT_STRNE/EXPECT_STRCASEEQ/EXPECT_STRCASENE内容相同 / 不同 / 忽略大小写的相同 / 不同浮点比较EXPECT_FLOAT_EQ/EXPECT_DOUBLE_EQ/EXPECT_NEAR浮点近似相等4 ULP 内/ 双精度近似相等 / 绝对误差界内异常断言EXPECT_THROW/EXPECT_ANY_THROW/EXPECT_NO_THROW抛出指定类型异常 / 抛出任意异常 / 不抛异常谓词断言EXPECT_PRED1EXPECT_PRED5及ASSERT_PRED1ASSERT_PRED5自定义谓词返回true显式结果SUCCEED()/FAIL()/ADD_FAILURE()/ADD_FAILURE_AT(file, line)直接产生成功 / 致命失败 / 非致命失败 / 指定位置的失败补充要点EXPECT_EQ比较指针时做的是指针相等比较比较两个 C 字符串时应使用EXPECT_STREQ按值比较而不是EXPECT_EQ按地址比较。比较指针与空指针时推荐写EXPECT_EQ(ptr, nullptr)而不是EXPECT_EQ(ptr, NULL)。浮点值由于舍入误差几乎不可能精确相等不应使用EXPECT_EQEXPECT_FLOAT_EQ/EXPECT_DOUBLE_EQ采用基于 ULPUnits in the Last Place的默认误差界EXPECT_NEAR(val1, val2, abs_error)则允许你指定绝对误差界。EXPECT_THAT(value, matcher)来自 GMock允许使用 matcher 描述更复杂的匹配例如EXPECT_THAT(value1, StartsWith(Hello))失败信息形如Value of: value1 Actual: Hi, world! Expected: starts with Hello谓词断言在失败时会打印每个参数的取值比单纯的EXPECT_TRUE提供更清晰的失败信息若谓词是重载函数或模板函数可能需要显式指定类型例如EXPECT_PRED1(static_castbool (*)(int)(IsPositive), 5)或EXPECT_PRED1(IsNegativeint, -5)。完整的断言列表请参见 Assertions Reference。编写简单测试TEST() 宏创建测试只需三步用TEST()宏定义并命名一个测试函数——它是普通的、不返回值的 C 函数在函数体内除任意合法 C 语句外使用各类 GoogleTest 断言检查值测试结果由断言决定只要任一断言失败致命或非致命或测试崩溃整个测试即失败否则成功。基本形式TEST(TestSuiteName, TestName) { ... test body ... }TEST()的参数从一般到具体第一个参数是测试套件名第二个参数是套件内的测试名。两者都必须是合法的 C 标识符且不应包含下划线_。一个测试的完整名称由套件名 测试名组成不同测试套件中的测试可以重名。以阶乘函数为例int Factorial(int n); // Returns the factorial of n // Tests factorial of 0. TEST(FactorialTest, HandlesZeroInput) { EXPECT_EQ(Factorial(0), 1); } // Tests factorial of positive numbers. TEST(FactorialTest, HandlesPositiveInput) { EXPECT_EQ(Factorial(1), 1); EXPECT_EQ(Factorial(2), 2); EXPECT_EQ(Factorial(3), 6); EXPECT_EQ(Factorial(8), 40320); }GoogleTest 按测试套件分组报告测试结果因此逻辑相关的测试应放在同一套件中——即TEST()的第一个参数保持一致。测试套件名与测试名的命名约定请遵循 Google C Style Guide 中函数与类的命名规范。可用平台Linux、Windows、Mac。在 gperftools 仓库中TEST()是最基础的测试组织方式。例如 src/tests/cleanup_test.cc 中的TEST(CleanupTest, Basic)以及 src/tests/current_allocated_bytes_test.cc 中的TEST(CurrentAllocatedBytes, Basic)都是直接以TEST()验证核心分配器行为的例子。Test Fixture为多个测试复用同一套数据配置当你发现两个或多个测试操作相似的数据时可以用测试夹具test fixture复用同一套对象配置。创建 fixture 的步骤从testing::Test派生一个类类体以protected:开头因为要在子类中访问 fixture 成员在类内声明计划使用的对象如有必要编写默认构造函数或SetUp()函数为每个测试准备对象。常见错误是把SetUp()写成Setup()小写 u——在 C11 下使用override关键字可以确保拼写正确如有必要编写析构函数或TearDown()函数释放SetUp()中分配的资源。关于何时用构造函数/析构函数、何时用SetUp()/TearDown()可参考 FAQ如需共享子程序在 fixture 中定义即可。使用 fixture 时要用TEST_F()代替TEST()这样才能访问 fixture 中的对象与子程序TEST_F(TestFixtureClassName, TestName) { ... test body ... }与TEST()不同TEST_F()的第一个参数必须是测试夹具类的名字_F代表 Fixture不再单独指定测试套件名。由于 C 宏系统的限制无法用一个宏同时处理两类测试用错宏会导致编译错误此外必须在TEST_F()之前定义好 fixture 类否则会得到 virtual outside class declaration 的编译错误。关键语义每个用TEST_F()定义的测试GoogleTest 都会在运行时创建一个全新的 fixture——立即通过SetUp()初始化运行测试通过TearDown()清理然后删除 fixture。同一套件中不同测试拥有不同的 fixture 对象GoogleTest 总是在创建下一个 fixture 之前删除上一个它不会为多个测试复用同一个 fixture。因此一个测试对 fixture 的修改不会影响其他测试这正是测试独立原则的落地保证。官方文档以 FIFO 队列Queue为例完整演示了这一过程。先定义被测类template typename E // E is the element type. class Queue { public: Queue(); void Enqueue(const E element); E* Dequeue(); // Returns NULL if the queue is empty. size_t size() const; ... };按惯例fixture 命名为FooTestFoo为被测类名class QueueTest : public testing::Test { protected: QueueTest() { // q0_ remains empty q1_.Enqueue(1); q2_.Enqueue(2); q2_.Enqueue(3); } // ~QueueTest() override default; Queueint q0_; Queueint q1_; Queueint q2_; };此例中无需自定义析构函数或TearDown()编译器生成的隐式析构函数即可完成全部清理。接着用TEST_F()编写测试TEST_F(QueueTest, IsEmptyInitially) { EXPECT_EQ(q0_.size(), 0); } TEST_F(QueueTest, DequeueWorks) { int* n q0_.Dequeue(); EXPECT_EQ(n, nullptr); n q1_.Dequeue(); ASSERT_NE(n, nullptr); EXPECT_EQ(*n, 1); EXPECT_EQ(q1_.size(), 0); delete n; n q2_.Dequeue(); ASSERT_NE(n, nullptr); EXPECT_EQ(*n, 2); EXPECT_EQ(q2_.size(), 1); delete n; }上面的例子同时使用了ASSERT_*与EXPECT_*取舍原则是希望断言失败后继续暴露更多错误就用EXPECT_*继续执行没有意义时用ASSERT_*。例如DequeueWorks中第二条断言是ASSERT_NE(n, nullptr)——因为后续要解引用指针n若n为NULL会段错误。这两个测试运行时实际发生的流程是GoogleTest 构造一个QueueTest对象记为t1第一个测试IsEmptyInitially在t1上运行t1被析构上述步骤在另一个QueueTest对象上重复这次运行DequeueWorks测试。可用平台Linux、Windows、Mac。gperftools 仓库内TEST_F()的实战案例可直接参考 src/tests/for_each_line_test.cc其中ForEachLineTest : public testing::Test在构造函数中初始化共享的lines_与example_数据然后用TEST_F(ForEachLineTest, Basic)与TEST_F(ForEachLineTest, NoLastEOL)分别验证按行遍历 proc maps 文本的行为src/tests/page_heap_test.cc 等测试同样大量使用 fixture 来复用分配器测试环境。调用测试RUN_ALL_TESTS() 与主入口TEST()与TEST_F()会隐式地把测试注册到 GoogleTest 中因此你无需像其他 C 测试框架那样手工罗列所有测试。定义好测试后用RUN_ALL_TESTS()运行它们。它返回0表示全部成功返回1表示存在失败。注意RUN_ALL_TESTS()运行的是链接单元内的所有测试——它们可以来自不同的测试套件甚至不同的源文件。RUN_ALL_TESTS()宏被调用时的执行序列保存所有 GoogleTest flags 的状态为第一个测试创建测试夹具对象通过SetUp()初始化它在夹具对象上运行测试通过TearDown()清理夹具删除夹具恢复所有 GoogleTest flags 的状态对下一个测试重复上述步骤直到所有测试运行完毕。如果发生致命失败后续步骤会被跳过。重要提醒绝不能忽略RUN_ALL_TESTS()的返回值否则会编译报错。这样设计的理由是自动化测试服务依据进程退出码exit code而不是 stdout/stderr 来判断测试是否通过因此你的main()必须返回RUN_ALL_TESTS()的值。另外RUN_ALL_TESTS()只能调用一次多次调用会与部分高级功能如线程安全的 death tests见 advanced.md冲突因而不被支持。可用平台Linux、Windows、Mac。编写 main() 函数从 gtest_main 到自定义入口大多数用户不需要自己编写main函数直接链接gtest_main而不是gtest即可——gtest_main提供了合适的程序入口。看本仓库的 vendored 源码 vendor/googletest/googletest/src/gtest_main.cc 即可确认普通平台下其main就是标准的两行模板——GTEST_API_ int main(int argc, char **argv) { printf(Running main() from %s\n, __FILE__); testing::InitGoogleTest(argc, argv); return RUN_ALL_TESTS(); }同一文件还为 Arduino 类平台提供setup()/loop()入口、为 QuRT 平台提供无参main()变体。只有当你需要在测试运行前做 fixtures 与测试套件框架无法表达的定制工作时才需要自己写main。手写main时它必须返回RUN_ALL_TESTS()的值。官方提供的完整模板如下#include this/package/foo.h #include gtest/gtest.h namespace my { namespace project { namespace { // The fixture for testing class Foo. class FooTest : public testing::Test { protected: // You can remove any or all of the following functions if their bodies would // be empty. FooTest() { // You can do set-up work for each test here. } ~FooTest() override { // You can do clean-up work that doesnt throw exceptions here. } // If the constructor and destructor are not enough for setting up // and cleaning up each test, you can define the following methods: void SetUp() override { // Code here will be called immediately after the constructor (right // before each test). } void TearDown() override { // Code here will be called immediately after each test (right // before the destructor). } // Class members declared here can be used by all tests in the test suite // for Foo. }; // Tests that the Foo::Bar() method does Abc. TEST_F(FooTest, MethodBarDoesAbc) { const std::string input_filepath this/package/testdata/myinputfile.dat; const std::string output_filepath this/package/testdata/myoutputfile.dat; Foo f; EXPECT_EQ(f.Bar(input_filepath, output_filepath), 0); } // Tests that Foo does Xyz. TEST_F(FooTest, DoesXyz) { // Exercises the Xyz feature of Foo. } } // namespace } // namespace project } // namespace my int main(int argc, char **argv) { testing::InitGoogleTest(argc, argv); return RUN_ALL_TESTS(); }要点说明testing::InitGoogleTest()负责解析命令行中的 GoogleTest flags 并把识别出的 flags 从参数中移除从而允许用户通过各类 flags 控制测试程序行为详见 AdvancedGuide。必须在调用RUN_ALL_TESTS()之前调用它否则 flags 无法正确初始化。在 Windows 上InitGoogleTest()同样支持宽字符串因此可用于以UNICODE模式编译的程序。旧 APIParseGUnitFlags()已弃用应改用InitGoogleTest()。在 gperftools 中落地vendored gtest 的构建与测试注册理解了 GoogleTest 的基本用法后再看 gperftools 是如何把它接入构建系统的。在 CMakeLists.txt 的BUILD_TESTING分支中仓库把 vendored 的 gtest 源码直接编译为静态库add_library(gtest STATIC vendor/googletest/googletest/src/gtest_main.cc vendor/googletest/googletest/src/gtest-assertion-result.cc vendor/googletest/googletest/src/gtest-death-test.cc vendor/googletest/googletest/src/gtest-filepath.cc vendor/googletest/googletest/src/gtest-matchers.cc vendor/googletest/googletest/src/gtest-port.cc vendor/googletest/googletest/src/gtest-printers.cc vendor/googletest/googletest/src/gtest-test-part.cc vendor/googletest/googletest/src/gtest-typed-test.cc vendor/googletest/googletest/src/gtest.cc) target_include_directories(gtest INTERFACE $BUILD_INTERFACE:${CMAKE_CURRENT_SOURCE_DIR}/vendor/googletest/googletest/include)注意第一行直接把gtest_main.cc编进了gtest库相当于为所有测试目标提供了自带 main 的 gtest_main能力。随后每个测试可执行文件都以gtest为链接目标并注册到 CTestadd_executable(low_level_alloc_unittest src/tests/low_level_alloc_unittest.cc) target_link_libraries(low_level_alloc_unittest low_level_alloc common gtest) add_test(low_level_alloc_unittest low_level_alloc_unittest)类似地src/tests/stacktrace_unittest.cc、src/tests/check_address_test.cc 等测试都通过target_link_libraries(..., gtest)接入并在 CMake 配置阶段通过add_test注册进 CTest。这意味着在 gperftools 中运行测试的方式是先cmake -S . -B build配置构建再cmake --build build编译最后在构建目录执行ctest或直接运行编译出的*_unittest可执行文件。由于gtest_main已内置这些测试程序甚至不需要自己写main。从源码结构看gperftools 的每个核心模块几乎都配有对应的*_unittest.cc测试文件如 src/tests/page_heap_test.cc、src/tests/tcmalloc_unittest.cc、src/tests/malloc_extension_test.cc 等它们共同组成了覆盖地址映射、页堆、线程缓存、堆检查、采样器等核心组件的测试矩阵——这正是本文介绍的断言、TEST()、TEST_F()与 fixture 机制在真实项目中的规模化应用。已知限制线程安全GoogleTest 设计上追求线程安全在提供pthreads库的系统上其实现是线程安全的但在其他系统如 Windows上目前从两个线程并发使用 GoogleTest 断言仍不安全。绝大多数测试都在主线程中进行断言因此通常不会遇到问题。如果你想帮助改进可以为你所在平台在gtest-port.h本仓库对应 vendor/googletest/googletest/include/gtest/internal/gtest-port.h中实现所需的同步原语。进一步阅读Assertions Reference全部断言宏的完整参考AdvancedGuideflags、death tests、参数化测试等高级主题FAQ常见问题含 Ctor 与 SetUp 的选择Quickstart: CMake在自有项目中用 FetchContent 引入 GoogleTest 的快速上手Quickstart: BazelBazel 构建快速上手Code samples更多使用示例本仓库测试源码src/tests 目录下的各*_unittest.cc文件赞分享性能剖析内存管理开发工具【免费下载链接】gperftoolsMain gperftools repository项目地址https://gitcode.com/gh_mirrors/gp/gperftools点击查看免费下载相关推荐GoogleTest Primer 精读基于 googletest 仓库掌握 C 单元测试的核心方法论与实战写法GoogleTest Primer 精读基于 googletest 仓库掌握 C 单元测试的核心方法论与实战写法 本篇指南以仓库 docs/primer.测试质量保障开发工具Google Test Primer 详解miniblink49 仓库内嵌 gtest 的 C 单元测试入门与实践Google Test Primer 详解miniblink49 仓库内嵌 gtest 的 C 单元测试入门与实践 导读 本文以 miniblink49前端桌面应用GoogleTest C 测试框架解析gperftools 仓库中内嵌的测试基石GoogleTest C 测试框架解析gperftools 仓库中内嵌的测试基石 GoogleTest 是 Google 出品的 C 单元测试框架也性能剖析内存管理开发工具上一篇Seismic震动检测原理大揭秘从加速度传感器到算法实现下一篇Nuclide终端分屏API插件开发接口创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考