前期寫了一個關於用例優化的一點經驗，見測試用例優化和bug提交的一點經驗。但顯得空洞，沒有實踐性。因此根據目前所做的項目進行一些舉例，把這個過程具體出來。歡迎大神出來指點和分享經驗。
1、測試用例目錄：
採用樹狀結構，一般不超過3級![]()
項目1、項目2也一般爲目錄，用excel管理用例爲列，那麼前面兩級樹一般都是文件夾，二級模塊名稱一般爲excel文件名，可以根據具體項目的層級深度進行劃分，最好提前做好規劃，否則模塊越多越容易混亂。
2、測試用例設計：
（1）方式1 詳細型Mode(子模塊名) | TestCase Name （用例名） | Summary （摘要） | Preconditions （預置條件） | setps(步驟) | expectedresults （預期結果） | result (執行結果) | keywords (關鍵字) | importance （優先級） | status (狀態) | execution (執行方式) |
用連接線‘-’連接模塊 | 條件-功能點 | 視情況簡 要描述測 試目的或 特殊原因 | 前提條件 | 1、步驟 2、步驟 | 1、結果 2、結果 | 冒煙 功能 場景 UI 流程 | 1、重要 2、一般 3、次要 | 1、未評審 2、已評審 | 1、手工 2、自動化 |
這種方式是傳統的用例設計方式，包含了步驟、結果等很多詳細信息。每個公司大同小異，不多說了，給你一個眼神自己體會。
優點：步驟、結果、條件等信息非常詳細；適合變化不頻繁的項目（如V模型項目組）；
缺點：設計和執行用例比較耗費時間。
（2）方式2 名稱型用例
Mode(子模塊名) | TestCase Name （用例名） | result (執行結果) |
用連接線‘-’連接模塊 | 條件-頁面-操作-結果 頁面-條件-操作-結果 |
這是我在項目實踐中總結出來的一種方式。說一下產生的背景，公司是做自有產品的互聯網公司，當時接手的項目比較大，在不斷的版本迭代中我們用例維護已經達到5000條以上，當時搭建了testlink進行用例管理，採取的是方式1的設計方式。但是產品需求也是頻繁變更，測試部的工程師們已是非常痛苦，大領導找到我想辦法，然後就有了這種方式。
這是通過用例名稱直接執行測試的方式，但對用例名稱的設計要講究技巧，這樣才能讓執行人員一眼就看出用例要測什麼怎麼測。我們通過統計計算，執行和設計用例的效率提高約30%。大大縮短了執行時間。目前這種方式已經在多個項目中進行了推廣執行。
優點：執行效率高，適合需求變更頻繁的項目；能根據測試點，快速修改相關用例；執行效率會隨人員對系統的熟悉程度的提高而增加；
缺點：對設計用例的人員的思維及對項目業務的熟悉程度有更高要求；對語言的使用及歸納總結能力有要求；當多個人同時設計一個項目的用例時需要有一致性。
（3）方式3 圖型用例
這是不少人都用過的思維導圖，這個想必大家都不陌生。這是當時做出方式2時的備選方案，這裏爲什麼提到它，是因爲，我們發現結合方式2和方式3，可以發揮很大的能量，非常適合快速迭代的小項目。目前公司有個以接單方式運行的中小項目正在使用這種用例設計方式。能快速執行。
優點：很直觀，簡單清晰。執行效率與方式2不分上下。
缺點：不方便統計，這點非常深刻，做測試報告的時候通過率這塊比較頭疼。
下一節將講一下用例設計的思路和格式方面的內容。歡迎交流。