企业官网建设流程全解析

做测试这行的人，几乎都会被新人问过一个同样的问题：黑盒测试和白盒测试到底是什么，区别在哪，我该学哪个。这问题看着基础，实际上真要掰扯清楚，得从测试目标、介入时机、技能栈、工具链一路讲到硬件层面的信号验证，绝不是背两句定义就能糊弄过去的。我见过不少团队把这两个概念混着用，结果需求评审会上测试同学说"这个功能我们黑盒覆盖了"，开发同学回一句"那底层逻辑谁验的"，会议直接卡壳。

这篇东西我打算把黑盒测试、白盒测试这两条线从头到尾拆一遍，包括它们各自的定义、设计方法、落地步骤、代码和硬件层面的实操，以及最关键的——什么时候该用哪个，怎么搭配着用。适合刚入行想建立完整测试认知的朋友，也适合做了几年测试但一直偏科、想补齐另一块的老手。尤其是做汽车电子、嵌入式方向的同学，"can硬件白盒测试规范"这块内容你大概率用得上，我会单独拎出来讲。

1. 先把概念说透：黑盒测试和白盒测试到底在测什么

1.1 从两个真实的测试场景说起

先别急着背定义，看两个场景。场景一：你拿到一个登录页面，输入手机号和验证码，点击登录，看能不能进系统。你完全不知道后端是用什么语言写的、数据库怎么存的、验证码是怎么校验的，你只关心"输进去的东西"和"吐出来的结果"对不对。这就是黑盒测试的典型姿态——把被测对象当成一个不透明的盒子，只看输入输出。

场景二：开发提交了一段订单金额计算代码，你打开源码，发现里面有个if (amount > 1000)走折扣分支，另一个else走原价分支。你想验证的是：这两条分支是不是都被跑到过，边界值 1000 走的哪条路，有没有哪条分支因为条件写错永远进不去。这时候你看的是盒子内部的结构、逻辑和路径，这就是白盒测试。

两个场景的差别不在于"测试做得好不好"，而在于测试的立足点完全不同。黑盒站在外部行为的角度，白盒站在内部实现的角度。这个立足点一旦确定，后面所有的用例设计方法、工具选型、验证重点都会跟着变。

1.2 黑盒测试：站在用户视角看结果

黑盒测试的核心定义可以浓缩成一句话：在不考虑程序内部结构和实现细节的前提下，通过输入数据观察输出结果，来验证功能是否符合需求。它还有个名字叫功能测试或者基于规格说明的测试，这个叫法其实更贴切，因为它的依据就是需求文档、接口文档、产品原型这些东西。

黑盒测试关注的永远是"应该做什么"，而不是"怎么做的"。需求说登录失败要提示"账号或密码错误"，那黑盒就验证这条提示；需求说单笔转账上限五万，那黑盒就盯着四万九、五万、五万零一这三个数字。至于后端是用什么算法做的校验、有没有加缓存、SQL 写得优不优雅，黑盒一概不管。

这种"不管内部"的特性带来两个直接好处。第一，测试人员和开发人员可以是完全两拨人，甚至测试人员不需要懂编程，业务方、产品经理、真实用户都能参与进来，视角天然贴近实际使用。第二，黑盒测试不容易被实现细节带偏，开发写错了逻辑，黑盒照样能发现，因为它是拿需求对照结果，而不是拿代码对照代码。

代价也很明显。黑盒测试无法保证代码内部的每条路径都被走到，可能出现"功能测起来都对，但某个异常分支里藏着空指针"的情况。而且当用例设计得不好时，黑盒测试很容易变成"点一遍功能就算完"，覆盖率全靠测试人员的经验和责任心，缺少量化的抓手。

1.3 白盒测试：把内部结构摊开来看

白盒测试的定义是：基于程序内部逻辑结构，设计用例来验证每条路径、每个分支、每个条件是否按预期工作。它又被称为结构测试或逻辑驱动测试。名字里的"白盒"就是透明盒子的意思——内部逻辑对测试者是可见的。

白盒测试关注的是"怎么做的"，以及"做的方式对不对"。它要回答的问题包括：这段代码有没有死代码（永远执行不到）、有没有逻辑冗余、循环边界处理对不对、异常路径有没有兜底、条件组合是不是都考虑到了。这些问题光靠黑盒从外部输入输出是看不出来的，必须深入代码内部。

