第一篇：可復用測試用例研究

可復用測試用例研究

0、引言

軟件測試的關鍵環節是設計和執行測試用例。測試用例的質量與測試人員的技能、經驗以及對被測軟件的理解密切相關。如果測試人員對被測軟件不甚了解，很難在短時間內設計出有效的測試用例；有的測試用例雖然面面俱到，但冗余現象嚴重，浪費時間、人力和物力。

隨著軟件復用技術的發展，測試復用引起了人們的極大關注，特別是對測試用例復用的研究。所謂測試用例復用，就是對一個軟件的已執行的測試用例，將其不同程度地應用于該軟件新的測試中或其他軟件的測試中。測試用例復用是可行和必要的，表現在：1）軟件測試對測試人員的經驗和技能要求高，通過復用，可提高測試人員技能，解決其經驗不足的問題，同時提高軟件測試質量；2）軟件測試是當前保證軟件質量的一種有效手段，但其占用軟件開發周期時間長，通過復用，可避免大量重復性勞動，縮短測試周期，提高效率；3）伴隨著同一個軟件的生存周期，軟件經歷了單元測試、集成測試、確認測試和系統測試，這一過程產生了成百上千的經過執行確認的高質量的測試用例，在前一測試階段執行過的一些測試用例可在后續測試階段中使用，包括在回歸測試、維護階段的版本升級和糾錯測試中都可使用；4）同一領域或相同系統架構的不同軟件，存在著測試用例復用的可能性，且隨著軟件復用技術的發展，很多有價值的組件可供使用，這也使測試用例復用成為可能。

由于軟件的抽象性、復雜性和多樣性，使得軟件測試成為一項復雜的、需要智慧和創造性的工作，要實現測試用例復用并不是一件簡單的事情。但測試用例復用是軟件測試發展的一個必然趨勢。本文從可復用測試用例的評估、描述、設計和使用四個方面對測試用例進行了系統研究，提出了可復用測試用例應具有的特性，為評估測試用例的可復用性提供準則；給出了可復用測試用例的系統描述要素，為規范和使用可復用測試用例提供了基礎；提出了面向復用的測試用例設計過程和基于復用的軟件測試模型，為測試用例復用提供了方法和實現策略。本文的研究內容在某類實時系統軟件測試中進行了應用，證明是有效和科學的。

1、可復用測試用例特性

文獻中定義了可復用測試用例的六個特性：通用性、簡潔性、獨立性、有效性、靈活性和檢索方便。本文對大量測試用例和測試用例復用的各種應用情況進行了分析，認為可復用測試用例應具有以下特性：通用性、有效性、獨立性、標準化和完整性，它們對可復用測試用例而言是充分的也是必要的。上述特性可作為評判一個測試用例是否具有可復用性的準則。

1）通用性。通用性是指可復用測試用例并不局限于具體的應用，不過分依賴于被測軟件的需求、設計和環境，能夠在某一類型、某一領域的相似軟件的測試中廣泛使用。

當前絕大多數的測試用例都不具有通用性，這樣的測試用例只能用于被測軟件和其當前環境，不可能用到其他軟件中。

2）有效性。測試用例的目標是發現軟件問題，因此，可復用測試用例也必須是能夠發現軟件問題的，并且是可靠和高效的。

3）獨立性。可復用測試用例的獨立性是指，對于測試需求R1和R2，測試用例集分別為cl和C2，c1和c2的交集為空，并且，每個可復用測試用例能夠獨立運行。測試用例是否具有獨立性，決定了測試用例可復用能力的強弱。

如果測試用例之間存在著相互聯系，或測試用例的運行環境取決于其他測試用例的執行狀態，那么，其中的測試用例不能復用時，與之相關的測試用例的可復用性也不復存在。

如何將測試用例的關聯性降至最低，是設計可復用測試用例必須解決的問題。首先，每個測試用例的目標應盡量獨立、單一；其次，測試用例不包含過多的具體實現細節。

4）標準化。測試用例通常用自然語言來描述，充分體現了測試人員的創造性和個人風格。但對于可復用測試用例，太多的個人風格不利于其他測試人員對測試用例的理解，必然影響其復用。因此可復用測試用例的標準化程度也反映了其易理解和可復用的能力。為此可復用測試用例應遵循統一或規范的格式或結構，規范的命名規則，使用術語、用簡明、易懂、無歧義的語言來描述，并且具有詳細的文檔。

