在典型的分布式系統中,允許存在許多種受支持的硬件和軟件組合。為了核實測試目標在不同的配置情況下(如不同的操作系統、瀏覽器或 CPU 的速度)能否正常工作或執行,應該對此進行測試。此外,測試還應涵蓋構件的組合,以便檢測在不同構件的交互中產生的缺陷。例如,確保由應用程序安裝的 DDL 版本不會與另一個應用程序需要的相同 DDL 的版本發生沖突。
采用下列指南來生成用于配置測試的測試用例:
確保對每個關鍵配置,應至少存在一個測試用例可用于對其進行確定。這是通過確定測試目標的環境所要求的硬件和軟件配置以及確定這些配置的優先級來完成的。應確保最先測試最常見的配置,包括: 打印機支持 網絡連接 - 局域網和廣域網 服務器配置 - 服務器驅動程序、服務器硬件 臺式機和/或服務器上安裝的其他軟件 所有已安裝軟件的軟件版本 確保對于每個可能有問題的配置至少存在一個測試用例。這些配置可能包括: 具有最低性能的硬件。 歷史上存在兼容性問題的共駐內存的軟件。 通過最慢的 LAN/WAN 連接訪問服務器的客戶機。 資源不足(緩慢的 CPU 速度、最小的內存或分辨率,磁盤空間不足等等) 為安裝測試生成測試用例安裝測試需要核實測試目標可以在所有可能的安裝情況下安裝。安裝情況可以指首次安裝測試目標,或是在裝有較早版本的機器上安裝測試目標的某個較新的版本或工作版本。安裝測試還應確保在遇到異常情況時(如磁盤空間不足),測試目標的執行情況仍可接受。
測試用例應包含以下各種軟件的安裝情況:
分發介質,例如磁盤、CD-ROM 或文件服務器。 首次安裝。 完全安裝。 自定義安裝。 升級安裝。客戶機服務器軟件的安裝程序具備一組特定的測試用例。不同于基于主機的系統,服務器和客戶機上的安裝程序是有所不同的。因而,安裝測試應執行構成測試目標的所有構件的安裝,包括客戶機、中間層以及服務器,這一點至關重要。
為其他非功能性測試生成測試用例理論上,應找到所有必需的輸入來生成測試用例模型、設計模型以及補充規約工件的測試用例。不過,如果此時您需要補充已有的輸入,那也不足為奇。
示例如下:
操作測試(用以檢驗在某次故障發生后以及在下一次故障發生前“較長時間”內軟件的運行情況)的測試用例。 對性能瓶頸、系統容量或測試目標的強度承受能力進行調查的測試用例。大多數情況下,您可以通過先前所確定的測試用例生成的某些測試用例來構建其變體或聚合關系體,借此來查找測試用例。
九、為單元測試生成測試用例
單元測試要求既測試單元的內部結構同時還要測試其行為特征。測試內部結構要求了解實施單元的方式,基于這種了解的測試被稱為白盒測試。對單元行為特征的測試側重于從外部可觀察的單元行為,而不需要了解或考慮其實施方式;谶@種方法的測試稱為黑盒測試;谶@兩種方法所生成的測試用例的說明如下。
白盒測試
理論上,應通過代碼測試每一條可能的路徑。在所有這些非常簡單的單元內實現這樣的目標是不切實際或幾乎是不可能的。作為最基本的測試,應將每個決定到決定路徑(DD 路徑)測試至少一次,這樣可確保將所有語句至少執行一次。決定通常是指 if 語句,而 DD 路徑是兩個決定之間的路徑。
要達到這種程度的測試覆蓋,建議您在選擇測試數據時應使每個決定都可以用每種可能的方法來評估。為達到上述目標,測試用例應確保:
每個布爾表達式的求值結果為 true 和 false。例如,表達式 (a<3) OR (b>4) 的求值結果為 true/false 的四種組合
每一個無限循環至少要執行零次、一次和一次以上。
可使用代碼覆蓋工具來確定白盒測試未測試到的代碼。在進行白盒測試的同時應進行可靠性測試。
示例:
假設您對類 Set of Integers 中的 member 函數執行結構測試。該測試在二進制搜索的幫助下,將檢查該集合是否包含了某個指定的整數。
成員 (member) 函數以及相應的流程圖。虛線箭頭指示出如何通過采用兩個測試用例將所有語句至少執行一次。
理論上,對于徹底測試的某個操作,測試用例應遍歷代碼內路徑的所有組合情況。在 member 函數的 while-loop 中存在三個可選擇的路徑。測試用例可以多次遍歷該循環,或是根本就不遍歷。如果測試用例根本就沒有遍歷循環,則在代碼中只能找到一條路徑。如果遍歷循環一次,您將發現有三條路徑。如果遍歷兩次,則您將發現存在六條路徑,如此類推。因而,路徑的總數應該是:1+3+6+12+24+48+...,在實際情況中,這個路徑組合總數根本無法無法處理。這就是為什么必須選擇所有這些路徑的子集的原因。本示例中,可以采用兩個測試用例來執行所有的語句。其中一個測試用例中,您可以選擇 Set of Integers = {1,5,7,8,11},而且測試數據 t = 3。在另一個測試用例中,您可以選擇 Set of Integers = {1,5,7,8,11},且 t = 8。
黑盒測試
黑盒測試的目的是為了在不了解單元將如何實施指定行為的情況下,對指定行為進行驗證。黑盒測試側重并依賴于單元的輸入和輸出。
等價類劃分是一種用來減少所需測試數量的技術。對于每一個操作都應確定參數和對象狀態的等價類。等價類是一組值的集合,對這組值來說,對象的行為應類似。例如,一個集合可有三個等價類:空、若干元素以及滿。
可使用代碼覆蓋工具來確定白盒測試未測試到的代碼。在進行黑盒測試的同時應進行可靠性測試。
接下來的兩個小節說明了如何通過選擇特定參數的測試數據來確定測試用例。
基于輸入參數的測試用例
輸入參數是由某個操作使用的參數。對于以下每個輸入條件,都應通過使用每個操作的輸入參數來編制測試用例:
每個等價類的正常值。
每個等價類的邊界值。
等價類之外的值。
非法值。
請記住要將對象狀態視作輸入參數。例如:如果在對集合這個對象測試添加操作,您必須使用集合內所有等價類的值來測試添加操作。所有等價類的值指的是:充滿元素的集合、有若干元素的集合、以及空集合。
基于輸出參數的測試用例
輸出參數是某個操作所改變的參數。某個參數既可以是輸入參數也可以是輸出參數。根據以下每個條件選擇輸入,以便獲得輸出。
每個等價類的正常值。
每個等價類的邊界值。
等價類之外的值。
非法值。
請記住將對象狀態視為輸出參數。例如,假設您對某個列表測試刪除操作,您必須選擇輸入值以便執行操作之后,列表為充滿狀態、具有若干元素或為空(采用它的所有等價類的值進行測試)。
如果對象受狀態控制(根據對象的狀態產生不同的反應),您應利用狀態矩陣,如下圖所示:
用于測試的狀態矩陣。您可以在此矩陣的基礎上測試激勵和狀態的所有組合。
十、為產品驗收測試生成測試用例
產品驗收測試是部署軟件前的最后測試操作。驗收測試的目標在于核實軟件是否已經準備就緒,而且可以由最終用戶按軟件設計來執行功能和任務。產品驗收測試通常不僅涉及執行軟件以確認其是否準備就緒,還涉及交付給客戶的所有產品工件,如培訓、文檔和包裝。
為軟件工件生成測試用例是按上文中說明的方式實現的。測試用例可與上面確定的測試用例(正式)或某個子集(非正式)相同或類似,這取決于產品驗收測試的正式程度。不管測試用例的深度如何,應該在實施和執行產品測試之前對測試用例和產品驗收計劃達成共識。
對非軟件工件的評估將隨著被評估工件的不同而相去甚遠。請參見每個特定非軟件工件的指南以及核對清單,查看這些工件的評估內容和評估方式。
十一、為回歸測試編制測試用例
回歸測試比較同一測試目標的兩個工作版本或版本,并將差異確定為潛在缺陷。據此可假定:新版本應該象早先版本一樣操作,并確保并未因為版本的變化而帶來缺陷。
理想狀態下,您可能希望一次迭代內的所有測試用例都能在后續迭代內使用。應遵照下列指導原則來確定、設計并實施測試用例,這些測試用例可以最大限度地發揮回歸測試和復用的價值,同時將維護的成本減至最低:
確保測試用例只確定關鍵的數據元素(創建/支持被測試的條件所需的數據元素)
確保每個測試用例都說明或代表一個唯一的輸入集或事件序列,其結果是獨特的測試目標行為
消除多余或等效的測試用例
將具有相同的測試目標初始狀態和測試數據狀態的測試用例組合到一起
文章來源于領測軟件測試網 http://www.kjueaiud.com/