測試用例設計
百科名片
測試用例就是乙個文件，描述輸入、動作、或者時間和乙個期望的結果，其目的是確定應用程式的某個特性是否正常的工作。
目錄定義
測試用例的基本格式
1. 用例編號
2. 測試標題
3. 重要級別
4. 測試輸入
5. 操作步驟
6. 預期結果
軟體測試用例
重用同型別專案的測試用例
利用已有的軟體checklist
加強測試用例的評審
定義測試用例的執行順序
測試用例執行
測試執行過程應注意的問題
及時更新測試用例
提交乙份優秀的問題報告單
1. 軟體配置
2. 硬體配置
3. 測試用例輸入 \ 操作步驟 \ 輸出
4. 輸出裝置的相關輸出資訊
5. 日誌資訊
測試結果分析
定義測試用例的基本格式
1. 用例編號
2. 測試標題
3. 重要級別
4. 測試輸入
5. 操作步驟
6. 預期結果
軟體測試用例
重用同型別專案的測試用例
利用已有的軟體checklist
加強測試用例的評審
定義測試用例的執行順序
測試用例執行
測試執行過程應注意的問題
及時更新測試用例
提交乙份優秀的問題報告單
1. 軟體配置
2. 硬體配置
3. 測試用例輸入 \ 操作步驟 \ 輸出
4. 輸出裝置的相關輸出資訊
5. 日誌資訊
測試結果分析
展開編輯本段定義
測試需求收集完畢後，開始測試設計。設計測試用例需要考慮以下問題：
編輯本段測試用例的基本格式
軟體測試用例的基本要素包括測試用例編號、測試標題、重要級別、測試輸入、操作步驟、預期結果，下面逐一介紹。
用例編號
測試用例的編號有一定的規則，比如系統測試用例的編號這樣定義規則： project1-st-001 ，命名規則是專案名稱＋測試階段型別（系統測試階段）＋編號。定義測試用例編號，便於查詢測試用例，便於測試用例的跟蹤。
測試標題
對測試用例的描述，測試用例標題應該清楚表達測試用例的用途。比如 「 測試使用者登入時輸入錯誤密碼時，軟體的響應情況 」 。
重要級別
定義測試用例的優先級別，可以籠統的分為 「 高 」 和 「 低 」 兩個級
測試用例設計
別。一般來說，如果軟體需求的優先順序為 「 高 」 ，那麼針對該需求的測試用例優先順序也為 「 高 」 ；反之亦然，
測試輸入
提供測試執行中的各種輸入條件。根據需求中的輸入條件，確定測試用例的輸入。測試用例的輸入對軟體需求當中的輸入有很大的依賴性，如果軟體需求中沒有很好的定義需求的輸入，那麼測試用例設計中會遇到很大的障礙。
操作步驟
提供測試執行過程的步驟。對於複雜的測試用例，測試用例的輸入需要分為幾個步驟完成，這部分內容在操作步驟中詳細列出。
預期結果
提供測試執行的預期結果，預期結果應該根據軟體需求中的輸出得出。如果在實際測試過程中，得到的實際測試結果與預期結果不符，那麼測試不通過；反之則測試通過。
編輯本段軟體測試用例
軟體測試用例的設計主要從上述 6 個域考慮，結合相應的軟體需求文件，在
測試用例設計
掌握一定測試用例設計方法的基礎上，可以設計出比較全面、合理的測試用例。具體的測試用例設計方法可以參見相關的測試書籍，白盒測試方法和黑盒測試方法在絕大多數的軟體測試書籍中都有詳細的介紹，這裡不作贅述。
編輯本段重用同型別專案的測試用例
如果我看得遠，那是因為我站在巨人的肩上 －－牛頓。
一般來說，每個軟體公司的專案可以分為固定的幾大類。可以按業務型別劃分，比如 erp 軟體、產品資料管理軟體、通訊軟體、地理資訊系統軟體等等；可以按軟體結構來劃分，比如 b/s 架構的軟體、 c/s 架構的軟體、嵌入式軟體等等。參考同類別軟體的測試用例，會有很大的借鑑意義。
如果，公司中有同類別的軟體系統，千萬別忘記把相關的測試用例拿來參考。如果，系統非常接近，甚至經過對測試用例簡單修改就可以應用到當前被測試的軟體。 「 拿來主義 」 可以極大的開闊測試用例設計思路，也可以節省大量的測試用例設計時間。
編輯本段利用已有的軟體checklist
在上面乙個小節中，按照不同的規則劃分了不同的軟體型別。每種型別的軟體都有一定的測試規範，比如， web 軟體系統在系統測試過程中，會有一系列的正規化，比如針對 cookie 就會有很多測試點。在設計測試用例的時候，不妨到網上去搜尋相關的 checklist ，不過國內外的**很少有這方面的資料，即便有，也不是特別系統。
可以先找乙份粗糙的 checklist ，然後，在設計測試用例的時候不斷的去完善它，以作為下次測試用例設計的基礎。
編輯本段加強測試用例的評審
測試用例設計完畢後，最好能夠增加評審過程。同行評審是 cmm3 級的乙個 kpa ，如果因為公司沒有通過 cmm3 級，就不開展同行評審是不恰當的。測試用例應該由產品相關的軟體測試人員和軟體開發人員評審，提交評審意見，然後根據評審意見更新測試用例。
如果認真操作這個環節，測試用例中的很多問題都會暴露出來，比如用例設計錯誤、用例設計遺漏、用例設計冗餘、用例設計不充分等等；如果同行評審不充分，那麼，在測試執行的過程中，上述本應在評審階段發現的測試用例相關問題，會給測試執行帶來**煩，甚至導致測試執行掛起。
編輯本段定義測試用例的執行順序
在測試用例執行過程中，你會發現每個測試用例都對測試環境有特殊的要求，或者對測試環境有特殊的影響。因此，定義測試用例的執行順序，對測試的執行效率影響非常大。比如某些異常測試用例會導致伺服器頻繁重新啟動，伺服器的每次重新啟動都會消耗大量的時間，導致這部分測試用例執行也消耗很多的時間。
那麼在編排測試用例執行順序的時候，應該考慮把這部分測試用例放在最後執行，如果在測試進度很緊張的情況下，如果優先執行這部分消耗時間的異常測試用例，那麼在測試執行時間過了大半的時候，測試用例執行的進度依然是緩慢的，這會影響到測試人員的心情，進而導致匆忙地測試後面的測試用例，這樣測試用例的漏測、誤測就不可避免，嚴重影響了軟體測試效果和進度。因而，合理地定義測試用例的執行順序是很有必要的。
編輯本段測試用例執行
測試用例設計完畢後，接下來的工作是測試執行，測試執行中
測試用例設計
應該注意以下幾個問題：
搭建軟體測試環境，執行測試用例
測試用例執行過程中，搭建測試環境是第一步。一般來說，軟體產品提交測試後，開發人員應該提交乙份產品安裝指導書，在指導書中詳細指明軟體產品執行的軟硬體環境，比如要求作業系統系統是 windows 2000 pack4 版本，資料庫是 sql server 2000 等等，此外，應該給出被測試軟體產品的詳細安裝指導書，包括安裝的操作步驟、相關配置檔案的配置方法等等。對於複雜的軟體產品，尤其是軟體專案，如果沒有安裝指導書作為參考，在搭建測試環境過程中會遇到種種問題。
如果開發人員拒絕提供相關的安裝指導書，搭建測試中遇到問題的時候，測試人員可以要求開發人員協助，這時候，一定要把開發人員解決問題的方法記錄下來，避免同樣的問題再次請教開發人員，這樣會招致開發人員的反感，也降低了開發人員對測試人員的認可程度。
編輯本段測試執行過程應注意的問題
測試環境搭建之後，根據定義的測試用例執行順序，逐個執行測試用例。在測試執行中需要注意以下幾個問題：
全方位的觀察測試用例執行結果： 測試執行過程中，當測試的實際輸出結果與測試用例中的預期輸出結果一致的時候，是否可以認為測試用例執行成功了？答案是否定的，即便實際測試結果與測試的預期結果一致，也要檢視軟體產品的操作日誌、系統執行日誌和系統資源使用情況，來判斷測試用例是否執行成功了。
全方位觀察軟體產品的輸出可以發現很多隱蔽的問題。以前，我在測試嵌入式系統軟體的時候，執行某測試用例後，測試用例的實際輸出與預期輸出完全一致，不過在查詢 cpu 佔用率地時候，發現 cpu 佔用率高達 90 ％，後來經過分析，軟體執行的時候啟動了若干個 1ms 的定時器，大量的消耗的 cpu 資源，後來通過把定時器調整到 10ms ， cpu 的佔用率降為 7 ％。如果觀察點單一，這個嚴重消耗資源的問題就無從發現了。
加強測試過程記錄： 測試執行過程中，一定要加強測試過程記錄。如果測試執行步驟與測試用例中描述的有差異，一定要記錄下來，作為日後更新測試用例的依據；如果軟體產品提供了日誌功能，比如有軟體執行日誌、使用者操作日誌，一定在每個測試用例執行後記錄相關的日誌檔案，作為測試過程記錄，一旦日後發現問題，開發人員可以通過這些測試記錄方便的定位問題。
而不用測試人員重新搭建測試環境，為開發人員重現問題。
及時確認發現的問題： 測試執行過程中，如果確認發現了軟體的缺陷，那麼可以毫不猶豫的提交問題報告單。如果發現了可疑問題，又無法定位是否為軟體缺陷，那麼一定要保留現場，然後知會相關開發人員到現場定位問題。
如果開發人員在短時間內可以確認是否為軟體缺陷，測試人員給予配合；如果開發人員定位問題需要花費很長的時間，測試人員千萬不要因此耽誤自己寶貴的測試執行時間，可以讓開發人員記錄重新問題的測試環境配置，然後，回到自己的開發環境上重現問題，繼續定位問題。
與開發人員良好的溝通： 測試執行過程中，當你提交了問題報告單，可能被開發人員無情駁回，拒絕修改。這時候，只能對開發人員曉之以理，做到有理、有據，有說服力。
首先，要定義軟體缺陷的標準原則，這個原則應該是開發人員和測試人員都認可的，如果沒有共同認可的原則，那麼開發人員與測試人員對問題的爭執就不可避免了。此外，測試人員打算說服開發人員之前，考慮是否能夠先說服自己，在保證可以說服自己的前提下，再開始與開發人員交流。
編輯本段及時更新測試用例
測試執行過程中，應該注意及時更新測試用例。往往在測試執行過程中，才發現遺漏了一些測試用例，這時候應該及時的補充；往往也會發現有些測試用例在具體的執行過程中根本無法操作，這時候應該刪除這部分用例；也會發現若干個冗餘的測試用例完全可以由某乙個測試用例替代，那麼刪除冗餘的測試用例。
總之，測試執行的過程中及時地更新測試用例是很好的習慣。不要打算在測試執行結束後，統一更新測試用例，如果這樣，往往會遺漏很多本應該更新的測試用例。
測試用例編寫說明
測試用例編寫說明 1 一 什麼是測試用例 1 二 我們的測試原則 1 三 理解設計 1 四 構造測試用例的框架 2 五 充實用例內容 2 六 可玩性測試部分 3 七 易用性測試部分 3 八 後續維護更新 4 一 什麼是測試用例 為測試遊戲中某乙個或一組特定功能而制訂的測試方法，通常是關於該功能中若干...
關於基本測試用例的說明 3
一 設計基本測試用例的目的 1.基於軟硬體質量的考慮，軟硬體測試必須能夠覆蓋軟硬體的基本功能，才能進一步保證軟硬體在修改完成後不會對其他模組造成影響，不會影響基本功能的正常使用。2.基於時間因素的考慮，軟硬體測試必須能夠加以量化，才能進一步讓領導掌握所需要的測試過程，而基本測試用例將測試過程具體量化...
功能測試用例
專案編號 s 專案名 分類 模 整合測試用例 version 專案承擔部門 撰寫人 簽名 完成日期 本文件使用部門 主管領導 專案組 客戶 市場 維護人員 使用者評審負責人 簽名 評審日期 修訂文件歷史記錄 日期版本說明作者 目錄1.簡介 1 1.1目的 1 1.2範圍 1 1.3定義,首字母縮寫及...