編寫測試案例常用的的編寫方法

Ⅰ 測試用例的設計方法有哪些

黑盒：等價類劃分法，邊界值法 ，因果圖法，場景法，錯誤推斷法 白盒：基本路徑覆蓋法，條件覆蓋法，語句覆蓋法，判定覆蓋法

Ⅱ 如何寫測試案例

關於 測試 用例，我們有太多的疑惑了，測試用例的依據？好的測試用例評估....等等。我們依據需求分析，依據開發文檔，依據系統設計文檔，甚至依據UI寫測試用例，我們就真的足夠了？不夠，真的不夠。需求在變，開發文檔跟著變，設計文檔也在改動，UI也在做變化，那我們的測試用例應該怎麼寫？

個人認為，一個好的、有效的測試用例，應該具備以下幾個特徵：

1．覆蓋全面。測試的每個路徑都涉及到， 功能測試 、界面測試、有性能要求的做 性能測試 、有安全要求的做 安全測試 （網路安全、通信安全..）等。

2．測試用例的後期維護時間短。測試用例寫出來，不可能一成不變，根據系統的優化，測試用例都應該做相應的修改。針對需要修改的測試用例，我們修改了測試用例的哪些部分？測試前提、測試過程、測試數據、測試結果？如果四個方面都需要做修改，要麼就是該功能完全變了，要麼就是測試用例寫的不夠好。在系統做優化的時候，一般只需要修改測試數據就可以

3．對內的測試用例與對外的測試用例不一樣。某些行業，測試用例需要隨著系統一起交付用戶使用。對內的測試用例，應該以尋求BUG為主，我們可以把過程寫的流暢簡單些，但是測試數據一定要充分；對外的測試用例，應該以指導用戶參與測試為主，所以過程需要比對內的測試用例詳細，但是測試數據可以減少。因為用戶主要是想知道，這個系統是否可以使用，他不是真的為了給你找BUG。

4．同一個產品的不同項目，許多的測試用例可以公用的。所以，針對不同的項目編寫測試用例，有許多我們拿以前的測試用例直接黏貼過來用，減少了許多寫測試用例的時間。

針對以上幾個特徵，編寫測試用例前，我們應該做哪些 工作 ？我一般會花一些時間去看看需求文檔、設計文檔、開發文檔；有機會就去找市場部的人交談，在他們抽煙的時候，冒一根不夠，就再冒一根，慢慢的問我想知道的問題；最好也和研發部的開發人員了解下情況，這個系統他們怎麼看的，打算怎麼做，有必要可以說說你的觀點。

當這些前提你都做了，你完全可以寫測試用例了，當然邊寫還是要邊溝通，也許有新的發現呢？如果邊寫測試用例的時間

不夠，你沒有太多的時間去做這么多的鋪墊工作，也沒有關系，你可以先把一些通用的測試用例寫出來：登陸、增加數據、修改數據、查詢數據等，然後把業務要求

比較強的測試用例放在最後編寫，這樣我們既沒有浪費時間，也可以按時交測試用例。

測試用例寫出來，維護怎麼辦？測試用例的維護，寫過測試用例的朋友都知道，大家都去嘟囔修改測試用例很無聊，首先

它沒有太多的技術含量（這個大家都不喜歡，好多人也認為測試沒有技術含量），第二這個過程很繁瑣和枯燥。如果想維護簡單，在編寫測試用例的時候你就應該考

慮到這點。各項描述應該怎麼寫，通俗易懂而且是通用的是首選。舉例：

方法一：

測試前提：系統服務運行正常、，具有xiaoming這個用戶，密碼為999999

測試過程：

1.訪問系統登錄頁面 http://localhost:8089/index.jsp

2.輸入用戶名：xiaoming

輸入密碼：999999

3.點擊「登錄」

測試數據：

用戶名密碼舉例：

系統用戶：xiaoming，密碼999999；xiaohong，密碼666666

用戶名與密碼不匹配：xiaoming，密碼666666；xiaohong，密碼999999

非系統用戶：xiaowang，密碼999999；xiao，密碼666666

非法參數：#￥%，密碼HH*&56；yong12%……，密碼**……（

測試結果：使用正確的用戶名與密碼，可以登錄系統；使用錯誤的用戶名和密碼，不能登錄系統

結果分析：

方法二：

測試前提：系統服務運行正常、具有系統用戶數據

測試過程：

1.訪問系統登錄頁面

