設計測試案例的時候，需要有清晰的測試思路，對要測試什麼，按照什麼順序測試，覆蓋哪些需求做到心中有數。測試用例編寫者不僅要掌握軟體測試的技術和流程，而且要對被測軟體的設計、功能規格說明、使用者試用場景以及程式/模組的結構都有比較透徹的理解。測試用例設計一般包括以下幾個步驟：
測試需求應該在軟體需求基礎上進行歸納、分類或細分，方便測試用例設計。測試用例中的測試集與測試需求的關係是多對一的關係，即乙個或多個測試用例集或測試用例套件對應乙個測試需求。
軟體測試，不單純是或不能是只基於功能的黑盒測試，還需要對軟體的內部處理邏輯進行測試。為了不遺漏測試點，需要清楚的了解軟體產品的業務流程。建議在做複雜的測試用例設計前，先畫出軟體的業務流程。如果設計文件中已經有業務流程設計，可以從測試角度對現有流程進行補充。如果無法從設計中得到業務流程，測試工程師應通過閱讀設計文件，與開發人員交流，最終畫出業務流程圖。業務流程圖可以幫助理解軟體的業務和資料處理邏輯和資料流向，從而指導測試用例的設計。
從業務流程上，應得到以下資訊：
a、 主流程是什麼
b、 條件備選流程是什麼
c、 資料流向是什麼
d、 關鍵的判斷條件是什麼
完成了測試需求分析和軟體流程分析後，開始著手設計測試用例。測試用例設計的型別包括功能測試，邊界測試，異常測試，效能測試，壓力測試等。在用例設計中，除了功能測試用例外，應盡量考慮邊界、異常、效能的情況，以便發現更多的隱藏問題。
黑盒測試的常見測試用例設計方法有：場景圖，因果圖分析，判定表法，正交表法，狀態轉換法，等價類劃分，邊界值劃分、和錯誤猜測法等，白盒測試的測試用例設計方法有：語句覆蓋、判定覆蓋、條件覆蓋、判定/條件覆蓋、多重條件覆蓋。在這裡主要討論黑盒測試。在設計測試用例的時候可以使用軟體測試用例設計方法，結合前面的需求分析和軟體流程分析進行設計：
功能測試：測試某個功能是否滿足需求的定義，功能是否正確，完備。
適合的技術：由業務需求和設計說明匯出的功能測試、等價類劃分
邊界測試：對某個功能的邊界情況進行測試。
適合的技術：邊界值劃分
適合的技術：由業務需求和設計說明匯出的特殊業務流程、錯誤猜測法、邊界值分析、內部邊界值測試、
效能測試：檢查系統是否滿足在需求中所規定達到的效能，效能主要包括了解程式的內外部效能因素。內部效能因素包括測試環境的配置，系統資源使用狀況；外部因素包括響應時間，吞吐量等。
適合的技術：業務需求和設計說明匯出的測試
壓力測試：壓力測試又稱強度測試，主要是檢查系統執行環境在極限情況下軟體執行的能力，比如說給乙個相當大的負荷或網路流量給應用軟體相容測試：測試軟體產品在不同的平台，不同的工具，相同工具的不同版本下功能的相容性。
測試用例設計完成後，為了確認測試過程和方法是否正確，是否有遺漏的測試點，需要進行測試用例的評審。
測試用例評審一般是由測試leader安排，參加的人員包括：測試用例設計者、測試leader、專案經理、開發工程師、其它相關開發測試工程師。測試用例評審完畢，測試工程師根據評審結果，對測試用例進行修改，並記錄修改日誌。
測試用例編寫完成之後需要不斷完善，軟體產品新增功能或更新需求後，測試用例必須配套修改更新；在測試過程中發現設計測試用例時考慮不周，需要對測試用例進行修改完善；在軟體交付使用後客戶反饋的軟體缺陷，而缺陷又是因測試用例存在漏洞造成，也需要對測試用例進行完善。一般小的修改完善可在原測試用例文件上修改，但文件要有更改記錄。軟體的版本公升級更新，測試用例一般也應隨之編制公升級更新版本。測試用例是「活」的，在軟體的生命週期中不斷更新與完善。
什麼是以人為綱，就是根據軟體開發生命週期過程中，測試人員所面對的測試上游專案成員角色。
一般網際網路型專案型公司，標準崗位角色配置
一 產品人員：產品經理
原型設計
互動設計
頁面重構
二 開發人員 前端開發
服務介面開發
後台管理開發
dba資料庫管理
一 產品人員：產品經理 需求檔案（業務流程說明，業務規則說明）
原型設計 頁面原型設計稿
互動設計 頁面體驗互動設計說明
頁面重構 可供前端開發人員除錯開發前端指令碼的重構頁面
二 開發人員 前端開發 可執行訪問的前端頁面、前端頁面實現技術說明
服務介面開發 服務介面文件、服務架構元件間部署呼叫說明、服務內部偽處理邏輯流程說明
後台管理開發 後台查詢管理系統（面向客服 cms內容 生產運維等）
dba資料庫管理 庫表結構資料字典說明
最終要達到，人物合一，人和物要對的上一致統一。是人為產生的問題，就去問責相關人員。是交付產物的問題，就對交付產物進行分析定位，最終協調產品與開發給出合理的產品設計與技術解決方案，並及時提醒更正檔案並做用例落地設計。
what 什麼
why 為什麼
when 何時
where 何地
who 誰
how 怎麼做
這個方法，一般可以用來詢問具體的設計細節或技術實現細節，以加強對細節問題的梳理理解。
此圖大家要務必深入理解,測試用例的設計本質就是 ,找對測試物件->測試物件組合設計->減少無效組合->得到流程或資料流序列.
針對不同的層,如系統頁面層,頁面內部,具體輸入項 ,雖然每個層的測試物件不一樣,但你用久了這些用例設計方法就會發現如上圖的"測試用例共性步驟"其實是一樣的.用例設計方法的本質是相同的,
靈活採用設計方法,不要被該圖所迷惑,不是死的,不是教你這層就是這樣固定的設計方法,要活學活用領悟精髓.
這種用例目錄樹結構,可以很好的和用例設計管理工具平台(如testlink ,alm或者叫qc等之類的用例管理工具) 相結合.達到 分層 解耦 重用 呼叫之用例特性.各層之間不耦合,業務流,操作流和資料流分開.
功能性測試用例設計方法深入理解
設計測試案例的時候，需要有清晰的測試思路，對要測試什麼，按照什麼順序測試，覆蓋哪些需求做到心中有數。測試用例編寫者不僅要掌握軟體測試的技術和流程，而且要對被測軟體的設計 功能規格說明 使用者試用場景以及程式 模組的結構都有比較透徹的理解。測試用例設計一般包括以下幾個步驟 1 測試需求分析測試需求應該...
深入理解ES6 擴充套件物件的功能性
1.物件字面量語法擴充套件 function person name,age function person name,age 2.object.is 方法接受兩個引數，如果這兩個引數型別相同且具有相同的值，則返回true。該方法的執行結果大部分情況與 運算子相同，唯一的區別在於 0和 0被識別為不...
功能性測試方法和流程
方法 常用 1.功能分解 2.等價類劃分 3.邊界值分析 4.因果圖法 一 功能分解 通過功能分解可以明確軟體功能性測試的內容，使軟體功能性測試可度量，有利於測試監督和管理 二 等價類劃分 將程式的輸入或輸出域的不同區間或分為不同的資料類，以便匯出測試用例 有效等價類 對於程式的需求來說是合理的 有...