定義
測試用例（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。
一個測試用例的好壞，一半體現在測試用例標題上。一個好用例的標題，書寫方式有三種：
- 一句完整的話（不超過30個漢字）
- 功能簡報形式
- 例：電影詳情頁-返回
- 例：欄目-發佈
- 例：電影-添加
- 按條件/狀態
- 例：發起轉碼-無源媒體文件
- 例：發起轉碼-有源媒體文件
- 例：鑑權-已訂購產品已過期
- 例：鑑權-已訂購產品未過期
- 例：鑑權-未訂購產品
3、預置條件
預置條件-測試用例能執行的前提條件。可以是到達某一狀態，也可以是一些配置。
書寫要求：一個簡潔的結果。
- 用戶已成功登陸
- 自動審覈的開關已關
- 不需要寫是怎麼登陸的/如何將開關關掉的。
4、測試步驟
測試步驟是指如何執行用例，先做什麼後做什麼，是有順序的概念在的。
步驟和用例的目標需要是一致的，任意一個偏離目標整個case就是無意義的。
書寫要求：可執行的操作，功能用例步驟不大於7，流程用例步驟隨業務而定-這裏不做限制。
- 採集電影[check1]
- 預處理電影[check2]
- 審覈電影[check3]
- 發佈電影[check4]
5、預期結果
預期結果是和測試步驟一一對應的，有幾個檢查點，就需要有幾個結果。
書寫要求：和測試步驟中check點一一對應，檢查點>=1個
預期結果需要是可檢查的，可從三個方面進行校驗：
- 界面（結果會直接顯示在界面上的）
- 數據庫（有些數據只會存於數據庫中）
- 磁盤（文件數據需具體到磁盤上看是否存在，數據是否正確）
6、測試數據
測試數據：測試時使用到的數據。
書寫要求：可用電影。
不用寫到實際數據，在測試添加電影功能時，不需要寫具體電影、導演、演員、宣傳圖片。
具體的數據-可以在數據準備時做好，如符合規格的圖片（海報、圖標、劇照），符合碼率的媒體文件（正片和預覽片）。
測試用例整體是有邏輯的
測試用例整體是有邏輯的-需要有用例設計的魂，編寫測試用例的兩個途徑：
- 先有用例設計，從整個產品/項目出發，先確定測試範圍、測試目標，再細化範圍到具體對象->具體功能，確定設計用例技術和測試方法，再來編寫用例。
- 測試執行後-通過Bug反推 修改補充用例。
兩者相結合纔會產出一份漂亮且有效的測試用例，理論->實踐->理論過程。
編寫測試用例常見問題
- 用例標題意圖不明確
- 用例中引用其他用例
- 用例中包含過多的細節
- 用例中出現籠統的詞
- 反覆、多次
- 確定反覆的具體次數
- 確定一個反覆的範圍
- 長時間
- 確定長時間的具體時間
- 確定一個長時間的範圍
- 大量
- 確定具體的數據量
- 從需求/規格中中參照值
- 用例中步驟不可執行
- 用例中期望結果不可驗證
參考資料：