2.輸入用戶名和密碼

3.提交數據

測試數據：

用戶名密碼舉例：【假設xiaoming，密碼999999為系統用戶】

說明：用戶名只能為數字、字母、下劃線『_』，首字不能為下劃線

密碼不能為空格

正確格式的用戶名：xiaoming、xiao123、xiao_123、123_xiao等

錯誤格式的用戶名：xiao%、123_xiao+空格、！@等

密碼的輸入參照用戶名的輸入規則

測試結果：系統用戶能夠登錄系統並具有對應的許可權、非系統用戶不能登錄系統

結果分析：

參照以上兩個測試用例，我們就能很明顯的分辨出用例的優劣。第一個測試用例我們至少需要准備xiaoming這一

個測試數據、登錄界面如果增加了需要輸入驗證碼，我們就要重新修改測試過程，測試數據我們也要做很多修改（就拿用戶名可以輸入數字、字母、下劃線來說，正

確的組合就有2*3*3=18種），測試結果，我們登錄系統為了做什麼？沒有許可權怎麼辦？我們應該具有哪些許可權？第一個用例就沒有做說明，可以說，測試結

果的說明是不全面的。

第二個測試用例，如果系統增加了需要輸入驗證碼，我們在測試過程的第二步，只需要說明輸入用戶名、密碼、驗證碼，測試數據我們不需要做變化，在結果分析里，增加說明：用戶名、密碼、驗證碼正確，准入，否則拒絕。

第二個測試用例，有個不足，就是測試數據不全面。我在編寫測試用例時，針對這個測試用例，我有個測試數據的附件。【附件分為兩部分，手工測試以及 自動化測試 ，手工測試我會有個詳細的數據說明，並不是把所有的數據組合都列出來，而是詳細的說明組合的方式方法，一共有多少種（包含邊界值法以及特殊值等）；自動化測試的數據說明簡單很多，寫一個正則表達式搞定】。

按照第二個測試用例，我們的工作就不再是苦力了，而是智慧的苦力。我們不再是點點點，慢慢的我們知道哪些是主要關注的，哪些是次要關注的，我們應該怎麼去設計數據等等。慢慢的，我們學會了思考，我們也真的進步了。

歡迎大家多提意見，我們一起進步。

Ⅲ 系統測試案例的編寫，一般會用到哪些方法

1.等價類
2.邊界值
3.錯誤推測
4.因果圖
5.判定表
6.正交實驗
7.功能圖
等等，個人感覺前三個最常用了，正交表偶爾用下！
復雜業務可能會用到因果圖！

Ⅳ 測試用例的幾種常見設計方法

一、等價類劃分

         定義： 把全部輸入數據合理劃分為若乾等價類,在每一個等價類中取一個數據作為測試的輸入條件,用少量代表性的測試數據，取得較好的測試結果。等價類劃分可有兩種不同的情況：有效等價類和無效等價類。

1）確定等價類

             有效等價類：     滿足輸入條件的

             無效等價類：     不能滿足輸入條件的     超出范圍的數值  

            空值   

            特殊字元   

            有空格（前、中、後）

2）生成測試用例

每個等價類編寫一個測試用例；

設計一條測試用例，盡可能多地覆蓋所有還未被覆蓋的有效等價類；

設計一條測試用例，覆蓋一條還未被覆蓋到的無效等價類。

等價類劃分的六大原則：

1）輸入條件規定了取值范圍或值的個數的情況下，則可以確立一個有效等價類和兩個無效等價類。

例如：手機號碼由11位數字組成

有效：11位符合電話號碼規則的數字

無效：1、小於11位數字；2、大於11位數字

2）在輸入條件規定了輸入值的集合或者規定了「必須如何」的條件的情況下，可以確立一個有效等價類和一個無效等價類。

3）在輸入條件是一個布爾量的情況下，可確定一個有效等價類和一個無效等價類。布爾量是一個二值枚舉類型，一個布爾量具有兩種狀態：true和false

4）在規定了輸入數據的一組值（假定n個），並且程序要對每一個輸入值分別處理的情況下，可確立n個有效等價類和一個無效等價類。

例如：

輸入條件說明輸入為：中文、英文、數字三種之一，則分別取這三種值作為三個有效等價類，另外把這三種字元以外的任何字元作為無效等價類

5）在規定了輸入數據必須遵守的規則的情況下，可確立一個有效等價類（符合規則）和若干個無效等價類（從不同角度違反規則）

