定義

測試用例（Test Case）是測試設計的一個產出物，它直接體現測試設計的思想，一份漂亮的測試用例不僅僅是設計思路的優秀體現，更是便於流轉和執行，具有可讀性、傳遞性。它一般是為某個特殊目標而編制的一組測試輸入、執行條件及預期結果，用以核實程式是否滿足某個特定需求及沒有完成多餘操作，即保證以下兩點：

• 程式做了它應該做的事情
• 程式沒有做它不該做的事情

因此，作為測試實施依據的測試用例，必須要能完整覆蓋測試需求，而不應針對單個Case去評判好壞。

怎麼寫好用例

0、用例模板

首先，一份漂亮的測試用例-需有一個用例模板，模板可以將測試用例的結構形式固定化、標準化，對編寫者啟引導作用，保證一份測試用例資料完整。

1、對被測版本足夠了解

由粗略詳細步驟來解讀產品需求文件，如互動、功能流程、邊界、約束等等。充分理解技術實現原理（實現的邏輯原理、架構及對其他平臺的依賴、介面等）。

深入理解使用者群，分析使用者使用場景、可能的使用方法及使用者心理，完全從使用者角度出發，來設計Case，同時對使用者體驗做出一定的判斷。

2、設計Case優先順序

一般BugFree或禪道工具中編寫好Case後可以按優先順序來篩選優先順序，如果是用Excel文件來寫可以來通過不同背景色來標識相應的優先順序，無論評審還是執行，都可以按此來查閱。無論是冒煙測試用例還是功能測試用例，節省大量時間。

3、從粗到細分析需求

可以使用工具輔助，第一遍需求分析時，粗略畫出測試需求框架；第二遍分析需求時，開始延伸每個出子測試點；細化測試點時，可參考或引用寫好的公共Case， 也要考慮到被測版本中該功能的特性。另外需要考慮的就是測試點的顆粒度要把握好。

4、測試用例Update

需求分析階段和開發階段，都可能出現需求變更，這時對於我們前期粗略整理好的測試點就需要及時的同步更新了。另外在Case評審階段，可能會出現Case冗餘或遺漏，也需要在評審結束後在Case池裡及時修整。如果專案中有使用需求工具之類的，可以利用工具去同步通知到每個節點的負責人，會大大 減少UPdate的時間。

如何快速提升TestCase能力

1、 熟悉業務

這是必備條件，因為所有Case都是從業務層開始入手的，而終端使用者也是以業務為出發點。

2、 培養使用者思維

測試人員需要站在客戶的角度分析使用者需要什麼、想要什麼、不想要什麼，這樣有利於我們更好的挖掘隱含需求。所以設計場景時也同樣是站在使用者角度。

3、 勿限制測試思維

對於好的測試人員，都會有自己的一份通用測試用例表， 每次編寫測試用例時，會將重複或公共的功能摘出來，去參照已有的通用Case。但若不能做到及時更新，隨公司專案變更等，很可能在某些專案中固步自封，不能靈活地運用。

所以通用Case總結更新是必不可少的，也可以分享出來讓同行參謀 ，大家集思廣益，也許其他人有更新奇的方法，這樣會不斷地開拓自己的測試思維 ，而不至於一直重複原有的經驗。

4、 樂於分享，有計劃地總結

給自己的學習過程制訂一個詳細的計劃，量化到天，排好每天要學習的東西。同時最重要的是，一定要養成總結的習慣 ，每天總結 ，每個專案總結 ，總結測試方法，總結Bug原因，奇葩Bug等等，這些將會成為你日後工作的寶貴財富。

同時，主動總結久了，你會發現自己有質的提升，而且對於當前的工作會更遊刃有餘，經驗是靠日積月累的。

一份漂亮的測試用例

一份漂亮的測試用例應該具有目標、可讀、簡潔的特點，而這些是通過從各個屬性所填的內容散發出來的。

1、用例編號

用例編號就是測試用例文件中一個代號，需全域性唯一，我們可以通過代號快速找到測試用例。

用例編號的書寫，建議是專案名_模組名_001，我們可以通過編號快速知道一個專案有多少用例，專案中一個模組有多少用例。

2、用例標題

目的:概述測試用例的主要內容，明確用例意圖
在做用例評審時，通過瀏覽一個模組的用例標題，能快速判斷有沒有遺漏功能；通過瀏覽一個功能用例標題，能快速判斷出有沒有遺漏正常或異常case。

一個測試用例的好壞，一半體現在測試用例標題上。一個好用例的標題，書寫方式有三種：

1. 一句完整的話（不超過30個漢字）
2. 功能簡報形式

• 例：電影詳情頁-返回
• 例：欄目-釋出
• 例：電影-新增

1. 按條件/狀態

• 例：發起轉碼-無源媒體檔案
• 例：發起轉碼-有源媒體檔案
• 例：鑑權-已訂購產品已過期
• 例：鑑權-已訂購產品未過期
• 例：鑑權-未訂購產品

3、預置條件

預置條件-測試用例能執行的前提條件。可以是到達某一狀態，也可以是一些配置。

書寫要求：一個簡潔的結果。

• 使用者已成功登陸
• 自動稽核的開關已關
• 不需要寫是怎麼登陸的/如何將開關關掉的。

4、測試步驟

測試步驟是指如何執行用例，先做什麼後做什麼，是有順序的概念在的。
步驟和用例的目標需要是一致的，任意一個偏離目標整個case就是無意義的。

書寫要求：可執行的操作，功能用例步驟不大於7，流程用例步驟隨業務而定-這裡不做限制。

• 採集電影[check1]
• 預處理電影[check2]
• 稽核電影[check3]
• 釋出電影[check4]

5、預期結果

預期結果是和測試步驟一一對應的，有幾個檢查點，就需要有幾個結果。

書寫要求：和測試步驟中check點一一對應，檢查點>=1個

預期結果需要是可檢查的，可從三個方面進行校驗：

1. 介面（結果會直接顯示在介面上的）
2. 資料庫（有些資料只會存於資料庫中）
3. 磁碟（檔案資料需具體到磁碟上看是否存在，資料是否正確）

6、測試資料

測試資料：測試時使用到的資料。
書寫要求：可用電影。
不用寫到實際資料，在測試新增電影功能時，不需要寫具體電影、導演、演員、宣傳圖片。
具體的資料-可以在資料準備時做好，如符合規格的圖片（海報、圖示、劇照），符合位元速率的媒體檔案（正片和預覽片）。

測試用例整體是有邏輯的

測試用例整體是有邏輯的-需要有用例設計的魂，編寫測試用例的兩個途徑：

1. 先有用例設計，從整個產品/專案出發，先確定測試範圍、測試目標，再細化範圍到具體物件->具體功能，確定設計用例技術和測試方法，再來編寫用例。
2. 測試執行後-通過Bug反推 修改補充用例。

兩者相結合才會產出一份漂亮且有效的測試用例，理論->實踐->理論過程。

編寫測試用例常見問題

• 用例標題意圖不明確
• 用例中引用其他用例
• 用例中包含過多的細節
• 用例中出現籠統的詞

1. 反覆、多次
   
   • 確定反覆的具體次數
   • 確定一個反覆的範圍
2. 長時間
   
   • 確定長時間的具體時間
   • 確定一個長時間的範圍
3. 大量
   
   • 確定具體的資料量
   • 從需求/規格中中參照值
     
     • 用例中步驟不可執行
     • 用例中期望結果不可驗證

參考資料：