状态转换与场景法

• 0-switch/1-switch/N-switch 的定义
• 各覆盖级别的路径长度与成本
• 工程取舍依据

状态转换测试中，switch 指"连续迁移的次数"。0-switch 覆盖是"每个迁移至少执行一次"（即每个状态到目标状态的一次转换），是最基础的覆盖，用例数等于迁移数；1-switch 覆盖是"连续两条迁移的序列至少执行一次"（长度2的路径），能发现"连续迁移衔接不当"的缺陷；N-switch 覆盖是"连续 N 条迁移的序列至少执行一次"，覆盖长度 N+1 的路径，路径数随 N 指数增长。工程取舍：0-switch 成本最低、覆盖最基本的行为正确性，适合大多数场景；当状态间存在复杂衔接、需要验证连续状态序列时用 1-switch；N-switch 仅用于状态机复杂、路径衔接风险高且安全的场景，因为它路径爆炸、用例成本极高。通常默认 0-switch，按风险升级到 1-switch，N-switch 需谨慎。

switch 覆盖度量的是"状态迁移路径"的粒度。0-switch 只验证每条迁移本身，1-switch 验证"迁移-迁移"的衔接，N-switch 验证更长序列。覆盖度越高，缺陷发现能力越强，但成本指数增长，因此工程上按状态机复杂度与风险分级选择，避免无谓的 N-switch 爆炸。

• 主成功场景与备选场景的概念
• 覆盖率计算的含义
• 场景覆盖的完整性

主成功场景（main success scenario）是用例正常执行、无异常分支的路径，即"用户成功完成目标的理想流程"；备选场景（alternative scenarios）是主流程之外的异常或可选分支，如"登录失败""支付失败""库存不足"。覆盖率计算通常以"用例图/场景流"为基准：场景覆盖率 = 已覆盖场景数 / 总场景数（主场景 + 所有备选场景），其中主场景一般覆盖1条，备选场景按分支逐一计数。工程上常用"主场景 + 各备选场景各覆盖一次"作为基线覆盖，即"1+备选数"的用例数；若需求对所有分支组合都覆盖则需结合判定表/组合测试。覆盖率的意义在于：只测主场景而漏备选场景，会漏掉绝大多数异常处理缺陷，因为备选场景才是缺陷高发区。

覆盖率计算的核心是"场景基准"——先画出用例的完整场景流（主场景+备选分支），再统计已覆盖场景占总场景的比例。这种"以场景为单位"的覆盖度量，比"以用例为单位的通过率"更能反映流程覆盖的完整性。工程上强调"主场景必测、备选场景按风险全测"，避免只测一帆风顺的路径。

• actor 与 system boundary 的概念
• 集成测试中接口与交互的界定
• 外部系统/人的交互验证

actor 是与系统交互的外部实体（用户、外部系统、设备），system boundary 是系统与外界的边界，界定了"系统内部行为"与"外部交互"的分界。在集成测试中，其工程价值在于：第一，明确"被测系统与外部系统的接口"——actor 中的外部系统（如支付网关、短信服务）对应集成测试要验证的接口契约，边界决定了哪些是系统内部逻辑、哪些是外部依赖；第二，界定"责任边界"——用例的精简在于正确划分系统与 actor 的职责，集成测试通过验证 actor 与系统之间的消息往返（请求/响应/异常）来确认边界双方行为正确；第三，指导"打桩与真实集成"——边界外的 actor 可先用 mock/桩替代，再做真实集成，分层验证。因此 actor 与 system boundary 帮助集成测试准确圈定"要联调的接口"与"要模拟的外部依赖"。

集成测试的价值在于验证"组件/系统之间的交互"，actor 与 system boundary 正是定义交互点与交互方的工具。通过明确哪些 actor 是真实外部系统、哪些是系统内部模块，集成测试能准确设计接口测试、契约测试与桩/驱动，避免边界不清导致的测试范围混乱。

• 场景法与用例测试的步骤
• 两者的异同
• 适用场景判断