例如：輸入條件說明每個學生可選修1~3門課程

有效：選修1~3門課程

無效：1、未選修課程

            2、選修課程超過3門

6）在確知已劃分的等價類中各元素在程序處理中的方式不同的情況下，則應再將該等價類進一步的劃分為更小的等價類。

等價類劃分法要點：長度、類型、字母、漢字、特殊字元、空、空格

二、邊界值分析法

邊界值分析方法是對等價類劃分方法的補充。

使用邊界值分析方法設計測試用例，首先應確定邊界情況。通常輸入和輸出等價類的邊界，就是著重測試邊界的情況。選取正好等於，剛剛大於或剛剛小於邊界值的值作為測試數據，而不是選取等價類中的典型值或任意值作為測試數據。

1）如果輸入條件規定了一個輸入值范圍，那麼應針對范圍的邊界設計測試用例，針對剛剛越界的情況設計無效輸入測試用例；

比如：需求規定輸入的數字在0~100范圍內，此時測試數據應該有一下幾類：

a.剛剛等於邊界：0、100；

b.剛剛超出邊界范圍：-1、101:；

c.剛剛在范圍內：1、99

2）如果輸入條件規定了輸入值的數量，那麼應針對最小數量輸入值、最大數量輸入值，以及比最小數量少一個、比最大數量多一個的情況設計測試用例；

例1：輸入手機號碼有：

a 輸入11位合法數字；b 輸入10 位合法數字；c 輸入12位合法數字

例2：輸入6~8位數字密碼：

a 輸入6位數字；b 輸入8位數字c 輸入5位數字；d 輸入9位數字

3）如果程序輸入或輸出是一個有序序列，則應該特別注意該序列的第一個和最後一個元素。

三、錯誤推測法

錯誤推測法是基於經驗和直覺推測程序中所有可能存在的各種錯誤，從而有針對性的設計測試用例的方法。需要多實踐，且在實踐時多積累常見問題。

      錯誤推測方法的基本思想： 列舉出程序中所有可能有的錯誤和容易發生錯誤的特殊情況，根據他們選擇測試用例-例如， 在單元測試時曾列出的許多在模塊中常見的錯誤-以前產品測試中曾經發現的錯誤等， 這些就是經驗的總結。還有， 輸入數據和輸出數據為0的情況。輸入表格為空格或輸入表格只有一行-這些都是容易發生錯誤的情況。可選擇這些情況下的例子作為測試用例。

四、因果圖法

        因果圖法適用於描述對於多種輸入條件組合的測試方法。（有多步輸入操作）

        根據輸入條件的組合、約束條件和輸出條件的因果關系，分析輸入條件的各種組合情況，從而設計測試用例的方法，它適用於檢查程序輸入條件涉及的各種組合情況。

例題：有一個處理單價為1元5角錢的盒裝飲料的自動售貨機軟體。若投入1元5角硬幣，按下「可樂」、「雪碧」、「紅茶」按鈕，相應的飲料就送出來。若投入的是兩元硬幣，在送出飲料的同時退還5角硬幣。

分析：

輸入條件：a  投入1元5角硬幣      b  投入2元硬幣

1  按「可樂」按鈕        2  按「雪碧」按鈕      3  按「紅茶」按鈕

中間狀態：1  已投幣      2  已按按鈕

輸出結果：A  送出可樂  B  送出雪碧    C  送出紅茶    D  退還5角硬幣

測試用例：

1）投幣1元5角，按「可樂」按鈕，送出可樂

2）投幣1元5角，按「雪碧」按鈕，送出雪碧

3）投幣1元5角，按「紅茶」按鈕，送出紅茶

4）投幣2元，按「可樂」按鈕，送出可樂，退5角硬幣

5）投幣2元，按「雪碧」按鈕，送出雪碧，退5角硬幣

6）投幣2元，按「紅茶」按鈕，送出紅茶，退5角硬幣

輸入組合：投硬幣+按按鈕

結果組合：送出飲料+退錢

Ⅳ 如何編寫有效測試用例

測試用例，是一份關於具體測試步驟的文檔，它描述了測試的輸入參數、條件及配置、預期的輸出結果等，以判斷被測軟體的工作是否正常。

設計、書寫和執行測試案例是測試活動中重要的組成部分，測試案例通常由測試案例管理系統或工具進行管理。

測試用例的重要性是毋庸置疑的，它是軟體測試全部過程的核心，是測試執行環節的基本依據。測試用例編寫應該遵循的原則：

