1. 从代码到图形为什么我们需要程序流图与控制流图你好我是老张在软件测试这行摸爬滚打了十几年。今天咱们不聊那些高大上的测试框架和自动化工具就聊聊最基础、也最容易被轻视的两个“图”——程序流图和控制流图。很多刚入行的测试工程师甚至一些工作了几年的朋友一听到要画这两个图头就大了觉得这是学校里才考的“八股文”实际工作中用不上。我以前也这么想直到在一次复杂的系统故障排查中面对几十万行代码我才真正体会到能把一段代码清晰地画成图是一种多么宝贵的能力。简单来说程序流图就像是代码的“全景游览地图”。它把程序中的每一个操作比如赋值、计算和每一个判断比如if、while都用特定的图形符号表示出来然后按照代码的执行顺序用箭头把这些图形连接起来。这样一来哪怕是一段非常冗长的代码你也能通过这张图一眼看清它的整体执行脉络知道程序从哪里开始经过哪些步骤最后在哪里结束。而控制流图则是程序流图的“精简版”或“骨架版”。它更关心的是程序的“逻辑结构”特别是分支和汇合的点。在控制流图中我们会把一连串顺序执行、没有分支的语句合并成一个“节点”只保留那些影响程序走向的关键判断点。这样做的目的是为了后续进行更高级的分析比如计算代码的圈复杂度这是衡量代码复杂度和测试用例设计量的重要指标或者为白盒测试中的路径覆盖提供依据。所以画这两个图绝不是为了应付考试。它们是测试工程师理解代码逻辑、设计测试用例、尤其是设计路径覆盖测试用例的基石。当你面对一个复杂的函数光靠读代码可能理不清有几个分支、几条路径时动手画一画一切就豁然开朗了。接下来我就用最“小白”的方式带你一步步掌握绘制技巧并重点剖析几个新手百分之百会踩的坑。2. 手把手实战绘制程序流图与控制流图光说不练假把式咱们直接看代码。假设我们有下面这段简单的C语言函数功能是判断一个年份是否为闰年。int is_leap_year(int year) { int result 0; // 1. 初始化结果 if (year % 4 0) { // 2. 判断能否被4整除 if (year % 100 0) { // 3. 判断能否被100整除 if (year % 400 0) { // 4. 判断能否被400整除 result 1; // 5. 是闰年 } else { result 0; // 6. 不是闰年 } } else { result 1; // 7. 是闰年 } } else { result 0; // 8. 不是闰年 } return result; // 9. 返回结果 }2.1 绘制程序流图程序流图的元素很简单通常我们用椭圆形表示“开始/结束”矩形框表示“处理步骤”比如赋值、计算菱形表示“判断”。咱们就按照代码行一步一步画。开始画一个椭圆里面写上“开始”或“Start”。步骤1从开始箭头指向一个矩形框框里写result 0。判断2从上一个矩形框箭头指向一个菱形菱形里写year % 4 0 ?。从这个菱形会引出两个箭头通常向下或向右标“Y”或“真”表示条件成立向右或向下标“N”或“假”表示条件不成立。分支条件为真如果条件成立Y进入内层判断。箭头指向一个新的菱形year % 100 0 ?。更深层分支如果year % 100 0成立Y再指向菱形year % 400 0 ?。这个判断如果成立Y箭头指向矩形result 1步骤5如果不成立N箭头指向矩形result 0步骤6。分支条件为假回到第3步的判断year % 100 0 ?如果它不成立N则箭头指向矩形result 1步骤7。外层分支条件为假回到最外层的判断year % 4 0 ?如果它不成立N则箭头直接指向矩形result 0步骤8。汇合与结束步骤5、6、7、8这四个给result赋值的矩形框它们的出口箭头最终都应该指向最后一个矩形框return result步骤9。最后从“返回”框箭头指向一个椭圆“结束”。画完之后你会得到一张有多个判断菱形和分支箭头的图。这张图完整地复现了代码的所有执行语句和顺序这就是程序流图。2.2 绘制控制流图现在我们基于程序流图来简化出控制流图。控制流图的核心是“节点”和“边”。节点代表一个或多个顺序执行的基本块边代表控制流的转移。识别基本块基本块是指一段顺序执行、只有一个入口和一个出口的代码序列。我们从上面代码可以划分出几个基本块块Aresult 0(第1行)。块B判断year % 4 0(第2行)。注意判断语句本身单独成为一个块。块C判断year % 100 0(第3行)。块D判断year % 400 0(第4行)。块Eresult 1(第5行)。块Fresult 0(第6行)。块Gresult 1(第7行)。块Hresult 0(第8行)。块Ireturn result(第9行)。合并与连接在控制流图中我们更关注结构。有时为了更简洁可以把仅包含简单赋值且逻辑上可合并的块处理一下但初学者建议先按每个语句块画清楚。用带箭头的线边连接它们A - BB(真) - CB(假) - HC(真) - DC(假) - GD(真) - ED(假) - FE - IF - IG - IH - I图形化表示把每个块画成一个圆圈或矩形在控制流图中常用圆圈在里面标上块名A, B, C...或关键语句。然后按照上面的连接关系画上箭头。最终你会得到一个像树状又带汇合的网络图。这个图去掉了具体的操作细节清晰地展示了is_leap_year函数有4条独立的执行路径A-B-H-I, A-B-C-G-I, A-B-C-D-F-I, A-B-C-D-E-I这为我们设计覆盖所有路径的测试用例提供了直接依据。3. 深度解析逻辑运算符带来的“思维陷阱”好了基础画法掌握了现在我们来聊聊真正容易翻车的地方。这也是很多教材和文章一笔带过但在实际做题和工作中极易出错的关键点。我们来看一个经典的、令人困惑的例子。考虑下面这段伪代码逻辑1. IF (A 1 AND A 2) OR (x 1) 2. THEN Process P1 3. ELSE 4. THEN Process P2 5. END IF现在的问题是当第一个复合条件(A 1 AND A 2)判断为“假”时程序流程应该指向哪里是直接跳到第4行的Process P2吗很多人的第一反应是哦AND两边只要有一个为假整个条件就为假所以这个IF条件不成立应该执行ELSE分支也就是指向Process P2。错了这是一个典型的思维误区。让我们像编译器一样冷静地分析一下。整个IF的条件是(A 1 AND A 2) OR (x 1)。这是一个由OR连接的两个子表达式。对于OR运算编译器和程序执行流程采用的是短路求值策略。短路求值的意思是计算逻辑表达式时一旦结果能够确定就不再计算剩余的子表达式。对于OR如果左边的子表达式为真那么整个表达式已经确定为真右边的子表达式根本不会被执行或判断。对于AND如果左边的子表达式为假那么整个表达式已经确定为假右边的子表达式也不会被计算。现在回到我们的流程图绘制上。当程序执行到判断节点(A 1 AND A 2) OR (x 1)时它并不是一口气把整个表达式算完再决定去哪。流程图的走向描绘的是程序运行时实际进行的判断顺序。程序会先计算(A 1 AND A 2)这个子表达式。计算这个子表达式时又会先计算A 1。如果A 1为假根据AND的短路规则A 2根本不会被执行判断整个子表达式(A 1 AND A 2)的结果立即确定为假。此时对于最外层的OR来说它的左边操作数子表达式结果是假。仅凭左边为假无法确定整个 OR 表达式的结果因为如果右边x 1为真整体仍为真。因此程序必须继续去计算判断OR的右边操作数x 1。所以在程序流图上当A 1判断为“假”时流程箭头不应该直接指向ELSE对应的Process P2模块而应该指向下一个需要判断的节点即x 1 ?这个判断节点。这就是为什么在开篇提到的那个经典题目里“第一个节点的错误fail判断流向第五个节点而不是第四个节点”。因为第四个节点可能对应的是A 2这个判断而由于A 1已经为假程序逻辑决定了根本不会走到A 2的判断所以箭头指向了代表x 1判断的第五个节点。总结这个核心陷阱绘制程序/控制流图时不能基于我们人脑对整个逻辑表达式的综合理解来直接画最终分支。必须严格遵循程序运行时序和短路求值规则一步步拆解每一个逻辑判断点。AND和OR在流程图中会体现为多个层级化的判断节点而不是一个简单的“真/假”二分。4. 常见误区与最佳实践指南除了上面那个“逻辑运算符”的大坑在实际绘制和应用中还有一些常见的误区值得我们警惕。误区一混淆图形元素这是最基础的错误。一定要牢记椭圆形开始/结束矩形处理过程菱形判断。我曾经见过有新手把计算语句放进菱形里或者把判断条件写在矩形里这样画出来的图逻辑是混乱的也无法用于后续的圈复杂度计算等分析。养成规范绘制的习惯是后续一切分析的基础。误区二遗漏汇合点在复杂的条件分支或循环结束后多条路径往往会重新汇合到同一点。在流程图中这个汇合点必须明确画出来。例如一个if-else语句无论走哪个分支执行完后都应该箭头指向同一个后续节点。很多人在画图时只关心分支怎么展开却忘了把它们“收拢”导致流程图有多个错误的出口。在控制流图中这体现为多个节点指向同一个后续节点。误区三对循环结构的处理不当对于while、for、do-while循环在流程图中要清晰地画出循环判断菱形和循环体矩形并确保循环体执行完后箭头指回判断条件形成一个闭环。在控制流图中循环结构会形成一个环这是增加圈复杂度的主要来源。新手容易把循环的退出箭头画错位置或者忽略了循环判断条件为假时直接跳出循环指向的下一个节点。误区四认为控制流图节点越少越好前面说控制流图是程序流图的简化但“简化”是指合并顺序执行的语句块而不是随意合并。每一个可能改变程序控制流的点尤其是判断语句原则上都应该成为一个独立的节点。错误地合并节点会导致你计算出的圈复杂度偏低从而低估了测试的复杂度和需要设计的用例数这是非常危险的。最佳实践建议先写注释再画图面对复杂代码先用注释在代码上标出你认为的基本块边界和判断点。这能帮你理清思路。使用工具辅助但理解本质像 Visio、Draw.io甚至一些专业的软件分析工具都能自动或半自动生成流图。初期可以借助工具验证自己的手绘图但一定要亲手画几次理解每个箭头背后的逻辑工具生成的结果有时也会因解析规则不同而有差异。用流图辅助用例设计画图不是目的。画出控制流图后你应该能一眼看出所有的独立路径。以闰年函数为例4条路径就对应至少4个测试用例不能被4整除、能被4整除但不能被100整除、能被100整除但不能被400整除、能被400整除。这就是路径覆盖测试的基础。与圈复杂度结合圈复杂度 V(G) 可以通过控制流图计算边数 - 节点数 2。它定量地反映了程序的复杂性并且直接给出了实现路径覆盖所需测试用例数的下限。当你画完图算一下圈复杂度可以反过来检查你的图是否画得合理。画程序流图和控制流图就像程序员写代码前的伪代码构思是测试工程师分析代码逻辑的利器。这个过程强迫你慢下来仔细追踪程序的每一处分支和转折。我职业生涯早期曾因为忽略了一个复杂的多层逻辑判断导致一个边界条件漏测引发了线上问题。从那以后对于核心逻辑我再忙也会在纸上画一画。希望今天的分享能帮你绕开那些坑真正把这两个“图”用起来让你的测试设计更加扎实、全面。