測試用例（test case）是測試設計的乙個產出物，它直接體現測試設計的思想，乙份漂亮的測試用例不僅僅是設計思路的優秀體現，更是便於流轉和執行，具有可讀性、傳遞性。它一般是為某個特殊目標而編制的一組測試輸入、執行條件及預期結果，用以核實程式是否滿足某個特定需求及沒有完成多餘操作，即保證以下兩點：
因此，作為測試實施依據的測試用例，必須要能完整覆蓋測試需求，而不應針對單個case去評判好壞。0、用例模板
首先，乙份漂亮的測試用例-需有乙個用例模板，模板可以將測試用例的結構形式固定化、標準化，對編寫者啟引導作用，保證乙份測試用例資料完整。
1、對被測版本足夠了解
由粗略詳細步驟來解讀產品需求文件，如互動、功能流程、邊界、約束等等。充分理解技術實現原理（實現的邏輯原理、架構及對其他平台的依賴、介面等）。
深入理解使用者群，分析使用者使用場景、可能的使用方法及使用者心理，完全從使用者角度出發，來設計case，同時對使用者體驗做出一定的判斷。
2、設計case優先順序
一般bugfree或禪道工具中編寫好case後可以按優先順序來篩選優先順序，如果是用excel文件來寫可以來通過不同背景色來標識相應的優先順序，無論評審還是執行，都可以按此來查閱。無論是冒煙測試用例還是功能測試用例，節省大量時間。
3、從粗到細分析需求
可以使用工具輔助，第一遍需求分析時，粗略畫出測試需求框架；第二遍分析需求時，開始延伸每個出子測試點；細化測試點時，可參考或引用寫好的公共case， 也要考慮到被測版本中該功能的特性。另外需要考慮的就是測試點的顆粒度要把握好。
4、測試用例update
需求分析階段和開發階段，都可能出現需求變更，這時對於我們前期粗略整理好的測試點就需要及時的同步更新了。另外在case評審階段，可能會出現case冗餘或遺漏，也需要在評審結束後在case池裡及時修整。如果專案中有使用需求工具之類的，可以利用工具去同步通知到每個節點的負責人，會大大 減少update的時間。
1、 熟悉業務
這是必備條件，因為所有case都是從業務層開始入手的，而終端使用者也是以業務為出發點。
2、 培養使用者思維
測試人員需要站在客戶的角度分析使用者需要什麼、想要什麼、不想要什麼，這樣有利於我們更好的挖掘隱含需求。所以設計場景時也同樣是站在使用者角度。
3、 勿限制測試思維
對於好的測試人員，都會有自己的乙份通用測試用例表， 每次編寫測試用例時，會將重複或公共的功能摘出來，去參照已有的通用case。但若不能做到及時更新，隨公司專案變更等，很可能在某些專案中固步自封，不能靈活地運用。
所以通用case總結更新是必不可少的，也可以分享出來讓同行參謀 ，大家集思廣益，也許其他人有更新奇的方法，這樣會不斷地開拓自己的測試思維 ，而不至於一直重複原有的經驗。
4、 樂於分享，有計畫地總結
給自己的學習過程制訂乙個詳細的計畫，量化到天，排好每天要學習的東西。同時最重要的是，一定要養成總結的習慣 ，每天總結 ，每個專案總結 ，總結測試方法，總結bug原因，奇葩bug等等，這些將會成為你日後工作的寶貴財富。
同時，主動總結久了，你會發現自己有質的提公升，而且對於當前的工作會更游刃有餘，經驗是靠日積月累的。
乙份漂亮的測試用例應該具有目標、可讀、簡潔的特點，而這些是通過從各個屬性所填的內容散發出來的。
1、用例編號
用例編號就是測試用例文件中乙個代號，需全域性唯一，我們可以通過代號快速找到測試用例。
用例編號的書寫，建議是專案名_模組名_001，我們可以通過編號快速知道乙個專案有多少用例，專案中乙個模組有多少用例。
2、用例標題
目的:概述測試用例的主要內容，明確用例意圖
在做用例評審時，通過瀏覽乙個模組的用例標題，能快速判斷有沒有遺漏功能；通過瀏覽乙個功能用例標題，能快速判斷出有沒有遺漏正常或異常case。
乙個測試用例的好壞，一半體現在測試用例標題上。乙個好用例的標題，書寫方式有三種：
一句完整的話（不超過30個漢字）
功能演示文稿形式
按條件/狀態 3、預置條件預置條件-測試用例能執行的前提條件。可以是到達某一狀態，也可以是一些配置。
書寫要求：乙個簡潔的結果。
4、測試步驟測試步驟是指如何執行用例，先做什麼後做什麼，是有順序的概念在的。
步驟和用例的目標需要是一致的，任意乙個偏離目標整個case就是無意義的。
書寫要求：可執行的操作，功能用例步驟不大於7，流程用例步驟隨業務而定-這裡不做限制。
5、預期結果預期結果是和測試步驟一一對應的，有幾個檢查點，就需要有幾個結果。
書寫要求：和測試步驟中check點一一對應，檢查點》=1個
預期結果需要是可檢查的，可從三個方面進行校驗：
介面（結果會直接顯示在介面上的）6、測試資料資料庫（有些資料只會存於資料庫中）
磁碟（檔案資料需具體到磁碟上看是否存在，資料是否正確）
測試資料：測試時使用到的資料。
書寫要求：可用電影。
不用寫到實際資料，在測試新增電影功能時，不需要寫具體電影、導演、演員、宣傳。
具體的資料-可以在資料準備時做好，如符合規格的（海報、圖示、劇照），符合位元速率的**檔案（正片和預覽片）。
測試用例整體是有邏輯的
測試用例整體是有邏輯的-需要有用例設計的魂，編寫測試用例的兩個途徑：
先有用例設計，從整個產品/專案出發，先確定測試範圍、測試目標，再細化範圍到具體物件->具體功能，確定設計用例技術和測試方法，再來編寫用例。兩者相結合才會產出乙份漂亮且有效的測試用例，理論->實踐->理論過程。測試執行後-通過bug反推 修改補充用例。
反覆、多次長時間大量
如何設計測試用例
測試基礎 測試用例 測試用例 test case 是為某個特殊目標而編制的一組測試輸入 執行條件以及預期結果，以便測試某個程式路徑或核實是否滿足某個特定需求。測試用例作用 檢驗是否滿足客戶需求 度量測試人員的工作量 展現測試用例的思路。測試用例包含 用例編號 唯一的編號。用例名稱 言簡意賅，描述準確...
如何設計測試用例
用例設計原則 存在關聯業務的測試點的考慮 常用測試設計方法 測試型別分析法 將乙個功能點按照不同的測試型別進行劃分，針對每乙個測試型別都進行測試點設計的分析方法。舉例說明 功能測試 效能測試 壓力測試 可靠性測試 相容性測試 安全性測試 容錯測試 功能測試常規測試點 基本流程測試 單個輸入框測試 邊...
如何設計測試用例
網路 測試工作最為基礎核心的內容就是設計測試用例，什麼樣的測試用例是好的測試用例？我們一般會認為數量越少，發現缺陷越多的用例就是最好的用例。那麼我們如何才能設計出好的測試用例呢？乙份好的用例是設計出來的，是測試人員思路和方法的集合，而非測試邏輯和需求的羅列。測試用例設計的幾個準則 1 用例設計 思路...