基本格式
軟體測試用例的基本要素包括測試用例編號、測試標題、重要級別、測試輸入、操作步驟、預期結果，下面逐一介紹。
用例編號： 測試用例的編號有一定的規則，比如系統測試用例的編號這樣定義規則： PROJECT1-ST-001 ，命名規則是項目名稱＋測試階段類型（系統測試階段）＋編號。定義測試用例編號，便於查找測試用例，便於測試用例的跟蹤。
測試標題： 對測試用例的描述，測試用例標題應該清楚表達測試用例的用途。比如 “ 測試用戶登錄時輸入錯誤密碼時，軟體的回響情況 ” 。
重要級別： 定義測試用例的優先權別，可以籠統的分為 “ 高 ” 和 “ 低 ” 兩個級別。一般來說，如果軟體需求的優先權為 “ 高 ” ，那么針對該需求的測試用例優先權也為 “ 高 ” ；反之亦然，
測試輸入： 提供測試執行中的各種輸入條件。根據需求中的輸入條件，確定測試用例的輸入。測試用例的輸入對軟體需求當中的輸入有很大的依賴性，如果軟體需求中沒有很好的定義需求的輸入，那么測試用例設計中會遇到很大的障礙。
操作步驟： 提供測試執行過程的步驟。對於複雜的測試用例，測試用例的輸入需要分為幾個步驟完成，這部分內容在操作步驟中詳細列出。
預期結果： 提供測試執行的預期結果，預期結果應該根據軟體需求中的輸出得出。如果在實際測試過程中，得到的實際測試結果與預期結果不符，那么測試不通過；反之則測試通過。
軟體測試用例的設計主要從上述 6 個域考慮，結合相應的軟體需求文檔，在掌握一定測試用例設計方法的基礎上，可以設計出比較全面、合理的測試用例。具體的測試用例設計方法可以參見相關的測試書籍，白盒測試方法和黑盒測試方法在絕大多數的軟體測試書籍中都有詳細的介紹，這裡不作贅述。
步驟
測試用例設計任何單元測試說明的第一個測試用例應該是以一種可能的簡單方法執行被測單元。看到
被測單元第一個測試用例的運行成功可用增強人的自信心。如果不能正確執行，最好選擇一
個儘可能簡單的輸入對被測單元進行測試/調試。
這個階段適合的技術有：
模組設計導出的測試
對等區間劃分
步驟2：正面測試(Positive Testing)
正面測試的測試用例用於驗證被測單元能夠執行應該完成的工作。測試設計者應該查閱
相關的設計說明；每個測試用例應該測試模組設計說明中一項或多項陳述。如果涉及多個設
計說明，最好使測試用例的序列對應一個模組單元的主設計說明。
適合的技術：
設計說明導出的測試
對等區間劃分
狀態轉換測試
步驟3：負面測試(Negative Testing)
負面測試用於驗證軟體不執行其不應該完成的工作。這一步驟主要依賴於錯誤猜測，需
要依靠測試設計者的經驗判斷可能出現問題的位置。
適合的技術有：
錯誤猜測
邊界值分析
內部邊界值測試
狀態轉換測試
步驟4：設計需求中其它測試特性用例設計
如果需要，應該針對性能、餘量、安全需要、保密需求等設計測試用例。
在有安全保密需求的情況下，重視安全保密分析和驗證是方便的。針對安全保密問題的
測試用例應該在測試說明中進行標註。同時應該加入更多的測試用例測試所有的保密和安全
冒險問題。
適合的技術：
設計說明導出的測試
重用同類型項目的測試用例
如果我看得遠，那是因為我站在巨人的肩上 －－牛頓。
測試用例設計一般來說，每個軟體公司的項目可以分為固定的幾大類。
可以按業務類型劃分，比如 ERP 軟體、產品數據管理軟體、
通信軟體、地理信息系統軟體等等；可以按軟體結構來劃分，
比如 B/S 架構的軟體、 C/S 架構的軟體、嵌入式軟體等等。參考同類別軟體的測試用例，會有很大的借鑑意義。如果，公司中有同類別的軟體系統，千萬別忘記把相關的測試用例拿來參考。如果，系統非常接近，甚至經過對測試用例簡單修改就可以套用到當前被測試的軟體。 “ 拿來主義 ” 可以極大的開闊測試用例設計思路，也可以節省大量的測試用例設計時間。
執行
測試用例執行過程中，搭建測試環境是第一步。一般來說，軟體產品提交測試後，開發人員應該提交一份產品安裝指導書，在指導書中詳細指明軟體產品運行的軟硬體環境，比如要求作業系統系統是 Windows 2000 pack4 版本，資料庫是 Sql Server 2000 等等，此外，應該給出被測試軟體產品的詳細安裝指導書，包括安裝的操作步驟、相關配置檔案的配置方法等等。對於複雜的軟體產品，尤其是軟體項目，如果沒有安裝指導書作為參考，在搭建測試環境過程中會遇到種種問題。
測試用例設計測試執行過程應注意的問題
測試環境搭建之後，根據定義的測試用例執行順序，逐個執行測試用例。在測試執行中需要注意以下幾個問題：
全方位的觀察測試用例執行結果： 測試執行過程中，當測試的實際輸出結果與測試用例中的預期輸出結果一致的時候，是否可以認為測試用例執行成功了？答案是否定的，即便實際測試結果與測試的預期結果一致，也要查看軟體產品的操作日誌、系統運行日誌和系統資源使用情況，來判斷測試用例是否執行成功了。全方位觀察軟體產品的輸出可以發現很多隱蔽的問題。以前，我在測試嵌入式系統軟體的時候，執行某測試用例後，測試用例的實際輸出與預期輸出完全一致，不過在查詢 CPU 占用率地時候，發現 CPU 占用率高達 90 ％，後來經過分析，軟體運行的時候啟動了若干個 1ms 的定時器，大量的消耗的 CPU 資源，後來通過把定時器調整到 10ms ， CPU 的占用率降為 7 ％。如果觀察點單一，這個嚴重消耗資源的問題就無從發現了。
加強測試過程記錄： 測試執行過程中，一定要加強測試過程記錄。如果測試執行步驟與測試用例中描述的有差異，一定要記錄下來，作為日後更新測試用例的依據；如果軟體產品提供了日誌功能，比如有軟體運行日誌、用戶操作日誌，一定在每個測試用例執行後記錄相關的日誌檔案，作為測試過程記錄，一旦日後發現問題，開發人員可以通過這些測試記錄方便的定位問題。而不用測試人員重新搭建測試環境，為開發人員重現問題。
及時確認發現的問題： 測試執行過程中，如果確認發現了軟體的缺陷，那么可以毫不猶豫的提交問題報告單。如果發現了可疑問題，又無法定位是否為軟體缺陷，那么一定要保留現場，然後知會相關開發人員到現場定位問題。如果開發人員在短時間內可以確認是否為軟體缺陷，測試人員給予配合；如果開發人員定位問題需要花費很長的時間，測試人員千萬不要因此耽誤自己寶貴的測試執行時間，可以讓開發人員記錄重新問題的測試環境配置，然後，回到自己的開發環境上重現問題，繼續定位問題。
與開發人員良好的溝通： 測試執行過程中，當你提交了問題報告單，可能被開發人員無情駁回，拒絕修改。這時候，只能對開發人員曉之以理，做到有理、有據，有說服力。首先，要定義軟體缺陷的標準原則，這個原則應該是開發人員和測試人員都認可的，如果沒有共同認可的原則，那么開發人員與測試人員對問題的爭執就不可避免了。此外，測試人員打算說服開發人員之前，考慮是否能夠先說服自己，在保證可以說服自己的前提下，再開始與開發人員交流。
及時更新
測試用例設計測試執行過程中，應該注意及時更新測試用例。
往往在測試執行過程中，才發現遺漏了一些測試用例，這時候應該及時的補充；往往也會發現有些測試用例在具體的執行過程中根本無法操作，
這時候應該刪除這部分用例；也會發現若干個冗餘的測試用例完全可以由某一個測試用例替代，那么刪除冗餘的測試用例。
總之，測試執行的過程中及時地更新測試用例是很好的習慣。
不要打算在測試執行結束後，統一更新測試用例，如果這樣，往往會遺漏很多本應該更新的測試用例。
提交一份優秀的問題報告單
軟體測試提交的問題報告單和測試日報一樣，都是軟體測試人員的工作輸出，
測試用例設計是測試人員績效的集中體現。因此，提交一份優秀的問題報告單是很重要的。
軟體測試報告單最關鍵的域就是 “ 問題描述 ” ，這是開發人員重現問題，定位問題的依據。問題描述應該包括以下幾部分內容：軟體配置、硬體配置、測試用例輸入、操作步驟、輸出、當時輸出設備的相關輸出信息和相關的日誌等。
軟體配置： 包括作業系統類型版本和補丁版本、當前被測試軟體的版本和補丁版本、相關支撐軟體，比如資料庫軟體的版本和補丁版本等。
硬體配置： 計算機的配置情況，主要包括 CPU 、記憶體和硬碟的相關參數，其它硬體參數根據測試用例的實際情況添加。如果測試中使用網路，那么網路的組網情況，網路的容量、流量等情況。硬體配置情況與被測試產品類型密切相關，需要根據當時的情況，準確翔實的記錄硬體配置情況。
測試用例輸入 \ 操作步驟 \ 輸出： 這部分內容可以根據測試用例的描述和測試用例的實際執行情況如實填寫。
輸出設備的相關輸出信息： 輸出設備包括計算機顯示器、印表機、磁帶等等輸出設備，如果是顯示器可以採用抓屏的方式獲取當時的截圖，其他的輸出設備可以採用其它方法獲取相關的輸出，在問題報告單中提供描述。
日誌信息： 規範的軟體產品都會提供軟體的運行日誌和用戶、管理員的操作日誌，測試人員應該把測試用例執行後的軟體產品運行日誌和操作日誌作為附屬檔案，提交到問題報告單中。
根據被測試軟體產品的不同，需要在 “ 問題描述 ” 中增加相應的描述內容，這需要具體問題具體分析。
結果分析
軟體測試執行結束後，測試活動還沒有結束。測試結果分析是必不可少的重要環節， “ 編筐編簍，全在收口 ” ，測試結果的分析對下一輪測試工作的開展有很大的借鑑意義。前面的 “ 測試準備工作 ” 中，建議測試人員走讀缺陷跟蹤庫，查閱其他測試人員發現的軟體缺陷。測試結束後，也應該分析自己發現的軟體缺陷，對發現的缺陷分類，你會發現自己提交的問題只有固定的幾個類別；然後，再把一起完成測試執行工作的其他測試人員發現的問題也匯總起來，你會發現，你所提交問題的類別與他們有差異。這很正常，人的思維是有局限性，在測試的過程中，每個測試人員都有自己思考問題的盲區和測試執行的盲區，有效的自我分析和分析其他測試人員，你會發現自己的盲區，有針對性的分析盲區，必定會在下一輪測試用避免盲區。軟體測試
| 軟體測試定義是：為了發現程式中的錯誤而執行程式的過程.它是幫助識別開發完成（中間或最終的版本）的計算機軟體（整體或部分）的正確度(correctness) 、完全度(completeness)和質量(quality)的軟體過程；是SQA(software quality assurance)的重要子域。希望在完成這個詞條的同時，與大家共同學習。 |