白盒测试最适合的介入时机是单元测试阶段，也就是开发写完一个函数、一个模块的时候。这个阶段代码是新鲜的，开发自己也最清楚逻辑，顺手把分支覆盖做了，成本最低。等到系统集成完了再回头补白盒，等于把地基拆了重砌，怎么算都不划算。

需要提前说明一点：白盒测试并不等于"只有写代码的人才能做"。静态代码审查、逻辑覆盖分析这些工作，测试人员只要具备一定的代码阅读能力就能参与。真正门槛高的是自动化白盒测试脚本的编写，那确实需要开发或懂开发的测试来承担。所以别被"白盒=开发专属"这种说法劝退，能读代码就已经跨过一半门槛了。

1.4 一张对照表把差异摊平

光靠文字描述容易记混，我整理了一张对照表，把两个概念的关键维度摆在一起对比。这张表建议存下来，以后跟人解释的时候直接甩过去，比说十分钟都管用。

看这张表你会发现，两者根本不存在谁替代谁的关系。黑盒负责回答"做对了没有"，白盒负责回答"做全了没有"，一个管需求符合性，一个管实现完备性。真正成熟的项目，两条线是同时推进的，只不过不同阶段的侧重点不一样。

2. 黑盒测试的落地打法：用例怎么设计才不白干

2.1 等价类划分与边界值：性价比最高的两个方法

黑盒测试用例设计的方法有一大堆，但如果你时间有限，只能掌握两个，那就选等价类划分和边界值分析，这两个方法的投入产出比高得离谱。

等价类划分的思路是把输入域切成若干"等价"的区间，每个区间里挑一个代表值来测就够了，因为系统对同一区间内所有值的处理逻辑是一样的。比如一个输入框要求填年龄，有效范围 18 到 60，那有效等价类就是 18 到 60 这个区间，你随便挑个 30 测一下；无效等价类有两个，小于 18 一个，大于 60 一个，各挑个代表值。这样三个用例就把整个输入域的心理覆盖做完了，不用从 1 测到 100。

边界值分析则是盯着区间的边界做文章，因为绝大多数 bug 都藏在边界上。程序员写判断时最容易犯的错就是<和<=搞混，或者循环少跑一次多跑一次。对 18 到 60 这个范围，边界值一般取上点、内点、离点：18、19、30、59、60，再加上刚好越界的 17 和 61。实测下来，边界值用例能抓出的 bug 数量往往占整个功能测试的很大比例。

我个人的习惯是把这两个方法绑在一起用：先用等价类把输入域切成几块，再对每一块的边界补上边界值用例。一个输入框大概能设计出六到八个用例，覆盖质量比"随便点几下"高太多，而且写用例的时候有章可循，不会漏。

输入：年龄（有效 18-60） 有效等价类：18 <= age <= 60 无效等价类：age < 18，age > 60 边界值用例： - 17（无效下边界外） - 18（有效下边界） - 19（有效内点） - 59（有效内点） - 60（有效上边界） - 61（无效上边界外）

2.2 判定表、场景法与正交试验：复杂逻辑的拆解

当功能不是单个输入框，而是"多个条件组合决定一个结果"的时候，等价类和边界值就不够用了，得上判定表。判定表的好处是把所有条件组合和对应动作列成一张矩阵，哪条规则被漏掉了、哪两条规则冲突了，一眼就能看出来。

举个生活化的例子。一个电商优惠规则：用户是会员，且订单满 200，且使用优惠券，三个条件同时成立才打八折。三个条件各两种取值，组合起来就是 2 的 3 次方等于 8 种情况。判定表会把这 8 种全列出来，标明每种情况下打不打折。有了这张表，用例设计就不会凭感觉，一条条对着写就行。

场景法适合有明确业务流程的功能，比如"下单-支付-发货-收货-评价"这种链路。它的做法是先把基本流（一切顺利的主流程）走通，再针对每条备选流（支付超时、库存不足、地址无效等分支）单独设计用例。场景法的价值在于它是以用户的实际使用路径为线索，能把跨模块的联动问题带出来，这是单点功能测试做不到的。

正交试验法用在参数多、组合爆炸的场景。假设一个功能有 4 个参数，每个参数 3 种取值，全排列是 81 种用例，跑一遍要人命。正交表能把这 81 种压缩到 9 种左右，还能保证任意两个参数的取值组合都被覆盖到至少一次。工具方面，老牌的 PICT、Allpairs 都能自动生成正交用例，输入参数和取值范围，输出用例表，省事。

