測試用例(test case)是為某個特殊目標而編制的一組測試輸入、執行條件以及預期結果，以便測試某個程式路徑或核實是否滿足某個特定需求，通俗的講：就是把我們測試系統的操作步驟用按照一定的格式用文字描述出來。
1、 理清思路，避免遺漏
理清思路是我們認為最重要的一點，有的系統本來就是乙個大而複雜的專案，我們需要把專案功能細分，根據每乙個功能通過編寫用例的方式來整理我們測試系統的思路，避免遺漏掉要測試的功能點。
2、 跟蹤測試進度進展
通過編寫測試用例，執行測試用例，我們可以很清楚的知道我們的測試進度，方便跟蹤我們的測試進度。
3、 回歸測試
首先我們的系統不是測一遍就完了的，我們需要在開發環境上測試，測試環境上還要進行回歸，其次還有可能涉及到合併測試，而且也有可能會有不同的人在不同的階段進行測試，那麼我們就需要測試用例來規範和指導我們的測試行為。
4、 歷史參考
在我們所做專案的各個版本中，也許會有很多功能是相同或相近的，我們對這類功能設計了測試用例，便於以後我們遇到類似功能的時候可以做參考依據。
另外如果產品發布後出現了發布缺陷，測試用例也是分析發布後缺陷的依據之一。
1、測試需求分析，得到測試點
在測試需求分析階段，我們只有需求文件，所以編寫測試用例的唯一依據就是需求文件，因此在進行用例編寫之前一定要進行需求分析，需求分析的主要工作就是：了解需求的整個實現背景；分析需求的合理性；明確需求的範圍，挖掘需求文件中隱藏的需求；在通過需求交底的過程，確定開發的初步實現思路和方法，隨著測試需求分析的深入，列出需求的框架，包括測試範圍即各個功能點，測試的場景等；確定一些測試可以提前介入的工作等；需要說明的是對於需求中的問題一定要記錄下來，找需求確認，需求漏掉的或者存在問題的地方，開發和測試更容易漏掉，而且遺漏的需求很有可能會使得專案整體業務邏輯發生變化，一定要及時提前確認。
2、分析得到用例優先順序
得到了需求的各個測試點後，應該先將這些測試點簡單的分配一下優等級，一般分為高中低三個優先順序，我認為得到優先順序後可以讓需求用例的設計更有側重和著重點。
3、細化測試點變成可執行case
根據測試需求分析得到的需求框架，梳理細化測試點，這裡的測試點雖然粗，但是不應該有遺漏，這是進行測試點細化的前提。根據測試點，細化出具體的測試用例，要注意各個點的組合測試的情況，還要注意各個測試點的反向測試的情況。
在細化測試點的時候，我們可以要參考以前寫好的公共測試用例，甚至可以直接引用，這樣既可以避免一些不必要的時間浪費，但是參考不等於照搬，在引用的同時，也一定要思考本次需求自己特有的測試點。
另外需要考慮的就是測試點細化到什麼程度的問題，也就是乙個度的問題，我們要把握好測試點細化的乙個度的問題，太粗的測試點沒有指導意義，太細的測試點容易讓我們糾的太細，忽略整體的測試，反而也起不到乙個指導的效果，所以一定要把握好測試點細化的度。
4、及時更新測試用例
需求分析和用例編寫階段，是主要的細化用例時間，這段時間的目標是梳理出可指導執行測試的用例，但是需求會有變動，需求會有維護，用例也一樣，所以用例是需要持續維護的， 所以在需求變動的同時，我們也要及時維護測試用例，否則的話，測試用例很可能成為乙個錯誤的指導。
另外測試用例完成後就會進入乙個用例評審的階段，在用例評審階段，會有用例評審人，針對你的用例作出的評審，主要檢查你的用例是否有測試點遺漏，場景遺漏，測試case描述模糊，測試結果輸出模糊等問題，針對用例評審人提出的問題，我們也要及時的更改我們的用例。
5、及時維護通用測試用例
什麼是通用測試用例呢？我理解的通用測試用例就是：專案中或者跨專案中很多的公用業務，固化模組，這些功能基本上是趨於穩定不變的，因此可以梳理出通用的比較全面的測試點，作為指導和規範業務和模組的規範，這些生成的規範即通用的測試用例。當我們針對某一模組或者業務持續維護時，就發現我們需要持續維護這的用例，就會發現有些用例業務類似、執行步驟一致、驗證項屬性一致等等，這個時候通過梳理業務的通用屬性，通用用例梳理梳理成章。所以說，通用的測試用例是乙個對用例不斷維護的產出，因此我們在測試軟體維護的過程中一定要及時的更新通用測試用例，對後面的測試和用例維護有乙個很大的指導作用。
1、 熟悉業務，了解系統
任何系統都有大的業務背景，只要熟悉了業務知識才能更有效的使用系統。
任何系統在使用過程中，都有乙個熟悉的過程，對系統越熟悉，越容易發現系統問題和業務問題。
2、 用客觀的思考方式站在使用者的角度分析
作為測試人員如果想提公升測試用例的編寫能力，首先應該做到的就是站在客戶的角度分析客戶需要什麼和客戶想要什麼，客戶不想要什麼，也就是所謂的客戶的使用場景，這樣有利於我們更好的挖掘和思考隱含的需求。至於這個需求該不該做，那是需求人員的職責，這個需求做起來復不複雜那是開發人員的事情，作為測試人員需要考慮的事就是你所設計的正向和反向測試用例是不是使用者常用到的場景，以及一些客戶基本不會用到的場景有哪些。
3、 多思考，不要拘束於慣性思維
我們知道乙個人做乙個工作時間越久，也就是我們說的經驗越豐富，可能這個思維方式就會越被限定住。比如，測試的統計表多了，當拿到乙個新增的統計表的時候，首先想到的是公用用例上所列的測試點基本上就是最全的了，我都不用思考，直接用就行了。
其實這是乙個誤區，公用用例的目的是幫助我們減少一些不必要的內耗，但是我們的思維不要被它所限定，如果公用用例中某個點是錯的，那我們豈不要一錯再錯了。所以作為乙個測試人員如果想要提公升自己的測試用例設計能力，一定要多思考，不要被這種慣性思維束縛，不要被所謂的經驗束縛。
4、 不要閉門造車，利用好網路資源
5、 善於總結分享
基於以上四點我們還要做到善於總結，樂於分享，把經常見到的用例設計的誤區和一些好的用例設計，和用例設計習慣分享給周圍的小夥伴，這樣可以集眾人之所長，不斷提公升我們的用例設計能力。
登陸模組郵箱用例設計 電子郵件模組測試用例
序號 測試步驟 進入電子郵件功能模組 新建返回電子郵件功能選單，選擇進入郵箱設定 當已有郵箱設定但是未啟動的情況下，依次選擇進入除 了郵箱設定之外的功能 返回電子郵件功能選單，選擇進入郵箱設定 在已有郵箱設定開啟之後的情況下，選擇進入收發郵件 序號測試步驟 選擇電子郵件 新建，選擇乙個字尾，然後進入...
登陸頁面測試用例
顯式基本功能 1.已註冊使用者名稱和正確密碼，是否登陸成功 2.已註冊使用者名稱和錯誤密碼，是否登陸失敗，並且提示資訊是否正確 3.非註冊使用者和任意密碼，驗證是否登陸失敗，並且提示資訊是否正確 4.使用者名稱和密碼都是空，驗證是否登陸失敗，並且提示資訊是否正確 5.使用者名稱和密碼兩者之一為空，驗...
測試用例 郵箱註冊
用例編號 分類所屬等價類 測試描述 輸入資料 預期結果 實際結果 測試人員 測試時間 000001 郵件位址 有效6 18個字元，可使用字母 數字 下劃線，須以字母開頭 jianghe 123456 可用2020 11 21 22 00 000002 郵件位址 無效純數字 45678129 不可用2...