用序列图设计测试用例：从时序图到完整用例清单

接触过几年软件测试的人应该都有这种感觉：拿到需求文档，第一反应是找用例设计方法，等价类、边界值、判定表背得滚瓜烂熟，可真到写测试用例的时候，还是觉得心里没底。尤其是涉及多个模块交互、多个接口串联的场景，你根本说不清先调谁后调谁，调用之后系统应该处于什么状态，某个中间步骤失败了到底该回滚还是继续往下走。这种模糊感，恰恰是序列图能解决的核心问题。

序列图（Sequence Diagram）是UML里动态建模的一张图，核心价值就是把"谁在什么时间、按什么顺序、调用谁的什么方法"画出来。对测试来说，它天然就是一份覆盖面很广的用例设计素材。我这些年做过的支付、电商、物联网项目，凡是接口交互复杂、有回调有异步消息的，几乎都靠序列图来兜底设计测试用例。这篇文章就把我从序列图里"挖用例"的完整方法和踩过的坑整理出来，适合做功能测试、接口测试、测试开发，以及准备软件测试面试的朋友参考。文章后面会用一个"订单超时自动取消"的实战案例，把从时序图到最终用例清单的每一步都拆开讲，保证你看完能直接抄作业。

1. 序列图测试设计的价值：为什么选它而不是等价类/边界值

1.1 序列图在测试里到底承担什么角色

很多人对序列图的印象停留在大学UML课程里，觉得它就是个画给开发看的交互图，跟测试关系不大。这个认知其实是错的。序列图描述的是系统内部各对象（或者外部用户、外部系统）之间在时间维度上的消息交换过程，它回答的问题恰恰是测试最关心的三件事：输入是什么（消息参数）、步骤是什么（消息顺序）、输出是什么（返回消息和状态变化）。

举个例子，一个最简单的登录功能，你画一条序列图出来，就能看到用户→登录Controller→用户服务→数据库这一条完整链路。等价类划分只能告诉你用户名该填什么格式的合法数据、什么是不合法的数据，但序列图能告诉你"用户服务查完数据库之后，是直接把结果返回给Controller，还是先写日志再返回""数据库查不到用户时，是抛异常还是返回空对象"，这些信息直接决定了测试用例的预期结果写得准不准。

所以在测试领域，序列图的角色应该被定义为"预期行为契约"。需求文档是给所有人看的业务描述，而序列图是技术层面的行为描述，它把"系统应该怎么做"这种抽象描述变成了一条条具体的消息调用链。测试人员拿着这份契约，才能设计出真正贴合系统真实行为的用例，而不是靠猜。

1.2 对比其他测试设计方法，序列图的独特优势

做测试设计的人都知道，方法论那一套说起来头头是道：等价类划分管输入数据，边界值分析管临界点，判定表管条件组合，状态迁移管状态流转，场景法管业务流程。那序列图法跟这些比，优势到底在哪？

我做了个对比表，方便你理解它们的适用边界：

从表里能看出来，序列图法最独特的地方在于它天然覆盖了"时序"和"交互"这两个维度。等价类、边界值回答的是"给什么数据"，判定表回答的是"什么条件下走哪条分支"，而序列图回答的是"消息按什么顺序在参与者之间流动，中间有哪些分支、循环、并行、异常返回"。一个支付系统最怕的恰恰不是某一个字段测错了，而是支付网关回调、库存锁定、超时取消这几个事件撞在一起时的顺序问题，这种问题不用序列图根本说不清楚。

所以我的观点很明确：序列图法不是用来替代等价类、边界值的，它是跟这些方法配合使用的。用等价类把每条消息的参数取值搞定，用判定表把alt片段里的条件组合搞定，再用序列图把所有交互路径完整串起来，这样的测试设计才立体。

1.3 什么项目最值得用序列图做测试