2.3 实操走一遍：给一个登录接口设计黑盒用例

理论说再多不如走一遍。假设有个登录接口POST /api/login，入参是手机号和密码，规则是：手机号必须是 11 位数字且以 1 开头，密码长度 6 到 20 位，两者都正确才返回登录成功。

第一步，用等价类划分拆输入。手机号的有效等价类是"11 位、以 1 开头"，无效等价类包括"非数字字符"、"位数不足 11"、"位数超过 11"、"不以 1 开头"。密码的有效等价类是"6 到 20 位"，无效等价类是"少于 6 位"、"多于 20 位"、"包含非法字符"。

第二步，用边界值补刀。手机号取 11 位（边界内）和 10 位、12 位（边界外）；密码取 6 位、20 位（有效边界）和 5 位、21 位（无效边界）。

第三步，组合成用例。这里要注意一个技巧：设计用例时尽量让每个用例只针对一个无效条件，其他输入保持有效，这样才能定位问题来源。如果一条用例里塞了好几个无效输入，测试失败了都不知道是哪个条件触发的。

用例编号 | 手机号 | 密码 | 预期结果 TC-01 | 13800000000 | abc123 | 登录成功 TC-02 | 1380000000 | abc123 | 提示手机号格式错误 TC-03 | 138000000000 | abc123 | 提示手机号格式错误 TC-04 | 23800000000 | abc123 | 提示手机号格式错误 TC-05 | 13800000000 | abc12 | 提示密码长度不符 TC-06 | 13800000000 | abc12345678901234567890 | 提示密码长度不符 TC-07 | 13800000000 | 正确密码 | 登录成功，返回 token TC-08 | 13800000000 | 错误密码 | 提示账号或密码错误

这套用例设计下来大概十条左右，覆盖了格式校验、长度校验、正确路径、错误路径。你会发现它没有任何投机取巧的地方，全是按方法推导出来的，谁来做结果都一样。这就是方法的价值——把测试从"凭经验"变成"可复现"。

2.4 黑盒测试的注意事项与踩坑记录

黑盒测试看起来门槛低，但有几个坑我踩过不止一次，说出来给大家避避。

第一个坑，只测有效路径。很多新人拿到需求，习惯性地按正常流程点一遍，通了就认为测完了。实际上异常路径才是 bug 重灾区。输入非法字符、网络中断、并发请求、数据为空，这些场景必须专门设计用例。

第二个坑，把界面元素当成测试对象。比如验证一个列表，只看页面显示了 10 条数据就通过了。但数据对不对、排序对不对、翻页后数据有没有重复，这些才是核心。界面只是数据的呈现方式，测的是数据本身。

第三个坑，用例写完不复用。黑盒用例是资产，不是一次性消耗品。版本迭代后，把旧用例拿出来回归，比每次重新设计高效得多。建议用带标签的用例管理系统，把用例按模块、按优先级组织好。

注意：黑盒测试的"黑"是指测试者对内部实现不关心，不代表测试者是瞎子。对业务规则理解得越深，设计出的用例质量越高。别把黑盒当成"不懂技术也能做"的借口。

3. 白盒测试的落地打法：从代码覆盖到硬件信号

3.1 逻辑覆盖的六个等级，别只盯着语句覆盖

白盒测试里最核心的概念是逻辑覆盖，它按严格程度从低到高分成六个等级。很多人一提高覆盖率就以为是在说行覆盖，其实那只是最低的一档。

语句覆盖是最弱的，要求代码里每条可执行语句至少执行一次。它的问题在于照顾不到条件分支，比如if (a && b)，只要让这个 if 为真跑进去，语句覆盖就满了，但 b 为假的情况压根没验到。

判定覆盖要求每个判定（if、while 这些）的真假两个结果都至少出现一次。条件覆盖则是要求判定里每个条件的真假都要出现一次。两者经常打架：满足了条件覆盖不一定满足判定覆盖。所以有了判定/条件覆盖，要求同时满足两者。

再往上走是条件组合覆盖，要求每个判定里所有条件的取值组合都至少出现一次。最后是路径覆盖，要求程序中所有可能的执行路径都被走到。路径覆盖最彻底，但代价也最高——一个稍微复杂的函数，路径数量会指数级膨胀，实际项目里很难完全做到。

实操中的建议是：单元测试阶段至少做到判定覆盖，核心业务逻辑争取做到条件组合覆盖，路径覆盖交给静态分析工具去辅助识别风险路径，不必强求 100%。

