一、关于”好的“测试用例
　　在设计测试用例的时候有多种设计方法和策略可以使用，使得测试用例设计得更丰富，尽可能覆盖到更多的程序路径和功能场景。常见的测试用例设计方法被提到最多的就是等价类划分、边界值分析、错误推断法等，而且在常规思路中希望测试用例越全面越完整越好。但是在复杂测试问题场景中，设计出完整全面的测试用例不是不可能，但是数量巨大的测试用例往往严重降低了测试效率，甚至可以说不是很好的用例设计。从我自己的经验，作为一名测试新手，最开始设计测试用例的时候希望做到”全面“，眼花缭乱的用例乍一看很是惊艳，可是真正测试起来便知其效率有多低下、冗余有多繁杂。因而，设计出全面完整的测试用例不是难事，难在如何将用例做减法。也就是说，如何用尽可能少的测试用例覆盖到更多的程序路径和功能场景，这才算是一份‘好的”的测试用例。
　　二、关于PairWise策略
　　PairWise（又称全对偶）策略是组合测试中的一种设计测试用例的方法，在很早之前就被提出，且被多项文章和实验证明是成效显卓。为了更好地理解PairWise，我们先假设一个常见的测试场景。假如我们测试公司电脑能够正常打印，需要测试两个因素，操作系统和打印机类型。假设操作系统有win7、mac、win8三个，打印机类型有EP、HP两种。我们此时设计一下测试用例：

　　假如此时我们再增加一个测试因素，打印类型（打印单面、打印双面两个值），按照“全面”的测试用例设计方法，此时我们的测试用例个数达到6*2=12个，当然这也可以接受。

　　但是我们考虑到这其中有冗余的情况，比如7号测试用例win7-HP这两个因素组合的情况已经由1号测试用例测试过了，且7号测试用例HP-双面这两个因素的组合也会由8号测试用例测试。因而7号测试用例就是多余的，因为它可能发现的bug，1号和8号完全可以测试出来。按照这个思路，我们需要的是在一组测试用例中能够保证至少一个用例中的每个其他变量的每个取值都配对过。这样的话我们只要6个测试用例就够了：

　　事实上，如果这三个参数中的某两个参数的值的任意不同的组合会触发一个bug的话，那表格上的那组测试用例也可以发现该bug。
　　相对于所有组合情况来说，PairWise的测试效率要高很多。例如，如果你想测试10个参数且每个参数都有26个值的功能，所有组合情况将导致存在141167095653376个测试用例。而PairWise测试法就只要测试1094个测试用例就可以。因而善于利用PairWise设计测试用例，可以利用较少的测试用例覆盖尽可能全的测试路径。

　　三、PairWise策略设计用例实践
　　在云阅读接口测试的用例设计过程中，有时会用到PairWise设计策略，以保证测试覆盖率的同时提升测试效率。比如在最近的”阅读圈评论大师榜“的接口测试中，测试人员要设计不同的大师评论，查看调用接口时返回的数据是否完整。大师评论设计的因素主要有：评论主体（书籍、资讯、文章）、选中文字还是不选中文字（选中、不选中）、原评论还是子评论（原评论、子评论）。其中是否选中文字只是针对书籍或者文章这两种评论主体才会有的区分。如果我们按照全面完整的思路设计测试用例时，我们会得到4+2+4=10个测试用例。

　　如果我们按照PairWise策略设计测试用例的话，我们只需要6个测试用例就可以了：

　　这样的话我们只需要设计6种评论就可以满足测试要求了，可以提高测试效率。那这样设计测试用例是否是完备的呢？验证一下。从倒数第二个表格中，我们可以看一下省掉的这4个测试用例，其中的一个是4号测试用例（书籍+选中+子评论），这个用例需要验证的点包括：接口返回书籍详细信息、接口返回评论的选中文字、接口返回子评论和原评论的全部信息，所以这个用例完全可以由1号测试用例（书籍+选中+原评论）与6号测试用例（文章+选中+子评论）这两个测试用例验证出。也就是说，4号用例能测试出来的bug，1号与6号也能测试出来。自然我们可以不需要4号测试用例。当然，这也仅仅是使用PairWise策略设计测试用例的一次小实践，10个用例减少到6个，但是这种测试策略和原理掌握了的话，在以后更为复杂繁琐的测试场景中，合理地利用PairWise能够更大地减少不必要测试用例的数量、提高测试效率。PairWise自然也有其缺点，就是难以发现在特殊因素组合情况下产生的bug，但是这种策略的优势体现在复杂的测试场景中在比较完备的测试用例和测试效率之间的平衡折衷。