不是所有项目都需要在序列图上投入大量精力。一个纯CRUD的管理后台，接口就是简单的增删改查，画序列图的意义不大，用等价类和流程用例就够了。但下面这几类项目，我强烈建议测试人员主动要求开发提供序列图，或者自己根据接口文档补画：

多微服务协作的系统。订单、支付、库存、积分分属不同服务，一个请求要跨三四个服务才走完，没有序列图你根本判断不了每个服务该在什么时候被调用，失败时该补偿还是回滚。

有大量异步消息和回调的系统。比如支付回调、短信回调、消息队列消费、定时任务触发，这类事件没有明确的同步返回，测试用例的"预期结果"往往依赖状态变化或者消费日志，序列图能把异步事件的触发时机和后续影响画清楚。

涉及硬件与软件交互的嵌入式系统。现在汽车HMI、工控设备这类项目越来越热，车载中控屏跟底层控制器之间的软硬件接口测试，本质就是验证指令消息的顺序和响应时间，序列图几乎是标配。

高并发、强顺序要求的核心链路。像秒杀、订票这种系统，多个请求同时到达时的顺序处理逻辑极其关键，序列图加上并发的测试方法，能挖出很多隐蔽的竞态问题。

一句话总结：只要系统里存在"多个参与者在时间上有先后依赖关系"，序列图就是测试设计最好的抓手。

2. 从序列图提取测试场景：标准流程与核心技巧

2.1 先读懂序列图的五个关键元素

想把序列图变成测试用例，第一步是读懂图里每一个元素在表达什么。很多测试新手拿到序列图就懵，本质上是没搞清楚图里那几条线和方框的语义。这里我把最核心的五个元素过一遍，每个都结合测试的角度说。

生命线（Lifeline）。就是图顶部那个矩形加一条竖直虚线，代表一个参与者。这个参与者可以是用户、外部系统、服务、类、数据库，甚至是消息队列。从测试角度看，每一条生命线就是一个被测对象，或者至少是测试必须关注的一个环节。两条生命线之间的交互，就是接口测试、集成测试要覆盖的边界。

消息（Message）。用箭头表示，是从一条生命线指向另一条生命线的调用或信号传递。实心箭头代表同步调用（发出去要等对方返回），开放箭头代表异步消息（发出去就不等结果），虚线箭头代表返回消息。测试里最核心的工作就是把每一条消息当成一个测试步骤，把消息的参数当成输入，把消息的返回当成预期结果。这里有个特别容易忽略的点：返回消息也是消息，它的值直接影响后续流程，所以"预期返回值"要逐一验证，不能只关心最终结果。

激活条（Activation Bar）。就是生命线上那个细长矩形，表示该参与者正在执行的时间段。激活条越长，说明这个处理越耗时，也暗示着这个环节是性能测试要关注的点。如果某个激活条跨越了很长一段消息交互，说明它是外部依赖方，稳定性测试要重点照顾。

组合片段（Combined Fragment）。这是序列图里最复杂也最值钱的部分，是各种带标签的方框。最常见的有几种：

从测试角度来看，组合片段就是"分支条件"的集合。alt里的每个条件分支是一条独立路径，opt是"走或不走"两条路径，loop是循环次数的边界，par则直接指向并发测试场景。读图时把这些片段全部标出来，用例的骨架就有了。

状态约束与时间约束（State/Time Constraint）。有些序列图会在生命线上用花括号标注前置状态或时间要求，比如{state = CREATED}表示执行到这个节点时对象必须处于已创建状态，或者{t < 30s}表示某条消息必须在30秒内发出。这些约束直接就是测试用例的前置条件和预期时间指标，看到了必须单独摘出来。

2.2 四步法把时序图变成测试用例

读懂了元素，接下来就是标准化的转换流程。我总结了一套四步法，团队里的新人照着走基本不会漏场景。

第一步：盘点参与者与消息清单。把图里所有的生命线列出来，确定哪些是测试能直接操控的（比如用户、前端），哪些是依赖的（比如支付网关、数据库），然后把所有消息按顺序编号，形成一张"消息清单"。清单里要包含消息名、发送方、接收方、参数、返回类型。这一步做完，你就拥有了这副时序图的"完整接口目录"。