圈复杂度是衡量路径数量的一个实用指标，公式是V(G) = 判定节点数 + 1，也可以写成V(G) = 边数 - 节点数 + 2。圈复杂度等于几，就说明这个函数理论上独立路径有几条，也基本决定了你需要写几条测试用例才能覆盖完整。经验值上，圈复杂度超过 10 的函数就该考虑重构了。

3.2 静态分析和动态分析各自管什么

白盒测试按是否运行代码，分成静态分析和动态分析两大类，这个区分很重要，很多人混着说。

静态分析不运行程序，直接对着源代码或者中间产物做检查。手法包括代码走查、结对审查、静态扫描工具分析。静态检查能发现的问题包括：未使用的变量、潜在的空指针、数组越界风险、资源未释放、编码规范问题。工具方面，Java 生态有 SonarQube、SpotBugs、Checkstyle，C/C++ 有 Cppcheck、Coverity，Python 有 Pylint、Flake8。这类工具接进 CI 流水线，每次提交自动跑一遍，能在代码合并前挡掉一批低级问题。

动态分析是把程序跑起来，通过插桩、埋点、覆盖率统计来观察实际执行情况。单元测试配合覆盖率工具就是典型的动态分析。它能告诉你"哪些代码真的被执行了"，这是静态分析做不到的。静态分析能识别"可能有问题"，动态分析能确认"确实跑到了"。

两者谁也不能替代谁。一个常见误区是接了个 SonarQube 就以为白盒测试做到位了，其实那只是静态的一部分，动态的覆盖率验证完全没做。反过来，覆盖率 100% 也不代表没问题，因为覆盖率只说明代码被执行过，不说明执行结果对不对，这就是所谓"高覆盖率陷阱"。

3.3 代码白盒实操：覆盖率统计怎么跑

光讲概念太空，直接上一个能跑的 Python 例子。假设有个除法函数，要求除数为 0 时抛异常。

# calc.py def divide(a, b): if b == 0: raise ValueError("除数不能为0") return a / b

给它写单元测试，用 pytest 框架：

# test_calc.py import pytest from calc import divide def test_divide_normal(): assert divide(6, 3) == 2 def test_divide_zero(): with pytest.raises(ValueError): divide(1, 0)

跑覆盖率统计，命令是：

pip install pytest pytest-cov pytest --cov=calc --cov-report=term-missing

输出会告诉你每条语句有没有被覆盖，哪些行没跑到（term-missing 会把漏掉的行号打出来）。第一次跑的时候如果只写了test_divide_normal，你会看到覆盖报告里raise ValueError那行标红，提示这个分支没被覆盖。补上test_divide_zero之后，覆盖率才到 100%。

这个例子的意义在于让你体会到：覆盖率不是一个数字，而是一面镜子，它明确告诉你哪条路径还没验。C/C++ 项目可以用 gcov 配合 lcov 生成可视化报告，Java 项目用 JaCoCo，前端 JavaScript 用 Istanbul 或者 nyc，思路都是一样的。

接入 CI 之后，可以设置覆盖率门槛，比如"新增代码覆盖率低于 80% 直接构建失败"。这个门槛别定太高，90% 以上的强制要求经常逼得开发写一堆无意义的断言去凑数，反而降低测试质量。

# 在 pytest.ini 或命令行里加覆盖率门槛 pytest --cov=calc --cov-fail-under=80

3.4 CAN硬件白盒测试规范要点拆解

做汽车电子和嵌入式方向的同学，接触到的白盒测试往往不只在代码层面，还要下沉到硬件信号层面，这就是"can硬件白盒测试规范"要解决的问题。CAN 总线作为车载和工业控制里最常用的通信总线之一，它的硬件测试有自己的一套逻辑。

先说清楚为什么 CAN 总线要做硬件白盒测试。代码层面的测试只能验证通信协议栈的逻辑对不对，但实际信号在物理线上传输时会不会失真、电平幅度够不够、时序对不对、终端电阻匹配不匹配，这些是代码测不出来的。硬件白盒测试就是拿示波器、CAN 分析仪这些设备，直接观察总线上的电信号，把物理层的问题挖出来。

第一块是电平参数验证。CAN 总线是差分信号，CAN_H 和 CAN_L 两条线，显性位时两者压差大约 2V，隐性位时压差接近 0V。测试时要验证实际测得的差分电压是不是落在这个范围内。如果显性电平幅度不够，接收节点就可能误判成隐性位，造成通信错误。这里要注意测量点要选在总线末端，因为总线中间和末端测出来的波形不一样。