5）完整性。每個可復用測試用例應包括全部應有的要素，不能有缺失，并且每個要素的描述是充分的。文獻規定了測試用例應包括的要素，但對于可復用測試用例而言是不夠的，應加以補充。

2、面向復用的測試用例設計過程

當前，測試用例設計都砥向不同的具體應用，與被測軟件是緊耦合的。考慮到復用的目的，測試用例的設計應不同于以往。本文提出了面向復用的測試用例設計過程，給出了設計過程中應實施的各項活動，主要包括被測軟件（系統）共性分析、測試策略分析、設計測試用例、測試用例評審、測試用例執行和修改、測試用例入庫共六個步驟，如圖l所示。該過程對現有測試用例的復用處理也是適用的。

2．1共性分析

同一領域或相同架構的軟件存在著共性需求。通過共性分析或領域分析，并結合任務分析等方法，梳理出被測軟件所屬領域或相同類型軟件的相同或相似特征及需求，例如，工作流程、共性場景、功能、性能等，從而挖掘出可復用點，例如，相對獨立且類似的功能、相同的構件、相似的業務流程。該步驟實質上要抽象出被測軟件應用領域的概念，類似于設計模式中的共性分析。

這項活動需要領域專家、軟件專家、設計人員、測試專家等人員參與。

2．2 測試策略分析

針對共性分析挖掘出的可復用點，分析各復用點的測試策略，包括測試類型、測試方法、測試環境、測試覆蓋率等內容。

2．3 設計測試用例

根據前兩個步驟的分析結果對每個可復用點設計測試用例。在設計時，應使所設計的測試用例滿足可復用測試用例的特性，特別要注意以下幾方面：

1）每個測試用例的目的要盡量獨立、單一，以滿足可復用測試用例獨立性的要求。

2）對一項明確的測試需求，應關注“測試思想”，即測試思路，以滿足可復用測試用例通用性要求。當前，為了使測試用例是可操作的、可復現的，一般都要求測試用例要設計得非常詳細，例如，每一操作步驟的輸入數據、操作等信息都要具體描述。這樣的測試用例和被測軟件是緊耦合的，只有在同一軟件的回歸測試和版本升級維護測試中可能會復用到，在其他情況下復用是很困難的。在設計可復用測試用例時，測試用例的可操作性、可復現性要弱化，即，對測試用例進行通用化處理，排除和特定應用相關的具體信息，以降低測試用例和被測軟件的相關度，例如，參數化或公式來代替具體的輸入數據，抽象出共同或關鍵的操作等。但為了加強測試用例的可操作性和可復現性，在設計可復用測試用例時，應對一些差異之處進行預測，即進行可變性分析mJ，并用適當的方式描述出來。只有這樣，當復用該測試用例時，測試人員可以在原有基礎上對其進行完善，使其能夠滿足特定的測試情況。

3）將設計出的測試用例用規范而精煉的自然語言清晰地描述出來，保證其完整、標準。軟件評測組織或機構應定義本組織使用的規范和術語。

需要說明的是，對于一個具體的測試項目，因為面向復用，所以以上所設計的測試用例可能不完全滿足被測軟件的測試需求，為此，應針對被測軟件的需求補充新的用例或對現有用例進行充實完善。

2．4 測試用例評審

可復用測試用例設計完成后，組織領域專家、軟件專家、測試專家、軟件設計人員對其進行評審，確保所設計的測試用例是正確的，滿足可復用測試用例的特性。

評審同時應關注以下幾點：每個共性需求的測試策略是否合適；每個共性需求是否被可復用測試用例所覆蓋；每個共性需求是否被可復用測試用例進行了充分測試，例如，某一共性功能，不能僅測試正常情況，還應測試邊界和異常情況。如果測試用例沒有通過評審，則需要重新回到設計測試用例步驟。

2．5 測試用例執行和修改

將通過評審確認的測試用例用于被測軟件，尋找其不正確或不完善之處并糾正完善。

2．6 測試用例入庫

將經過測試執行確認的可復用測試用例統一納入測試用例庫中，供測試人員在后續軟件測試或以后的項目中查詢使用。測試用例庫應是按照一定的組織結構形成的測試用例集合。