第二步：识别分支、可选、循环和并行。把所有的alt、opt、loop、par片段挑出来，标出每个片段的条件和分支数。这一步的关键是计算理论路径数：如果有两个alt片段各有2个分支，理论上就是4条路径；如果其中一个还有嵌套，路径数会翻倍增长。但注意，理论路径数不等于实际用例数，很多分支条件之间是互斥的或者受业务限制的，要先用业务逻辑做裁剪。

第三步：从入口到出口遍历全部场景路径。这是整个流程里最需要功底的环节。从序列图的第一条消息开始，沿着箭头走到最后一条消息，每遇到一个分支就分叉出一条新的路径，最终你能得到一个"场景路径树"。遍历时我习惯用"主路径优先"的原则：先把最正常的成功路径走完，再逐条插入异常和分支路径。这样做的好处是，每一条异常路径都能明确地挂靠在某条主路径上，用例的层次感特别清晰。

第四步：把场景路径转成测试用例。每条路径对应一条或者多条测试用例，转换时要注意三个要素。前置条件要覆盖路径起始时的状态约束，比如订单必须处于创建状态；操作步骤就是路径上所有消息的序列，但要转成测试可执行的描述，比如"调用创建订单接口"而不是"用户调用订单服务createOrder方法"；预期结果要同时验证返回值、系统状态变化、以及后续消息是否被正确触发。到了这一步，序列图设计的基本盘就出来了。

2.3 覆盖度怎么算：消息覆盖、分支覆盖、路径覆盖

序列图用得好不好，得有个量化标准。我平时做用例评审会问团队成员三个覆盖度指标，这里也分享给你。

消息覆盖度。公式是被测试用例覆盖到的消息数除以序列图里的总消息数。每条消息都至少有一条用例覆盖到，这是最低要求。比如图里有10条消息，你的用例只覆盖了7条，那剩下3条消息对应的交互行为就没被测到，风险就藏在那里。

分支覆盖度。所有alt、opt片段里的每个分支至少要有一条用例走到。注意，分支覆盖不是说"条件满足"这一侧走到就行，"条件不满足"走另一侧也必须覆盖。很多人在实际测试里只测了业务最关心的成功分支，把异常分支和else分支漏了，分支覆盖度往往只有50%，这是大忌。

路径覆盖度。理论上有多少条完整路径，被实际设计了多少条用例。做路径覆盖时要记住一个原则：完全穷举不现实，组合爆炸是真实存在的。两个alt四个条件，理论路径就有16条，全测不划算也没必要。实际做法是先保证主路径和关键异常路径全部覆盖，再用业务优先级做裁剪，对高频路径做全组合覆盖，对低频路径做至少一次覆盖。

举一个真实例子，我之前测过一个转账功能，时序图里有两条alt，一条管余额是否充足，一条管账户状态是否正常，理论上4条路径。但业务上"余额不足且账户冻结"这种组合根本不可能出现，因为账户冻结时根本走不到余额检查。这类路径在裁剪阶段就可以划掉，剩下3条路径，每条再配合等价类数据，用例就既完整又不冗余。

3. 实战案例：订单超时自动取消的完整测试用例设计

3.1 业务背景与时序图解析

理论讲再多都不如一个完整案例来得直观。这个案例我选了一个几乎所有电商项目都有的场景：订单创建后，如果用户在一定时间内没有支付，系统要自动取消订单、释放库存。这个场景涉及用户、订单服务、支付网关、库存服务、消息队列、定时任务等多个参与者，而且包含同步调用、异步回调、定时触发、并发竞态，非常适合演示序列图驱动测试设计。

