無論缺陷預防
工作貫徹落實地多好，軟件組件總有缺陷。這很明顯，因為開發商無法阻止/消除
軟件開發周期的所有缺陷。因此，軟件必須進行徹底的
測試，然后才交付給最終用戶。測試人員的責任是：設計既可以（ⅰ）找軟件缺陷，又能（ii ）評估該軟件的性能，可用性和可靠性等方面的測試。
現在，為了實現這些目標，測試人員必須（往往是從一個非常大的執行域中）選擇和/或制定
測試用例的有限數量。不幸的是，完整的測試通常不是在這個范圍，預算和時間的約束內實現和/或執行的。重要的是，當測試開始失控且不按計劃地運行時，由于預期無法實際，測試人員往往承受了來自管理層和利益相關者的巨大壓力。
因此，測試人員必須有效地計劃測試并制定正確的測試用例，選擇并執行合適的用例，監控過程，以確保有效利用工作資源和時間。所以，要列出這些無疑是一項艱巨的任務；要有效地實施，測試人員需要受過適當的教育和培訓并擁有贏得管理層支持的能力。
一般情況下，測試人員會用兩種不同的測試方法，其中，使用常規方法，測試人員主要是嘗試用所有可能的輸入去測試一個模塊或組件，用所有可能的軟件結構去實踐。盡管這種做法仍在使用，測試人員卻在慢慢灌輸推理軟件的一切的價值，最終使他們能夠檢測出所有可能存在的缺陷。但見多識廣且有學問的測試員們都明白，這在現實或經濟上是不可行，不可實現的目標。
現在，另一種方法可能就是讓測試員們隨機選擇測試輸入，希望這些測試能將大的缺陷找出來。不過，測試專家認為，隨機生成的測試輸入在評估系統的質量屬性方面表現紀錄欠佳。所以，從測試的角度來看，這是一個無休止的爭論和懸而未決的問題。盡管如此，我們還是認為，測試員的最終目標是了解測試的功能、輸入/輸出域和使用環境，等等。
同樣，對于某些特定類型的測試，測試人員也需要詳細地了解代碼是如何構造的。此外，測試人員也需要利用關于常在軟件開發或維護過程中生成的特定缺陷的知識。有了這些信息，測試者就必須明智地選擇測試輸入的子集，以及被認為最有可能找測試過程中條件和限制內的缺陷的測試輸入組合。然而，這個過程需要時間和精力。所以，測試人員知道且贊同：只有開發出基于執行的測試的有效測試用例，才能最大化和/或優化對時間和資源的利用。
“有效測試用例”我們是指：“一個很可能找出缺陷的測試用例” 。因此，制定有效測試用例的能力對于一個組織邁向一個更高質量的測試過程來說是非常重要的；反過來，一個組織邁向一個更高質量的測試過程對制定有效測試用例的能力也有許多積極影響。
例如，如果測試用例是有效的，那么：
檢測缺陷的概率更大。
更有效地利用組織資源。
測試再用的可能性更高。
更符合測試、項目進度、預算，更重要地，提供更高質量的軟件產品的可能性。
測試用例設計方法 - 概念化
上面介紹了有效測試用例的種種好處，但縝密考慮測試人員用來設計這些有效測試用例的方法也同樣重要。為了回答這個問題，有必要把軟件作為一個精心設計的產品來查看和/或檢查。現在，有了這個觀念，就有兩個基本方法可以用來設計測試用例：
黑盒（有時也稱為功能或規格）測試方法。
白盒（有時也稱為clear或透明盒 ）測試方法。
使用
黑盒測試方法，測試人員把SUT （測試中的軟件）當作一個不知道其內部結構（即如何運作）的不透明盒子，測試人員只知道它的作用。使用這種方法的SUT的大小可以是一個簡單的模塊、成員函數、對象群、一個子系統、或一個完整的軟件系統。此外， SUT的基礎行為或功能的描述可以由正式規格，輸入/處理/輸出圖（ IPO），或一套定義明確的先決、后置條件來提供；重要的是，另一個值得一提的信息來源是：需求規格說明文檔，通常描述SUT的功能，輸入及預期輸出。現在，鑒于上述來源，測試員提供指定輸入到SUT，進行測試運行，然后確定所產生的輸出是否與說明文檔中提供的一致。因為黑盒測試方法只考慮了軟件的行為和功能，它通常被稱為
功能測試，或基于規范的測試。這種方法特別有用，極有助于找到要求和規格中的缺陷。
與此相反，
白盒測試方法關注將被測試的軟件的內部結構。因此，使用白盒測試方法來設計測試用例，測試人員應該先了解結構，且為了實現這一目標，必須可隨時參考和理解代碼或適當的類偽代碼的要求。一旦對結構有了必要的了解，測試者就可以選擇合適的測試用例去實踐特定的內部結構要素，并確定它們是否正常工作。例如，測試用例通常被設計來實踐所有語句或發生在一個模塊或成員函數中的真/假分支。但是，由于白盒測試的設計，執行和結果分析非常耗時，這種方法被限制和/或通常只適用于軟件的小部分，如模塊或成員函數。然而，白盒測試方法對于找出設計和基于代碼的控件的邏輯缺陷和順序缺陷，初始化缺陷和數據流缺陷等特別有用。
然而，從測試員的角度來看，要實現向用戶提供低缺陷高質量的軟件的目標，必須把這兩種方法都用來設計測試用例。另外，這兩種方法都支持測試員選擇有限數量的將被用于測試的測試用例。這兩種方法可以相互補充，因為每個都或許有助于找到某些特定類型的缺陷。重要的是，有了使用這兩種方法設計出的一組測試用例，測試員找到SUT中各種不同類型缺陷的機會就增加了。
測試員還有一套有效的可再用的用來進行回歸測試（更改后的重新測試），以及
軟件測試的新版本。
上面是一份概要：使用任一設計方法制定測試用例的各種可用方法。
但是，在使用任一設計方法準備測試用例前有一些因素需要考慮清楚。它們分別是：
測試相關風險。
預期缺陷類型。
測試員的知識和經驗。
測試水平和必須進行分組和管理的小組活動。
用于執行測試用例的工具。
應用程序，軟件和問題域的類型。
客戶要求，等等。
現在除了上述因素，以下幾個要點和/或問題在選擇正確的測試用例設計技術中發揮了至關重要的作用：
基于“經驗”的測試用例設計
在基于經驗的技術中，是人們的知識，技能和專業知識（關于域，技術等）構成了測試條件和測試用例的基礎，且對制定測試條件和測試用例很重要。
在這兒，人們技術和業務兩方面的經驗都是絕對必需的，必要的，因為這給測試分析和設計過程提供了不同的角度。
重要的是，有了他們使用類似系統工作的豐富（前）的經驗，他們或許對什么會出錯，什么有助于測試有了想法和/或深入的理解。
因此，基于經驗的技術與基于規范既與基于結構的技術偕行，又可用于沒有規格，或者規格不足或過時的時候。
這可能是用于設計測試低風險系統的測試用例的唯一技術，但是這種方法可能在非常緊急的情況下特別有用，事實上，這是導致探索性測試的一個因素。
“隨機”方式—考慮了嗎？
通常，任何軟件模塊或系統都有輸入域，從這個域里選擇并使用測試輸入數據建和/或執行測試用例。
現在，如果一個測試人員從必要輸入域中隨機選擇輸入，準備測試用例，并用它們來測試應用程序，這種方法被稱為“隨機測試”。
例如，如果一個模塊的有效輸入域是1到100之間所有的正整數，然后用這種方法測試人員會隨機或胡亂地從該領域內選擇值，如，選15 ， 27和33。
但是，使用這種方法，也有一些一直無解的問題：
值（上面的例子中三個值）足以表明，執行測試用或運行例測試時，模塊符合其規格嗎？
是否有其他輸入值，比那些（在本例中）被選中的值，更能找缺陷？
抑或有效輸入域外的任何值應該作為執行測試用例的測試輸入？
這就是說，測試數據應包括大于100的浮點值，負值或整數值？
因此，上述問題可以立即通過更加結構化的黑盒測試設計方法解決，盡管使用隨機測試輸入可以節省一些時間和精力，其他測試輸入選擇方法要求。
但是，根據許多測試專家，隨機選擇測試輸入會產生一個有效的用于執行測試用例的測試數據集的機會非常小，并且對于一個更結構化的方法，隨機方法生成測試輸入的相對有效性總成為自省和/或研究的課題。