软件开发设计具有高内聚低耦合的思想，其实测试用例设计同样需要遵循高内聚低耦合的思想。
举例说明：
一个软件功能A，具有三个子功能A1、A2、A3，可以使用下面两种方法来设计测试用例
1、第一种方法：一个用例（一组用例）覆盖3个子功能，即Test_A1_A2_A3;
2、第二种方法：3个单独的用例（3组用例），分别测试3个子功能，即Test_A1、Test_A2、Test_A3；
对以上2种方式进行对比分析：
第一种方法优势：
1、适用于小项目或简单功能；
2、用例编写快速，不容易产生冗余用例；
第一种方法不足：
1、复杂项目或功能不适用；
2、可维护性不好，当程序存在需求变更时，用例杂糅在一起，耦合度较高，不易维护；
3、可执行性不好，用例较长，步骤较多，执行起来相对麻烦；
4、如果第一轮测试过程中A1存在阻塞，或A1有bug，那么A2、A3不会被测试；这样第一轮测试就存在一些未测试用例；
后续存在以下2种场景假设（为了说明后果，做了一些极端假设）：
假设1：A1修复后，执行Test_A1_A2_A3，发现A2存在bug，A2修复后，执行Test_A1_A2_A3，发现A3存在bug，这样后面几轮测试中总会出现新提出的bug，这不符合尽早测试尽早暴露bug的测试原则；如果所有用例都这么设计（也就是存在一定数量的A2、A3），A2、A3涉及的bug数量又较多，影响bug收敛趋势，那么测试人员可能需要像项目经理、测试经理做出解释了；
假设2：A1修改时间较长，到了项目后期才修改好，此时再执行Test_A1_A2_A3，发现A2或A3存在bug，且bug比较严重，此时临近上线，严重bug暴露时间较晚，不好修复，项目上线时间存在风险；修改A2或A3，对程序影响较大，还存在一定的质量风险；
综上，用第一种方法设计，用例可维护性不好，测试时可能会存在bug延迟发现，影响上线时间和程序质量的情况；
第二种方法优势：
1、适合任何功能或项目，无论大小；
2、可维护性好，当存在需求变更时，只需要修改对应功能即可；
3、可执行性好，单独的用例更短小，步骤相对少，执行起来思路也更清晰；
4、符合测试尽早执行原则，bug在第一轮测试中更容易及早暴露，不会出现A1阻塞，A2、A3就不测试的情况；
第二种方法不足：
1、用例数量更多，看起来更繁杂，编写时间更长；
2、如果存在一些前置条件重复的情况，用例可能存在冗余操作；（可以通过合理设计用例顺序与结构，尽量避免此种情况）
综上，第二种方法更合理；可维护性、可执行性好，及早暴露bug，降低项目风险，提高项目质量；代价是编写用例时间会更长一些；