我们假设业务规则是这样的：用户在商城下单，订单初始状态为"待支付"；用户发起支付后由支付网关处理，处理结果通过异步回调通知订单服务；如果订单创建后30分钟内仍未支付，超时任务调度器会自动取消订单并释放库存；如果支付回调和超时取消同时发生，系统要保证最终状态一致。

对应的序列图，我用非正式的文本形式画在下面，方便你看清参与者之间的消息顺序：

用户 订单服务 支付网关 库存服务 调度器 | | | | | |--1.创建订单-->| | | | |<---2.orderId--| | | | |--3.发起支付-->| | | | | |--4.调用收银合并-->| | | |<---5.支付二维码--| | | | | | | | | |(用户等待支付) | | | | | | |--6.异步回调--->| | | |<--7.校验签名--| | | | | | | | | |branch(支付成功) | | | |--8.锁定库存---->| | | | |<--9.锁定结果----| | | | |--10.更新状态->| | | | | | | | | |branch(支付失败) | | | |--11.更新状态->| | | | | | | | | | | |--12.查询超时订单->| | | | |<--13.超时订单列表-| | |--14.取消订单--->| | | | |--15.释放库存---->| | | | |<--16.释放结果----| | | | |--17.更新状态->| | |

图里中间有两条判断逻辑：第7条消息收到回调后走支付成功还是支付失败分支；第14条消息是调度器触发取消订单。这两个分支再加上"支付回调与超时取消并发"的情况，就是我们设计用例的主战场。

细化一下消息清单，方便后面设计用例时引用：

3.2 场景拆分与用例明细

有了消息清单，接下来就是按四步法拆场景。先画出理论路径：消息1-5是一条主路径，之后第6条回调进来走两条分支（成功/失败），加上调度器的取消路径，理论路径就有四条：正常支付成功、支付失败、超时取消、支付成功但库存锁定失败。再考虑"支付回调与超时取消并发"这条特殊路径，最终整理出下面这些核心场景。

你注意看SC-01到SC-04这两组，它们就是alt分支产生的场景，每个分支都有一条用例。SC-05是为了验证并发问题单独加的，SC-06和SC-07是边界时间用例，SC-08是回调幂等用例，SC-09是释放库存失败时的补偿逻辑。这些用例组合在一起，序列图里所有消息和分支就全覆盖了。

3.3 这个案例里最容易测漏的三个点

我拿这个案例带过好几个测试新人，几乎每次都会漏掉下面三个点，这里特别拎出来强调一下。

第一，时间边界比你想的复杂。"30分钟超时"不是一个瞬间，中间涉及订单创建时间的存储、调度器扫描时间的精度、时区问题。最常见的问题是用例只在"明显超时"（比如过了40分钟）的场景下测，而忽略了29分59秒和30分00秒之间的边界。这个边界恰好是业务最容易出bug的地方，很多系统的调度器扫描频率是每30秒一次，那"29分59秒未支付"和"30分00秒未支付"在数据库里可能同时被扫到，处理逻辑一旦没考虑时间精度，就会出现提前取消或者超时未取消的线上事故。

第二，回调幂等性必须单独验证。支付网关的回调机制是"至少一次"投递，也就是说同一笔支付结果可能被回调好几遍，加上网络抖动导致的重试，一个订单收到两三次相同的成功回调是非常正常的事。如果系统没做幂等处理，第二次回调进来就会重复锁定库存或者重复发状态变更通知。序列图上只画了一次"异步回调"，但测试里必须在正常场景之外再造一个"重复回调"场景，验证消息处理是幂等的。这就是"图上看不到但必须测"的典型场景。

第三，并发竞态是隐藏的重灾区。SC-05这种场景，很多人觉得不可能发生：用户早不支付晚不支付，为什么非得在超时那一瞬间支付？但真实系统里完全可能，因为调度器扫描有延迟，支付网关回调也有延迟，两个事件可能撞在一起。这种并发情况下，如果订单服务在取消订单前没有做状态校验，或者状态更新不是原子性的，就会闹出"库存已释放但订单被标记为已支付"的笑话。我在真实项目里见过不止一次这种事故，解决方案无非是状态机校验加分布式锁，但测试必须先把场景造出来，逼系统显形。

