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