如何編寫高質量的測試用例？有哪些方法論或原則？

01-08

從事測試很久了，可還是在產品發布的時候有問題，不知道用例設計到什麼程度才能更好的規避？

瀉藥。

單元測試用例

單元測試用例有人總結出來了編寫用例的3A原則，分別是

Arrange: 初始化測試對象或者準備測試數據
Act : 調用被測方法
Assert: 斷言

給一個例子(c#)

[TestMethod] public void Withdraw_ValidAmount_ChangesBalance() { // arrange double currentBalance = 10.0; double withdrawal = 1.0; double expected = 9.0; var account = new CheckingAccount("JohnDoe", currentBalance); // act account.Withdraw(withdrawal); double actual = account.Balance; // assert Assert.AreEqual(expected, actual); }

服務間的介面測試用例

服務間的介面測試實際上是黑盒測試，3A原則也適用於這種測試用例的編寫

Arrange: 準備測試數據，這裡的方案會有很多
Act : 使用各種參數調用被測介面
Assert: 斷言

舉個例子(python)

def test_get_task_by_id(self): # arrange create_task_res = self.create_task("test", "desc") new_id = create_task_res["id"]


        # act

        url_for_get_by_id = self.ip + "/api/tasks/" + str(new_id)

        res = requests.request("GET", url_for_get_by_id).json()

# assert self.assertEqual(res["id"], new_id)

手工測試用例

手工的功能測試用例也可以用3A原則來編寫。

Arrange: 準備被測功能相關的測試數據，比如往系統里錄入一批工單以便測試工單的分頁功能
Act : 調用被測的功能，實際上這就是我們一直講的測試步驟
Assert: 斷言

舉個例子

# arrange and act 打開chrome瀏覽器並跳轉至http://localhost/wordpress/wp-login.php 在用戶名文本框中輸入admin 在密碼文本框中輸入admin 點擊登陸按鈕 # assert 瀏覽器跳轉到http://localhost/wordpress/wp-admin/ 右上角出現「你好，amdin」字樣

在一些測試團隊中，手工測試用例會在測試人員之間進行傳播，比如李雷寫了手工測試用例，韓梅梅則是用例的執行者。如果李雷的測試用例寫的比較抽象派和印象派，韓梅梅是很難去直接執行的，所以會有一些測試團隊強調盡量編寫可以讓人理解，也就是不用腦補的手工測試用例。但是寫的越精確花費的時間就越長，如果項目周期緊張的話，是沒有充足的時間去寫完備的測試用例的。

在這種情況下，一些有經驗的測試人員會寫一些測試大綱，相當於是測試備忘錄，提醒自己該測哪些情況，不要有遺漏，比如

登錄成功的情況登錄失敗：用戶名密碼為空登錄失敗：密碼不對登錄失敗：只輸用戶名不輸密碼

用例的維護

用例的維護成本往往是很高的

單元測試用例：被測代碼發生變化時單元測試用例需要相應更新
服務間介面用例：被測服務的介面或邏輯發生變化時需要相應更新
手工測試用例：需求變化了用例就要跟著改

保證用例跟需求的一致性一直是很大的挑戰。這也是TDD測試驅動開發所希望解決的問題——如果需求文檔直接是可以執行的測試用例，需求跟用例合二為一自然就不存在同步的困難了。

綜上，希望能夠對你有所幫助

這是別人寫的，借過來給大家看看

高質量的標準：

1、覆蓋到所有的業務邏輯（包括正常邏輯和異常邏輯）

2、覆蓋到所有的典型用戶場景

3、覆蓋到所有的需求點

4、測試目標明確，並且測試步驟能夠最快的達到測試目的或者測試時間很短

5、沒有冗餘的用例

6、測試用例能夠直接附帶測試策略，該模塊的策略指定人和用例執行人能夠非常清楚

如何達到該目標：

一、基於邏輯的用例設計過程：

A、用例編寫過程：

1、優先完成業務邏輯圖，需要在測試的角度上面去畫邏輯圖，包括數據流完整的輸入和輸出過程，並且自己能夠理解為什麼這樣處理

2、根據自己的理解分析每個邏輯的處理是否完善，是否有沒有覆蓋到的地方，並提交缺陷預防bug

3、根據邏輯編寫測試用例，保證每個邏輯都能夠有對應的用例覆蓋

4、編寫邏輯用例的過程中思考如何去改進該用例的測試過程，比如：介面測試，自動化測試，腳本。並且，能夠及時讓研發提供對應的介面和調試方法

5、用例要按照10分鐘原則，即保證10分鐘內能夠執行完成

B、用例評審過程：

1、先講解整個業務邏輯圖，需要保證評審人員對於整個業務邏輯圖都非常清楚，並且能夠理解為什麼這樣做

2、分析整個業務邏輯圖是否有沒有覆蓋到的場景或者分支情況（採用頭腦風暴的方式）

3、分析業務邏輯的異常處理情況（是否每個業務邏輯都有對異常情況進行處理，也採用頭腦風暴的方式）

4、是否將邏輯的用例分類比較合理，讓大家通過邏輯很容易就找到對應的用例

5、分析是否所有的邏輯都能夠找到對應的用例（通過邏輯找到對應的用例）,包括前面沒有考慮到的邏輯

6、分析用例是否有冗餘，是否多個用例都是覆蓋的同一個邏輯（包括測試步驟和檢查點）

7、分析用例的測試方法是否有改進，是否能夠直接通過代碼靜態走讀、介面測試、自動化測試（包括編寫腳本）、引入工具等等來進一步提高我們的測試效率

測試用例異常處理分析：

1、僅僅只能保證已有的邏輯沒有問題，但是可能出現部分情況沒有處理導致失效的情況，可以通過後面的場景用例和需求用例來補充覆蓋

2、邏輯裡面異常情況考慮不充分，導致測試用例也相對比較欠缺，可以通過對每個邏輯進行頭腦風暴，分析是否有其他異常情況，並且評審時重點評審這塊

3、研發的邏輯有可能本身就是錯誤的，但是如果順著研發的邏輯去編寫用例時會導致用例也有問題，達不到測試目的，所以需要從需求和設計的角度去提前分析邏輯是否有問題

4、過程中研發的邏輯可能變化比較快，這樣會導致邏輯測試用例也要經常變化，所以需要保證研發的編碼是與設計一致的，並且邏輯是盡量根據設計來進行的

另外，邏輯用例的設計可以在編碼中後期進行，這樣的改動會少點

多看看別人寫的測試用例，或看看軟體測試書籍，

如何編寫測試用例（筆記） - Testing 分享

可以學習一下《軟體測試認證資格》

測試行業專業認證機構 - ISTQB

測試用例設計是一門學科。所謂高質量的用例，我理解是在控制用例規模的前提下，提高測試的充分性和完備性（當然還有有效性）；要做到這些，除了經驗積累，確實有方法論可循。