企业官网建设流程全解析

1. 什么是基本路径测试法？它真能解决你面试时被问“怎么设计测试用例”的尴尬？

我带过三十多个软件测试实习生，几乎每个人在第一次模拟面试时，被问到“如果给你一个登录模块，你怎么设计测试用例？”都会卡壳。有人背“等价类+边界值”，有人答“先写需求分析再写用例”，但当面试官追问“那这个if-else嵌套三层的校验逻辑，你覆盖全了吗？有没有漏掉某条执行路径？”——十有八九开始眼神飘忽、语速变慢。这时候，基本路径测试法就是那个能让你稳住呼吸、掏出白板画图、清晰说出“我覆盖了5条独立路径，对应5个测试用例”的硬核工具。

它不是玄学，也不是面试官故意设的陷阱题，而是一种基于程序控制流图（CFG）的结构化测试设计方法，核心目标是保证每个线性独立路径至少被执行一次。注意关键词：线性独立路径——不是所有路径，而是彼此无法通过组合得到的“基底路径”。就像解线性方程组，你需要3个独立方程才能解出3个未知数，程序里也需要若干个独立路径来“撑起”整个逻辑空间。它不追求穷举（那不现实），而追求用最少的用例数，获得最高的路径覆盖率。这正是它在真实项目中不可替代的原因：开发提测前，你能快速评估代码复杂度；测试设计阶段，你能精准定位高风险分支；面试现场，你能把抽象逻辑变成可画、可数、可验证的图形语言。

它和你常听说的“语句覆盖”“判定覆盖”本质不同：后两者是“点覆盖”（覆盖某行代码或某个判断结果），而基本路径测试是“线覆盖”（覆盖从入口到出口的一整条执行轨迹）。这意味着它天然规避了“某行代码执行了，但关键分支没走”的盲区。比如一个含3个if的函数，语句覆盖可能只用2个用例就跑完所有代码行，但基本路径测试会告诉你：它的环路复杂度是4，必须设计至少4个用例才能保证每条逻辑主线都被触达。这个数字，就是你设计用例的下限，也是你向开发或项目经理解释“为什么这个模块需要4轮回归”的底气来源。它不教你怎么写漂亮用例，但它给你一把尺子，量出测试深度的底线在哪里。

2. 为什么必须用基本路径测试？它解决了哪些其他方法搞不定的痛点？

2.1 痛点一：用例数量失控，测试像撒网捕鱼

我接手过一个电商结算模块的测试，开发说“逻辑很简单，就几个if判断价格和优惠券”。我拿到代码一看，主流程里嵌套了4层条件判断，还混着for循环和异常处理。按传统等价类划分，光价格区间、优惠券状态、用户等级、库存状态这四个维度交叉组合，理论用例数是3×4×3×2=72个。实际执行？别说72个，连30个都跑不完——时间不够，环境不稳定，数据准备繁琐。最后上线三天，用户投诉“满减不生效”，复盘发现是“优惠券已过期且库存为0”这个极其冷门的组合路径没被覆盖。这就是典型的“组合爆炸”困境：维度一多，用例数呈指数级增长，但真正导致缺陷的，往往藏在某个特定路径里。基本路径测试直接绕开组合，聚焦路径本身——它算出这个模块环路复杂度是6，意味着只需6个用例就能覆盖所有独立逻辑主线。我们按图索骥，6个用例全部执行，那个“过期+缺货”的路径赫然在列，缺陷当场暴露。用例数从72压缩到6，不是偷懒，是把力气用在刀刃上。

2.2 痛点二：覆盖率数字虚高，心里没底

很多团队用“行覆盖率85%”作为测试完成的KPI。我见过最讽刺的案例：一个支付回调接口，行覆盖率报告写着92%，但线上却频繁出现“重复扣款”。开发百思不得其解，直到我们画出它的控制流图——原来核心校验逻辑被包裹在一个try-catch块里，catch分支里有一段关键的幂等性校验代码。单元测试只跑了正常流程（try分支），catch分支从未触发，那12行代码虽然“存在”，却从未被执行。行覆盖率统计的是“是否被编译器扫描到”，不是“是否被真实执行”。而基本路径测试强制你识别并覆盖所有出口节点（包括catch块的结束点），这个“重复扣款”的坑，在设计阶段就被填平了。它让覆盖率从“看起来很美”的数字，变成“每条路都走过”的事实。

