軟體測試策略

軟體測試策略

為什麼要編寫測試策略？測試策略就是如何進行軟體software測試計畫測試策略目標包括:

取得利益相關者(比如管理部門、開發人員、測試人員、顧客和使用者等)致性目標；

從開始階段對期望值進行管理；

確保「開發方向正確」；

確定所有要進行測試型別

1、策略和軟體software測試策略

(1)策略:在定政治路線指導下根據具體條件而規定鬥爭原則、方式和思路方法《新華字典》

(2)軟體software測試策略:在定軟體software測試標準、測試規範標準指導下依據測試專案特定環境約束而規定軟體software測試原則、方式、思路方法集合

測試策略為測試提供全域性分析並確定或參考:

專案計畫、風險和需求；

相關規則、政策或指示；

所需過程、標準和模板；

支援準則；

利益相關者及其測試目標；

測試資源和評估；

測試層次和階段；

測試環境；

各階段完成標準；

所需測試文件和檢查思路方法

2、軟體software測試策略重要性

(1)任何個完全測試或窮舉測試工作量都是巨大在實戰上是行不通因此任何實際測試都不能保證被測中不遺

漏或缺陷；

(2)為了最大程度較少這種遺漏同時最大限度發現可能存在在實施測試前必須確定合適測試思路方法和測試

策略並以此為依據制定詳細測試案例

3、軟體software測試策略目

是不是所有軟體software測試都要運用現有軟體software測試思路方法去測試呢？答案是否定依據軟體

software本身性質、規模和應用場合區別我們將選擇區別測試方案以最少軟硬體、人力資源投入得到最佳測試

效果這就是測試策略目標所在

4、軟體software測試策略影響原因

軟體software測試策略隨著軟體software生命週期變化、軟體software測試思路方法、技術和工具區別

發生變化這就要求我們在制定測試策略時候應該綜合考慮測試策略影響原因及其依賴關係這些影響原因可能包

括:測試專案資源原因、專案約束和測試專案特殊需要等

5、軟體software測試策略制定過程

(1)輸入

需要軟硬體資源詳細介紹說明；

針對測試和進度約束而需要人力資源角色和職責；

測試思路方法、測試標準和完成標準；

目標系統功能性和技術性需求；

系統侷限(即系統不能夠提供需求)等等

(2)輸出

已批准和簽署測試策略文件、測試用例、測試計畫；

需要解決方案測試專案；

(3)過程

1)確定測試需求

測試需求所確定是測試內容即測試具體物件在分析測試需求時可應用以下幾條般規則:

測試需求必須是可觀測、可測評行為如果不能觀測或測評測試需求就無法對其進行評估以確定需求是否已

經滿足在每個用例或系統補充需求和測試需求的間不存在對關係用例通常具有多個測試需求；有些補充需求將派

生個或多個測試需求而其他補充需求(如市場需求或包裝需求)將不派生任何測試需求

測試需求可能有許多**其中包括用例模型、補充需求、設計需求、業務用例、和終端使用者訪談和軟體

software構架文件等應該對所有這些**進行檢查以收集可用於確定測試需求資訊

2)評估風險並確定測試優先順序¤

成功測試需要在測試工作中成功地權衡資源約束和風險等原因為此應該確定測試工作優先順序以便先測試最

重要、最有意義或風險最高用例或構件為了確定測試工作優先順序需執行風險評估和實施概要並將其作為確定測

試優先順序基礎

3)確定測試策略

個好測試策略應該包括:實施測試型別和測試目標、實施測試階段、技術、用於評估測試結果和測試是否完

成評測和標準、對測試策略所述測試工作存在影響特殊事項等內容

如何才能確定個好測試策略呢？我們可以從基於測試技術測試策略、基於測試方案測試策略兩個方面來回

答這個問題

① 基於測試技術測試策略要點

著名測試專家給出了使用各種測試思路方法綜合策略:

任何情況下都必須使用邊界值測試思路方法；

必要時使用等價類劃分思路方法補充定數量測試用例；

對照邏輯檢查已設計出測試用例邏輯覆蓋程度看是否達到了要求；

如果功能規格介紹說明中含有輸入條組合情況則已開始可以選擇因果圖思路方法

② 基於測試方案測試策略

對於基於測試思路方法測試策略般來說應該考慮如下方面:

根據重要性和旦發生故障將造成損失來確定它測試等級和測試重點；

認真研究使用盡可能少測試用例發現盡可能多避免測試過度和測試不足!

軟體測試策略的技術方法