场景法是基于用户真实使用场景设计端到端测试的方法，从"用户的真实行为流"出发，覆盖主流程与异常流程；用例测试（Use Case Testing）基于 UML 用例图建模，从"actor 与系统的交互"出发，按主成功场景与备选场景设计用例。相同点：都以"用户/actor 视角"设计端到端流程测试，都强调主流程与分支覆盖。不同点：场景法更强调"真实业务场景、端到端数据流、用户旅程"，适合从业务角度验证完整流程；用例测试更结构化、以用例图/场景流为规范，适合需求有明确用例建模的团队。适用场景：场景法适合业务端到端验证、回归测试用户旅程；用例测试适合用例需求文档规范、需要按 actor 与场景系统化覆盖的项目。实践中常结合：用用例图建模系统交互，用场景法补充真实用户旅程。

场景法偏"业务真实"，用例测试偏"结构严谨"。两者都覆盖主流程与分支，但场景法更贴近用户视角、更强调端到端与真实数据，用例测试更强调系统化建模与 actor 交互。工程上"先用例建模、再场景补充"能兼顾严谨与真实。

• 无效迁移的测试
• 不可达状态的含义
• 工程边界

invalid transitions（无效迁移）指状态图中没有定义、在业务上不允许的迁移（如"已支付"直接迁移到"待支付"），测试需验证系统是否拒绝这些非法迁移或给出错误提示；unreachable state（不可达状态）指从初始状态出发，无论如何都无法到达的状态，通常由状态图设计错误或死代码导致。工程边界在于：无效迁移要"验证系统正确拒绝非法操作"，这是防御性测试；不可达状态需要"分析其成因"——是死代码（应删除）还是状态图建模遗漏了合法路径（应补充），而非盲目测试。若不可达状态对应真实可达的代码路径，说明状态模型失准，需修正模型。测试时通过"状态→事件→迁移"矩阵，识别未定义迁移并验证其被拒绝，同时审查是否存在永远无法到达的状态。

无效迁移是"系统应拒绝的操作"，不可达状态是"状态模型的缺陷信号"。两者的工程边界是：无效迁移用"否定性测试"验证防御能力，不可达状态用"分析"判断是死代码还是模型遗漏。正确处理这两类，能让状态机测试既验证正确性又发现建模问题。

• 状态覆盖、转换覆盖、路径覆盖的含义
• 各自的效果与粒度
• 爆炸控制

状态覆盖（state coverage）要求每个状态至少被访问一次，是最基本的覆盖，验证"所有状态都可到达"；转换覆盖（transition coverage）要求每个迁移至少执行一次，验证"所有状态转换都正确"，效果强于状态覆盖；路径覆盖（path coverage）要求所有可能的迁移路径至少执行一次，覆盖最全，但路径数随状态与迁移数指数增长，易爆炸。避免组合爆炸的方法：默认用状态覆盖+转换覆盖（成本可控、覆盖主要风险）；对路径覆盖，用"基于风险选取关键路径"（如主成功路径、异常路径、回归高风险路径）而非穷举全部路径，或用 N-switch 限制路径长度，或用等价类/组合测试筛选路径组合。即以"状态+转换覆盖"为基础，路径覆盖按需聚焦。

三种覆盖的粒度从"节点"到"边"到"路径"，覆盖越强成本越高、爆炸风险越大。工程上以"状态覆盖+转换覆盖"为基线，路径覆盖按风险（关键业务流程、异常处理）挑选，避免全路径穷举。这体现了"覆盖优先 + 成本控制"的平衡。

• 基本流与备选流的概念
• 从用例提取场景的方法
• 端到端测试路径的构造

场景法中，基本流（basic flow）是用例顺利执行的主流程，即主成功场景；备选流（alternative flow）是主流程之外的异常或可选分支，如数据错误、权限不足、外部系统失败。提取方法：从用例描述中识别"主流程步骤"（基本流），再识别"若…则…"条件分支、异常处理步骤（备选流），给每个分支编号（如备选流1、备选流2）。端到端测试路径的构造：主路径从基本流出发覆盖全部步骤；此外，在基本流中每个可能进入备选流的点插入备选流，形成"基本流 + 备选流"的扩展路径，如"基本流→备选流1→返回基本流→完成"。通过覆盖"基本流单独、每个备选流插入基本流、备选流之间组合"形成完整端到端测试路径集，保证主流程与各异常分支都被验证。

