淺談軟體測試必會技能之測試用例編寫基本

什麼是測試用例？百科測試用例的概念如下：

測試用例(Test Case)是指對一項特定的軟體產品進行測試任務的描述，體現測試方案、方法、技術和策略。其內容包括測試目標、測試環境、輸入資料、測試步驟、預期結果、測試指令碼等，最終形成文件。簡單地認為，測試用例是為某個特殊目標而編制的一組測試輸入、執行條件以及預期結果，用於核實是否滿足某個特定軟體需求。

在整個測試的過程中，提測之前，準確說，應該在需求評審、技術方案確認之後，那我們就需要去編寫測試用例，通過測試用例來執行測試。

本篇只是單純的描述如何編寫一條用例，針對用例本身，比如：包含哪些必要欄位、可以有哪些擴展欄位、每個欄位應該編寫到什麼樣的程度。

測試用例的好處

1.任何測試人員都可以執行

可以給不是很熟悉該業務或者該模組的同學直接去執行，而不需要去反覆再同開發、產品對接，或者是猜測該條用例的意思或者意圖。

2.減少不必要的溝通成本、節省實際執行時間

一條步驟清晰的用例，完全可以照著一步步執行，預期結果清晰，則可以很容易地斷定該條用例是否通過，前置條件清楚明白，則可以順利執行。

3.儘可能的減少重複勞動

在實際的工作中，我們會發現A同學寫的用例交接給B同學之後，由於用例步驟不詳細、前置不清晰等，導致無法理解、執行，然後會去重寫該模組的用例，這就導致工作成本的增加。

4.歸檔

為後續的迭代、迴歸，回溯或者交接等提供清晰的依據以及指導。

常規基本用例包含欄位

用例名稱、前置條件、輸入步驟、預期結果、備註等，這幾個欄位是必不可少的。

在保證基本欄位清晰的情況下，根據需要，我們可以適當新增一些欄位，比如：用例編號、優先順序、使用平臺、是否自動化、關聯需求、是否通過、網路、備註等等。

基本欄位必不可少，而且還要清晰描述：

1.用例名稱

能完整且簡潔的描述該條用例要做什麼，執行場景是什麼，可包含：模組名+執行場景。

2.前置條件

用例執行需要做哪些前置步驟，或者需要哪些條件才能使該條用例順利的執行下去？一般來說，在功能模組之前存在關聯時或者依賴時，此時需要將前置條件寫清楚，因為這些依賴和關聯的點，可能只有當時相關的測試和開發比較清楚。

例：限免時段內重複領取福利。

（1）在前置條件或者備註裡，最好解釋一下限免規則；

（2）釋出限時免費的活動到測試環境；

（3）同一時段內，領取過一次。

3.用例步驟或者輸入步驟

這裡也是指導用例執行的關鍵，需要將每一步寫的比較清楚，否則其他人來執行的話，很容易出錯或者理解錯。

比如安卓端，正常情況釋出朋友圈文字模式，圖+文章，釋出成功這個用例

例：

（1）正常登入微信

（2）點擊發現

（3）點選朋友圈

（4）點選右上角拍照按鈕，選擇圖片

（5）輸入文字

（6）點選右上角發表

4.預期結果

預期結果非常重要，不僅要將相關的檢查點寫的清晰、完整，而且還要嚴謹、不易產生誤解，能夠讓其他人執行用例之後，明確判斷該條用例是否通過。

比如點選下載某個表情包或者檔案，這裡的檢查包括前端、後端、資料、本地檔案等檢查。

（1）下載過程中進度條的檢查；

（2）下載完成之後檔案是否完整、正常開啟，內容是否正確；

（3）如果存在狀態，狀態是否變化；

（4）如果存在資料儲存，資料庫檢查等。

5.用例編號

代表著用例ID，可以通過多種方式來定，只要清晰明瞭即可。一般可以是：需求編號+功能模組代號+測試類別+編號。

6.優先順序

用例優先順序一般分為3個級別，P0P1P2，P0為最高級別，P2為最低級別。在測試活動中，P0級別用例通常會作為開發提測前的自測用例，因此，P0級別的用例比較重要，但量不能太多，在後續的迭代功能、迴歸測試中，會起著比較重要的作用。一般為正常功能、主流程用例。

7.使用平臺

一般是指測試平臺，比如：android、IOS、ipad、或者WEB、PC端、mac、等。

8.是否自動化

一般是指UI自動化或者介面自動化，如果已經自動化的用例，後續在迴歸測試以及迭代版本的冒煙測試上可以使用自動化來替代，方便區分、統計。

9.關聯需求

這個一般是指需求的連結，或者需求名稱（如果沒有連結的話），方便後續回溯，以及其他人來使用或者熟悉該模組的測試以及開發。

10.是否通過

標註當前測試用例是否通過。

11.網路

測試需要使用網路，比如：3G、4G、wifi、弱網或者弱網詳細參數，比如：丟包、延遲、具體網速、網路容錯等等。

12.備註

一般說明該用例需要注意的事項或者特殊的事項。

部分圖片來源網路，如有侵權請聯絡作者刪除。