测试与质量：单元测试/集成测试

可视化演示

展示系统处理流水线、实时性能指标曲线及多方案对比分析，包含数据流转、吞吐延迟监控与方案评估。

单元测试基础

备菜台是你的第一道防线。一块里脊肉不能等炒成菜才尝出馊味——切好之后，你会先单独切一小片，煎一煎、闻一闻，确认它本身没问题。在代码世界里，这个“单独检验一小片”的动作，就是单元测试。它不看配菜、不看火候，只看这一块食材自身是否合格。哪怕整个厨房乱成一锅粥，只要每份食材单独检验过关，最终出大问题的概率就会低得多。

单元测试的“单元”，通常指一个函数、一个类的方法，或一个独立组件。测试只关心它自己：给定输入，验证输出；不连接数据库，不发起网络请求，不依赖其他模块。正因为彻底隔离，单元测试运行极快——上千条用例往往几秒钟就跑完。这种“快”催生了持续集成里最珍贵的循环：改一行代码，几秒内就知道有没有弄坏别的东西。

常见的单元测试框架有 JUnit（Java）、pytest（Python）、Jest（JavaScript）。它们都提供断言（assert）、测试发现、覆盖率统计等基础能力。写单元测试时，核心是逼自己思考模块的“输入—输出”契约：函数接什么参数、返回什么结果、异常边界如何处理。如果一个函数连契约都讲不清楚，那它本身就该重构了。

这就像你在备菜台逐样检验食材：坏掉的胡椒罐被立刻挑出来丢掉，而不是混进菜里。单元测试的价值就在“早发现、快定位”——成本最低、收益最高。它解决的问题是“食材本身有没有坏”，而不是“整道菜好不好吃”。

集成测试要点

食材单独检验合格，不代表组合起来一定好吃。番茄单独很新鲜，牛肉单独很嫩，但火候不对、下锅顺序颠倒，出来的菜照样难以下咽。集成测试做的就是“组合后试味”：把多个模块拼在一起，验证它们协作时是否符合预期。它关注的是接口、数据传递和外部依赖的交互。

模块之间的“接口”是集成测试的头号对象。比如订单模块要调用库存模块的扣减接口，单元测试里两边各自通过，但如果订单模块传入的参数格式库存模块根本不认，那就要靠集成测试来暴露。这就是为什么集成测试往往需要真实的数据库、消息队列或第三方服务的测试环境，只有环境接近生产，协作问题才会显形。

集成测试的难点在于环境与数据配置：测试库要准备好、前置数据要造好、异步消息要等它落地。数据流走向验证是重头戏——一笔订单从下单到扣库存、到发通知、到生成账单，每一步的数据是否按预期流转。集成测试数量虽少，但每个用例覆盖的路径长、信息量大，跑起来也比单元测试慢得多。

这就像焖一锅红烧肉：肉要好、酱油要真，但更重要的是两者在锅里的相遇方式。集成测试保证的是“食材相遇不出乱子”——接口对得上、数据传得对、顺序不颠倒。它是单元测试和端到端测试之间的“承上启下”层。

测试金字塔

聪明的厨师不会把大量时间花在每道菜上桌前搞满汉全席式的全流程试吃——那太慢太贵。他的质检体系是金字塔形的：底部是大量快速的单品检查，比如尝盐、闻油、按一按肉质的弹性；中部是中等数量的组合试味；塔尖才是极少数完整的宴会走查。这就是测试金字塔的直觉原型：底厚顶薄。

在软件世界里，金字塔给出了三种测试的理想配比：单元测试约占 70%，集成测试约占 20%，端到端测试约占 10%。单元测试便宜、快速、易定位；端到端测试最接近用户真实体验，但慢、脆、难排查——一旦失败，你往往不知道是前端、后端还是数据库哪一环出了问题。金字塔的启示是：用便宜的测试覆盖大多数逻辑，把昂贵测试留给关键链路。

比例并非死规矩，而是一盏警示灯。如果团队写了大量端到端测试，金字塔就会“倒置”：测试套件越来越慢，CI 流水线从几分钟拖到几十分钟，开发者开始为了赶进度随意跳过测试。倒置金字塔的团队，往往不是在测试质量上更优秀，而是在用昂贵的代价换取并不更高的安全感。

回到厨房，你是愿意花 50 分钟完整试吃一桌菜，还是花 10 分钟把每样食材都快速验过再加 20 分钟试吃几道关键菜？后者显然更高效。测试金字塔的本质是资源分配哲学：把黄金投在回报率最高的地方。

Mock与Stub

餐厅后厨里，供应商送来的鱼偶尔会晚点。为了不耽误备菜，主厨会安排一个帮厨“替身”先顶上——替身的职责是让流程先跑起来。在测试世界里，当我们不想真的连接数据库、调用支付接口时，也会请“替身”上场。这些替身统称测试替身，其中最常用的两个就是 Stub 和 Mock。

两者的差别可以用一个镜头来记：Stub 像是“举着标准菜牌的替身”——你说“上菜”，它就把预设好的菜递给你，你验证的是“拿到的东西对不对”，这是状态验证；Mock 则像是“带着小本本的替身”——它不光递菜，还会记录你喊了它几次、喊的时候说了什么话，之后你要检查“它是不是被正确调用了”，这是行为验证。

实际编码中的选用很简单：如果你只关心“调用后返回值是否正确”，用 Stub 即可；如果你还关心“这个依赖是否被调用了、调用了几次、参数对不对”，就必须用 Mock。很多框架（如 Mockito、unittest.mock）同时支持两种用法——同一个替身，你只用它的“预设数据”功能时它是 Stub，你用它的“调用断言”功能时它就变成了 Mock。

