2.1測試用例概述
2.2測試用例設計方法
2.3測試用例優先順序
2.4測試用例管理
測試用例（test case）是為某個特殊目標而編制的一組測試輸入、執行條件以及預期結果，以便測試某個程式路徑或核實是否滿足某個特定需求，通俗的講：就是把我們測試系統的操作步驟用按照一定的格式用文字描述出來。
理清思路是我們認為最重要的一點，有的系統本來就是乙個大而複雜的專案，我們需要把專案功能細分，根據每乙個功能通過編寫用例的方式來整理我們測試系統的思路，避免遺漏掉要測試的功能點。
通過編寫測試用例，執行測試用例，我們可以很清楚的知道我們的測試進度，方便跟蹤我們的測試進度。
首先我們的系統不是測一遍就完了的，我們需要在開發環境上測試，測試環境上還要進行回歸，其次還有可能涉及到合併測試，而且也有可能會有不同的人在不同的階段進行測試，那麼我們就需要測試用例來規範和指導我們的測試行為。
在我們所做專案的各個版本中，也許會有很多功能是相同或相近的，我們對這類功能設計了測試用例，便於以後我們遇到類似功能的時候可以做參考依據。
另外如果產品發布後出現了發布缺陷，測試用例也是分析發布後缺陷的依據之一。
在測試需求分析階段，我們只有需求文件，所以編寫測試用例的唯一依據就是需求文件，因此在進行用例編寫之前一定要進行需求分析，需求分析的主要工作就是：了解需求的整個實現背景；分析需求的合理性；明確需求的範圍，挖掘需求文件中隱藏的需求；在通過需求交底的過程，確定開發的初步實現思路和方法，隨著測試需求分析的深入，列出需求的框架，包括測試範圍即各個功能點，測試的場景等；確定一些測試可以提前介入的工作等；需要說明的是對於需求中的問題一定要記錄下來，找需求確認，需求漏掉的或者存在問題的地方，開發和測試更容易漏掉，而且遺漏的需求很有可能會使得專案整體業務邏輯發生變化，一定要及時提前確認。
得到了需求的各個測試點後，應該先將這些測試點簡單的分配一下優等級，一般分為高中低三個優先順序，我認為得到優先順序後可以讓需求用例的設計更有側重和著重點。
根據測試需求分析得到的需求框架，梳理細化測試點，這裡的測試點雖然粗，但是不應該有遺漏，這是進行測試點細化的前提。根據測試點，細化出具體的測試用例，要注意各個點的組合測試的情況，還要注意各個測試點的反向測試的情況。
在細化測試點的時候，我們可以要參考以前寫好的公共測試用例，甚至可以直接引用，這樣既可以避免一些不必要的時間浪費，但是參考不等於照搬，在引用的同時，也一定要思考本次需求自己特有的測試點。
另外需要考慮的就是測試點細化到什麼程度的問題，也就是乙個度的問題，我們要把握好測試點細化的乙個度的問題，太粗的測試點沒有指導意義，太細的測試點容易讓我們糾的太細，忽略整體的測試，反而也起不到乙個指導的效果，所以一定要把握好測試點細化的度。
需求分析和用例編寫階段，是主要的細化用例時間，這段時間的目標是梳理出可指導執行測試的用例，但是需求會有變動，需求會有維護，用例也一樣，所以用例是需要持續維護的， 所以在需求變動的同時，我們也要及時維護測試用例，否則的話，測試用例很可能成為乙個錯誤的指導。
另外測試用例完成後就會進入乙個用例評審的階段，在用例評審階段，會有用例評審人，針對你的用例作出的評審，主要檢查你的用例是否有測試點遺漏，場景遺漏，測試case描述模糊，測試結果輸出模糊等問題，針對用例評審人提出的問題，我們也要及時的更改我們的用例。
什麼是通用測試用例呢？我理解的通用測試用例就是：專案中或者跨專案中很多的公用業務，固化模組，這些功能基本上是趨於穩定不變的，因此可以梳理出通用的比較全面的測試點，作為指導和規範業務和模組的規範，這些生成的規範即通用的測試用例。當我們針對某一模組或者業務持續維護時，就發現我們需要持續維護這的用例，就會發現有些用例業務類似、執行步驟一致、驗證項屬性一致等等，這個時候通過梳理業務的通用屬性，通用用例梳理梳理成章。所以說，通用的測試用例是乙個對用例不斷維護的產出，因此我們在測試軟體維護的過程中一定要及時的更新通用測試用例，對後面的測試和用例維護有乙個很大的指導作用。
任何系統都有大的業務背景，只要熟悉了業務知識才能更有效的使用系統。
任何系統在使用過程中，都有乙個熟悉的過程，對系統越熟悉，越容易發現系統問題和業務問題。
作為測試人員如果想提公升測試用例的編寫能力，首先應該做到的就是站在客戶的角度分析客戶需要什麼和客戶想要什麼，客戶不想要什麼，也就是所謂的客戶的使用場景，這樣有利於我們更好的挖掘和思考隱含的需求。至於這個需求該不該做，那是需求人員的職責，這個需求做起來復不複雜那是開發人員的事情，作為測試人員需要考慮的事就是你所設計的正向和反向測試用例是不是使用者常用到的場景，以及一些客戶基本不會用到的場景有哪些。
我們知道乙個人做乙個工作時間越久，也就是我們說的經驗越豐富，可能這個思維方式就會越被限定住。比如，測試的統計表多了，當拿到乙個新增的統計表的時候，首先想到的是公用用例上所列的測試點基本上就是最全的了，我都不用思考，直接用就行了。
其實這是乙個誤區，公用用例的目的是幫助我們減少一些不必要的內耗，但是我們的思維不要被它所限定，如果公用用例中某個點是錯的，那我們豈不要一錯再錯了。所以作為乙個測試人員如果想要提公升自己的測試用例設計能力，一定要多思考，不要被這種慣性思維束縛，不要被所謂的經驗束縛。
基於以上四點我們還要做到善於總結，樂於分享，把經常見到的用例設計的誤區和一些好的用例設計，和用例設計習慣分享給周圍的小夥伴，這樣可以集眾人之所長，不斷提公升我們的用例設計能力。
測試用例設計
1.測試用力的概念 測試用例是為特定的目的而設計的一組的測試輸入。執行條件和預期的結果，體現在測試方案 方法 技術和策略。2.測試用例具備的特點 1 正確性 2 完整性 3 準確 4 清晰 簡潔 5 可維護性 6 適應性 7 可重用性 8 其他 3.測試用例基本原則 個人認為比較重要的加黑了。1 基...
測試用例設計
1.名稱與標識 2.測試追蹤 3.用例說明 4.測試的初始化要求 5.測試的輸入 6.期望的測試結果 7.評價測試結果的準則 8.操作過程 9.前提和約束 10.測試終止條件 編寫用例規範 1 系統性 對系統業務流程要完整說明整個系統的業務需求 系統由幾個子系統組成以及它們之間的關係 對模組業務流程...
測試用例設計
測試用例格式 用例編號 a b c d a 產品或專案名稱 b 用例屬性 st,it,ut c 客戶管理 新增客戶，什麼型別的客戶 d編號 例 crm st 客戶管理 新增客戶 001 測試項 針對於某種物件的測試用例 客戶管理 新增客戶 20個字元的客戶資訊 新增名稱包含單引號的客戶資訊 用例屬性...