軟體測試的策略、方法和技術是多種多樣的。對於軟體測試技術，可以從不同的角度加以分類：從是否需要執行被測軟體的角度，可分為靜態測試和動態測試。從測試是否針對系統的內部結構和具體實現演算法的角度來看，可分為白盒測試和黑盒測試。

1.靜態方法與動態方法

所謂靜態方法是指不執行被測程式本身，僅通過分析或檢查源程式的文法、結構、過程、介面等來檢查程式的正確性。靜態方法通過程式靜態特性的分析，找出欠缺和可疑之處，例如不匹配的引數、不適當的迴圈巢狀和分支巢狀、不允許的遞迴、未使用過的變數、空指標的引用和可疑的計算等。靜態測試結果可用於進一步的查錯，並為測試用例選取提供指導。

動態方法是指通過執行被測程式，檢查執行結果與預期結果的差異，並分析執行效率和健壯性等效能，這種方法由三部分組成：構造測試例項、執行程式、分析程式的輸出結果。

2.功能測試與結構測試

（1）功能測試

功能測試是指在對程式進行的功能抽象的基礎上，將程式劃分成功能單元，然後在資料抽象的基礎上，對每個功能單元生成測試資料進行測試。用這種方法進行測試時，被測程式被當作打不開的黑盒，因而無法了解其內部構造，因此又稱為黑盒測試。

黑盒測試也稱功能測試或資料驅動測試，它是在已知產品所應具有的功能，通過測試來檢測每個功能是否都能正常使用。在測試時，把程式看作乙個不能開啟的黑盒子，在完全不考慮程式內部結構和內部特性的情況下，測試者在程式介面進行測試，只檢查程式功能是否按照需求規格說明書的規定正常使用，程式是否能適當接收輸入資料而產生正確的輸出資訊，並且保持外部資訊的完整性。

在功能測試中，被測軟體的輸入域和輸出域往往是無限域，因此窮舉測試通常是不可行的。必須以某種策略分析軟體規格說明，從而得出測試用例集，盡可能全面而又高效地對軟體進行測試。下面就說明幾種功能測試的方法：

a.等價類劃分

所謂等價類，就是指某個輸入域的集合，集合中的每個輸入對揭露程式錯誤來說是等效的，把程式的輸入域劃分成若干部分，然後從每個部分中選取少數代表性資料作為測試用例，這就是等價類劃分方法。它是功能測試的基本方法。

b.因果圖法

因果圖是一種形式語言，由自然語言寫成的規範轉換而成，這種形式語言實際上是一種使用簡化記號表示數字邏輯圖。因果圖法是幫助人們系統地選擇一組高效測試用例的方法，此外，它還能指出程式規範中的不完全性和二義性。

c.邊值分析

實踐證明，軟體在輸入、輸出域的邊界附近容易出現差錯，邊值分析是考慮邊界條件而選取測試用例的一種功能測試方法。所謂邊界條件，是相對於輸入和輸出等價類直接在其邊緣上，稍高於和稍低於其邊界的這些狀態條件。邊值分析是對等價類劃分的有效補充。

(2)結構測試

結構測試是根據被測程式的內部結構設計測試用例的一類測試，又稱為白盒測試。白盒測試也稱結構測試或邏輯驅動測試，它是知道產品內部工作過程，可通過測試來檢測產品內部動作是否按照規格說明書的規定正常進行，按照程式內部的結構測試程式，檢驗程式中的每條通路是否都有能按預定要求正確工作，而不顧它的功能。其主要方法有邏輯驅動、基路測試等，主要用於軟體驗證。白盒法全面了解程式內部邏輯結構、對所有邏輯路徑進行測試。白盒法是窮舉路徑測試。在使用這一方案時，測試者必須檢查程式的內部結構，從檢查程式的邏輯著手，得出測試資料。貫穿程式的獨立路徑數是天文數字。但即使每條路徑都測試了仍然可能有錯誤。第一，窮舉路徑測試決不能查出程式違反了設計規範，即程式本身錯誤的程式。第二，窮舉路徑測試不可能查出程式中因遺漏路徑而出錯。第三，窮舉路徑測試可能發現不了一些與資料相關的錯誤。

與功能測試不同的是，結構測試涉及程式內部結構。儘管使用者更傾向於基於程式規格說明的功能測試，但是結構測試能發現潛在的邏輯錯誤，而這種錯誤往往是功能測試發現不了的。它們各有利弊，常常結合使用。

軟體測試策略

軟體測試策略

軟體測試策略

軟體測試策略

相關推薦