一.簡介
測試用例：為了特定的目的（證明軟件存在某問題）而設計的一組由測試輸入、執行條件、預期結果構成的文檔
假如開發了一個APP，就光從賬戶登錄頁面來看，怎么保證用戶使用的時候沒有BUG呢？就需要測試人員進行全方面的測試，確保在各種情況下不會出錯
要做這個登錄頁面的測試用例，你會從哪些方面思考進行測試呢？看似簡單的頁面功能能夠設計多少條測試用例完成較全面的測試呢？10條以內？20條？.......
測試用例簡單來說就是指導如何做測試的文檔，該文檔主要記錄需要驗證被測軟件的是否滿足需求。
測試用例表現形式常見的有兩種，可以以模板形式展示
一種是通過Excel直接編寫，大多數項目中都需要按照這種方式設計編寫
一種是通過xmind直接整理測試點，適合時間緊迫，項目沒有強制要求時，可以設計測試點的形式編寫。對於業務流程類的測試，也可以整理為測試點進行測試。
二.為什么寫測試用例
產品出現問題了，你為啥沒有測出來呢？
當然，除了避免“甩鍋和背鍋”，其實寫測試用例更重要的作用如下：
- 技術上將需求轉化為具體可驗證的指標
- 以文檔的形式記錄軟件可能存在的問題
- 防止測試過程的活動出現遺漏，提高工作效率
- 測試工作量的展示
三.如何編寫測試用例
既然寫測試用例如此重要，那么如何更好的編寫測試用例呢？個人認為需要滿足如下幾點：
- 常規思考，設身處地的從用戶角度出發（比如：實際用戶是這么使用的么，會不會遇到異常情況呢？）
- 測試理論方法的支撐（比如：根據需求設計測試用例時，能用到哪些常見的測試用例設計方法？）
- 產品的熟悉和經驗的積累（比如：已經有過類型項目經驗，曾經在某個方面有過問題，當時是如何處理的呢？）
上述的設計用例過程，有個前提，就是對於測試有耐心和毅力，加上日常有意識的思維訓練，才會寫出全面的用例。
1.常規思考
回歸到開篇的一個基本登錄頁面，按照常規思路能否會想到如下截圖的測試點呢？實際，這些測試點都是源於從用戶角度出發，結合需求進行細化設計的過程。實際測試中是不是只有這些測試點呢？
2.學習積累
相信大多數測試工程師都能夠想到上述基本的測試點，然在實際工作中面對的項目不同，設計測試用例的顆粒度也有不同的要求，如果針對上述登錄的模塊，更深入一層考慮呢？此時需要對產品的熟悉程度及測試經驗的加持，而且這些點的設計是不斷學習、熟悉項目、測試積累中得到的。
3.理論支撐
有了常規的思考，有了經驗的積累，還需要理論的支撐。測試用例畢竟是通過人去思考設計，這個過程不可避免有疏漏。如何規避？實際就需要測試理論的支撐，個人認為深入思考設計用例不外乎以下兩方面：
測試用例的設計方法
測試理論中很關鍵一塊就是將需求拆分為具體的測試點，然后根據用例設計方法進行具體的設計，其中拆分需求的關鍵是熟悉需求，將文檔中已有的描述內容，按照用戶使用場景、個人測試經驗的積累（如果有的話）、把大段的內容拆分成能夠直接用用例設計方法的測試點，這樣就直接可以通過簡明扼要的文字描述轉化為Excel的測試用例，在這個過程通俗理解就是拆分細化的過程，直到可以直接寫用例驗證一個具體的功能點即可。
其中熟知的設計用例方法有：
- 觀察法
- 等價類、邊界值
- 判定表、因果圖
- 流程圖、場景法
- 錯誤推測法等
測試設計的思路開拓
倘若按照需求將已有的描述信息都已經拆分完畢了，是不是就可以確保測試沒有問題了呢？
其實不然，在上述基礎上如果還需要再拓展全面測試，還需要借助於軟件質量模型的特性，從這些特性出發，給予測試用例設計者更多的思考空間。這樣的設計就更加的全面可靠。
常見軟件質量模型特性說明：
- 功能性：功能有沒有，好不好用
- 性能效率：對應系統的資源耗費程度及響應時間
- 易用性：容易理解、學習、使用
- 兼容性：能夠兼容不同的軟硬件平台
- 可靠性：不易出問題，萬一出問題容易恢復
- 安全性：對於用戶的安全保障（外在的人生安全、內在的信息安全等）
- 可移植性：能否在不同環境條件下無故障運行
- 可維護性：對於后期的修復維護是否方便快捷
因此，對於上述登錄功能，按照上述質量模型的思路指導，就得到如下的測試點：
四.總結
此時的你再回過頭來看看，還會認為登錄這個百試不爽的功能就設計十幾條甚至幾十條測試用例了嗎？顯然不是那么簡單，需要在熟悉需求基礎上，進行拆分細化，將常規的思考、經驗的積累、理論的支撐結合起來使用，最終才能轉化為測試待驗證的結果。
熟悉需求上第一步，在此基礎上進行測試點的拆分細化，這個過程如果對於復雜一點的功能點，需要借助於測試用例的設計方法，對於頁面級的測試點應用最多的不外乎是等價類、邊界值。
僅僅熟悉了需要，還需要結合經驗的積累，從質量模型的特性出發，進行全面的思考功能點的設計，是否出現遺漏的，是否有項目特殊要求的。
最后，用例的設計不是一蹴而就的事情，好的用例也是需要不斷的練習，反復的修改評審，才能編寫出卓越的用例。