4. 常见坑位与排查实录：真实项目中踩过的雷

4.1 序列图画得不准确，测试跟着错

第一个要说的坑，是序列图本身的准确性问题。我给你交个底：开发给的序列图，很多时候赶不上代码演进的速度。今天画的图，明天需求一改，图没更新，代码已经改了。你要是拿着旧图设计用例，轻则用例步骤对不上实际接口，重则整个测试方向都跑偏。

我踩过一次很深的坑。之前测一个运费计算功能，开发给的序列图里画的是"订单服务→运费服务→规则引擎"这条链路。我照着设计了几十条用例，执行的时候发现运费服务根本没被调用，是订单服务直接本地算的。后来查代码才知道，项目优化时把运费计算改成了本地实现，远程调用早就下线了，图还是老样子。那次之后我学乖了，拿到序列图的第一件事不是直接设计用例，而是先在测试环境里跑一遍真实链路，确认图里的参与者和消息顺序跟现状一致。对不上的地方，要么让开发更新图，要么自己改图并备注原因。

这里给一个可落地的建议：序列图一定要跟着代码走。如果你是测试人员，最好的习惯是让开发在需求设计阶段就把序列图画好，随代码评审一起维护；如果已经落后了，你至少要会用Arthas、链路追踪这类工具在测试环境把真实调用链拉出来，跟序列图做一次比对。图不准的时候，把它当参考，把真实链路当标准。

4.2 异步消息和回调怎么设计用例

异步消息是序列图测试里最让人头疼的部分。同步调用你发个请求等返回就能断言，异步消息发出去了，响应不会马上回来，预期结果往往要等一段时间才能验证。你设计用例的时候必须想清楚"异步消息之后怎么收口"。

以订单支付回调为例，同步设计里的"断言返回结果"不适用了，你得换一套思路。我的做法是把一条异步用例拆成三段来写：触发段、等待段、验证段。触发段负责把异步事件发出去；等待段明确写清楚等待条件，比如"等待消息队列消费完成，轮询订单状态直到变为已支付，超时60秒"；验证段再检查最终状态和关联系统的数据。这里还有个细节，异步测试环境里的消息队列一定要可控，最好能用mock把外部消息源替换成测试自己能触发的，不然你就在那里干等真实支付网关回调，测试根本跑不稳定。

回调接口和消息消费的稳定性也必须纳入用例设计。支付网关回调可能延迟、可能重复、可能丢失，消息队列消费可能失败重试。我在设计用例时通常会加两类场景：一类是"回调延迟到达"，验证延迟后的处理结果是否符合预期；另一类是"消费失败后重试成功"和"消费失败超过最大重试次数进入死信队列"，验证重试机制和补偿机制是否正常。这些在序列图里通常只画了一个箭头，但测试展开之后往往是一串用例。

4.3 竞态条件：并发场景的测试思路

序列图上出现par片段，或者你发现两条消息可能在时间上重叠时，并发测试就躲不掉了。但并发测试有个难点：你需要稳定地复现竞态，而不是指望运气。靠手动操作去"同时点两个按钮"，成功率极低，必须有方法。

我的经验是分三步。第一步，从序列图找出可能并发的消息对，分析它们是否操作了同一个资源，比如订单状态、库存数量。第二步，利用工具在关键节点上人为制造阻塞，把竞态窗口拉大。具体做法有几种：在测试代码里对某个接口加延迟、用mock服务把某个外部调用暂停几秒、或者用并发压测工具让大量线程同时触发。第三步，在有阻塞的情况下同时触发两条消息，验证最终一致性。

针对订单超时取消这个案例，最直接的复现方式是：用mock把支付回调接口的处理时间人为拉长到10秒，让回调处理还没结束，再触发调度器去取消同一个订单。这时候就能看到，系统到底是先判断订单状态还是直接取消，会不会出现状态互相覆盖的矛盾。这种测试不用自动化工具也能做，但做的时候要记录清楚每一步的时间线，否则不好定位问题。

