⒈測試用例文件
編寫測試用例文件應有文件模板，須符合內部的規範要求。測試用例文件將受制於測試用例管理軟體的約束。
軟體產品或軟體開發專案的測試用例一般以該產品的軟體模組或子系統為單位，形成乙個測試用例文件，但並不是絕對的。
測試用例文件由簡介和測試用例兩部分組成。簡介部分編制了測試目的、測試範圍、定義術語、參考文件、概述等。測試用例部分逐一列示各測試用例。
每個具體測試用例都將包括下列詳細資訊：版本號、模組名稱、用例編號、用例名稱、用例級別、預知條件、驗證步驟、期望結果（含判斷標準）、測試結果、測試時間、測試人員等。
⒉測試用例的設定
我們早期的測試用例是按功能設定用例。後來引進了路徑分析法，按路徑設定用例。演變為按功能、路徑混合模式設定用例。
按功能測試是最簡捷的，按用例規約遍歷測試每一功能。
對於複雜操作的程式模組，其各功能的實施是相互影響、緊密相關、環環相扣的，可以演變出數量繁多的變化。沒有嚴密的邏輯分析，產生遺漏是在所難免。路徑分析是乙個很好的方法，其最大的優點是在於可以避免漏測試。
但路徑分析法也有侷限性。在乙個非常簡單字典維護模組就存在十餘條路徑。乙個複雜的模組會有幾十到上百條路徑是不足為奇的。
筆者以為這是路徑分析比較合適的使用規模。若乙個子系統有十餘個或更多的模組，這些模組相互有關聯。再採用路徑分析法，其路徑數量成幾何級增長，達5位數或更多，就無法使用了。
那麼子系統模組間的測試路徑或測試用例還是要靠傳統方法來解決。這是按功能、路徑混合模式設定用例的由來。
⒊設計測試用例
測試用例可以分為基本事件、備選事件和異常事件。設計基本事件的用例，應該參照用例規約（或設計規格說明書），根據關聯的功能、操作按路徑分析法設計測試用例。而對孤立的功能則直接按功能設計測試用例。
基本事件的測試用例應包含所有需要實現的需求功能，覆蓋率達100%。
設計備選事件和異常事件的用例，則要複雜和困難得多。例如，字典的**是唯一的，不允許重複。測試需要驗證：
字典新增程式中已存在有關字典**的約束，若出現**重複必須報錯，並且報錯文字正確。往往在設計編碼階段形成的文件對備選事件和異常事件分析描述不夠詳盡。而測試本身則要求驗證全部非基本事件，並同時盡量發現其中的軟體缺陷。
可以採用軟體測試常用的基該方法：等價類劃分法、邊界值分析法、錯誤推測法、因果圖法、邏輯覆蓋法等設計測試用例。視軟體的不同性質採用不同的方法。
如何靈活運用各種基該方法來設計完整的測試用例，並最終實現暴露隱藏的缺陷，全憑測試設計人員的豐富經驗和精心設計。
編制測試用例
因此測試用例的設計和編制是軟體測試活動中最重要的。測試用例是測試工作的指導，是軟體測試的必須遵守的準則。更是軟體測試質量穩定的根本保障。著重介紹一些編制測試用例的具體做法。1 測試用例文件 編寫測試用例文件應有文件模板，須符合內部的規範要求。測試用例文件將受制於測試用例管理軟體的約束。軟體產品或軟體...
登入的測試用例
1 乙個好的用例的表述要點，即用例中應當包含的資訊乙個優秀的測試用例，應該包含以下資訊 1 軟體或專案的名稱 2 軟體或專案的版本 內部版本號 3 功能模組名 4 測試用例的簡單描述，即該用例執行的目的或方法5 測試用例的參考資訊 便於跟蹤和參考 6 本測試用例與其他測試用例間的依賴關係7 本用例的...
功能測試用例
專案編號 s 專案名 分類 模 整合測試用例 version 專案承擔部門 撰寫人 簽名 完成日期 本文件使用部門 主管領導 專案組 客戶 市場 維護人員 使用者評審負責人 簽名 評審日期 修訂文件歷史記錄 日期版本說明作者 目錄1.簡介 1 1.1目的 1 1.2範圍 1 1.3定義,首字母縮寫及...