一、黑匣子测试基础

1.1 什么是黑匣子系统集成测试

先说说黑匣子测试。说白了，就是你把系统当成一个不透明的盒子。

你不需要知道里面代码怎么写的，模块怎么连的。你只关心一件事：输入什么，输出什么。

我刚开始带项目时，有个开发同事跟我说：「你测我代码干嘛？我单元测试都过了。」我当时就笑了。单元测试过了，不代表系统能跑起来。你想想看，两个模块各自没问题，一对接就崩，这种事我见过太多次了。

黑匣子系统集成测试，核心就三点：

• 接口验证：A模块发给B模块的数据，B能不能正确解析？
• 功能串联：用户点一个按钮，整个流程能不能走通？
• 外部依赖：数据库、消息队列、第三方API，这些外部系统是不是真的能配合？

举个例子。我之前做一个支付系统，单测都绿了。结果一集成，发现订单模块传给支付模块的金额字段，一个是字符串，一个是整数。嗯，就这么一个小坑，线上差点出事故。

1.2 测试与质量保证的区别

这个问题，我面试时经常问。很多人答不上来。

测试和质量保证，不是一回事。我简单给你拆开讲。

维度	测试（Testing）	质量保证（QA）
目标	发现缺陷	预防缺陷
时机	开发完成后	贯穿整个生命周期
对象	产品本身	流程、规范、标准
手段	执行用例、验证功能	评审、审计、度量
结果	Bug列表	改进建议、流程优化

我打个比方。测试就像质检员，产品做出来了，他一个个检查，有问题的挑出来。质量保证呢？更像是在生产线上装传感器，提前发现哪个环节容易出问题，然后改进流程。

我曾经在一个项目里，测试团队天天加班找Bug，但Bug越找越多。后来我建议他们往前端走一步，参与需求评审和设计评审。结果呢？很多问题在写代码之前就暴露了。这就是质量保证的价值。

1.3 测试金字塔模型

测试金字塔，这概念你应该听过。但我发现很多人只是知道个名字，实际用起来完全走样。

先看经典的三层结构：

        /\
       /  \
      / E2E \
     /--------\
    / 集成测试  \
   /--------------\
  /   单元测试     \
 /--------------------\

从上到下：

• 顶层（E2E测试）：数量最少，跑得最慢，维护成本最高。但最贴近用户真实操作。
• 中间层（集成测试）：验证模块间的交互。数量适中，性价比高。
• 底层（单元测试）：数量最多，跑得最快，定位问题最精准。

我见过最离谱的项目，测试金字塔是倒过来的。E2E测试写了一堆，单元测试几乎没有。每次跑回归测试，全组人等两个小时。而且E2E一挂，根本不知道是哪个模块的问题。

为什么会这样？说白了，很多人觉得写单元测试麻烦，不如直接跑界面。但你想过没有，一个E2E用例的执行时间，够你跑几百个单元测试了。

我个人习惯的配比是这样的：

• 单元测试：70%
• 集成测试：20%
• E2E测试：10%

当然，这个比例不是死的。如果你的系统对外部依赖特别多，集成测试的比例可以适当提高。但底层逻辑不变：越底层的测试，越要多写。

嗯，这里要注意一点。测试金字塔不是让你只写单元测试。集成测试和E2E测试同样重要。只是说，你的投入比例要合理。别把鸡蛋都放在一个篮子里。