4.4 面试里碰到的序列图题目怎么答

面试这一块跟咱们的主题也相关。软件测试面试题里经常出现"如何根据序列图设计测试用例""什么是时序图"这类问题，我以面试官的身份给你透个底：面试官不是在考你UML语法，是想看你的测试设计思路。

一个能拿高分的回答套路，我建议分四层。第一层，说清楚序列图是什么，核心关注消息、生命线、组合片段，强调它是动态交互图。第二层，说清楚测试步骤，就是前面讲的四步法：整理参与者和消息、识别分支和循环、遍历场景路径、转换成用例。第三层，举一个简单的例子，比如登录或下单，现场口述几条从序列图推出的用例，展示你的实操能力。第四层，点出序列图法的优势，特别是对异步、回调、并发场景的覆盖能力，顺便提一句覆盖度指标，比如消息覆盖、分支覆盖、路径覆盖，这会比那些只会背八股文的候选人明显高出一截。

这里提醒一下，准备面试的时候不要只停留在概念层面，一定自己找一张真实项目的序列图练习转换用例。我面试的时候最常问的一个问题是："这张图里有几个alt片段，你会设计哪几条用例？"能把这个问题答得具体、有层次的人，基本就是真正用序列图做过测试的。

5. 工具链与自动化扩展：把序列图用出效率

5.1 画图与建模工具怎么选

序列图驱动的测试设计要落地，工具先得选对。这里我把常见的工具按使用场景分了三类，你根据团队情况挑。

文本化工具首选PlantUML。说实话现在我自己写序列图基本都用PlantUML，因为它用纯文本描述图形，可以放到Git里做版本管理，和代码一起走评审。改动序列图跟改代码一样能看见diff，测试团队和开发团队维护起来都方便。比如订单超时取消的序列图，用PlantUML写出来就几十行文本，后续需求变更直接改文本重新渲染，比在画图工具里拖线条高效太多。PlantUML还支持导出PNG、SVG，放到测试用例文档里做附件很省事。

在线协作类工具用draw.io。如果需要跟产品和业务一起评审，draw.io这种在线协作工具更合适，可以多人同时编辑，方便快速画个草图然后把焦点放在业务逻辑讨论上。它同样支持导出XML，简单场景下够用了。

重型建模工具是Enterprise Architect或StarUML。这类工具适合大型项目，模型库、代码生成、XMI导出一应俱全。如果你的公司已经用EA做架构管理，测试人员最好也接入进去，直接从模型库里提取序列图元素，自动生成部分测试文档。但要注意，这类工具学习成本高、许可证也不便宜，团队规模小的话性价比不高。

我的建议是：优先选能进版本管理的文本化方案。测试用例设计这件事，追踪历史变更比画得好看重要得多。我用PlantUML画图后，会在设计文档里贴一张渲染出来的图，同时把源文件路径写在用例管理平台上，这样图的历史版本和用例的对应关系永远有据可查。

5.2 序列图驱动的自动化测试思路

把序列图转换成手工测试用例只是第一步，再往前走一步，序列图还能驱动自动化测试。这里分享几个我在实际项目里用过的思路，从简单到复杂。

最简单的一种是直接用API测试工具承载序列图消息。序列图里的每条消息基本都能对应一个HTTP接口或者RPC调用，你可以把消息清单导入Postman或者JMeter，按顺序组合成测试集。比较成熟的团队还会把消息清单导出成OpenAPI或者Postman Collection，然后在持续集成流水线里定时跑，这就是最轻量的接口自动化。

