公司年底要過技能點，報了一個高階用例設計，寫了一些自己的總結，在這記錄下那些準備技能點材料的苦逼週末。。。

ps：文章第二部分，為什麼要寫測試用例，出自“蟲師”的部落格

一、什麼是測試用例

         測試用例（Test Case）是為某個特殊目標而編制的一組測試輸入、執行條件以及預期結果，以便測試某個程式路徑或核實是否滿足某個特定需求，通俗的講：就是把我們測試系統的操作步驟用按照一定的格式用文字描述出來。

二、為什麼要寫測試用例

1、 理清思路，避免遺漏

理清思路是我們認為最重要的一點，有的系統本來就是一個大而複雜的專案，我們需要把專案功能細分，根據每一個功能通過編寫用例的方式來整理我們測試系統的思路，避免遺漏掉要測試的功能點。

2、 跟蹤測試進度進展

通過編寫測試用例，執行測試用例，我們可以很清楚的知道我們的測試進度，方便跟蹤我們的測試進度。

3、 迴歸測試

首先我們的系統不是測一遍就完了的，我們需要在開發環境上測試，測試環境上還要進行迴歸，其次還有可能涉及到合併測試，而且也有可能會有不同的人在不同的階段進行測試，那麼我們就需要測試用例來規範和指導我們的測試行為。

4、 歷史參考

在我們所做專案的各個版本中，也許會有很多功能是相同或相近的，我們對這類功能設計了測試用例，便於以後我們遇到類似功能的時候可以做參考依據。

另外如果產品釋出後出現了釋出缺陷，測試用例也是分析釋出後缺陷的依據之一。

三、如何編寫用例

1、測試需求分析，得到測試點

在測試需求分析階段，我們只有需求文件，所以編寫測試用例的唯一依據就是需求文件，因此在進行用例編寫之前一定要進行需求分析，需求分析的主要工作就是：瞭解需求的整個實現背景；分析需求的合理性；明確需求的範圍，挖掘需求文件中隱藏的需求；在通過需求交底的過程，確定開發的初步實現思路和方法，隨著測試需求分析的深入，列出需求的框架，包括測試範圍即各個功能點，測試的場景等；確定一些測試可以提前介入的工作等；需要說明的是對於需求中的問題一定要記錄下來，找需求確認，需求漏掉的或者存在問題的地方，開發和測試更容易漏掉，而且遺漏的需求很有可能會使得專案整體業務邏輯發生變化，一定要及時提前確認。

2、分析得到用例優先順序

得到了需求的各個測試點後，應該先將這些測試點簡單的分配一下優等級，一般分為高中低三個優先順序，我認為得到優先順序後可以讓需求用例的設計更有側重和著重點。

3、細化測試點變成可執行case

根據測試需求分析得到的需求框架，梳理細化測試點，這裡的測試點雖然粗，但是不應該有遺漏，這是進行測試點細化的前提。根據測試點，細化出具體的測試用例，要注意各個點的組合測試的情況，還要注意各個測試點的反向測試的情況。

在細化測試點的時候，我們可以要參考以前寫好的公共測試用例，甚至可以直接引用，這樣既可以避免一些不必要的時間浪費，但是參考不等於照搬，在引用的同時，也一定要思考本次需求自己特有的測試點。

另外需要考慮的就是測試點細化到什麼程度的問題，也就是一個度的問題，我們要把握好測試點細化的一個度的問題，太粗的測試點沒有指導意義，太細的測試點容易讓我們糾的太細，忽略整體的測試，反而也起不到一個指導的效果，所以一定要把握好測試點細化的度。

4、及時更新測試用例

需求分析和用例編寫階段，是主要的細化用例時間，這段時間的目標是梳理出可指導執行測試的用例，但是需求會有變動，需求會有維護，用例也一樣，所以用例是需要持續維護的， 所以在需求變動的同時，我們也要及時維護測試用例，否則的話，測試用例很可能成為一個錯誤的指導。

另外測試用例完成後就會進入一個用例評審的階段，在用例評審階段，會有用例評審人，針對你的用例作出的評審，主要檢查你的用例是否有測試點遺漏，場景遺漏，測試case描述模糊，測試結果輸出模糊等問題，針對用例評審人提出的問題，我們也要及時的更改我們的用例。

5、及時維護通用測試用例

什麼是通用測試用例呢？我理解的通用測試用例就是：專案中或者跨專案中很多的公用業務，固化模組，這些功能基本上是趨於穩定不變的，因此可以梳理出通用的比較全面的測試點，作為指導和規範業務和模組的規範，這些生成的規範即通用的測試用例。當我們針對某一模組或者業務持續維護時，就發現我們需要持續維護這的用例，就會發現有些用例業務類似、執行步驟一致、驗證項屬性一致等等，這個時候通過梳理業務的通用屬性，通用用例梳理梳理成章。所以說，通用的測試用例是一個對用例不斷維護的產出，因此我們在測試軟體維護的過程中一定要及時的更新通用測試用例，對後面的測試和用例維護有一個很大的指導作用。

四、如何提升用例編寫能力

1、   熟悉業務，瞭解系統

任何系統都有大的業務背景，只要熟悉了業務知識才能更有效的使用系統。

任何系統在使用過程中，都有一個熟悉的過程，對系統越熟悉，越容易發現系統問題和業務問題。

2、   用客觀的思考方式站在使用者的角度分析

作為測試人員如果想提升測試用例的編寫能力，首先應該做到的就是站在客戶的角度分析客戶需要什麼和客戶想要什麼，客戶不想要什麼，也就是所謂的客戶的使用場景，這樣有利於我們更好的挖掘和思考隱含的需求。至於這個需求該不該做，那是需求人員的職責，這個需求做起來複不復雜那是開發人員的事情，作為測試人員需要考慮的事就是你所設計的正向和反向測試用例是不是使用者常用到的場景，以及一些客戶基本不會用到的場景有哪些。

3、   多思考，不要拘束於慣性思維

我們知道一個人做一個工作時間越久，也就是我們說的經驗越豐富，可能這個思維方式就會越被限定住。比如，測試的統計表多了，當拿到一個新增的統計表的時候，首先想到的是公用用例上所列的測試點基本上就是最全的了，我都不用思考，直接用就行了。

其實這是一個誤區，公用用例的目的是幫助我們減少一些不必要的內耗，但是我們的思維不要被它所限定，如果公用用例中某個點是錯的，那我們豈不要一錯再錯了。所以作為一個測試人員如果想要提升自己的測試用例設計能力，一定要多思考，不要被這種慣性思維束縛，不要被所謂的經驗束縛。

4、   不要閉門造車，利用好網路資源

提升測試用例設計能力，多思考是非常重要的，但是不是讓你傻思考，當你的進步遇到瓶頸的時候，不要閉門造車，做井底之蛙，要充分利用網路上的學習資源，學習一些前輩的經驗，並把這些運用到實際的測試用例設計中去。山外青山樓外樓，多瀏覽和關注一些關於測試用例設計的網站或者微信公眾號，廣開言路，相信會對你的測試用例設計能力的提升會有很大的幫助的。

5、   善於總結分享

基於以上四點我們還要做到善於總結，樂於分享，把經常見到的用例設計的誤區和一些好的用例設計，和用例設計習慣分享給周圍的小夥伴，這樣可以集眾人之所長，不斷提升我們的用例設計能力。