特性：

一個好的測試用例應該具有較高的發現某個尚未發現的錯誤的可能性，而一個成功的測試案例能夠發現某個尚未發現的錯誤，通常一個好的測試案例有以下特性：

測試用例不可能設計得天衣無縫，也不可能完全滿足軟體需求的覆蓋率，測試執行過程里肯定會發現有些測試路徑或數據在用例里沒有體現，那麼事後該將其補充到用例庫里，以方便他人和後續版本的測試。

測試用例的信息有很多，可以根據實際的情況進行增刪，一般來說一個優秀的測試用例應該包含以下信息：

這些信息建議可以由測試案例自動生成。

測試級別進行說明：

6.測試類型：功能測試、邊界測試、異常測試、性能測試、壓力測試、兼容測試、安全測試、恢復測試、安裝測試、界面測試、啟動/停止 測試、文檔測試、配置測試、可靠性測試、易用性測試、多語言測試。
7.預置條件：對測試的特殊條件或配置進行說明
8.測試步驟：詳細描述測試過程，案例的操作步驟建議少於15個。
9.預期結果：預期的測試結果

例如：假設目前測試中國移動互聯簡訊網關是否能正確發送簡訊給中國聯通互聯網關，測試用例的設計如下：
（1）測試用例ID：TC000001
（2）測試用例名稱：中國移動全球通手機用戶成功發送簡訊給中國聯通手機用戶
（3）測試功能點：中國移動全球通手機用戶成功簡訊給中國聯通手機用戶，中國聯通網關返回成功的狀態報告
（4）測試目的：
A、中國移動互聯簡訊網關能否正確處理全球通用戶發送給中國聯通用戶的簡訊；
B、中國移動互聯簡訊網關能否正確處理中國聯通互聯簡訊網關返回成功的狀態報告的情況。
（5）測試級別：基本功能測試
（6）測試類型：功能測試
（7）預置條件：各網關實體按照組網圖中的關系連接好，各實體之間的連接和通信正常。
（8）測試步驟：
A、中國移動全球通手機用戶（13901000001）給中國聯通手機用戶（13001000001）發送MO簡訊，內容為「測試」，目的號碼填為中國聯通手機號碼；
B、中國聯通互聯簡訊網關把簡訊下發給中國聯通用戶成功後，給中國移動互聯簡訊網關返回一個標識成功的狀態報告。
（9）預期結果：
A、中國聯通手機用戶（13001000001）接收到了簡訊，內容為「測試」，源號碼為中國移動全球通的用戶號碼（13901000001）；
B、在中國移動互聯簡訊網關上產生SMO話單，其中「短消息發送狀態」填0（表示成功），「源手機號碼」13001000001，「目的手機號碼」為13001000001。

下面是一個完整的測試用例的模版：

對一個全新的產品來說，首先需要了解的是產品需求文檔和產品模塊之間的關系。然後需要從需求文檔中書寫與所有需求相對應的主路徑測試案例和煙霧測試案例， 這個時候也同時會包括一定的基本路徑測試案例甚至是詳細測試案例。在這個時候，因為對產品沒有直接的使用感受，書寫測試案例要考慮面廣而不要太過精細。繼 續閱讀產品功能定義文檔，將所有的功能定義直接對應寫相關的測試案例，這個時候，最好能夠對程序的本身有一定的接觸，加深對程序的了解，以便寫出更好，更 全面的測試案例。最後，在實際測試中，還需要不斷擴充，修改以前的測試案例，得到完整的基本功能測試案例和詳細測試案例。如果對於一個已有一定或大部分案 例的產品來說，不管測試者是否本身熟悉這個產品，其主要的任務就是閱讀，檢查需求及相關的變更，然後對原有的案例進行理解，擴充和修改。這就是案例的重用 /復用。設計測試案例的時候，需要有清晰的測試思路，對要測試什麼，按照什麼順序測試，覆蓋哪些需求做到心中有數。測試用例編寫者不僅要掌握軟體測試的技 術和流程，而且要對被測軟體的設計、功能規格說明、用戶試用場景以及程序/模塊的結構都有比較透徹的理解。

測試用例設計一般包括以下幾個步驟：
1、測試需求分析從軟體需求文檔中，找出待測試軟體/模塊的需求，通過自己的分析、理解，整理成為測試需求，清楚被測試對象具有哪些功能。測試需求的特點是：包含軟體需求，具有可測試性。