进阶一点是读取序列图模型文件做半自动用例生成。像EA或者PlantUML导出的XMI格式文件里，实际上已经包含了生命线、消息、组合片段的结构化信息。你可以写一个小程序解析XMI，把消息顺序提取出来，再根据alt片段的分支自动展开成多组路径。虽然最终生成的用例还是要人工核对条件和预期值，但至少最繁琐的路径遍历工作被自动化了。我之前用Python写过一个很简单的解析器，从XMI里提取出消息序列之后，配合模板生成Excel用例框架，测试人员只需要填参数和预期结果，效率提升非常明显。

再往深了走，序列图可以和契约测试、链路追踪结合起来。微服务架构下，消息顺序本身就构成了一份隐形的契约，服务间接口的调用顺序变了，链路就可能断开。用Pact这类契约测试工具，把序列图里服务间的交互关系固化成契约，任何一方改了接口都能在测试阶段被及时发现。链路追踪系统比如SkyWalking也能帮上忙，它把真实请求的调用链记录下来，你可以拿真实调用链和序列图做自动比对，发现不一致的调用顺序就自动告警，这个思路在大型分布式项目里非常实用。

5.3 在团队里落地的推进建议

方法再好，落不了地也是空的。如果你想把序列图驱动测试设计在团队里推起来，我建议按下面这个节奏来，别一上来就全面铺开。

第一，先挑一个核心链路做试点。找一个业务重要性最高、交互最复杂的流程，比如支付、下单、退款这类，让开发补画序列图，然后测试按四步法设计一轮用例。试点的好处是风险可控，而且这类流程往往已经存在测试盲区，做了之后效果立竿见影，更容易说服团队继续推广。

第二，把序列图设计嵌入现有的测试流程。可以安排在测试用例评审之前加一道"序列图走查"环节：测试人员对照序列图逐条确认用例是否覆盖了所有消息、分支和循环边界。开发人员参与走查，能纠正图与代码不一致的问题，产品和测试也能提前对齐业务预期。这个环节在需求评审阶段做效果最好，越早发现交互逻辑问题，修复成本越低。

第三，别过度建模。序列图管交互、管顺序、管时序，但不管每个输入框怎么校验，那部分交给等价类边界值。一个系统画四五张核心序列图就够用了，别想着把每个功能都画一遍，那样维护成本会高到团队直接放弃。我见过有的团队把序列图当摆设，画完就扔进文档库吃灰，这种形式主义的做法还不如不画。

最后再提醒一句关于"软件测试项目实战"和新人培训的事。如果你在带新人或者自己正在转行学测试，我强烈建议把序列图测试设计作为练习项目的一个必做环节。很多新人写用例只盯着功能表面，不会从交互层面思考，一旦他学会从序列图出发设计用例，测试设计的思维层级会有一个明显的跃升。现在不少软件测试课程里也把序列图作为重要的测试设计内容来讲，这个趋势是对的。

写在最后的一些经验

序列图驱动测试设计这条路，我自己走了好几年，从最初只会照着图抄消息，到现在能依据时序图预判风险点，中间确实踩了不少坑。印象最深的是第一次在支付项目里用序列图排查线上问题，当时一笔重复支付的客诉怎么都查不出原因，后来把支付回调、对账任务、超时取消三张序列图叠在一起看，才发现是回调重试和定时任务补单撞了车，本质上就是两个异步消息在同一时间窗内操作了同一笔订单。那次之后，我对序列图的信任度就彻底拉满了。

如果你想快速上手，我建议今天就在手头最熟悉的系统里挑一条核心业务链路，让开发提供序列图或者自己根据接口文档补画一张，然后走一遍消息盘点、分支识别、路径遍历、用例转换的完整流程。做完一轮，你会对"系统是怎么协作的"这件事产生跟以前完全不同的理解。这个内容后续还可以往两个方向扩展：一是配合状态机图做状态和交互的双重验证，二是把序列图消息清单接入自动化测试平台，彻底解决手工维护接口自动化用例成本高的问题。我个人的体会是，测试设计方法千千万，但能把一张图画成一套高质量测试用例，这门本事走到哪里都不过时。