场景法的核心是"把用例的流程分支组织成可执行的路径"。基本流是骨干，备选流是分支，通过"在分支点插入备选流"构造扩展路径，能系统覆盖主流程与异常处理。这种方法把"用例文档"转化为"端到端测试路径"，是流程类测试的标准设计手段。

• 三种覆盖的定义
• 覆盖粒度的递进
• 覆盖选择

状态覆盖（state coverage）指测试中每个状态至少被访问一次，验证状态的可达性；转换覆盖（transition coverage）指每个迁移（状态转换）至少被触发一次，验证迁移的正确性；路径覆盖（path coverage）指所有可能的迁移路径至少被走一遍，验证路径序列的正确性。三者粒度递进：状态覆盖只关注"节点"，转换覆盖关注"边"，路径覆盖关注"边序列"。工程上通常以状态覆盖与转换覆盖为基本要求（成本低、覆盖主要风险），路径覆盖因路径数爆炸而按需选取关键路径。例如状态覆盖遗漏"某状态不可达"缺陷，转换覆盖能发现"某迁移错误"，路径覆盖能发现"连续迁移衔接错误"。

三种覆盖是状态机测试的"节点-边-路径"三级度量，覆盖度越高、发现缺陷能力越强、成本越高。工程上按状态机复杂度与风险选择合适的覆盖级别，避免无谓的路径穷举。

• 订单状态流的状态与迁移
• 主流程与各异常分支
• 端到端场景构造

订单/支付状态流转可建模为状态机：待支付→已支付→发货中→已发货→已签收，以及退款分支（退款中→已退款/退款失败）。测试时用场景法覆盖：主路径（下单→支付→发货→签收→完成）验证正常流程；各分支包括——支付失败（支付中→支付失败→可重试）、取消订单（支付前取消、支付后取消不同规则）、退款（签收前/后退款、部分退款、超时未发货自动退款）、异常（库存不足下单失败、支付超时、重复支付回调）。每个分支形成端到端场景，验证状态迁移正确、数据一致性（库存、金额、订单状态）与幂等性（重复支付、重复退款）。还需覆盖状态合法性：非法迁移（如未支付直接发货）应被拒绝。通过"主流程场景 + 各异常分支场景 + 非法迁移验证"实现完整覆盖。

订单状态流是典型的状态机+场景结合场景，核心是"状态迁移正确 + 数据一致 + 幂等"。场景法覆盖主流程与各分支，状态机覆盖迁移合法性，两者结合能系统验证订单全生命周期。实战中还要关注支付回调、对账、退款等异步/分布式场景，补充时序与幂等验证。

• 状态/事件/迁移的识别
• 状态表与状态图的区别
• 适用场景

建立状态模型的步骤：先识别状态（state）——系统在给定时刻所处的稳定情形（如订单的"待支付""已支付"），识别的关键是"状态之间可区分且有业务意义"；再识别事件（event）——触发状态改变的外部输入（如"支付成功""取消"）；最后识别迁移（transition）——"某状态下发生某事件→迁移到新状态"，并标注迁移对应的动作/条件。状态表（state table）把"状态×事件→目标状态"用矩阵表示，适合规则多、信息密集、便于程序化生成用例的场景；状态图（state diagram）用节点与箭头可视化，适合展示整体结构、用于评审与理解状态流。工程上"先画状态图理解、再用状态表落地用例"，两者互补。

状态模型是状态转换测试的基础，识别"状态/事件/迁移"是建模核心。状态表偏"结构化、易生成用例"，状态图偏"可视化、易沟通"，实践中常结合：用状态图梳理拓扑，用状态表系统化枚举迁移并生成测试用例。状态识别要避免"把过程步骤当状态"（状态是稳定的，不是瞬时动作）。

• 状态爆炸的成因
• 基于风险的状态子集
• pairwise 选择