測試需求應該在軟體需求基礎上進行歸納、分類或細分，方便測試用例設計。測試用例中的測試集與測試需求的關系是多對一的關系，即一個或多個測試用例集對應一個測試需求。
2、業務流程分析軟體測試，不單純是基於功能的黑盒測試，還需要對軟體的內部處理邏輯進行測試。為了不遺漏測試點，需要清楚的了解軟體產品的業務流程。建 議在做復雜的測試用例設計前，先畫出軟體的業務流程。如果設計文檔中已經有業務流程設計，可以從測試角度對現有流程進行補充。如果無法從設計中得到業務流 程，測試工程師應通過閱讀設計文檔，與開發人員交流，最終畫出業務流程圖。業務流程圖可以幫助理解軟體的處理邏輯和數據流向，從而指導測試用例的設計。

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

A、主流程是什麼
B、條件備選流程是什麼
C、數據流向是什麼
D、關鍵的判斷條件是什麼
3、測試用例設計
完成了測試需求分析和軟體流程分析後，開始著手設計測試用例。測試用例設計的類型包括功能測試，邊

界測試，異常測試，性能測試，壓力測試等。在用例設計中，除了功能測試用例外，應盡量考慮邊界、異

常、性能的情況，以便發現更多的隱藏問題。

黑盒測試的測試用例設計方法有：等價類劃分、邊界值劃分、因果圖分析和錯誤猜測，白盒測試的測試用

例設計方法有：語句覆蓋、判定覆蓋、條件覆蓋、判定/條件覆蓋、多重條件覆蓋。在這里主要討論黑盒測

試。在設計測試用例的時候可以使用軟體測試用例設計方法，結合前面的需求分析和軟體流程分析進行設

計：

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

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

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

適合的技術：邊界值劃分

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

類似這樣的情況需要書寫相關的異常測試。

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

性能測試：檢查系統是否滿足在需求中所規定達到的性能，性能主要包括了解程序的內外部性能因素。內部性能因素包括測試環境的配置，系統資源使用狀況；外部因素包括響應時間，吞吐量等。

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

壓力測試：壓力測試又稱強度測試，主要是檢查系統運行環境在極限情況下軟體運行的能力，比如說給一個相當大的負荷或網路流量給應用軟體兼容測試：測試軟體產品在不同的平台，不同的工具，相同工具的不同版本下功能的兼容性。

4、測試用例評審

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

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

5、測試用例更新完善

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

Ⅵ 編寫測試用例有哪些方法

可以採用軟體測試常用的基該方法：等價類劃分法、邊界值分析法、錯誤推測法、因果圖法、邏輯覆蓋法等設計測試用例。視軟體的不同性質採用不同的方法。如何靈活運用各種基該方法來設計完整的測試用例，並最終實現暴露隱藏的缺陷，全憑測試設計人員的豐富經驗和精心設計。

編寫測試用例文檔應有文檔模板，須符合內部的規范要求。測試用例文檔將受制於測試用例管理軟體的約束。 軟體產品或軟體開發項目的測試用例一般以該產品的軟體模塊或子系統為單位，形成一個測試用例文檔，但並不是絕對的。

測試用例文檔由簡介和測試用例兩部分組成。簡介部分編制了測試目的、測試范圍、定義術語、參考文檔、概述等。測試用例部分逐一列示各測試用例。每個具體測試用例都將包括下列詳細信息：版本號、模塊名稱、用例編號、用例名稱、用例級別、預知條件、驗證步驟、期望結果（含判斷標准）、測試結果、測試時間、測試人員等。

(6)編寫測試案例常用的的編寫方法擴展閱讀

測試執行過程中，應該注意及時更新測試用例。往往在測試執行過程中，才發現遺漏了一些測試用例，這時候應該及時的補充；往往也會發現有些測試用例在具體的執行過程中根本無法操作，這時候應該刪除這部分用例；也會發現若干個冗餘的測試用例完全可以由某一個測試用例替代，那麼刪除冗餘的測試用例。

總之，測試執行的過程中及時地更新測試用例是很好的習慣。不要打算在測試執行結束後，統一更新測試用例，如果這樣，往往會遺漏很多本應該更新的測試用例。

Ⅶ 你所熟悉的測試用例設計方法都有哪些