3、基于復用的軟件測試模型

文獻給出了一個測試用例復用流程：首先定義被測軟件的測試用例類型；再根據所定義的從測試用例庫中檢索是否有適合的用例；如果可以找到，則提取出測試用例，程序結束；否則，需要設計測試用例，驗證其正確性，如果正確，則添加到庫中以便再次復用，程序結束。這個流程只適用于完全不需要進一步完善的可復用的測試用例，由于可復用測試用例的通用性，該流程顯然不適用于實際情況。文獻[12]給出了另一個測試用例復用模型，該模型建立在沒有測試用例庫的基礎上，且將測試用例分為內外兩類，本文認為這種劃分是不必要的。

本文提出了基于復用的軟件測試模型。該模型面向一個軟件測試項目，但不同于以往的測試模型，主要表現在模型中融合了面向復用的測試用例設計以及對測試用例的復用上，模型如圖2所示。

“測試需求分析和共性分析”中，測試人員一方面要根據被測試軟件需求分析、設計說明等文檔或軟件代碼梳理出被測軟件的測試需求，另一方面要針對被測軟件所屬領域及軟件類型進行面向復用的共性分析。

“定義測試策略”中，測試人員根據測試目標和上一步的結果定義測試策略，包括測試方法、測試類型、測試環境等內容。

“定義測試用例”中，測試人員根據測試需求和共性分析結果及所定義的測試策略，定義所需要的測試用例。這里定義的測試用例只是給出一個測試用例名稱及其測試目的。

“查詢可復用測試用例庫”中，測試人員用多字段檢索功能從可復用測試用例庫中查找滿足要求的測試用例。對測試用例的查詢是不確定的，查詢結果通常是一個相似的測試用例集合。如果可以找到，則“提取測試用例”并對其進行分析，確定出最合適的測試用例；如果沒有，則“設計”新的測試用例。找到的測試用例，往往因其通用性，并不能完全滿足測試需求，要對其“補充完善”。在設計新的測試用例時，要考慮到上節“設計測試用例”要求。

在傳統模型評審的基礎上，本模型“測試評審”還包括對新設計的可復用測試用例是否滿足要求的審查；對復用的測試用例是否補充完善的審查；所有測試用例是否滿足被測軟件的測試需求的審查。

“執行測試用例”中，測試人員將所設計的測試用例逐用例逐步驟地執行。在執行過程中，認真觀察并詳實地記錄測試過程、測試結果和發現的錯誤，形成測試記錄。如果在執行過程中發現測試用例有不正確和不完善之處，則糾正；如果測試用例不充分，則補充。

測試人員在“測試總結”中對所有測試結果進行分析總結，將通過測試執行驗證的可復用測試用例放入可復用測試用例庫中，以便后續復用。

該模型的優點為：1）對已有的可復用的測試用例進行了復用，避免了大量的重復性工作，提高了測試質量和效率；2）考慮了面向復用的測試用例設計，避免再次產生大量的不可復用的測試用例。

4、可復用測試用例描述要素

測試用例的輸入、操作、預期結果和評估標準、前提條件是測試用例不可少的要素，但對于可復用測試用例而言，這是不夠的。本文在文獻規定的測試用例要素基礎上，增加了新的內容。從而從多個角度完整地對可復用測試用例進行了描述，為可復用測試用例的標準化提供了模板，為建立可復用測試用例庫并對測試用例實施有效管理提供了基礎，也為測試用例檢索提供了多個檢索字段。

1）測試用例名稱：名稱能清晰且簡潔地表達測試用例的功能。

2）ID：該ID在數據庫中是唯一的。

3）版本號：用于測試用例的版本管理，每個測試用例應按照定義的規則設定一個版本號。

4）測試需求：對要驗證的測試需求的描述和測試要求，例如，功能、性能等。

5）測試階段：被測軟件所處的測試階段，包括單元測試、部件測試、配置項測試、系統測試，或者單元測試、集成測試、確認測試、系統測試。

6）測試方法：黑盒測試中的等價類劃分、因果圖，白盒測試中的語句覆蓋、分支覆蓋等。

7）測試類型：有功能測試、性能測試、安全測試、用戶界面測試、接口測試、安裝測試等，可選擇多項。