状态爆炸指状态×事件组合过多导致用例数失控。控制方法有两类：一是基于风险的状态子集——按业务影响与缺陷概率对状态和迁移分级，只对高风险状态（如涉及金额、支付、权限的状态）和关键迁移做完整覆盖，对低风险状态用冒烟/代表路径覆盖，从而聚焦测试资源；二是 pairwise 选择——当需要验证"多个状态维度组合"（如多子系统状态、多设备状态）时，不穷举全组合，改用 pairwise 保证任意两状态维度组合被覆盖，大幅降低用例数。此外还可通过状态抽象（合并等价状态）、N-switch 限制路径长度、约束剔除不可能组合来进一步压缩。核心是"先按风险收敛，再用组合手段抽样"。

状态爆炸的根源是"状态×事件×路径"的全组合增长。风险分级收敛"哪些状态必须全覆盖"，pairwise 收敛"哪些组合必须覆盖"，两者结合把指数级规模降到可控范围。这体现了"覆盖优先 + 成本控制"的工程原则，尤其适用于状态机规模大的系统。

• 场景法与用户旅程测试的关系
• 从用户行为流提取场景
• 与用例测试的差异

场景法与用户旅程（user journey）测试高度相关：用户旅程是从用户真实行为视角描述的端到端流程（如"注册→浏览→下单→支付→评价"），场景法正是从这些真实行为流中提取端到端测试场景。提取方法：从用户需求/行为数据/产品设计出发，梳理用户在系统中的完整行为链路，识别其中的关键步骤、分支与异常点，构造主路径与备选路径场景。与基于用例（use case）的差异：用户旅程/场景法更强调"真实用户在高层的端到端行为流"，跨多个功能模块、关注用户体验与数据贯通；用例测试更"结构化、以内聚的用例为单元"，聚焦某 actor 与系统的交互。场景法更贴近业务真实、更利于发现跨模块集成问题，用例测试更利于系统化单元覆盖。实践中常互补：用用例做结构化覆盖，用场景法做端到端真实旅程验证。

场景法本质是"用户旅程的测试化"，核心是"跨模块端到端"与"真实用户视角"。与用例测试的差异在于"粒度与视角"：用例聚焦单 actor 交互，场景聚焦跨模块真实旅程。理解这一差异，才能在"系统化覆盖"与"真实业务验证"之间合理配置测试。

• 状态模型指导探索路径
• 探索式测试的自由度与导向
• 缺陷发现

状态转换测试与探索式测试结合时，用状态模型作为探索的"地图与导向"：先建立系统的状态图/状态表，识别关键状态、高风险迁移与已知薄弱区，然后让探索式测试围绕这些"未充分覆盖的迁移""边界状态""异常迁移"展开，即"用状态模型圈定探索方向，用探索的自由度补充脚本化覆盖的盲区"。具体做法：对照状态模型检查哪些状态、迁移、路径尚未被脚本化用例覆盖，将这些盲区作为探索 Charter；探索过程中发现状态迁移异常、状态不一致、非法状态（如状态卡死、状态冲突）即缺陷。状态模型还帮助探索者理解"当前处于什么状态、下一步可尝试哪些事件"，从而系统性地尝试各种事件组合，避免盲目乱点。二者结合实现"模型驱动的定向探索"。

状态模型擅长"指明覆盖盲区"，探索式测试擅长"发现意想不到的缺陷"。集合二者的价值在于：用状态模型为探索提供"结构化方向"，避免自由探索陷入盲目；用探索的灵活性补充状态模型覆盖不到的细节与异常。这是一种"结构"与"自由"互补的测试策略。

• 有效转换与无效转换的概念
• 各自的测试策略
• 测试重点

有效转换（valid transition）是状态模型中定义、业务上允许的迁移，测试策略是验证"从正确状态、正确事件触发后能正确迁移到目标状态并执行正确动作"，重点是正常流转的正确性。无效转换（invalid transition）是状态模型中未定义、业务上不允许的迁移，测试策略是验证"从错误状态或非法事件触发时系统能正确拒绝、给出错误提示、不产生状态改变"，重点是防御能力的正确性。两者的用例设计不同：有效转换逐条验证正向迁移；无效转换需针对"每对错误状态-事件"验证被拒绝（如"未登录状态下执行支付"）。测试目标是"有效转换正确执行 + 无效转换被正确拒绝"，二者缺一不可，共同保证状态机行为正确且健壮。