測試用例常見的設計方法有：等價類劃分法、邊界值分析法、錯誤推測法、判定表法、正交實驗法。
一、等價類劃分法
顧名思義，顧名思義，等價類劃分，就是將測試的范圍劃分成幾個互不相交的子集，他們的並集是全集，從每個子集選出若干個有代表性的值作為測試用例。
二、邊界值分析法
長期的測試工作經驗告訴我們，大量的錯誤是發生在輸入或輸出范圍的邊界上，而不是發生在輸入輸出范圍的內部。因此針對各種邊界情況設計測試用例，可以查出更多的錯誤。
三、錯誤推測
錯誤推測法是指：在測試程序時，人們可以根據經驗或直覺推測程序中可能存在的各種錯誤，從而有針對性地編寫檢查這些錯誤的測試用例的方法。
這種方法沒有固定的形式，依靠的是經驗和直覺，很多時候，我們都會不知不覺的使用到。
四、判定表法
又稱為策略表，基於策略表的測試，是功能測試中最嚴密的測試方法。該方法適合於邏輯判斷復雜的場景，通過窮舉條件獲得結果，對結果再進行優化合並，會得到一個判斷清晰的策略表。
五、正交實驗法
用語言描述正交實驗法會很抽象難懂，簡單說，就是在各因素互相獨立的情況下，設計出一種特殊的表格，找出能以少數替代全面的測試用例。

(7)編寫測試案例常用的的編寫方法擴展閱讀：
功能測試方法還有很多，例如因果圖法，狀態轉換測試法等，他們都略為復雜，像正交實驗法一樣，有各自的一套東西，不過本質都是通過畫圖，讓我們更好的思考，最後轉化成判定表。
實際上常用的是前面五種方法，包括：等價類劃分法、邊界值分析法、錯誤推測法、判定表法、正交實驗法。
等價類劃分法劃分標准：
1) 完備測試、避免冗餘
2) 劃分等價類重要的是：集合的劃分、劃分為互不相交的一組子集，而子集的並是整個集合
3) 並是整個集合：備性
4) 子集互不相交：保證一種形式的無冗餘性
5) 同一類中標識（選擇）一個測試用例，同一等價類中，往往處理相同，相同處理映射到「相同的執行路徑」。

Ⅷ 測試怎麼做

最近，很多小夥伴正在面試新工作做准備。所以我整理一下軟體測試的基本工作流程和一些測試用例編寫方法。大致內容如下，希望這些內容對大家有幫助。

首先，作為測試人員需了解業務，分析需求點

為什麼測試人員要參加需求分析？也就是進行測試需求分析的目的是什麼？

第一、把用戶需求轉化為功能需求

1）對測試范圍進度量

2）對處理分支進行度量

3）對需求業務的場景進行度量

4）明確其功能對應的輸入、處理和輸出

5）把隱式需求轉變為明確

第二、明確測試活動的五個要素

測試需求是什麼、決定怎麼測試、明確測試時間、確定測試人員、確定測試環境、測試中需要的技能，工具以及相應的背景知識，測試過程中可能遇到的風險等等。測試需求需要做到盡可能的詳細明確，以避免測試遺漏和誤解。

那麼，接下來怎麼進行測試需求分析？

1）確認功能

（業務功能、輔助功能、數據約束、易用性需求、編輯約束、參數需求、許可權需求、性能約束）

1、業務功能：與用戶實際業務直接相關的功能或者細節；

2、輔助功能：輔助完成業務功能的一些功能或者細節，例如：設置過濾條件；

3、數據約束：功能的細節，主要是用於控制在執行功能時，數據的顯示範圍，數據之間的關系等；

4、易用性需求：功能的細節，產品中必須提供，便於功能操作使用的一些細節，例如：快捷鍵等；

5、編輯約束：功能的細節，在功能執行時，對輸入數據項目的一些約束條件，例如：只能輸入數字等；

6、參數需求：功能的細節，在功能執行時，需要根據參數設置不同，進行不同處理的細節；

7、許可權需求：功能的細節，在功能執行的過程，根據不同的許可權進行不同的處理，不包括直接限制某個功能的許可權；

8、性能約束：功能的細節，執行功能時，必須滿足的性能需求；

2）場景分析

1、考慮場景的調用者：考慮每一個場景提供的服務是供哪些外部模塊或者系統調用的，找出所有調用者。調用前提，約束都要考慮。每一個調用都可以考慮成一個大的業務流程（一般和外部有交互的業務出錯率比較大，需要重點關注）。