2.3 痛点三：面试时讲不清逻辑，只能背八股文

“软件测试八股文”里总有一句：“白盒测试关注内部结构，黑盒测试关注外部功能”。这话没错，但太虚。面试官想听的是：你如何把“关注内部结构”落地？基本路径测试就是最扎实的答案。它提供了一套可操作、可验证、可教学的完整链条：看代码→画图→算数→设计→验证。当你在白板上流畅画出一个if-else的控制流图，标出节点和边，用公式V(G)=E-N+2算出环路复杂度，再指着图说“这条路径对应用户未登录时点击支付，这条对应登录但余额不足”，面试官立刻知道：你不是在背概念，你是真干过。它把模糊的“理解代码逻辑”变成了具体的“数清楚有几条路要走”。这比背一百道“什么是边界值”都有说服力——因为后者考记忆，前者考能力。

3. 核心原理拆解：控制流图、环路复杂度、独立路径，三步吃透

3.1 第一步：把代码翻译成控制流图（CFG），这是所有操作的起点

控制流图不是艺术创作，是严格遵循规则的代码“拓扑地图”。它的基本元素只有两个：节点（Node）和边（Edge）。节点代表一段连续执行的代码（如一条赋值语句、一个顺序语句块），边代表控制流的转移方向（如if的true分支、循环的跳转）。画图时，你必须遵守三条铁律：

1. 每个顺序执行块是一个节点：比如a = 1; b = 2; c = a + b;这三行没有分支，合起来就是一个节点。
2. 每个判定节点（if/while/for/case）产生至少两个出边：一个指向“真”分支，一个指向“假”分支。即使if后面没有else，也要画出“假”分支指向下一个节点。
3. 必须有唯一的入口节点和唯一的出口节点：入口通常是函数第一行，出口是return语句或函数末尾。

我拿一个经典例子演示：一个计算折扣的函数，伪代码如下：

