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