2、考慮系統內部各個場景之間的聯系：形成內部業務流程，需要分析每個場景之間的約束關系，執行條件，組織出各種業務流程圖。

3）挖掘隱性需求

這需要測試工程師的經驗積累：

1）常用的或者規定的業務流程

2）各個業務流程分支的遍歷

3）明確規定不可使用的業務流程

4）沒有明確規定但是應該不可使用的業務流程

5）其他異常或者不符合規定的操作

接下來，一起說說測試用例設計那點事兒

1、如何進行測試用例的設計？

編寫測試用例之前，我們需要對項目的需求有清晰的了解，對要測試什麼，按照什麼順序測試，覆蓋哪些需求做到心中有數，作為測試用例的編寫者不僅了解要有常見的測試用例編寫方法，同時需要了解被測軟體的設計、功能規格說明、用戶使用場景以及程序/模塊的結構。

步驟

1）測試需求分析：從項目部拿到軟體的需求規格說明書後，開始對項目的需求進行分析，通過自己的分析、理解，整理成為測試需求， 清楚分析出被測試對象具有哪些功能。明確測試用例中的測試集用例與需求的關系，即一個或多個測試用例集對應一個測試需求。

2）業務流程分析：分析完需求後，明確每一個功能的業務處理流程，不同的功能點做業務的組合，以及項目的隱式需求。如遇復雜的測試用例設計前，先畫出軟體的業務流程。從業務流程上，應得到以下信息：

A、主流程是什麼?

B、條件備選流程是什麼?

C、數據流向是什麼?

D、關鍵的判斷條件是什麼?

3）測試用例設計：

完成以上兩步則可進行測試用例設計，功能測試用例，應盡量考慮邊界、異常、性能的情況，以便發現更多的隱藏問題。設計測試用例的常見方法：

等價類 → 邊界值 → 因果圖 → 判定表 → 狀態遷移 → 正交實驗 → 場景法 → 錯誤推斷（注意：編寫測試用例時，我們盡可能取的不應該是有效等價類而應該是無效等價類）

4）編寫完成後自我檢查以及部門內部評審：

①測試用例本身的描述是否清晰，語言准確；是否存在歧義性；

②測試用例內容是否完整，是否清晰的包含輸入和預期輸出的結果；測試步驟是否清晰；

③測試用例中使用的測試數據是否恰當，准確；

④測試用例是否具有指導性，是否能靈活的指導軟體測試工程師通過測試用例發現更多的缺陷，而不是限制他們的思維；

⑤是否考慮到測試用例執行的效率。對於不斷重復執行的步驟，是否保證了驗證點相同；或者測試用例的設計是否存在冗餘性等。這些都可能導致測試用例執行效率低下；

⑦畫出軟體需求跟蹤矩陣，驗證測試用例是否完全覆蓋了需求，驗證測試用例的覆蓋性；

⑧測試用例是否完全遵守了軟體需求的規定。這一點其實有一些難做到。考慮到時間/成本的關系，應該視具體情況而定。

5）測試用例更新完善：

測試用例編寫完成之後需要不斷完善，如遇需求更改或功能新增時，測試用例必須配套修改更新，同時在測試過程中發現設計測試用例時考慮不周，需要對測試用例進行修改完善;在軟體交付使用後客戶反饋的軟體缺陷，而缺陷又是因測試用例存在漏洞造成，也需要對測試用例進行完善。

緊接著，測試用例執行的過程

首先搭建測試環境，准備好測試數據，進行預測，預測通過之後，按照測試用例進入正式測試，有效的測試執行可以將測試用例發揮最大的價值。因此，測試用例規范執行有助於更好的發現代碼中存在的缺陷。根據個人測試工作經驗，好的測試執行應該包含如下內容：

①測試執行中評估測試執行時間不足，需及時上報風險。滿足質量優先，進度其次原則。

②測試用例按優先順序順序執行，通常是基本、詳細和異常順序執行。

③未執行用例、標志為刪除或者無效的用例，需註明原因。

④執行過程中有疑問的測試用例（場景、操作步驟、檢查點等）需找測試設計人員澄清。

⑤測試執行需對用例描述的檢查點逐一檢查，避免遺漏。

⑥重視不易重現的缺陷場景，可能是一個bug。

⑦執行過程中發現有前期設計遺漏用例需補充到用例文檔並執行驗證。