这与厨房如出一辙：如果只是需要一条“不会坏的鱼”来走流程，让帮厨举着菜牌就行（Stub）；如果你要确认“服务员有没有真的向供应商下单、下了几次”，就得让帮厨记录每一次传话（Mock）。替身的价值是让后厨运转不被外部世界的不确定性卡住。

测试覆盖率

质检员每天会在记录表上打勾：今天检查了 70 种食材，占总食材的 70%。这个数字看起来令人安心，但注意——它只说明“这些食材被看过了”，并不说明“这些食材都是合格的”。软件世界的测试覆盖率（Coverage）同理：它度量的是“测试执行到了多少行代码”，而不是“这段代码里没有 Bug”。

覆盖率最基础的是行覆盖率，即测试执行过的代码行占总代码行的比例。更严格的是分支覆盖率，它统计 if/else、switch 等分支是否都被走到。分支覆盖比行覆盖更接近“逻辑验证”——同样是 10 行代码，可能有的分支永远没被触发，行覆盖却显示 100%。

覆盖率的局限必须认清：一个模块覆盖率 100%，可能只是所有代码行都被“路过”，却没有任何一行被“验证”了正确的行为。比如一个函数内部 if (a > b) 的两条分支都执行了，如果断言写得软弱无力，照样会有 Bug 溜走。所以覆盖率是“体检表”，不是“免死金牌”。它最合理的用法是配合缺陷密度——如果在覆盖率高的模块里 Bug 依旧频发，说明测试质量差，该回头检查断言的有效性了。

质检记录表上打满勾，不代表今晚的宴席一定完美；但一张很少打勾的表，肯定说明品控形同虚设。覆盖率的正确姿势是“把它当温度计，而不是体检报告”——发现低覆盖率区域就去补测，但永远不要为了凑数字而写空断言。

AAA组织规范

后厨最怕混乱的操作台：盐罐找不着、锅铲插在炒锅里、配菜和剩菜混在一起。为此，成熟的厨房会把每个烹饪动作拆成三段：备料——把食材、调料、厨具全部备好；烹饪——开火执行；试味装盘——尝一口、确认味道、端上桌。这套三段式在测试代码里就是 Arrange-Act-Assert，它让每个测试用例的结构都清晰可读。

Arrange（准备）是测试的“备料阶段”：创建被测对象、初始化依赖、设置 Mock 的预期返回值、准备输入数据。这一段是测试的“场景搭建”，决定了测试的故事背景。Act（执行）是“烹饪阶段”：只做一件事——调用被测的方法或函数。这一段通常只有一行代码，如果有超过三行的“执行”动作，说明被测单元的接口设计可能有问题。Assert（断言）是“试味阶段”：验证执行结果是否符合预期，可以是返回值、异常、或者 Mock 的调用行为。

AAA 规范最大的价值是可读性维护。其他工程师在读测试时，先看 Arrange 了解背景，再看 Act 抓住动作，最后看 Assert 明白验收标准——整个测试读起来像一段微型故事的“起因—经过—结果”。反之，如果三者混成一团，测试一挂，你往往要花十分钟才搞明白它在测什么。

操作台的标准三段式，让任何一个帮厨都能快速接手后厨工作；同样，AAA 规范让任何一个新成员都能快速读懂测试意图。这不是风格偏好，而是团队协作的效率基础设施——可读的测试代码，就是可维护的质量资产。

AI 应用场景

Python 演示

import unittestfrom unittest.mock import Mock  def get_discount(user_client, user_id):    # 根据用户信息返回折扣，vip 打 8 折，普通用户不打折    user = user_client.fetch(user_id)    return 0.8 if user["vip"] else 1.0  class TestDiscount(unittest.TestCase):    """演示 Arrange-Act-Assert 结构与 Mock/Stub 的用法"""     def test_vip_discount_with_mock(self):        # Arrange: 准备替身，预设返回数据        mock_client = Mock()        mock_client.fetch.return_value = {"vip": True}         # Act: 执行被测函数        discount = get_discount(mock_client, 1)         # Assert: 断言结果，并验证 mock 行为        self.assertEqual(discount, 0.8)        mock_client.fetch.assert_called_once_with(1)     def test_normal_user_with_stub(self):        # Arrange: 用 stub 返回普通用户数据        stub_client = Mock()        stub_client.fetch.return_value = {"vip": False}         # Act: 执行被测函数        discount = get_discount(stub_client, 2)         # Assert: 只验证状态，不验证调用过程        self.assertEqual(discount, 1.0)  if __name__ == "__main__":    unittest.main(verbosity=2)

1. mock_client = Mock()创建测试替身，隔离 user_client 这个外部依赖，避免连接真实用户服务。
2. mock_client.fetch.return_value = {"vip": True}Stub 的核心用法：预设返回值，让替身“按剧本说话”。
3. discount = get_discount(mock_client, 1)Act 阶段：只调用一次被测函数，保持执行动作单一清晰。
4. self.assertEqual(discount, 0.8)状态验证：断言返回值是否正确。
5. mock_client.fetch.assert_called_once_with(1)Mock 独有的行为验证：确认 fetch 被调用了恰好一次，且参数是 1。
6. unittest.main(verbosity=2)启动测试运行器，verbosity=2 让每个用例的通过/失败信息更详细。

常见误区

面试题