有效转换验证"该做的做对"，无效转换验证"不该做的不做"。只测有效转换会漏掉状态机对非法操作的防御缺陷（如状态混乱、越权操作），只测无效转换则无法验证正常流转。正确策略是"以有效转换为主流程验证、以无效转换补充防御验证"，两者互补覆盖状态机完整行为。

• 状态转换与判定表的结合点
• 状态×条件组合的决策
• 联合设计的价值

State Transition 与 Decision Table 联合设计的工程语义是：状态转换图定义"系统状态拓扑与迁移合法性"，判定表定义"某状态下多条件组合决定的迁移动作"。即"状态机定结构、判定表定决策"。在许多状态机中，同一状态下触发某事件时，目标状态与动作取决于多个条件（如"订单为已支付状态，退货申请时，金额>0且理由合理→同意退款，否则→驳回"），这种"状态×条件组合→动作"的决策用判定表表达最清晰。联合设计时，对每个状态（尤其是状态多、迁移决策复杂的状态）建立一张判定表，枚举该状态下触发事件时各条件组合对应的迁移/动作，再与状态图整合验证。价值在于：状态图解决"从哪里到哪里的合法性"，判定表解决"到哪个目标、执行什么动作的条件决策"，两者互补覆盖状态机的结构与决策两个维度。

状态机解决"结构与合法性"，判定表解决"决策与条件化"，联合设计能完整表达"状态+条件→动作"的语义。对迁移决策复杂的状态，判定表是必要补充——单靠状态图无法清晰表达条件化迁移。这是流程类系统测试设计的标准组合。

• 前置条件、后置条件、不变量的概念
• 各自的测试作用
• 验证方法

前置条件（pre-conditions）是用例执行前必须满足的条件，如"用户已登录、库存充足"，测试时验证"前置条件不满足时用例应被正确拒绝或给出引导"；后置条件（post-conditions）是用例成功执行后系统应满足的状态，如"订单已生成、库存已扣减"，测试时验证"执行后系统状态符合后置条件，包括数据一致性"；不变量（invariants）是系统任何时刻都应保持的性质，如"账户余额不能为负""订单金额=商品金额合计"，测试时验证"无论操作顺序如何，不变量始终成立"。工程语义：前置条件定义"测试的起点约束"，后置条件定义"成功结果的验收标准"，不变量定义"系统状态的全局约束"。测试设计需同时验证"前置条件、后置条件、不变量"三者，重点检查异常执行后不变量是否被破坏。

前置/后置条件与不变量是"状态的前后约束"，用于验证用例执行的正确性与系统状态的一致性。测试时不仅验证"正常执行后置条件满足"，还要验证"异常路径后不变量不被破坏"。这强调"状态约束"而非仅"功能动作"，是高质量用例的重要视角。

• 模型驱动测试（MDT）的思想
• 自动生成状态转换用例
• 与手工设计的优劣

模型驱动测试（Model-Based Testing，MDT）用状态机模型作为测试的"唯一事实来源"，通过工具（如 Spec Explorer、GraphWalker、PyModel）按覆盖准则（状态覆盖/转换覆盖/路径覆盖）自动生成状态转换用例，再把生成的用例执行并断言，实现"建模→生成→执行"的自动化。相比手工设计，优势是：覆盖系统化、无遗漏（工具按准则穷举/抽样）、用例可随模型变更自动重建、可探索大量路径；劣势是：模型建立成本高、需要准确建模（模型错误则用例错误）、生成的用例可能过多或难以理解、对复杂/非确定性系统建模困难。工程上通常"模型驱动自动生成 + 人工补充边界/异常/业务场景"，兼得效率与质量。手工设计灵活、贴近业务，但费时、易遗漏；模型驱动系统、高效，但依赖模型质量。