⑧建議測試人員交叉執行重復測試用例，用例執行對相同測試人員有免疫性。避免可能的缺陷一直遺漏到現在。如有需要，建議保留測試結果，結果可視。以便於不同版本間的測試結果對比。已確認問題需及時按照問題單提單要求（規范和缺陷定級）提單。

⑨跟蹤問題單修復情況並回歸驗證問題單。每輪次測試結束，find一下是否有core文件產生。測試結束，將最終測試用例文檔上傳到歸檔目錄，實現用例重用。

以上是針對一般的軟體測試流程，如果是自動化測試的話，應該還有根據測試用例進行腳本編寫，運行腳本等。此處可能寫的不詳細，希望大家可以在下方評論讓我完善。

最後已達到准確要求的，根據測試情況寫測試報告，對整個測試過程和版本的質量做一個評估。

測試報告是指把測試的過程和結果寫成文檔，對發現的問題和缺陷進行分析，為糾正軟體的存在的質量問題提供依據，同時為軟體驗收和交付打下基礎。測試報告是測試階段最後的文檔產出物。優秀的測試經理或測試人員應該具備良好的文檔編寫能力，一份詳細的測試報告包含足夠的信息，包括產品質量和測試過程的評價，測試報告基於測試中的數據採集以及對最終的測試結果分析。

Ⅸ 常見的測試用例設計方法都有哪些

黑盒測試用例設計方法包括等價類劃分法、邊界值分析法、錯誤推測法、因果圖法、判定表驅動法、正交試驗設計法、功能圖法、場景圖法等。
白盒子測試方法：（強度由低到高）語句覆蓋、判定覆蓋、條件覆蓋、判定條件覆蓋、條件組合覆蓋、路徑覆蓋。
測試人員經常用到的有等價類，邊界值，場景法，因果圖法。
具體方法的使用可以網路下，這里就不啰嗦了。

Ⅹ 測試用例是怎麼寫的

測試用例可以分為基本事件、備選事件和異常事件。設計基本事件的用例，應該參照用例規約（或設計規格說明書），根據關聯的功能、操作按路徑分析法設計測試用例。而對孤立的功能則直接按功能設計測試用例。基本事件的測試用例應包含所有需要實現的需求功能，覆蓋率達100%。

設計備選事件和異常事件的用例，則要復雜和困難得多。例如，字典的代碼是唯一的，不允許重復。測試需要驗證：字典新增程序中已存在有關字典代碼的約束，若出現代碼重復必須報錯，並且報錯文字正確。

往往在設計編碼階段形成的文檔對備選事件和異常事件分析描述不夠詳盡。而測試本身則要求驗證全部非基本事件，並同時盡量發現其中的軟體缺陷。

可以採用軟體測試常用的基該方法：等價類劃分法、邊界值分析法、錯誤推測法、因果圖法、邏輯覆蓋法等設計測試用例。視軟體的不同性質採用不同的方法。如何靈活運用各種基該方法來設計完整的測試用例，並最終實現暴露隱藏的缺陷，全憑測試設計人員的豐富經驗和精心設計。

設計原則

測試用例是一個文檔，是執行的最小實體。測試用例包括輸入、動作、時間和一個期望的結果，其目的是確定應用程序的某個特性是否可正常工作，並且達到程序所設計的結果。

以便測試某個程序路徑或核實是否滿足某個特定需求般在進行測試用例設計前要全面了解被測試產品的功能、明確測試范圍(特別是要明確哪些是不需要測試的)、具備基本的測試技術與方法等。測試用例設計一般遵循以下原則:

(1)正確性。輸入用戶實際數據以驗證系統是否滿足需求規格說明書的要求;測試用例中的測試點應首先保證要至少覆蓋需求規格說明書中的各項功能，並且正常。

(2)全面性。覆蓋所有的需求功能項;設計的用例除對測試點本身的測試外，還需考慮用戶實際使用的情況、與其他部分關聯使用的情況、非正常情況(不合理、非法、越界以及極限輸入數據)操作和環境設置等。

(3)連貫性。用例組織有條理、主次分明，尤其體現在業務測試用例上;用例執行粒度盡量保持每個用例都有測點，不能同時覆蓋很多功能點，否則執行起來牽連太大，所以每個用例間保持連貫性很重要。

(4)可判定性。測試執行結果的正確性是可判定的，每一個測試用例都有相應的期望結果。

(5)可操作性。測試用例中要寫清楚測試的操作步驟，以及與不同的操作步驟相對應的測試結果。