8）應用領域：說明被測軟件所屬領域。

9）系統類型：描述被測軟件所在系統的架構，如B／S、C／S、嵌入式軟件、非嵌入式軟件等。

lO）軟件編碼：描述被測軟件的編碼語言。

11）測試環境：描述該測試用例執行的軟硬件環境。

12）前提條件：測試用例執行前必須滿足的條件，或稱之為約束條件。

13）測試輸入：對輸入值的抽象描述或參數化描述，不能是具體的數據值。

14）操作步驟：說明執行該測試用例的一系列相關聯的操作。

15）預期結果：說明測試用例執行后的期望結果。每一操作步驟也可有自己的預期結果。

16）評估標準：描述評判測試用例執行中產生的中間和最后結果是否正確的準則。

17）附件：對測試用例附加的一些描述信息，可任意表示，例如文本、圖像、模型、與測試用例有關的一些文檔，方便測試人員進一步理解測試用例。

上述要素對可復用測試用例而言是必要的，不可缺少。而且要注意的是，測試人員在描述測試用例各要素時，應盡可能地使用規范語言和術語，以使測試用例規范化和易于理解。

5、應用

本文的研究內容在航天測控領域進行了應用。在航天測控計算機系統中，有一類實時系統軟件。在不同型號任務中，該類軟件的功能、性能、接口和運行環境都有區別，但不同任務對該類軟件有共性需求。更多細節信息的子帶圖像予以了更多地保留，恢復了圖像的邊緣輪廓，而且經圖像分解后的子帶圖像含有相同尺寸的大小，也更易于處理。本文算法的缺陷則是執行速度較慢，不如前三種算法，而且對分解后所得到系數處理也比較簡單，這些都需作進一步的改進。

第二篇：自動售貨機測試用例

題目：有一個處理單價為5角錢的飲料的自動售貨機軟件測試用例的設計。其規格說明如下：若投入5角錢或1元錢的硬幣，押下〖橙汁〗或〖啤酒〗的按鈕，則相應的飲料就送出來。若售貨機沒有零錢找，則一個顯示〖零錢找完〗的紅燈亮，這時在投入1元硬幣并押下按鈕后，飲料不送出來而且1元硬幣也退出來；若有零錢找，則顯示〖零錢找完〗的紅燈滅，在送出飲料的同時退還5角硬幣。1.分析這一段說明，列出原因和結果 原因：

1.售貨機有零錢找 2.投入1元硬幣 3.投入5角硬幣

4.押下橙汁按鈕 5.押下啤酒按鈕

結果：

21.售貨機〖零錢找完〗燈亮

22.退還1元硬幣

23.退還5角硬幣

24.送出橙汁飲料 25.送出啤酒飲料 2.畫出因果圖

如圖所示。所有原因結點列在左邊，所有結果結點列在右邊。建立中間結點，表示處理的中間狀態。中間結點：

11.投入1元硬幣且押下飲料按鈕 12.押下〖橙汁〗或〖啤酒〗的按鈕 13.應當找5角零錢并且售貨機有零錢找 14.錢已付清

3.轉換成判定表：

4.設計測試用例

1)在售貨機有零錢找的情況下，投入1元硬幣，押下橙汁按鈕，找回5角硬幣并送出橙汁飲料。

2)在售貨機有零錢找的情況下，投入1元硬幣，押下啤酒按鈕，找回5角硬幣并送出啤酒飲料。

3)在售貨機有零錢找的情況下，投入1元硬幣，系統不做任何處理。

4)在售貨機有零錢找的情況下，投入5角硬幣，押下橙汁按鈕，送出橙汁飲料。5)在售貨機有零錢找的情況下，投入5角硬幣，押下啤酒按鈕，送出啤酒飲料。6)在售貨機有零錢找的情況下，投入5角硬幣，系統不做任何處理。7)在售貨機有零錢找的情況下，押下橙汁按鈕，系統不做任何處理。8)在售貨機有零錢找的情況下，押下啤酒按鈕，系統不做任何處理。

9)在售貨機沒有零錢找的情況下，投入1元硬幣，押下橙汁按鈕，售貨機“零錢找完”燈亮，并退還1元硬幣。

