第10章状态图方法设计测试用例
测试用例设计方式之状态迁移图法
测试用例设计方式之状态迁移图法在碰到有事务流或由于某种条件成立致使状态改变的软件项目时，如何进行测试用例的设计就比较麻烦。
以前所讲的各类方式，每一个被测对象之间是没有彼此的关联或数据流向发生，碰到如此的事务流软件就要考虑用其他方式进行用例的设计了。
以前在讲操作系统原理时，曾经提到过进程的状态转换。
咱们看以以下图形：当进程从就绪队列中被进程调度算法选中的时候，它就被调进CPU里执行，那个时候进程的状态由就绪状态变换到执行状态；而当该进程执行完毕的时候，是由于所分派的时刻片用完，进程调度算法又回到就绪队列里从头提取。
当进程执行到一按时期时，由于发生I/O事件，例如：外部数据的输入或运行的中间数据的输出，这时CPU必需进行中断处置，那么该进程就由执行状态转变成阻塞状态，等待事件的完成；当事件完成后，进程从阻塞状态就转换成绩绪状态，等待进程调度算法的再一次选中。
以上是操作系统中进程的状态迁移进程。
咱们以QQ登录界面为例子，用来讲解状态图法设计测试用例。
（一）通过对QQ登录界面的分析，咱们看到有4个输入项：ip1：输入帐号ip2：输入密码ip3：点击“登录”按钮ip4：点击“关闭”按钮（二）那么从QQ启动界面开始，进行状态迁移分析：第1轮状态图：第2轮状态图：第3轮状态图：（三）从最后的状态图中能够看出QQ登录界面最后的状态有7种，那么从这7种状态中构造出状态类表：状态/用例用例1 用例2 用例3 用例4 用例5 用例6 用例7 用例8 QQ启动 1 1 1 1 1 1 3 1 1 帐号已输入 2 2 4 3密码已输入 2 2 4“登录”按钮已点击 3 3 2 2帐号/密码已输入 3 3 5 5 4 2 QQ主界面 4 4 6 6 5 退出 2 4 3（四）有一些用例没有列出，望大伙儿自己试探，最后所有的测试用例都省略。
测试用例设计方法-功能图法
测试⽤例设计⽅法-功能图法功能图法定义：功能图由状态迁移图和布尔函数组成.状态迁移图⽤状态和迁移来描述.⼀个状态指出数据输⼊的位置（或时间）,⽽迁移则指明状态的改变.同时要依靠判定表或因果图表⽰的逻辑功能.例,⼀个简化的⾃动出纳机ATM的功能图。
应⽤：1. 功能图介绍⼀个程序的功能说明通常由动态说明和静态说明组成.动态说明描述了输⼊数据的次序或转移的次序.静态说明描述了输⼊条件与输出条件之间的对应关系.对于较复杂的程序,由于存在⼤量的组合情况,因此,仅⽤静态说明组成的规格说明对于测试来说往往是不够的.必须⽤动态说明来补充功能说明.功能图⽅法是⽤功能图FD形式化地表⽰程序的功能说明,并机械地⽣成功能图的测试⽤例.功能图模型由状态迁移图和逻辑功能模型构成.状态迁移图⽤于表⽰输⼊数据序列以及相应的输出数据.在状态迁移图中,由输⼊数据和当前状态决定输出数据和后续状态.逻辑功能模型⽤于表⽰在状态中输⼊条件和输出条件之间的对应关系.逻辑功能模型只适合于描述静态说明,输出数据仅由输⼊数据决定.测试⽤例则是由测试中经过的⼀系列状态和在每个状态中必须依靠输⼊/输出数据满⾜的⼀对条件组成.功能图⽅法其实是是⼀种⿊盒⽩盒混合⽤例设计⽅法。
（功能图⽅法中,要⽤到逻辑覆盖和路径测试的概念和⽅法,其属⽩盒测试⽅法中的内容.逻辑覆盖是以程序内部的逻辑结构为基础的测试⽤例设计⽅法.该⽅法要求测试⼈员对程序的逻辑结构有清楚的了解.由于覆盖测试的⽬标不同,逻辑覆盖可分为:语句覆盖,判定覆盖,判定-条件覆盖,条件组合覆盖及路径覆盖.下⾯我们指的逻辑覆盖和路径是功能或系统⽔平上的,以区别与⽩盒测试中的程序内部的.）2. 测试⽤例⽣成⽅法从功能图⽣成测试⽤例,得到的测试⽤例数是可接受的. 问题的关键的是如何从状态迁移图中选取测试⽤例. 若⽤节点代替状态,⽤弧线代替迁移,则状态迁移图就可转化成⼀个程序的控制流程图形式.问题就转化为程序的路径测试问题（如⽩盒测试）问题了.3. 测试⽤例⽣成规则为了把状态迁移（测试路径）的测试⽤例与逻辑模型（局部测试⽤例）的测试⽤例组合起来,从功能图⽣成实⽤的测试⽤例,须定义下⾯的规则.在⼀个结构化的状态迁移（SST）中,定义三种形式的循环:顺序,选择和重复.但分辨⼀个状态迁移中的所有循环是有困难的.（其表⽰图形省略）。
第07讲、使用状态转换图设计测试用例
• 步骤三、找出什么动作会导致什么状态发生，画出状态转换图
– 第1轮、将所有可能的输入单独加载到被测系统的空闲状态，得到新的状态
输入动作 在人民币金额文本框中输入 数据
动作编号
ip1
ip2 ip3
人民币金额已输入
选择国家 输入汇率
ip1 退出 ip6 ip5 清除 空闲 ip4 错误 提示 ip2
ip6
ip5 ip7
ip4
ip1 所有输入 ip4 显示等价 金额 已完成 ip5
清除
错误 提示
第5轮、
ip6 错误 提示 ip7 ip4 人民币金额 国家已输入 ip6 ip2
国家已选择
ip5 ip6 ip2 ip1
ip5
ip6 退出 ip6 ip5
人民币金额已输入
ip3
ip1
空闲 ip7 ip4 错误 提示
ip3 国家已选择 汇率已输入 ip5 ip7 ip4 ip6 错误 提示
ip1 所有输入 ip4 显示等价 金额 已完成
ip5 ip7
ip4
清除
错误 提示
（2）再找次要动作和状态
国家已选择
点击“计算”按钮
点击“清除”按钮 点击“退出”按钮 在提示错误消息中点击“确 定”按钮
ip4
ip5 ip6
ip7
– 第2轮、将所有可能的输入单独加载到上一步得到的每一个状态中，再得 到新的状态
错误 提示 ip4 ip5 ip6 退出 ip6 ip5 清除
人民币金额已输入
ip2 ip6 ip1
状态转换图法
• 找出软件所有的状态以及导致这些状态发生变化的所有输入动作， 进而用图形的方法把相关联的输入动作和状态联系在一起，真实模 拟用户的操作顺序流程。 • 状态转换图法的核心 – 软件所有的状态 – 导致状态发生变化的所有输入动作
第10章状态图方法设计测试用例
本章学习目标
• 掌握用状态图方法设计测试用例
2/24
内容进度
• 状态图方法
– 需要测试的是什么 – 如何使用画出状态图 – 编写测试用例
• 用状态图方法解决一个实际问题
3/24Βιβλιοθήκη 案例分析• 案例演示并分析
4/24
内容进度
• 状态图方法
– 需要测试些什么 – 如何使用画出状态图 – 编写测试用例
5.1 对“显示金额”加所有可能的输入，经分析，不再有新的 状态产生，即此程序有如下9个状态：
空闲 遗漏国家和人民币 国家已选择 人民币已输入 遗漏人民币信息 遗漏国家信息 完成两种输入 显示等价金额 退出
10/24
内容进度
• 状态图方法
– 需要测试些什么 – 如何使用画出状态图 – 编写测试用例
13/24
状态转换图方法小结
• 软件状态是核心 • 状态图转换方法步骤
14/24
word版本第10章状态图方法设计测试用例测试技术第十章状态图法测试技术本章学习目标把握用状态图方法设计测试用例224测试技术内容进度状态图方法需要测试的是什么如何使用画出状态图编写测试用例用状态图方法解决一个实际问题324测试技术案例分析案例演示并分析424测试技术内容进度状态图方法需要测试些什么如何使用画出状态图编写测试用例
8/24
第四步：对第三步产生的每个新状态分别加所有可能 的输入。
4.1 对“国家已选择、人民币已输”加所有可能的输入（省略 了ip5）。 4.2对“国家未选择”加所有可能的输入（只有ip6） 4.3对“人民币未输”加所有可能的输入（只有ip6）
9/24
第五步：对第四步产生的每个新状态分别加所有可能 的输入。
软件测试技术基础教程10.用例设计方法-状态迁移
根据状态迁移树，抽取测试路径，每个叶子节点构成一条路径，则下图可抽取4条路径。
路径1：预订—已取消 路径2：预订—已支付—已取消 路径3：预订—已支付—已出票—已取消 路径4：预订—已支付—已出票—已使用
4条路径分别构成4条测试规则，需注意的是，仅仅是构成4条规则，针对每个节点的功能仍需
通过等价类及边界值进行功能验证，状态迁移设计法不保证单个功能点的正确性，仅保证状
用例设计方法-状态迁移
状态迁移设计法是关注被测对象的状态变化，在需求规格说明中是否有不可达的状态和非法的状态， 是否可能产生非法的状态迁移等。状态，即被测对象在特定输入条件下所保持的响应形式。对于被测 对象而言，如果根据需求规格抽象出它的若干状态，以及这些状态之间的迁移条件和迁移路径，那么 可以从其状态迁移路径覆盖的角度来设计测试用例。状态迁移设计法的目标是设计足够多的用例，以 覆盖被测对象的所有状态。
案例剖析
案例一：飞机售票系统。 （1）客户向航空公司打电话预定机票，此时机票信息处于“预订”状态。 （2）顾客支付了机票费用后，机票信息变为“已支付”状态。 （3）旅行当天到达机场，拿到机票后，机票信息变为“已出票”状态。 （4）登机检票后，机票信息变为“已使用”状态。 （5）在登机检票之前任何时间都可以取消自己的订票信息，如果已经支付了机票的费用，则 还可以退款，取消后，订票信息处于“已取消”状态。
分析上述需求，可以得到该被测对象一共有预订、 已支付、已出票、已使用、已取消这5种状态。绘 制状态迁移图如右图所示。
由上图得知，针对每个节点，利用有向箭头标识该节 点的输出，仅需关注每个节点本身的输出即可。例如， “预订”节点作为起始节点，仅关注其输出，即下一 个处理节点“已支付”，“已支付”节点仅关注其输 出，下一步可到“已出票”或“已取消”两个节点。 每个节点能够达到的下个节点规则都是根据被测对象 的需求规格确定的。 根据状态迁移图绘制状态迁移树如左图所示。
软件测试第10课-黑盒测试-因果图法
编号
1 2 3
输入
游客支付房款不足，选择单人间且有空房 游客支付房款不足，选择双人间且有空房 游客支付房款不足，未选择任何类型的房间
预期结果
某单人间被打开且系统提 醒房款不足 某双人间被打开且系统提 醒房款不足 所有房间均不被打开且 “房间已满”指示灯为灭 的状态 某豪华间被打开且系统提 醒房款不足 某单人间被打开 某双人间被打开 所有房间均不被打开且房 间已满灯为灭的状态
根据题意，原因和结果如下：
– 原因：
• 1——第一列字符是A； • 2——第一列字符是B； • 3——第二列字符是一数字。
– 结果：
• 21——修改文件； • 22 ——给出信息L； • 23——给出信息M。
其对应的因果图如下：11为中间节点；考虑到原因1和原
因2不可能同时为1，因此在因果图上施加E约束
4 5 6 7
游客支付房款不足，选择豪华间且有空房 游客支付全款，选择单人间且有空房 游客支付全款，选择双人间且有空房 游客支付全款，未选择任何类型的房间
8
游客支付全款，选择豪华间且有空房
某豪华间被打开
编号
9 10
输入
预期结果
游客不进行支付，选择单人间且有空房 所有房间均不被打开且房间已 满灯为灭的状态 游客不进行支付，选择双人间且有空房 所有房间均不被打开且房间已 满灯为灭的状态
内所有房款）或支付房间房款不足（仅支付订金），选择“单人
间”、“双人间”或“豪华间”，若该类型房间有空房，则相应类 型的房间被开启；若该类型房间无空房，则“房间已满”提示灯亮。
此时，支付房款不足的游客选择该类型的房间，则该类型的房间不
被开启且提示办理退款；若此期间，该房间类型有客人退房，则 “房间已满”指示灯灭，该类型房间的某间房被开启的同时提醒游
软件测试各章知识点总结
软件测试各章知识点总结第一章：软件测试概述软件测试是指为了发现软件中的错误和问题，评估软件质量，确保软件功能正常的过程。
软件测试的目的是验证软件是否符合用户的需求和期望，以及确保软件的质量达到一定的标准。
软件测试在整个软件开发过程中起着非常重要的作用，它能够帮助开发团队及时发现和修复问题，提高软件的稳定性和可靠性。
软件测试的基本原则包括全面性、系统性、可靠性和性能。
全面性指测试应该覆盖所有可能的情况，包括正常情况和异常情况；系统性指测试应该以系统为单位进行，而不是单个模块或功能；可靠性指测试结果应该是可靠的、准确的；性能指测试应该关注软件的性能表现。
软件测试的方法可以分为静态测试和动态测试。
静态测试是指在软件开发的早期阶段进行的，包括代码审查、设计审查和使用静态分析工具进行分析。
动态测试是指在软件开发的后期阶段进行的，包括单元测试、集成测试、系统测试和验收测试。
软件测试的类型包括功能测试、性能测试、安全测试、兼容性测试、可靠性测试等。
功能测试是验证软件功能是否符合用户需求的测试；性能测试是验证软件在各种条件下的性能表现的测试；安全测试是验证软件的安全性和可靠性的测试；兼容性测试是验证软件在不同平台和环境下的兼容性的测试；可靠性测试是验证软件的稳定性和可靠性的测试。
第二章：软件测试流程软件测试的流程包括测试计划、测试设计、测试执行、测试评估和测试报告。
测试计划是在测试开始之前进行的，包括确定测试目标、测试方法、测试资源和测试进度。
测试设计是在测试执行之前进行的，包括确定测试用例、测试数据和测试环境。
测试执行是在测试设计之后进行的，包括执行测试用例、记录测试结果和发现问题。
测试评估是在测试执行之后进行的，包括评估测试结果、计算测试覆盖率和分析测试效果。
测试报告是在测试评估之后进行的，包括总结测试结果、提出改进建议和撰写测试报告。
软件测试的自动化是指利用自动化测试工具进行软件测试的过程。
自动化测试包括测试脚本的编写、测试数据的准备和测试环境的配置。
软件测试测试用例编写及执行规范
软件测试测试用例编写及执行规范第1章测试用例编写概述 (4)1.1 测试用例定义 (4)1.2 测试用例目的 (4)1.3 测试用例编写原则 (4)第2章测试用例结构 (4)2.1 测试用例编号 (4)2.2 测试用例标题 (4)2.3 测试用例描述 (4)2.4 预置条件 (4)2.5 测试步骤 (4)2.6 预期结果 (4)2.7 实际结果 (4)2.8 测试结论 (4)第3章测试用例编写规范 (4)3.1 编写规则 (4)3.2 测试用例命名规范 (4)3.3 测试用例描述规范 (4)3.4 测试步骤与预期结果规范 (4)第4章测试用例执行流程 (4)4.1 测试用例执行准备 (4)4.2 测试用例执行过程 (4)4.3 测试用例执行结果记录 (5)4.4 测试用例执行异常处理 (5)第5章测试用例执行管理 (5)5.1 测试用例执行计划 (5)5.2 测试用例执行进度监控 (5)5.3 测试用例执行结果汇总 (5)5.4 测试用例执行报告 (5)第6章测试用例评审 (5)6.1 评审目的 (5)6.2 评审流程 (5)6.3 评审标准 (5)6.4 评审结果处理 (5)第7章测试用例维护 (5)7.1 测试用例更新时机 (5)7.2 测试用例更新流程 (5)7.3 测试用例版本管理 (5)7.4 测试用例维护记录 (5)第8章测试用例管理工具 (5)8.1 测试用例管理工具选型 (5)8.2 测试用例管理工具使用 (5)8.3 测试用例管理工具维护 (5)8.4 测试用例管理工具优化 (5)第9章自动化测试用例编写 (5)9.1 自动化测试用例特点 (5)9.2 自动化测试用例编写规范 (5)9.3 自动化测试用例编写工具 (5)9.4 自动化测试用例编写实践 (5)第10章自动化测试用例执行 (5)10.1 自动化测试用例执行策略 (5)10.2 自动化测试用例执行过程 (6)10.3 自动化测试用例执行结果分析 (6)10.4 自动化测试用例执行优化 (6)第11章移动端测试用例编写与执行 (6)11.1 移动端测试用例特点 (6)11.2 移动端测试用例编写规范 (6)11.3 移动端测试用例执行策略 (6)11.4 移动端测试用例执行实践 (6)第12章测试用例编写与执行最佳实践 (6)12.1 测试用例编写最佳实践 (6)12.2 测试用例执行最佳实践 (6)12.3 测试用例管理最佳实践 (6)12.4 测试团队协作最佳实践 (6)第1章测试用例编写概述 (6)1.1 测试用例定义 (6)1.2 测试用例目的 (6)1.3 测试用例编写原则 (7)第2章测试用例结构 (7)2.1 测试用例编号 (7)2.2 测试用例标题 (7)2.3 测试用例描述 (8)2.4 预置条件 (8)2.5 测试步骤 (8)2.6 预期结果 (8)2.7 实际结果 (8)2.8 测试结论 (8)第3章测试用例编写规范 (8)3.1 编写规则 (8)3.1.1 测试用例目的明确 (8)3.1.2 测试用例独立 (9)3.1.3 测试用例简洁明了 (9)3.1.4 测试用例分类 (9)3.1.5 测试用例优先级 (9)3.2 测试用例命名规范 (9)3.2.1 命名原则 (9)3.2.2 命名示例 (9)3.3 测试用例描述规范 (9)3.3.1 测试用例标题 (9)3.3.2 测试用例描述 (9)3.3.3 描述示例 (10)3.4 测试步骤与预期结果规范 (10)3.4.1 测试步骤 (10)3.4.2 预期结果 (10)3.4.3 步骤与预期结果示例 (10)第4章测试用例执行流程 (11)4.1 测试用例执行准备 (11)4.2 测试用例执行过程 (11)4.3 测试用例执行结果记录 (11)4.4 测试用例执行异常处理 (12)第5章测试用例执行管理 (12)5.1 测试用例执行计划 (12)5.2 测试用例执行进度监控 (13)5.3 测试用例执行结果汇总 (13)5.4 测试用例执行报告 (13)第6章测试用例评审 (14)6.1 评审目的 (14)6.2 评审流程 (14)6.3 评审标准 (14)6.4 评审结果处理 (15)第7章测试用例维护 (15)7.1 测试用例更新时机 (15)7.2 测试用例更新流程 (16)7.3 测试用例版本管理 (16)7.4 测试用例维护记录 (16)第8章测试用例管理工具 (17)8.1 测试用例管理工具选型 (17)8.2 测试用例管理工具使用 (17)8.3 测试用例管理工具维护 (17)8.4 测试用例管理工具优化 (18)第9章自动化测试用例编写 (18)9.1 自动化测试用例特点 (18)9.2 自动化测试用例编写规范 (18)9.3 自动化测试用例编写工具 (19)9.4 自动化测试用例编写实践 (19)第10章自动化测试用例执行 (20)10.1 自动化测试用例执行策略 (20)10.2 自动化测试用例执行过程 (20)10.3 自动化测试用例执行结果分析 (20)10.4 自动化测试用例执行优化 (21)第11章移动端测试用例编写与执行 (21)11.1 移动端测试用例特点 (21)11.2 移动端测试用例编写规范 (21)11.3 移动端测试用例执行策略 (22)11.4 移动端测试用例执行实践 (22)第12章测试用例编写与执行最佳实践 (23)12.1 测试用例编写最佳实践 (23)12.2 测试用例执行最佳实践 (23)12.3 测试用例管理最佳实践 (24)12.4 测试团队协作最佳实践 (24)第1章测试用例编写概述1.1 测试用例定义1.2 测试用例目的1.3 测试用例编写原则第2章测试用例结构2.1 测试用例编号2.2 测试用例标题2.3 测试用例描述2.4 预置条件2.5 测试步骤2.6 预期结果2.7 实际结果2.8 测试结论第3章测试用例编写规范3.1 编写规则3.2 测试用例命名规范3.3 测试用例描述规范3.4 测试步骤与预期结果规范第4章测试用例执行流程4.1 测试用例执行准备4.2 测试用例执行过程4.3 测试用例执行结果记录4.4 测试用例执行异常处理第5章测试用例执行管理5.1 测试用例执行计划5.2 测试用例执行进度监控5.3 测试用例执行结果汇总5.4 测试用例执行报告第6章测试用例评审6.1 评审目的6.2 评审流程6.3 评审标准6.4 评审结果处理第7章测试用例维护7.1 测试用例更新时机7.2 测试用例更新流程7.3 测试用例版本管理7.4 测试用例维护记录第8章测试用例管理工具8.1 测试用例管理工具选型8.2 测试用例管理工具使用8.3 测试用例管理工具维护8.4 测试用例管理工具优化第9章自动化测试用例编写9.1 自动化测试用例特点9.2 自动化测试用例编写规范9.3 自动化测试用例编写工具9.4 自动化测试用例编写实践第10章自动化测试用例执行10.1 自动化测试用例执行策略10.2 自动化测试用例执行过程10.3 自动化测试用例执行结果分析10.4 自动化测试用例执行优化第11章移动端测试用例编写与执行11.1 移动端测试用例特点11.2 移动端测试用例编写规范11.3 移动端测试用例执行策略11.4 移动端测试用例执行实践第12章测试用例编写与执行最佳实践12.1 测试用例编写最佳实践12.2 测试用例执行最佳实践12.3 测试用例管理最佳实践12.4 测试团队协作最佳实践第1章测试用例编写概述测试用例是软件测试过程中的核心组成部分，它对于保证软件质量、发觉潜在缺陷具有重要意义。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
空闲 遗漏国家和人民币 国家已选择 人民币已输入 遗漏人民币信息 遗漏国家信息 完成两种输入 显示等价金额 退出
10/24
内容进度
• 状态图方法
– 需要测试些什么 – 如何使用画出状态图 – 编写测试用例
• 用状态图方法解决一个实际问题
5/24
如何画出状态图
• 第一步：列出被测系统的输入事件
6/24
第二步：对空闲状态（程序刚启动时的状态）加所 有可能的输入，判断产生哪些新状态。
7/24
第三步：对第二步产生的每个新状态分别加所有可能 的输入。
3.1 对“人民币金额已输入”加所有可能的输入。 3.2 对“国家已选择”再加所有可能的输入（图中加ip5输入的 线省略了，因为其指向退出状态，不产生新状态）。 3.3对“国家未选择、人民币未输”加所有可能的输入（ip6） 3.4对“退出”加所有可能的输入（没有）
第十章 状态图法
本章学习目标
• 掌握用状态图方法设计测试用例
2/24
内容进度
• 状态图方法
– 需要测试的是什么 – 如何使用画出状态图 – 编写测试用例
• 用状态图方法解决一个实际问题
3/24
案例分析
• 案例演示并分析
4/24
内容进度
• 状态图方法
– 需要测试些什么 – 如何使用画出状态图 – 编写测试用例
8/24
第四步：对第三步产生的每个新状态分别加所有可能 的输入。
4.1 对“国家已选择、人民币已输”加所有可能的输入（省略 了ip5）。 4.2对“国家未选择”加所有可能的输入（只有ip6） 4.3对“人民币未输”加所有可能的输入（只有ip6）
9/24
第五步：对第四步产生的每个新状态分别加所有可能 的输入。
• 用状态图方法解决一个实际问题
11/24
编写测试用例
测试用例流程表
设计测试用例
12/24
编写测试用例
减少测试用例的方法
每种状态至少访问一次。 测试看起来最常见最普遍的状态转换。我们可以根据审查产品说 明书时分析收集到的信息确定某些用户情况可能比其他更常见。 测试状态之间最不常用的分支。这些分支是最容易被产品设计者 和程序员忽视的。 测试所有错误状态及其返回值。错误没有得到正确处理、错误提 示信息不正确、修复错误时未正确恢复软件等情况是常有的。 利用工具自动执行状态转换测试。
13/24
状态转换图方法小结
• 软件状态是核心 • 状态图转换方法步骤
14/24