前面我们已经分析讨论过了等价类、边界值、因果图、判定表、错误猜测等测试用例设计方法，但是我们知道，每一种方法都可以提供一组具体的有用的测试用例，但是都不能提供一个完整的、覆盖全面的测试用例集。因此，我们需要组合这些已知的测试用例设计方法、发挥各项测试设计方法的优点，设计出用例数少且覆盖全面的测试用例集。一组合理的策略如下：
用例设计测试策略
下述组合测试用例设计测试策略并不能保证可以发现程序所有的bug，但实践证明一个合理的折中方案。具体的方法如下：
（1）如果规格说明中包含输入条件组合的情况，应该首先使用因果图分析方法。
（2）在任何情况下都应该使用边界值分析方法。一定要记住，需要同时对输入和输出的边界进行分析。边界值分析可以产生一系列补充的条件。这些补充条件通常可以整合到因果图分析中。
（3）应为输入和输出确定有效和无效等价类，在必要情况下对上面确认的测试用例进行补充。
（4）使用错误猜测技术增加更多的测试用例。
（5）针对上述测试用例集检查程序的逻辑结构。应使用判定覆盖、条件覆盖、判定/条件覆盖或多重条件覆盖准则（最后的一个最为完整）。如果覆盖准则未能被前四个步骤中确定的测试用例所满足，并且满足准则也并非不可能（由于程序的性质限制，某些条件的组合也许是不可能实现的），那么可以增加足够数量的测试用例，以使覆盖准则得到满足。
业务特性测试策略
用例设计的结果是业务能力和测试能力、团队能力结合的综合体现。上述主要针对测试用例设计组合的测试策略的方法，这里，也谈谈个人对业务特性测试设计的测试策略：
（1）针对单特性考虑测试用例设计，单特性内可以考虑采用分而治之策略划分特性。不同的产品开发团队的组成方式可能不同。我经历过的有按照产品模块划分的、也有按照特性划分的。不管是以哪种形式划分，在分析规格时，先拆分业务特性（按业务模块或子特性）理解进行用例设计。业务颗粒度不大情况下会分析的更透彻，也就可以更有针对性的进行用例设计。
（2）考虑新特性（新增或修改）与产品其他特性的关联性，补充测试用例设计。这里最重要的一点是测试设计人员必须非常熟悉业务。同时，最好有产品特性矩阵。否则，很难完整的分析出特性间的影响关系。
（3）组织用例评审。邀请SE、TSE、MDE、TM等核心成员评审，利用团队的力量保证用例覆盖全面性。
（4）根据代码覆盖率执行结果重新设计测试用例去覆盖未覆盖到的测试逻辑。某些异常场景确实无法构造，也必须安排开发MDE进行代码走读确保逻辑无问题。这一条通常有要求执行代码覆盖率操作的产品才会实施。
参考资料
《黑盒测试用例设计方法》