模型驱动测试是"模型即测试规格"的自动化范式，核心是"用模型保证覆盖、用工具解放手工"。其优劣本质上"效率与覆盖 vs 建模成本与模型质量"的权衡。工程实践是"模型驱动的自动用例 + 人工的补充校验"，扬长避短。

• 主路径与备选路径的概念
• 提取方法
• 路径组合

场景法的主路径（main path）即用例的基本流，是用例正常顺利执行的主流程步骤，从用例描述中"正常情况下系统如何完成目标"的步骤序列提取；备选路径（alternative path）即备选流，是主流程出现异常或可选分支时的路径，从用例中"若…则…"的条件分支、异常处理、可选步骤提取。提取方法：先通读用例，画出主流程步骤链（主路径）；再逐步骤识别"可能出现的分支/异常"，每个分支生成一条备选路径（并标注从主路径哪个步骤进入、如何返回或结束）；最后把主路径与各备选路径组合成端到端测试用例。每条路径覆盖"主流程的某一步 + 一个分支及其处理"，保证主流程与各异常分支都被验证。

主路径与备选路径的提取本质是"对用例进行流程分支分解"。主路径是骨干，备选路径是分支，通过"在分支点插入备选路径"构造完整场景集。这是把用例文档转化为可执行端到端测试路径的标准方法，核心是"穷举分支、清晰标注入口与返回"。

• N-switch 在 GUI 工作流中的应用
• GUI 状态流的建模
• 用例数控制

GUI 工作流（注册、登录、向导）本质是有限状态机，页面/步骤是状态，用户操作（点击、输入、跳转）是事件。N-switch 覆盖在其中的应用：0-switch 覆盖每个页面跳转（每个迁移至少一次），1-switch 覆盖连续两步操作（如"输入错误→重试"），N-switch 覆盖更长的操作序列。例如注册向导"填写信息→验证→提交→成功/失败"，0-switch 覆盖各页面跳转，1-switch 覆盖"填写→验证失败→回填"等连续动作。控制用例数的方法：默认 0-switch 覆盖所有迁移，1-switch 用于高风险连续操作（如验证码、提交、支付），避免 N 过大的 N-switch 穷举；用状态抽象合并等价页面（如多个错误提示页合并为"错误态"），用约束剔除不可能组合，必要时用 pairwise 收敛多步骤组合。即"以 0/1-switch 为主，按风险控制 N"。

GUI 工作流用状态机建模后，N-switch 提供"操作序列"的覆盖度量。但 GUI 步骤多、N 增大会导致路径爆炸，因此工程上以 0/1-switch 为主、按风险控制更高阶 switch，并通过状态抽象与约束控制规模。这保证"覆盖关键操作序列"而不掉入穷举陷阱。

• 分布式状态的一致性问题
• 外部系统状态不一致的测试
• 状态回滚与补偿验证

微服务/分布式系统中，状态分散在多个服务/数据库，状态转换测试面临"状态一致性"与"时序"挑战。外部系统状态不一致时，测试需设计"最终一致"与"对账"场景：验证一方状态更新成功而另一方失败（如订单支付成功但库存服务扣减失败）时，系统是否通过重试、补偿、对账机制最终达到一致，而非停留在中间不一致状态。状态回滚与补偿的验证：构造"分布式事务中间失败"（如扣款成功但发券失败）的场景，验证系统是否触发回滚（回滚已扣款项）或补偿（补发券/标记失败），并验证回滚/补偿的幂等性（重复执行不产生副作用）。测试手段包括故障注入（模拟下游服务超时/失败）、延迟注入、消息补偿机制验证、对账任务验证。核心是验证"最终一致 + 幂等 + 补偿正确"，而非仅验证单服务状态转换。

分布式状态测试的难点是"多服务状态无法原子一致"，需验证"最终一致"与"补偿/回滚"机制。状态转换测试从"单服务状态机"扩展到"跨服务状态的最终一致性"，通过故障注入与对账验证确保系统在异常下能收敛到一致状态。这要求测试设计关注"补偿、幂等、对账"等分布式语义。