毫无疑问，Chromium 是人类史上最复杂的软件工程项目之一，根据 OpenHub🔗 的统计，目前（2025.11.28）有超过 3600 万行代码。

复杂软件工程的稳定性保证，离不开一个稳定、全面、灵活且高效的测试框架。

提到测试，免不了会涉及一些前置知识，包括但不限于 TDD（Test-Driven Development，测试驱动开发），单元测试/集成测试/冒烟测试，CI（Continuous Integration，持续集成）等。别着急，后文会详细阐述。

本文更多是想以 Chromium Testing Framework 为例，结合理论和工程实践，帮助大家对“测试”二字，有更深入了解，进而产生敬畏。至于目标，当然还是在认识和利用工具的基础上，提高代码质量，减少生产环境的 bug，早点下班！

1. 关于测试的几个名词

删繁就简，平常工作中最常见的，就是上面提到的三个：

• TDD
• 测试类型
• CI

TDD，即测试驱动开发，是软件开发过程中的一种流程习惯：先有测试用例，后有具体实现。

TDD 强调了测试在软件开发过程中的重要作用，不存在没有测试用例的代码。同时编写测试用例，可以帮助开发者从使用者角度，更好地理解和设计代码。

即便如此，100% TDD 的项目很少见，答案不言而喻，效率。人力是一方面，另一方面是有些场景下的测试用例极度复杂。当然也有说法，真正好的代码都易于测试。

这话当然也对。

只是在实际生产上，好的代码并没有那么多，严格遵循 TDD 会寸步难行，只能折衷，优先保证核心功能的测试覆盖度。

因此我建议，将 TDD 作为一个意识记在心里，尽最大努力实践，而不是奉为圭臬，强制遵守。

测试类型，常见的有：

• 单元测试（Unit Testing），对程序最小可测试部分（通常是单个函数、方法或类）的测试
• 集成测试（Integration Testing），对程序中两个及以上单元如何协作的测试
• 端到端测试（End-to-End Testing），模拟真实用户从头到尾使用程序的测试
• 冒烟测试（Smoking Testing），部署新版本前，验证核心功能是否正常工作的测试

CI，持续集成的观念在业界早已深入人心。几乎所有成熟的软件开发团队，都会定制适合自己的持续集成框架，并将测试作为流水线（Pipeline）上的重要一环。按照任正非的说法，这正是：用流程的确定性，减少由于人的因素所带来的不确定性。

2. 测试框架需要解决的问题

从哲学角度，我认为测试框架只需要解决一个问题：如何虚构真实？

测试框架的底色，可能永远都是虚构的，除非在量子世界。

但测试不是请客吃饭，做得不好是会出问题的。

因此测试框架需要做的，是能足够逼真地模拟真实环境，越真实，结果越可信。

什么是真实？

• 真实地假设实际使用中的前置条件

• 真实地执行生产环境里使用到的代码

• 真实地模仿用户行为

工程上则要考虑测试框架的易用性，全面性和运行效率。

• 易用性降低使用门槛，开发者不再畏惧编写测试用例，轻松上手

• 全面性涵盖所有测试场景，甚至时间流逝（Chromium 是支持的！）

• 运行效率代表着反馈延迟，越及时的反馈，迭代速度越快，问题便能更快收敛

3. Chromium 做了什么

Chromium 中的测试体系是分层的：Unit Test → Integration Test → Browser Test → Telemetry / End-to-End。

整个测试框架的基座是 gtest🔗，同样来自 Google，市面上最常用的 C++ 测试框架。

借助 gtest 实现单元测试非常简单，可参照：GoogleTest User’s Guide | GoogleTest🔗。

但是，gtest 作为一个通用的测试框架，并不覆盖诸如线程模拟、任务队列、消息循环、时钟时间等 Chromium 里需要的特殊场景。

于是 Chromium 自己动手，在 base::test 中提供了一系列辅助工具：

工具	作用
TaskEnvironment	模拟消息循环、执行异步任务
SingleThreadTaskEnvironment	模拟 UI/IO 线程环境
RunLoop / RunUntilIdle()	控制任务执行与等待
ThreadTestHelper	多线程测试辅助

甚至还可以做到环境隔离，如文件、网络、线程、时间等：

工具	用途
ScopedPathOverride	临时修改文件系统路径（如用户目录）
ScopedCommandLine	临时修改命令行参数
TestFuture	等待异步 Callback 返回结果
HistogramTester	验证 UMA / Metrics 是否记录正确
MockTimeDomain	让时间可控、可快进

还有更真实的。

Browser Test 会启动一个轻量的浏览器运行环境，包含进程模型、WebContents、TabStrip、Profile、History、Sync 等一整套浏览器功能，可进行 UI、导航、网络、渲染、同步等跨模块行为验证。

真实还是虚构？边界已经模糊了。

如果没有这套坚实的测试框架，我想 Chromium 的迭代，重构，发版，人们使用 Chrome/Edge 等一系列基于 Chromium 开发的浏览器体验，将大打折扣。

4. 总结

代码的质量，很大程度上由测试保证。因此，测试框架的质量，测试覆盖度，在很大程度上反映出代码品质。

同时，项目在积攒一系列测试用例后，重构的思想负担和出错空间也会大大减少，后续维护成本得以降低。

对于开发者，养成良好的测试习惯，如及时编写测试用例，保证代码的良好可测试性等，非常重要。

不仅如此，在我看来，测试的过程，其实是假设-验证-反馈-调整的不断循环，用现实的结果检验假设的有效性，尊重客观规律，及时调整自己不合理的认知。不要只是空想，要动手（Make your hands dirty），置身事内，和现实碰撞，你会逐渐明白什么是对的，并收集一些人们俗称为“经验“的东西。

代码在这个过程里不断趋于完善，我们的人生同样如此。

（完）

参考

1. The Chromium (Google Chrome) Open Source Project on Open Hub🔗
2. 测试驱动开发 - 维基百科，自由的百科全书🔗
3. 聊聊 clean code - 美团技术团队🔗