10)在售貨機沒有零錢找的情況下，投入1元硬幣，押下啤酒按鈕，售貨機“零錢找完”燈亮，并退還1元硬幣。

11)在售貨機沒有零錢找的情況下，投入1元硬幣，售貨機“零錢找完”燈亮。

12)在售貨機沒有零錢找的情況下，投入5角硬幣，押下橙汁按鈕，售貨機“零錢找完”燈亮，并送出橙汁飲料。

13)在售貨機沒有零錢找的情況下，投入5角硬幣，押下啤酒按鈕，售貨機“零錢找完”燈亮，并送出啤酒飲料。

14)在售貨機沒有零錢找的情況下，投入5角硬幣，售貨機“零錢找完”燈亮。15)在售貨機沒有零錢找的情況下，押下橙汁按鈕，售貨機“零錢找完”燈亮。16)在售貨機沒有零錢找的情況下，押下啤酒按鈕，售貨機“零錢找完”燈亮。

第三篇：測試用例怎么寫

怎么寫測試用例我剛剛就業來到公司做軟件測試我在學校沒有太多的機會做測試，測試用例和測試報告應該怎么寫。

● 測試用例編號

◇ 規則：編號具有唯一性、易識別性，由數字和字符組合成的字符串◇ 約定：

系統測試用例：產品編號-ST-系統測試項名-系統測試子項名-XXX

集成測試用例：產品編號-IT-集成測試項名-集成測試子項名-XXX單元測試用例：產品編號-UT-單元測試項名-單元測試子項名-XXX

● 測試項目

◇ 規則：當前測試用例所屬測試大類、被測需求、被測模塊、被測單元等◇ 約定：

系統測試用例測試項目：軟件需求項 如：測試手機在沒有SIM卡的情況下，可以撥打緊急電話

集成測試用例測試項目：集成后的模塊名或接口名 如：測試模塊A提供的文件接口

單元測試用例測試項目：被測試的函數名 如：測試函數int ReadFile(char *pszFileName)

● 測試標題

規則：測試用例的概括簡單的描述用例的出發點、關注點，原則上不能重復。● 重要級別

規則

高：保證系統基本功能、核心業務、重要特性、實際使用頻率高的測試用例；中：重要程度介于高和低之間的測試用例；

低：實際使用頻率不高、對系統業務功能影響不大的模塊或功能的測試用例。● 預置條件

規則：執行當前測試用例需要的前提條件，是后續步驟的先決條件● 輸入

規則：用例執行過程中需要加工的外部信息，輸入、文件、數據庫等● 操作步驟

規則：執行當前測試用例需要經過的操作步驟，保證操作步驟的完整性。● 預期輸出

規則：當前測試用例的預期輸出結果，包括返回值的內容、界面的響應結果、輸出結果的規則符合度等

第四篇：測試用例書寫標準

測試用例書寫標準

在編寫測試用例過程中，需要參考和規范一些基本的測試用例編寫標準，在ANSI/IEEE829-1983標準中列出了和測試設計相關的測試用例編寫規范和模板。標準模板中主要元素如下。

? 標識符（identification）：每個測試用例應該有一個唯一的標識符，它將成為所有和測試用例相關的文檔/表格引用和參考的基本元素，這些文檔/表格包括設計規格說明書、測試日志表、測試報告等。

? 測試項（test item）：測試用例應該準確地描述所需要測試地項及其特征，測試項應該比測試設計說明書中所列出地特性描述更加具體，例如做windows計算器應用程序地窗口設計，測試對象是整個地應用程序用戶界面，這樣測試項就應該是應用程序地界面地特性要求，例如縮放測試、界面布局、菜單等。

? 測試環境要求（test environment）：用來表征執行該測試用例需要地測試環境，一般來說，在整個的測試模塊里面應該包含整個的測試環境的特殊要求，而單個測試用例的測試環境需要表征該測試用例所單獨需要的特殊環境需求。

? 輸入標準（input criteria）：用來執行測試用例的輸入需求。這些輸入可能包括數據、文件，或者操作（例如鼠標的左鍵單擊，鼠標的按鍵處理等），必要的時候，相關的數據庫、文件也必須被羅列。

? 輸出標準（output criteria）：標識按照指定的環境和輸入標準得到的期望輸出結果。如果可能的話，盡量提供適當的系統規格說明書來證明期望的結果。

