我如何看待用于测试的状态模型。状态是系统准备好以有计划的方式响应一组定义的事件中的每一个。如果满足以下条件，您就知道系统处于新状态（与刚才相比）：

• 它现在响应的事件集与刚才的事件集不同。
• 系统现在对给定事件的响应与刚才对相同事件的响应不同。

什么算作一个状态。什么“算作一个单独的状态”不仅取决于系统及其行为（实际的或计划的），还取决于您建模的目的。您的目的可帮助您决定要包含哪些详细信息以及要排除哪些详细信息。如果您尝试通过向导测试可能的路径，那么您可能希望将每个页面建模为一个状态。另一方面，如果您尝试测试向导如何验证用户的输入，您可能不太关心每个页面作为一个单独的状态。

那么：你对状态建模的目的是什么？你想测试什么？包括与该目的相关的状态。

请注意，决定将什么放入模型以及省略什么始终是一个挑战。如果您发现您的图表变得过于混乱，状态和事件处于多个详细级别（例如工作流程转换与错误检测和纠正的详细信息），或者如果您的转换线遍布各处，请考虑将不同级别放在不同的位置图表。

探索的例子。这些相对简单，因此很容易练习。而且它们也比普通的电灯开关更丰富，因此它们更具指导性。

• 为汽车的巡航控制建模。
• 启动 PowerPoint，将其置于“演示”模式，然后按 B 键。然后再一次。然后按 W 键。还有哪些其他键可以做有趣的事情？显示幻灯片涉及哪些状态？
• 绘制缺陷跟踪系统中缺陷生命周期（或可能的生命周期）的状态模型。
• 通过银行的审批流程模拟贷款申请的可能流程，或通过保险公司的索赔流程模拟保险索赔的可能流程。

从状态模型生成测试想法。

对于每个状态，询问：

• 我该怎么做可能会导致系统更改状态？我还能做什么？
• 如果我导致模型未针对此状态显示的事件会发生什么？
• 在这种状态下我还没有尝试过哪些事件？
• 这种状态可能涉及哪些变量？如果我改变这些呢？
• 系统在此状态下访问哪些系统资源（例如，数据库事务、内存、域模型中的项目、文件……）。如果这些资源不可用或更改了怎么办？
• 我可以让系统直接进入这种状态，而不是转换模型所说的方式吗？（例如：在 Web 应用程序中，在某个工作流程的中途保存书签。完成或放弃工作流程。单击书签。系统如何处理？）
• 可能还有哪些其他状态未在模型中显示？

对于事件，请询问：

• 我还没有从哪些州尝试过这个活动？
• 如果我要重复、快速、缓慢、随机或......
• 如果我以不同的顺序进行这些活动会怎样？
• 如果我在模型没有响应的状态下执行此事件怎么办？
• 我怎么能以不同的方式处理这个事件（例如不同的数据、不同的时间、不同的输入机制[粘贴与键入、菜单选择与按钮按下与键盘快捷键……]）？
• 可能还有哪些其他事件未在模型中显示？

对于过渡，请询问：

• 如果我在系统进行转换时做一些事情怎么办？
• 我可以使系统进行模型未显示的转换吗？
• 我还没有尝试过哪些转换？

使用多种表示。

• 绘制气泡线状态图。
• 显示与表格相同的状态模型。在旁边，列出可能的状态。在顶部，列出可能的状态。每个单元格代表从开始状态（在侧面列出）到结束状态（在顶部列出）的转换。在每个单元格中，显示将导致该转换的事件。
• 将相同的状态模型显示为不同的表。在旁边，列出可能的状态。在顶部，列出可能的事件。每个单元代表系统在该状态下对该事件的响应。在每个单元格中，显示该事件在该起始状态下发生时系统进入的新状态。

比较表示，注意哪些细节更容易看到，哪些更难。例如，在气泡线图中，很容易看到流程，但很难看到系统可能响应给定事件的所有方式。您还看到了哪些其他差异？

给定模型与创建自己的模型。构建实际行为模型的行为是探索系统或特性的好方法。此外，其他人给你的模型通常是期望行为的模型。它们可能与实际行为不符。将每个“期望的行为”模型视为要验证的东西。

状态转换测试可能是软件测试中最常用的方法。每次测试人员执行一个动作，记录状态，然后考虑下一组可能的动作，他们实际上是在测试状态之间的转换。

有时状态转换图有助于简化具有多个状态和这些状态之间转换的复杂系统，并且可以帮助测试人员找到漏洞，或帮助测试人员将注意力集中在重要路径上。

状态转换测试也是基于模型的测试的支柱。

有关状态转换测试的简单示例和简单图表，请参见http://www.testingmentor.com/imtesty/2011/02/21/state-transition-testing-thinking-in-models/

状态转换图在某些情况下是一种方便的工具，但我不会将它们称为“软件测试技术”。

我不知道这与“沼泽标准时钟和电灯开关”有什么关系。

当您试图了解系统的工作原理时，状态转换图可以成为一种非常方便的交流辅助工具 - 如果您没有在白板上绘制不同的状态，它可以帮助您发现可能错过的转换你的面前。

这是一个真实的例子。让我们选择一个在线零售商。我们将研究订单——它们是可能具有多种不同状态的事物的一个很好的示例，您可能想要测试事物在这些状态之间的移动方式，以及当订单处于状态时您可以对订单执行哪些操作不同的状态。

以下是各州：

• 安全检查 - 一些订单将在下订单前通过例行安全检查
• 已下订单 - 订单已在系统上，正在等待库存可用
• 货物已分配 - 部分或全部库存已分配给订单
• 库存警告 - 部分商品缺货
• 已付款 - 在此阶段，您应该能够看到每件商品的发货日期
• 付款错误 - 付款时出现问题
• Pick in Progress - 订单在仓库系统中，货物实际上正在从货架上取走。现在更改订单详情/收货地址为时已晚！
• 运输 - 它已离开仓库，正在运往您的途中
• 已开票
• 计划取消 - 收到并确认取消请求
• 已取消 - 请求现已执行。

那里有十一个不同的州，一个单独的订单不会通过所有这些州。您可能会看到一些有意义的序列 - 例如已下订单、已分配货物、已付款、正在取货、已发货。但是，如果您只是尝试将序列列表放在一起，您很可能会错过应该测试的转换，您应该能够在图表中轻松发现。

绘制图表将揭示的另一件事是您所掌握的知识空白- 例如，您可能会开始怀疑 - 我可以在任何阶段提出取消请求吗？还是只有某些状态我可以达到“已安排取消”——也许我只能在没有货物分配的情况下取消订单，或者我可以在任何阶段取消订单，直到 Pick In Progress。如果我的订单处于付款错误状态 - 我可以从那里去哪里？如果我付款成功，订单会进入什么状态？如果我不这样做，它会去哪里？有时间限制吗？

试着从给出的例子中画出一个状态转移图，看看你现在知道的能填多少。您不够了解以填写的部分，或者您所获得的信息不明确的地方——这些都是您向业务分析师或产品负责人提出的问题。

这有帮助吗？