第二块是终端电阻验证。标准 CAN 总线两端各有一个 120 欧姆的终端电阻，并联之后总线上的等效阻抗应该是 60 欧姆左右。用万用表断电测总线两端电阻，如果测出来是 120 欧姆，说明有一端电阻缺失；如果是 40 欧姆，说明有节点多接了一个电阻。终端电阻不对会导致信号反射，波形上会出现振铃和过冲，通信距离一长就各种报错。这个坑在样车调试阶段特别常见，很多时候通信不稳定不是软件问题，是终端电阻没配好。

第三块是位时序和采样点验证。CAN 的每一位被分成同步段、传播段、相位缓冲段，采样点通常建议设在 75% 到 87.5% 之间。采样点设得太靠前，遇到信号传播延迟大的时候会采错；设得太靠后，抗干扰能力变差。测试方法是用示波器抓一位波形，测量采样点位置相对位宽的比例。不同节点如果采样点设置不一致，长总线上就容易出问题。

第四块是故障注入测试，这是硬件白盒里最能暴露问题的部分。要人为制造总线故障，看系统能不能正确处理。常见的注入场景包括：CAN_H 对地短路、CAN_H 对电源短路、CAN_H 和 CAN_L 短接、总线断路、终端电阻断开。每注入一种故障，观察系统是否进入总线关闭状态、是否有错误帧、恢复后能不能自动重连。这套测试在整车厂的网络管理规范里是必测项，早期不做，到了实车阶段再发现，排查成本翻好几倍。

做这块测试有几个实操心得。测波形的时候一定要用差分探头，别用两个单端探头去减，那样测出来的共模干扰很大，波形没法看。故障注入测试要在记录仪全程录像的情况下做，因为有些故障现象是偶发的，事后靠回忆根本说不清当时什么状态。还有就是测试顺序上先做无故障基准测试，记录一份正常的波形和报文做参考，后面出问题时好对比。

3.5 白盒测试的注意事项

白盒测试有几个容易走偏的地方。

第一，别为了覆盖率而覆盖率。见过团队为了把覆盖率刷到 95%，写一堆assert result is not None这种无效断言，覆盖率上去了，实际缺陷一个没发现。覆盖率是手段不是目的，关注点是"漏掉的那几行是不是有风险"，而不是那个百分比数字。

第二，白盒测试用例要跟代码同步维护。代码改了，原来针对旧逻辑写的白盒用例可能就失效了，甚至变成误导。建议把白盒测试纳入代码评审范围，改逻辑的时候一起改测试。

第三，硬件白盒测试要注意安全。故障注入尤其是短路类的测试，操作不当可能烧毁板子。做这类测试前先确认测试板不是关键样件，接线要断电操作，注入设备要有过流保护。

注意：白盒测试发现的问题往往比黑盒更隐蔽，因为它看的是"这条路径根本没被执行过"。一个条件写反了，黑盒可能因为恰好有别的逻辑兜底而测不出来，白盒一眼就能看到那个永远为假的分支。

4. 黑盒白盒不是二选一：测试策略怎么组合

4.1 测试金字塔与投入配比

测试圈有个经典的模型叫测试金字塔，它把测试分成三层：底层是单元测试，中间是集成测试，顶层是端到端测试。这个模型的核心观点是——越往底层测试，成本越低、速度越快、定位问题越准，所以底层应该占比最大。

把黑盒白盒映射到这个模型上就很清楚了：单元测试阶段白盒为主黑盒为辅，开发用单元测试框架直接验证函数逻辑，跑覆盖率；集成测试阶段两者混用，既验证模块间接口的功能正确性（黑盒），也验证数据在不同模块流转时内部状态对不对（白盒）；系统测试和验收测试阶段基本是黑盒的天下，站在用户角度验证整体功能。至于 CAN 硬件层面的白盒测试，它属于更底层的物理层验证，是金字塔最底下的地基。

现实中的情况往往是倒过来的——很多团队重手工黑盒、轻自动化单元测试，测试金字塔变成了"测试冰淇淋"，头重脚轻。这种结构下问题定位慢、回归效率低，上线前通宵测是常态。合理的配比大致是：单元测试占比 60% 到 70%，集成测试 20% 到 30%，端到端测试控制在 10% 以内。

4.2 不同阶段该用哪种

光说比例还不够，得说清楚每个阶段具体怎么用。

