軟件開發設計具有高內聚低耦合的思想，其實測試用例設計同樣需要遵循高內聚低耦合的思想。
舉例說明：
一個軟件功能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，降低項目風險，提高項目質量；代價是編寫用例時間會更長一些；