? 測試用例之間的關聯：用來標識該測試用例與其它的測試（或其它測試用例）之間的依賴關系，例如，用例A需要基于B的測試結果正確的基礎上才能進行，此時需要在A的測試用例中表明對B的依賴性，從而保證測試用例的嚴謹性。

綜上所述，如果使用一個數據庫的表來表征測試用例的話，它應該有以下的格式：

例一：對Windows記事本程序進行測試，選取其中的一個測試項――文件菜單欄的測試 測試對象：記事本程序文件菜單欄（測試用例標識1000，下同），所包含的子測試用例描述如下：

|---------文件/新建（1001）

|---------文件/打開（1002）

|---------文件/保存（1003）

|---------文件/另存（1004）

|---------文件/頁面設置（1005）

|---------文件/打印（1006）

|---------文件/退出（1007）

|---------菜單布局（1008）

|---------快捷鍵（1009）

選取其中的一個子測試用例――文件/退出（1007）作為例子，測試用例如下表所示：

通過這個例子了解了測試用例的組成方法。要組織成一個完整的良好測試用例，還需要更多的技巧，并要考慮一些常見的因素。

測試用例設計考慮因素

測試是不可能實現窮舉測試的，因此試圖用所有的測試用例來覆蓋所有測試可能遇到的情形是不可能的，所以，在測試用例的編寫、組織過程中，盡量考慮有代表性的典型的測試用例，來實現以點帶面的窮舉測試。這要求在測試用例設計中考慮一些基本因素： ? 測試用例必須具有代表性、典型性。

? 測試用例設計時，要濃縮系統設計。

例二：常見的web登錄頁面，通過這個例子來闡述從功能規格說明書到具體測試用例編寫的過程

A）用戶登錄的功能設計規格說明書（摘選）

―――――――――――――――――――――――――――――――――――――――

1． 用戶登錄

1．1滿足基本頁面布局（圖示，略）

1．2當用戶沒有輸入用戶名和密碼時，不立即彈出錯誤對話框，而是在頁面上使用紅色字體來提示，見2描述

1．3用戶密碼使用掩碼號（*）來標識。

1．4*代表必選字段，將出現在輸入文本框的后面。

2． 登錄出現錯誤

當出現錯誤時，在頁面的頂部會出現相應的錯誤提示。錯誤提示的內容見3。錯誤提示是高亮的紅色字體實現。

3． 錯誤信息描述

3．1

3．2密碼為空

3，3用戶名/

（注：本例子中的頁面圖示，消息編號如WMSG001的描述均為給出。）

―――――――――――――――――――――――――――――――――――――――

B）通用安全性設計規格說明書（摘選）

―――――――――――――――――――――――――――――――――――――――

1． 安全性描述

1．1輸入安全性：在用戶登錄或者信用卡驗證過程中，如果三次輸入不正確，頁面將需要重新打開才能生效。

1．2密碼：在所有的用戶密碼中，都必須使用掩碼符號（*），數據在數據庫中存儲使用統一的加密和解密算法。

1．3Cookie：在信用卡信息驗證，用戶名輸入時，Cookie都是被禁止的，當用戶第一次輸入后，瀏覽器將不再提供是否保存信息的提示，自動完成功能將被禁用。

1．4SSL校驗：所有的站點訪問時，都必須經過SSL校驗。

2． 錯誤描述（略）

―――――――――――――――――――――――――――――――――――――――

C）測試用例

結合相關的規格說明書，理解和掌握測試用例設計的關鍵點，測試用例設計如下表所示。

? 測試用例需要考慮到正確的輸入，也需要考慮錯誤的或者異常的輸入，以及需要分

析怎樣使得這樣的錯誤或者異常能夠發生。

用戶登錄功能測試用例

完善的測試用例

? 用戶測試用例的設計，要多考慮用戶實際使用場景。

第五篇：測試用例設計步驟

測試用例設計步驟

設計測試案例的時候，需要有清晰的測試思路，對要測試什么，按照什么順序測試，覆蓋哪些需求做到心中有數。測試用例編寫者不僅要掌握軟件測試的技術和流程，而且要對被測軟件的設計、功能規格說明、用戶試用場景以及程序/模塊的結構都有比較透徹的理解。測試用例設計一般包括以下幾個步驟：

