不管是文件化的測試用例，還是存在於測試人員頭腦中的測試想法和思維，針對測試物件的分析和設計都是整個測試過程的重要測試活動之一。在進行測試分析和設計之前，測試人員首先需要確定測試的需求**，即測試用例設計需要參考哪些測試依據文件？
測試用例設計的輸入文件是什麼？測試人員頭腦中第乙個蹦出的參考依據就是需求規格說明。確實，需求文件是我們測試設計的最主要參考文件。但是，由於時間限制、成本限制和個人能力限制等方面的原因，提供完備的需求規格說明幾乎是不可能的。現實情況是，需求規格說明常常是不全的、模糊的，甚至是錯誤的。
因此，測試設計中僅僅參考需求規格說明是不夠的，測試人員需要從更廣的範圍來定義測試用例設計的參考**。圖1是作者提出的測試用例設計的參考輸入的主要**架構圖。
圖1 測試用例設計的參考輸入的主要**
除了軟體產品相關的的開發文件之外，測試人員還需要收集來自使用者的需求、與產品相關的標準與規範、以前類似產品的需求、測試團隊的經驗知識庫，以及其他的一些隱現需求等。通過收集和分析這些參考輸入**，測試人員才能不斷提高測試的覆蓋率和質量。
1）開發文件
開發文件是測試人員進行測試用例分析與設計的最直接且必不可少的主要**。這裡的開發文件是乙個統稱，不同組織對其的稱呼不同，包含了系統需求規格、概要設計規格、詳細設計規格等不同的開發文件。
2）使用者需求
軟體測試同時包含了驗證（verification：do you build the product right?）與確認（validation：do you build the right product?）兩方面的工作。驗證主要基於系統需求，來驗證測試物件是否按照需求的定義實現了其中的功能和特性。而確認主要從使用者的角度，保證經過測試的產品是真正客戶所需要的，而不僅僅是了滿足了系統的需求。因此，測試不僅僅是面向開發的，同時也應該關注面向使用者。
使用者需求可以來自各個方面，例如早期產品系統人員與客戶直接溝通獲取的需求、從產品技術支援人員和市場人員了解到的客戶要求，以及從使用者現場反饋的針對產品的缺陷和要求等。
3）標準與規範
針對特定的軟體產品，不同標準組織和行業都制定了不同的標準和規範，而這些參考資料是開展測試分析和設計的又乙個重要輸入。例如電信產品相關的itu-t標準、ieee標準、rfc文件、國家電信行業規範等。
4）類似產品需求
隨著軟體產品越來越複雜，行業內採用增量-迭代開發模型的場合越來越多，例如敏捷開發。測試人員經常面臨的軟體產品是基於已有的系統之上，即測試物件是基於以前版本的功能增加、缺陷修復、平台移植等變更基礎之上。因此測試人員需要分析歷史測試是否全面，測試物件變更是否影響以前執行的軟體版本等。基於這些資訊，測試人員可以獲取新的測試需求。
5）測試經驗知識庫
測試並不是存在編碼之後的乙個階段，測試應該貫穿於整個軟體開發生命週期。類似於開發過程改進一樣，測試也應該是pdca（戴明質量環）的過程。因此，不同專案中的測試經驗是每次測試用例設計的重要輸入。通過測試經驗知識庫，測試團隊的測試經驗和技能才能在整個組織中共享。
測試經驗知識庫可以來自測試執行的經驗、測試過程中發現的缺陷分析和分類、使用者反饋的缺陷分析和分類等。
6）其他隱現的需求
（1）不同產品利益相關者針對測試物件中間版本的變更而達成的備忘錄；
（2）已經發布的使用者使用風格指南和使用者介面標準等；
（4）通過雜誌、網路等查詢類似測試物件產品的一些常見缺陷、失效，以及測試物件支援功能在使用者現場使用的討論。
[文章**]：專注於測試能力改進
測試用例設計
1.測試用力的概念 測試用例是為特定的目的而設計的一組的測試輸入。執行條件和預期的結果，體現在測試方案 方法 技術和策略。2.測試用例具備的特點 1 正確性 2 完整性 3 準確 4 清晰 簡潔 5 可維護性 6 適應性 7 可重用性 8 其他 3.測試用例基本原則 個人認為比較重要的加黑了。1 基...
測試用例設計
1.名稱與標識 2.測試追蹤 3.用例說明 4.測試的初始化要求 5.測試的輸入 6.期望的測試結果 7.評價測試結果的準則 8.操作過程 9.前提和約束 10.測試終止條件 編寫用例規範 1 系統性 對系統業務流程要完整說明整個系統的業務需求 系統由幾個子系統組成以及它們之間的關係 對模組業務流程...
測試用例設計
測試用例格式 用例編號 a b c d a 產品或專案名稱 b 用例屬性 st,it,ut c 客戶管理 新增客戶，什麼型別的客戶 d編號 例 crm st 客戶管理 新增客戶 001 測試項 針對於某種物件的測試用例 客戶管理 新增客戶 20個字元的客戶資訊 新增名稱包含單引號的客戶資訊 用例屬性...