网上查找了大量关于状态迁移法的知识，都没有得到自己想要的内容，因此自己动手来记录这个测试用例设计方法，首先我在mantis上筛选了一些常用的缺陷状态，如下；
| 新建 | new | 测试人员新建一个缺陷记录 |
| 已分派 | assigned | 将缺陷指派给对应的开发 |
| 已确认 | confirmed | 开发确认这是的确是缺陷，并且后续会处理 |
| 打回 | feedback | 开发认为这不是缺陷，打回给测试，不做修改 |
| 已打开但未处理 | open | 将缺陷置为打开状态，开始修改 |
| 已解决但未验证 | resolved | 缺陷已被开发修改，但没有被测试 |
| 已解决并已验证 | fixed | 缺陷已被开发修改，并且测试通过 |
| 重新打开 | reopen | 被开发修改过的缺陷，未通过测试验证 |
| 延期 | suspended | 缺陷当前不做修改或无法修改，需要延期处理 |
| 已关闭 | closed | 缺陷已确认被修复，并没有再复现，关闭 |
除了上述的状态以外，还有acknowledged(公认)、unable to reproceduce(无法复现)、duplicate(重复问题)、not fixable(无法修复)、no change required(不是问题)、won't fix(不做修改)等等
既然状态已经得到了，那么接下来就开始尝试使用状态迁移法来设计用例，
第一步：
先在表格中找出有关联的状态，并标记出来：行中表示上一个状态，列中表示下一个状态，归纳出的表格如下图所示；
| 新建 | 已分派 | 已确认 | 打回 | 已打开但未处理 | 已解决但未验证 | 已解决并已验证 | 重新打开 | 延期 | 已关闭 | |
| 新建 | ||||||||||
| 已分派 | 1 | 1 | ||||||||
| 已确认 | 1 | |||||||||
| 打回 | 1 | |||||||||
| 已打开但未处理 | 1 | 1 | 1 | 1 | ||||||
| 已解决但未验证 | 1 | |||||||||
| 已解决并已验证 | 1 | |||||||||
| 重新打开 | 1 | |||||||||
| 延期 | 1 | |||||||||
| 已关闭 | 1 | 1 | 1 |
假设缺陷生命周期的起始状态均为新建。
第二步：
绘制状态转换流程图，其实这个步骤感觉可以省略，直接整理向下或者向右的树形图，如下；
| 新建 | 已分派 | 已确认 | 已打开但未处理 | |||
| 延期 | 已打开但未处理 | |||||
| 打回 | 已分派 | |||||
| 已关闭 | ||||||
| 已打开但未处理 | 已解决但未验证 | 已解决并已验证 | 重新打开 | 已打开但未处理 | ||
| 已关闭 | ||||||
| 已关闭 | ||||||
以上就是整理出的向右的状态迁移树形图，每一个分支都是一个测试路径，接下来我们就可以做，
第三步：
将第二步的树形图转换成状态路径，如下：
- 新建->已分派->已确认->已打开但未处理
- 新建->已分派->已确认->延期->已打开但未处理
- 新建->已分派->打回->已分派
- 新建->已分派->打回->已关闭
- 新建->已分派->已打开但未处理->已解决但未验证->已解决并已验证->重新打开->已打开但未处理
- 新建->已分派->已打开但未处理->已解决但未验证->已解决并已验证->已关闭
- 新建->已关闭
从上面罗列的状态路径可以看出，有些路径的最后的状态并不缺陷实际的最终状态，主要是因为这些路径的后续状态在其他状态中已经体现。
第四步：
根据这些测试路径设计具体的用例和数据。
来源：https://www.cnblogs.com/suanmiaoup/p/12166571.html