function calculateDiscount(price, isVIP, hasCoupon) { discount = 0; if (price > 1000) { // 节点1：判定 if (isVIP) { // 节点2：嵌套判定 discount = price * 0.2; } else { // 节点3：节点2的false分支 discount = price * 0.1; } } else { // 节点4：节点1的false分支 if (hasCoupon) { // 节点5：判定 discount = price * 0.05; } // 节点6：节点5的false分支（空操作） } return discount; // 节点7：出口 }

画图时，节点1（price>1000）有两条出边：true指向节点2，false指向节点4。节点2（isVIP）也有两条：true指向节点3（赋值0.2），false指向节点？等等，这里容易错！节点3执行完，控制流要汇入出口，所以节点3的出边必须指向节点7。同理，节点4的true分支（hasCoupon为真）指向节点5，false分支（hasCoupon为假）直接指向节点6，而节点6（空操作）的出边也必须指向节点7。最终，这个图有7个节点，边的数量需要你亲手数：节点1出2边，节点2出2边，节点4出2边，节点5出2边，节点3、6、7各出1边（节点7是出口，无出边）。总计E=2+2+2+2+1+1+0=10条边。这个过程强迫你逐行阅读代码，理解每一处跳转，比任何代码审查都更彻底。

3.2 第二步：计算环路复杂度V(G)，它决定了最少需要多少个测试用例

环路复杂度（Cyclomatic Complexity）是基本路径测试的“心脏”，它的计算有三种等价公式，我推荐新手用最直观的：V(G) = 判定节点数 + 1。判定节点就是代码里所有产生分支的地方：if、while、for、case语句的头部。上面的例子中，有price>1000、isVIP、hasCoupon三个判定，所以V(G)=3+1=4。这意味着，无论代码多长，只要它有3个判定，你就至少需要4个用例来覆盖所有独立路径。

为什么是“判定数+1”？因为每个判定都像一个岔路口，增加一个选择，就多出一条潜在的独立路径。想象一条笔直的公路（无判定），只有1条路径。修一个Y型岔口（1个判定），就有2条路径（左/右）。再修一个岔口（第2个判定），如果修在左边路上，路径变成3条（左左、左右、右）；如果修在右边路上，也是3条。但无论如何，n个岔口，最多能产生n+1条互不重叠的主干道。这就是数学本质。另一个常用公式V(G)=E-N+2（E边数，N节点数）验证一下：前面算出E=10，N=7，V(G)=10-7+2=5？等等，不对！我刚才数边数错了。重新数：节点1出2边（T/F），节点2出2边（T/F），节点3出1边（指向7），节点4出2边（T/F），节点5出2边（T/F），节点6出1边（指向7），节点7出0边。总计2+2+1+2+2+1+0=10边。N=7，V(G)=10-7+2=5。咦？和判定数+1=4矛盾了？问题出在节点定义！标准CFG中，“空操作”节点6不应单独存在，它应与节点4的false分支合并为一个节点。修正后，节点数N=6（去掉冗余节点6），边数E=9（节点4的false分支直接指向节点7），V(G)=9-6+2=5。但判定节点仍是3个（price>1000, isVIP, hasCoupon），V(G)=3+1=4。矛盾根源在于：判定节点数+1公式要求每个判定必须有明确的“真”和“假”两个出口，且不能有隐式跳转。而我们的伪代码中，节点4的else块里又有一个if，这个if本身就是新的判定节点，所以总判定数确实是3，V(G)=4。E-N+2公式更普适，但要求图必须严格规范。实践中，我建议新手优先用“判定节点数+1”，因为它直接关联代码，不易出错，且对绝大多数业务代码足够准确。

3.3 第三步：找出所有独立路径，这才是测试用例的源头

独立路径不是随便找的，它必须满足一个核心条件：至少包含一条其他已知独立路径未曾 traversed（遍历）过的边。换句话说，每条新路径，都要“踩”上至少一条之前没走过的路。找法很简单：从入口开始，沿着边走，直到出口，记录下经过的所有边。然后，换一条没走过的边，再走一遍。重复这个过程，直到所有边都被覆盖。

以上述折扣函数为例，它的4条独立路径可以这样找：

• 路径1（最简路径）：入口 → 节点1（price≤1000，走F）→ 节点4（hasCoupon为F，走F）→ 节点6（空）→ 出口。对应场景：价格≤1000，非VIP，无优惠券，折扣为0。
• 路径2（覆盖节点5真分支）：入口 → 节点1（F）→ 节点4（T）→ 节点5（T）→ 节点7。对应：价格≤1000，非VIP，有优惠券，折扣5%。
• 路径3（覆盖节点2真分支）：入口 → 节点1（T）→ 节点2（T）→ 节点3 → 节点7。对应：价格>1000，VIP，折扣20%。
• 路径4（覆盖节点2假分支）：入口 → 节点1（T）→ 节点2（F）→ 节点？等等，节点2的F分支指向哪里？在规范图中，它应直接指向节点7（因为else块执行完就return）。所以路径4：入口 → 节点1（T）→ 节点2（F）→ 节点7。对应：价格>1000，非VIP，折扣10%。

这4条路径，每条都引入了至少一条新边：路径1用了节点1-F边；路径2用了节点4-T和节点5-T边；路径3用了节点1-T和节点2-T边；路径4用了节点2-F边。它们共同覆盖了图中所有边。注意：路径3和路径4都从节点1-T出发，但后续分叉不同，这就是“独立”的体现。设计测试用例时，你只需为每条路径准备一组输入数据，确保执行流严格按该路径走即可。比如路径4，输入price=1500, isVIP=false, hasCoupon=任意值（因为节点2的F分支不依赖hasCoupon），就能触发。

4. 实操全流程：从一段真实Java代码到5个可执行的测试用例

4.1 案例选取：一个银行转账核心方法（简化版）

为了贴合“银行软件测试”这个热搜词，我们选一个真实的、有业务风险的场景。以下是一个简化但逻辑完整的Java转账方法：

public class BankService { public String transfer(double fromBalance, double toBalance, double amount) { // 节点1：入口 if (amount <= 0) { // 节点2：判定1 return "转账金额必须大于0"; } if (fromBalance < amount) { // 节点3：判定2 return "余额不足"; } double newFrom = fromBalance - amount; double newTo = toBalance + amount; if (newFrom < 0 || newTo > 1000000) { // 节点4：判定3（复合条件，视为一个判定节点） return "转账后账户异常"; } // 节点5：成功逻辑 return "转账成功，新余额：" + newFrom + ", " + newTo; } }

这个方法有3个判定节点（amount≤0, fromBalance<amount, newFrom<0||newTo>1000000），所以V(G)=3+1=4。但等等，最后一个判定是“或”条件，它内部有两个子条件，是否算两个判定？不算。在CFG中，一个if语句无论内部条件多复杂，只要它产生一个分支决策点，就算一个判定节点。所以V(G)确实是4。但为了保险，我们还是用E-N+2验证一下。

4.2 步骤一：手绘控制流图，标注所有节点和边

我拿出一张A4纸，按规则画图：

• 节点1：入口（transfer方法开始）
• 节点2：判定1amount <= 0，出边：T（返回错误）、F（继续）
• 节点3：判定2fromBalance < amount，出边：T（返回错误）、F（继续）
• 节点4：判定3newFrom < 0 || newTo > 1000000，出边：T（返回错误）、F（继续）
• 节点5：成功返回语句
• 节点6：出口（所有return语句的终点，为统一出口）

边连接：

• 节点1 → 节点2
• 节点2-T → 节点6（返回"金额必须大于0"）
• 节点2-F → 节点3
• 节点3-T → 节点6（返回"余额不足"）
• 节点3-F → 节点4
• 节点4-T → 节点6（返回"账户异常"）
• 节点4-F → 节点5
• 节点5 → 节点6

数一下：节点N=6（1,2,3,4,5,6），边E=8（1→2, 2T→6, 2F→3, 3T→6, 3F→4, 4T→6, 4F→5, 5→6）。V(G)=E-N+2=8-6+2=4。确认无误。

4.3 步骤二：列出4条独立路径，并转化为测试用例

根据图，4条独立路径如下：

• 路径P1：1→2T→6。触发条件：amount <= 0。用例：transfer(1000, 500, 0)→ 期望返回"转账金额必须大于0"。
• 路径P2：1→2F→3T→6。触发条件：amount > 0且fromBalance < amount。用例：transfer(100, 500, 200)→ 期望返回"余额不足"。
• 路径P3：1→2F→3F→4T→6。触发条件：amount > 0,fromBalance >= amount, 但newFrom < 0 || newTo > 1000000为真。注意newFrom = fromBalance - amount，要让它<0，需fromBalance < amount，但这与路径P2冲突。所以只能让newTo > 1000000为真：toBalance + amount > 1000000。用例：transfer(100000, 999900, 101)→newTo = 999900 + 101 = 1000001 > 1000000→ 期望返回"转账后账户异常"。
• 路径P4：1→2F→3F→4F→5→6。触发条件：所有判定都为假。即amount > 0,fromBalance >= amount,newFrom >= 0 && newTo <= 1000000。用例：transfer(1000, 500, 100)→newFrom=900>=0,newTo=600<=1000000→ 期望返回"转账成功..."。

提示：路径P3的设计是关键难点。很多新手会试图让newFrom < 0，但newFrom = fromBalance - amount，若fromBalance < amount，则路径会在节点3就返回"余额不足"，根本走不到节点4。所以必须利用newTo > 1000000这个条件。这体现了基本路径测试的威力：它逼你发现代码中隐藏的、容易被忽略的边界场景。

4.4 步骤三：编写JUnit测试，验证路径覆盖

用JUnit 5写测试类：

import org.junit.jupiter.api.Test; import static org.junit.jupiter.api.Assertions.*; class BankServiceTest { private final BankService service = new BankService(); @Test void testPathP1_AmountZeroOrNegative() { String result = service.transfer(1000, 500, 0); assertEquals("转账金额必须大于0", result); } @Test void testPathP2_InsufficientBalance() { String result = service.transfer(100, 500, 200); assertEquals("余额不足", result); } @Test void testPathP3_ExceedsMaxBalance() { String result = service.transfer(100000, 999900, 101); assertEquals("转账后账户异常", result); } @Test void testPathP4_SuccessfulTransfer() { String result = service.transfer(1000, 500, 100); assertTrue(result.contains("转账成功")); assertTrue(result.contains("900.0")); assertTrue(result.contains("600.0")); } }

运行测试，4个用例全部通过。此时，你的路径覆盖率是100%。你可以用JaCoCo等工具生成报告，确认这4个用例确实覆盖了所有判定节点的真假分支。这就是基本路径测试的闭环：从代码→图→计算→路径→用例→验证。

5. 常见问题与避坑指南：那些没人告诉你的实战陷阱

5.1 陷阱一：把“独立路径”误解为“所有可能路径”，导致用例爆炸

新手最容易犯的错，就是看到一个有5个if的函数，就去穷举所有if的真假组合，算出2^5=32条路径，然后傻乎乎地设计32个用例。这是对“独立路径”的根本性误解。独立路径的数量由环路复杂度决定，不是由判定数量的幂次决定。一个含5个判定的函数，V(G)可能是6（如果它们是线性排列），也可能是10（如果存在嵌套和循环）。独立路径是线性无关的基底，不是所有排列组合。我曾见一个同事为一个V(G)=7的模块写了28个用例，理由是“有4个布尔参数，2^4=16，再加些边界值”。结果上线后，一个V(G)=7的路径缺陷漏掉了，因为他的用例根本没按图索骥，只是在参数空间里随机采样。记住：先画图，再算V(G)，再找V(G)条路径。这是铁律。

5.2 陷阱二：忽略循环，把while/for当作单个节点处理

循环是路径复杂度的“放大器”。一个简单的while(i < 10)，如果循环体内部没有分支，它本身只贡献1个判定节点（V(G)增加1）。但如果循环体内有if，情况就变了。例如：

for (int i = 0; i < list.size(); i++) { if (list.get(i).isValid()) { // 这个if是额外的判定节点！ process(list.get(i)); } }

这里的for循环贡献1个判定（i < list.size()），循环体内的if又贡献1个，总共2个判定节点。V(G) = 2 + 1 = 3。但更危险的是，循环本身会引入多条路径：执行0次、执行1次、执行多次。基本路径测试要求你覆盖“0次”（即循环条件首次为假）和“至少1次”（即进入循环体）这两条路径。所以，针对循环，你必须设计两个用例：一个让list为空（循环0次），一个让list有至少一个valid元素（循环至少1次）。我见过太多测试用例只覆盖“list有10个元素”的场景，却忘了“list为空”这个高频生产问题，原因就是没把循环的“0次执行”当作一条独立路径。

5.3 陷阱三：在面向对象代码中，混淆类方法与整体路径

基本路径测试是针对单个函数或方法的。一个类有10个方法，你不能画一个大图把它们全串起来算V(G)。每个方法独立计算。但有个灰色地带：方法调用。如果方法A调用方法B，而B的逻辑非常简单（如getter），通常不展开；但如果B是一个复杂的业务逻辑，且你正在测试A的集成行为，那么B的判定节点就应该计入A的CFG。我的经验是：如果被调用方法的源码可见且逻辑关键，就把它内联进图；如果它是第三方库或黑盒，就用一个“桩节点”代替，不增加V(G)。比如测试一个订单创建服务，它调用支付网关的pay()方法。如果pay()是你自己写的，且有复杂逻辑，就展开；如果是支付宝SDK，就画一个“调用支付网关”节点，不计为判定。

5.4 陷阱四：面试时只会算数，不会解释业务含义

技术面试官最讨厌背公式的考生。他问“这个方法V(G)是多少”，期待的不是“4”，而是“4，因为这里有3个if判定，每个都可能改变执行流向，加上入口，共4条主干逻辑。比如路径1对应用户输入负金额的拦截，路径2对应余额校验失败，路径3对应风控限额超限，路径4是正常成功流程。这4个场景覆盖了所有业务拒绝点和成功点。” 把数字翻译成业务语言，才是高级测试工程师的素养。我建议你在练习时，强制自己为每条路径写一句中文业务描述，就像给产品经理讲解一样。

6. 工具链与效率提升：从手动画图到自动化辅助

6.1 手工时代：纸笔与白板是最高效的入门工具

别急着打开IDE。我坚持让所有新人用A4纸和彩笔画前三张CFG图。为什么？因为手动画图的过程，强迫你逐行解析代码，理解每个分号、每个括号、每个return的位置。电脑绘图软件（如draw.io）太流畅，容易让你跳过思考，直接拖拽节点。而纸上画错一个边，擦掉重画的“物理成本”，会让你更谨慎地审视每一次跳转。我自己的第一张CFG图，画了7遍才正确，但从此对控制流的理解刻进了肌肉记忆。白板适合团队协作：你画图，同事指“这里少了一条else边”，即时讨论，比看文档高效十倍。

6.2 进阶工具：IDE插件与静态分析器

当你熟练后，可以借助工具提速。IntelliJ IDEA有插件“MetricsReloaded”，能一键分析Java方法的环路复杂度，并高亮显示。Eclipse也有类似插件。但要注意：工具算出的V(G)只是参考，CFG图必须你自己画。因为工具无法理解业务语义，可能把一个无害的日志打印语句误判为判定节点。我见过工具报告某个方法V(G)=12，但人工分析发现其中5个是日志if（if (log.isDebugEnabled())），这些在测试设计中应忽略，因为它们不影响核心业务逻辑。真正的V(G)应该是7。工具是加速器，不是决策者。

6.3 自动化边界：路径生成与用例骨架

目前没有工具能完全自动生成“可执行的测试用例”。但有些工具能帮你迈出关键一步：生成路径的伪代码描述。Python的pyan3库可以分析.py文件，输出CFG的dot格式图；Java的JQAssistant能做类似事情。更实用的是，你可以写一个简单的脚本，读取CFG图的JSON描述（节点、边、判定条件），然后为每条路径生成一个带注释的测试用例模板：

// 路径 P3: 1->2F->3F->4T->6 // 触发条件: amount > 0, fromBalance >= amount, (fromBalance - amount) < 0 || (toBalance + amount) > 1000000 // 由于 (fromBalance - amount) < 0 与 fromBalance >= amount 矛盾，故取后者 // 即: toBalance + amount > 1000000 @Test void testPathP3_ExceedsMaxBalance() { // TODO: 设置具体数值 double fromBalance = ?; double toBalance = ?; double amount = ?; String result = service.transfer(fromBalance, toBalance, amount); assertEquals("转账后账户异常", result); }

这个模板省去了你手动写注释和占位符的时间，把精力集中在最关键的“数值设计”上。这是我团队内部共享的脚本，它不生成最终用例，但把80%的机械劳动自动化了。

7. 在真实项目中的应用策略：不是每个模块都值得画图

7.1 优先级矩阵：什么代码必须画图，什么可以放过

基本路径测试不是银弹，它有成本。画一张CFG图，平均耗时15-30分钟。所以必须策略性使用。我用一个2x2矩阵来决策：

“高业务影响”由需求文档和线上事故历史决定；“高复杂度”由静态扫描工具初步筛选。我们团队规定：所有支付、转账、核心账务模块，V(G)>5就必须提交CFG图和路径用例；所有用户界面渲染模块，V(G)>15才启动此流程。这避免了在简单工具函数上浪费时间。

7.2 与敏捷开发的融合：在PR（Pull Request）中嵌入路径评审

我们把基本路径测试融入Code Review。开发提交PR时，除了代码，还需附上：

• 该方法的V(G)值（由IDE插件截图）
• 一张简化的CFG图（手绘拍照或draw.io导出PNG）
• 一个表格，列出V(G)条路径及其对应的测试用例编号

测试工程师Review时，不看代码细节，先看这张图：节点是否遗漏？边是否画全？V(G)计算是否正确？如果图有问题，直接打回，让开发重画。这比在测试阶段才发现“漏了一条路径”高效得多。一次PR评审平均节省2小时返工时间。图是沟通的通用语言，比文字描述“我覆盖了所有分支”有力一万倍。

7.3 面试实战：如何在5分钟内征服“基本路径测试”问题

如果你正在准备“软件测试面试题”，请记住这个黄金5分钟结构：

1. 定义（30秒）：“基本路径测试是一种白盒测试方法，目标是覆盖程序中所有线性独立路径，确保每条逻辑主线都被执行。它的核心是控制流图和环路复杂度。”
2. 原理（1分钟）：“我先画控制流图，把代码变成节点和边；然后算环路复杂度V(G)，常用判定节点数+1；最后找出V(G)条独立路径，每条路径设计一个用例。”
3. 举例（2分钟）：快速在白板上画一个简单if-else图，标节点，算V(G)=2，找2条路径，写2个用例。边画边说：“这条路径是if为真，对应用户登录成功；这条是if为假，对应密码错误。”
4. 价值（1分钟）：“它让我能精准量化测试深度。比如V(G)=8，我就知道至少要8个用例，而不是凭感觉写20个。在银行项目里，它帮我们发现了‘风控限额超限’这个被忽略的路径，避免了资损。”

不谈抽象理论，只讲“我怎么做”。面试官要的不是一个教科书答案，而是一个能立刻上手干活的工程师。

我在实际项目中发现，真正决定测试质量的，从来不是你会多少种方法，而是你敢不敢在关键模块上，花30分钟画一张图，然后说：“老板，这个模块有7条独立路径，我需要7个用例，这是清单。” 这份笃定，来自对基本路径测试的深刻理解，也来自无数次手绘CFG图时，铅笔尖划过纸面的沙沙声。它不炫技，不浮夸，但每次都能稳稳接住那个最致命的bug。