前期寫了乙個關於用例優化的一點經驗，見測試用例優化和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不分上下。
缺點：不方便統計，這點非常深刻，做測試報告的時候通過率這塊比較頭疼。
設計測試用例 1
測試用例概念 測試用例是指為實施測試而向被測試系統提供的輸入資料，操作或各種環境設定以及期望結果的乙個特定集合。測試用例控制軟體的執行過程，他是對每乙個測試專案的進一步例項化。寫測試用例的好處 理清思路，避免遺漏 這裡是我們認為最重要的一點，假如我們測試的專案大而複雜，我們可以把專案功能細分，根據每...
介面測試用例設計實踐總結
設計思路 優先順序 針對所有介面 1 暴露在外面的介面，因為通常改介面會給第三方呼叫 2 供系統內部呼叫的核心功能介面 3 供系統內部呼叫的非核心功能介面 優先順序 針對單個介面 1 正向用例優先測試，逆向用例次之 2 是否滿足前提條件 是否攜帶預設引數 引數是否必填 引數資料型別限制 引數資料型別...
測試用例1
2020 12 18 將基本測試用例學習完 測試時使用的案例，指導測試的執行。用例名稱 測試目的 測試輸入 要有測試資料 測試步驟 執行條件 預期結果 實際結果與預期結果相對比。測試用例構成要素 不知道內部實現，通過輸入輸出判定 8種方法測試用例的設計方法 等價類 邊界值 判定表 因果圖 狀態遷移圖...