需求分析阶段，黑盒测试就该介入了。测试人员参与需求评审，从用户视角提出可测试性的意见。比如需求里写"系统要快速响应"，这没法测，要追问"快速是几百毫秒"，把它变成可量化的验收标准。这个阶段白盒还没什么可做的，代码还没影。

编码阶段是白盒的主场。开发每写完一个模块就跑单元测试，覆盖率和静态扫描一起上。有条件的话让测试人员参与代码评审，从测试角度看看有没有难覆盖的逻辑。这个阶段黑盒基本缺席，因为功能还没集成起来。

集成测试阶段两条线并行。黑盒负责接口联调、数据一致性、异常传递这些跨模块问题；白盒负责看数据流转过程中关键对象的状态变化对不对。

系统测试和回归阶段以黑盒为主。全链路走一遍业务流程，各种边界、异常、兼容性场景集中验证。白盒这时候更多是辅助定位——出了 bug，用调试手段深入内部找根因。

上线后的问题排查阶段，白盒思维反而更重要。线上出了偶发问题，光靠黑盒复现困难，得结合日志、埋点、断点调试去分析内部执行路径。

4.3 常见误区

最后一个误区要说清楚。很多人以为"黑盒测试比白盒测试简单"，所以新人只能做黑盒，白盒是高级技能。这个说法不完全对。

从技能门槛看，写自动化白盒测试确实需要编程能力，门槛更高。但设计高质量的黑盒用例同样需要深厚的功底，判断哪些场景最关键、哪些边界最容易被忽略、哪些组合覆盖最有效，这些靠的是业务理解和测试思维，不是会写代码就能解决的。我见过代码能力很强的人，黑盒用例设计得一塌糊涂，边界值全漏。

真正成熟的测试人员是两条线都能拿起来的：能用白盒手段确认内部实现的可信度，也能用黑盒手段确认外部行为的正确性，还能在两者之间做取舍——这个功能该多花精力在白盒还是黑盒上，取决于它的风险等级和改动频率。

5. 常见问题与排查技巧实录

5.1 问题速查表

实际干活的时候，下面这些问题出现频率很高，我整理成表，遇到的时候直接对号入座。

5.2 几个压箱底的技巧

干了这么多年，有几条经验是文档里不会写、但实际特别管用的。

第一条，黑盒用例设计完后，让另一个不熟悉这个功能的人照着用例执行。如果他能顺畅跑完不用问你，说明用例写得清楚可复现；如果他到处卡壳，说明用例里藏着你自己懂但没写出来的隐含条件。这个"交叉执行"的方法能有效提升用例质量。

第二条，白盒测试别一上来就追求高覆盖率。新项目初期代码变动频繁，这时候写大量细粒度单元测试，改一次需求就要改一片测试，得不偿失。等接口稳定了、核心逻辑定型了，再集中补白盒测试。对易变的业务逻辑，用黑盒加集成测试兜住反而更划算。

第三条，做 CAN 硬件测试时，准备一份"标准波形库"。把各种正常工况下的波形截图存档，包括不同波特率、不同负载率、不同线长下的波形。后来出问题时，拿现场波形跟标准波形一对比，往往几分钟就能定位是电平问题还是时序问题还是干扰问题，比从头分析快得多。

第四条，把黑盒和白盒的发现关联起来。黑盒发现的每个 bug，都追问一句"为什么白盒没提前发现"。如果是因为没有对应的单元测试，那就补上；如果是设计时就没想到这个场景，那就完善需求。这样一次排查能同时改进两条线的测试能力。

第五条，覆盖率数据要按变更看，别只看总量。一个百万行的老项目，整体覆盖率 60% 可能已经很健康；但这次提交改的那 50 行，覆盖率必须是接近 100%。很多覆盖率工具支持 diff coverage 或者变更覆盖率统计，把门槛卡在新代码上，老代码慢慢补，这样既不阻塞迭代又能持续改善。

我个人的体会是，黑盒和白盒这两个词说起来简单，真正把它们用顺了，需要一个项目接着一个项目地磨。刚开始你可能纠结"这个用例算黑盒还是白盒"，做着做着就会发现，纠结分类本身意义不大，重要的是你手里有没有足够多的手段去发现问题，以及知不知道什么时候该用哪一招。测试这行的核心竞争力从来不是"我会用某个工具"，而是"面对一个系统，我知道它最可能在哪里出问题，并且有办法把它揪出来"。