当然，不会那么巧，所有的case都能4合1、3合1，我们还会有些疑问：
1. 是不是所有的case都可以合并？ 还是上面的例子只是个特例？
2. 合并到什么程度？是否需要把10多个三步操作都合并起来，得到一个20多步的操作？ 这个问题经过讨论，一般认为操作步骤在6~8步比较合理，组合的case不是很大，所能验证的内容也比较多，对于测试人员来讲是“舒服”的。

这个思路是不是可行，我们先合并一下试试看！

5. 合并后的结果

有了思路开始做。
先尝试一下把这162个小于3步的操作合并成一些6步的操作。我们采用这样的算法：

1. 先算出所有6步操作，记为集合A； 将所有小于等于3步操作的集合记为B；集合C为终结果集合，目前是空集；
2. 算出每一个6步操作能够包含几个2-3步的case，并将包含大值记为max；
3. 如果max>1，则将能够取得max值的那个6步操作，加入集合C；把这个6步操作和其所包含的2-3步操作从各自的集合中删除；返回2继续；
4. 如果max=1，则将集合B中剩余的元素全部加入C中，得到结果集合C，退出

简言之，算法会从所有6步操作的集合中选出能够包含这162个case的小集合，其中可能有部分case无法合并，无法合并的case直接进入结果集。这个算法可能不是优的，但是已经尽可能找到了那个小集。
经过算法合并以后，得出了如下结果：

用多步操作来合成3步操作，需要 35个case，这35个case覆盖了162个case中的151个：
0 2 3 2 3 4
0 3 7 2 4 1
0 4 2 6 2 1
4 7 5 8 4 3
2 6 5 9 5 1
5 2 6 3 7 1
5 3 7 3 7 4
5 4 3 2 6 1
。。。。。。

剩余11个case无法组合：
0 1
0 2 1
0 3 1
0 4 1
8 2 3
8 2 4
8 3 1
8 3 4
8 4 1
8 4 2
9 5 2
这些无法组合的case，是因为有的状态没有出路，走到这里会终结了。
于是，我们用35个6步的case，覆盖了原来162个case中的151个，剩余11个case，需要再单独验证一下。总case数为35+11=46个，在可以接受的范围内。

我们同样可以尝试用5步操作或7步操作来覆盖2-3步的操作，这里的2-3步也好，6步也好，都可以看作是宏定义，效果相似，case数稍有变化。我们可以尝试几个参数，找到覆盖率和工作量的佳组合。

6. 人力成本分析

在整个过程中，需要人力投入的工作只有初的状态矩阵，对于某个网站来说，这个状态矩阵相对稳定，变化不大，后期维护代价也比较小。
将状态矩阵拷贝为txt格式，即可作为程序的输入，执行程序即可得到操作序列。将矩阵的title也读入，直接把序列号替换为title，可以直接当做case来用了。
有了这样的一组case，我们可以避免依赖经验的测试或随机测试，又能保证覆盖率了。

五、 总结

如上所述，我们用遍历状态矩阵的方法，首先得到了所有2-3步操作组合。这一个“爆炸”的case集包括162个用例。通过case组合的方式，将162个测试用例变成了35+11=46个测试用例，在保证case覆盖率的同时，缩减case数到一个可测试的范围内。
在维护成本方面，只要维护一个状态矩阵和一个一劳永逸的小算法程序，即可得到测试case与状态图，比较方便。