2. 首先要解决的是覆盖率问题

　　对这样一个网站，只测试单个页面时，一般问题不大。按照通常的思路来处理，例如搜索产品，订购产品，提交订单，那么问题也不大。可是有时有这样的情况：

　　 用户习惯先添加到购物车，再统一提交

　　 提交到一半，发现有的东西不想要了，去掉一两件，重新提交。

　　 有一部分商品来自购物车，有一部分商品来自新选择的东西。

　　 已经提交的订单，后台还没处理时，用户有权力修改。

 　　说白了，上面状态图里的各种可能组合，都可以发生，用户可以沿着箭头所指的方向，不停的走下去。如果我们有某种组合没有测到，可能发生一些异常。

　　为了避免异常的发生，我们要测试尽量多的组合。组合的覆盖率要达到怎样的程度?

　　根据pairwise[3]的理论，90%以上的bug都是由两两成对的操作导致的。而在网站ajax页面测试中，可能这个数值会稍低一些。依据经验，我们发现大于两步操作的bug还是有一定数量，但是一定要大于三步操作才能发现的bug则很少。

　　因此我们暂时将覆盖率“拍”为“覆盖所有的三步操作组合”。如果测试设计能够达到这个覆盖率，那应当是非常全面了。

　　我们先制定这样一个覆盖率目标，事实上这个三步可以理解为N步，只是一个宏定义，再看怎么能简化。

　　3. 怎样达到这个覆盖率?

　　目标是“覆盖所有三步操作”，有了上面的状态图，通过遍历状态图，可以做到了。画状态图，是不是有点麻烦?

　　进一步，将状态图抽象一下，用状态矩阵来表示，遍历这个状态矩阵，可以穷尽三步操作。

　　那首先要完成状态矩阵这个体力活，根据上面的状态图，图中的页面用0-9来表示，从行号到列号，可以转换为1，不可以转换为0。

　　我们可以得出如下的矩阵：

接下来用程序遍历这个矩阵，找出所有2步及3步的操作，可以得到162个组合case：
0 1
0 2
0 3
0 4
0 2 1
0 2 3
0 2 4
0 2 6
0 3 1
0 3 2
0 3 4
0 3 7
0 4 1
0 4 2
0 4 3
0 4 7
2 1
2 3
2 4
2 6
。。。。

有了这些case，覆盖率一定很全了。

4. 如何缩减这些case

覆盖率目标达到了，但是有162个case，除了单个页面的功能验证，我们还要进行这么多的组合case测试，工作量太大。那么如何缩减这些case？
观察这些case，如果我们挨个做，很多步骤是重复的。例如，上面有这样4个case：
0 3 2
3 2 4
2 4 7
4 7 4
这4个case可以首尾相接，变成 0 3 2 4 7 4。把case中有重复的步骤合起来，4个case变成了一个case。
这个思路不错！按照这个思路，我们可以将case合并起来，4合1，case数量大大缩减。