1、測試需求分析

從軟件需求文檔中，找出待測試軟件/模塊的需求，通過自己的分析、理解，整理成為測試需求，清楚被測試對象具有哪些功能。測試需求的特點是：包含軟件需求，具有可測試性。測試需求應該在軟件需求基礎上進行歸納、分類或細分，方便測試用例設計。測試用例中的測試集與測試需求的關系是多對一的關系，即一個或多個測試用例集對應一個測試需求。

2、業務流程分析

軟件測試，不單純是基于功能的黑盒測試，還需要對軟件的內部處理邏輯進行測試。為了不遺漏測試點，需要清楚的了解軟件產品的業務流程。建議在做復雜的測試用例設計前，先畫出軟件的業務流程。如果設計文檔中已經有業務流程設計，可以從測試角度對現有流程進行補充。如果無法從設計中得到業務流程，測試工程師應通過閱讀設計文檔，與開發人員交流，最終畫出業務流程圖。業務流程圖可以幫助理解軟件的處理邏輯和數據流向，從而指導測試用例的設計。

從業務流程上，應得到以下信息：

A、主流程是什么

B、條件備選流程是什么

C、數據流向是什么

D、關鍵的判斷條件是什么

3、測試用例設計

完成了測試需求分析和軟件流程分析后，開始著手設計測試用例。測試用例設計的類型包括功能測試，邊界測試，異常測試，性能測試，壓力測試等。在用例設計中，除了功能測試用例外，應盡量考慮邊界、異常、性能的情況，以便發現更多的隱藏問題。

黑盒測試的測試用例設計方法有：等價類劃分、邊界值劃分、因果圖分析和錯誤猜測，白盒測試的測試用例設計方法有：語句覆蓋、判定覆蓋、條件覆蓋、判定/條件覆蓋、多重條件覆蓋。在這里主要討論黑盒測試。在設計測試用例的時候可以使用軟件測試用例設計方法，結合前面的需求分析和軟件流程分析進行設計：

功能測試：測試某個功能是否滿足需求的定義，功能是否正確，完備。

適合的技術：由業務需求和設計說明導出的功能測試、等價類劃分

邊界測試：對某個功能的邊界情況進行測試。

適合的技術：邊界值劃分

異常測試：對某些功能來說，其邊界情況無法簡單的了解或某些操作不完全是正確的但又是

可能發生的，類似這樣的情況需要書寫相關的異常測試。

適合的技術：由業務需求和設計說明導出的特殊業務流程、錯誤猜測法、邊界值

分析、內部邊界值測試。

性能測試：檢查系統是否滿足在需求中所規定達到的性能，性能主要包括了解程序的內外部

性能因素。內部性能因素包括測試環境的配置，系統資源使用狀況；外部因素包

括響應時間，吞吐量等。

適合的技術：業務需求和設計說明導出的測試

壓力測試：壓力測試又稱強度測試，主要是檢查系統運行環境在極限情況下軟件運行的能力，比如說給一個相當大的負荷或網絡流量給應用軟件兼容測試：測試軟件產品在不

同的平臺，不同的工具，相同工具的不同版本下功能的兼容性。

4、測試用例評審

測試用例設計完成后，為了確認測試過程和方法是否正確，是否有遺漏的測試點，需要進行測試用例的評審。

測試用例評審一般是由測試leader安排，參加的人員包括：測試用例設計者、測試leader、項目經理、開發工程師、其它相關開發測試工程師。測試用例評審完畢，測試工程師根據評審結果，對測試用例進行修改，并記錄修改日志。

5、測試用例更新完善

測試用例編寫完成之后需要不斷完善，軟件產品新增功能或更新需求后，測試用例必須配套修改更新；在測試過程中發現設計測試用例時考慮不周，需要對測試用例進行修改完善；在軟件交付使用后客戶反饋的軟件缺陷，而缺陷又是因測試用例存在漏洞造成，也需要對測試用例進行完善。一般小的修改完善可在原測試用例文檔上修改，但文檔要有更改記錄。軟件的版本升級更新，測試用例一般也應隨之編制升級更新版本。測試用例是“活”的，在軟件的生命周期中不斷更新與完善。