測試用例的設計

① 設計測試用例

如果想設計測試用例的話，特別簡單，而且非常方便，這也非常的正常，而且特別的好。

② 測試用例設計的基本原則是什麼

測試用例設計的最基本要求：覆蓋住所要測試的功能。這是再基本不過的要求了，但別看只是版簡單的一句話，要權能夠達到切實覆蓋全面，需要對被測試產品功能的全面了解、明確測試范圍（特別是要明確哪些是不需要測試的）、具備基本的測試技術（如：等價類劃分等）等。那麼滿足了上述這條要求是不是設計出來的測試用例就是好的測試用例了呢？答案：在理論上是，但在實際工程中還遠遠不是。之所以理論和實際會有這樣的差別，是因為在理論上不要考慮的東東，而在實際工程中是不得不考慮的
-
成本。這里的成本包括：測試計劃成本、測試執行成本、自動化測試用例、測試自動化成本，測試分析成本，以及測試實現技術局限、測試環境的bug、人為因素和不可預測的隨機因素等引入的附加成本等。
此文出自:中國it實驗室

③ 什麼是測試用例如何設計測試用例

一個測試用例描述了針對某個目標對程序進行測試所採用的一組實際輸入、程序執行條件、測試步驟和預期的輸出，以核實某個程序或其中的特定路徑是否滿足特定需求。由於程序輸入的范圍會非常大，因此會導致一個軟體可選的測試用例數目巨大（甚至是無窮的）。這時，需要恰當地設計和選擇測試用例集，以在限定的資源和時間內，盡可能地暴露軟體中的錯誤。因此，測試用例集的設計通常被認為是測試中最重要、也是最困難的方面。由於實際測試中使用的測試用例集的輸入范圍只是程序輸入的子集，因此即使軟體通過了測試，也無法保證程序一定是正確的。這說明測試本身是不完全的，不能證明程序無錯。人們認為，軟體測試活動從未間斷，只是在軟體交付用戶使用後，將由用戶扮演測試角色而已。
對每個測試用例都需要給出具體描述，表1給出了一個測試用例模版示例。
表1
測試用例模版用例標識：對該測試用例賦予一個唯一標識用例開發者：誰編寫的本用例
用例開發日期：編寫用例的日期測試項：描述將被測試的具體特徵、代碼模塊等對象測試輸入：測試時為程序提供的輸入數據前提條件：執行測試時系統應處於的狀態或要滿足的條件等環境要求：執行測試所需的軟硬體環境、測試工具、人員等測試步驟：(1)……；（例如，點擊「文件」菜單中的「新建」菜單項）
(2)……；（例如，在「test
case」目錄下選擇「test5.dat」文件）……預期輸出：希望程序運行得到的結果
用例之間的依賴性：該測試用例依賴或受影響的其它測試用例
當測試用例數量多時，文檔化的工作量就比較大。這時，模版內容在實際測試中可以根據需要進行簡化，例如把各個測試用例所共有的內容單獨列出來（如環境要求），並把所有測試用例用一張表格描述出來。

④ 測試用例的設計方法有哪些

黑盒測試用例設計方法包括等價類劃分法、邊界值分析法、錯誤推測法、因內果圖法、判定表容驅動法、正交試驗設計法、功能圖法、場景圖法等。
白盒子測試方法：（強度由低到高）語句覆蓋、判定覆蓋、條件覆蓋、判定條件覆蓋、條件組合覆蓋、路徑覆蓋。
測試人員經常用到的有等價類，邊界值，場景法，因果圖法。
具體方法的使用可以網路下，這里就不啰嗦了。

⑤ 測試用例的設計思路有哪些

通常來來講，測試工程師會源從以下四個方面考慮來設計測試用例：
1.覆蓋需求，既依據需求文檔或原型來設計功能模塊級測試用例；
2.相關業務，既著眼於業務的相關性來設計測試用例如：訂單模塊與支付模塊等；
3.特殊角度，既從一些異常處理、極端情況等來設計用例，如蘋果手機在極寒天氣下的死機問題；
4.補充完善，基於一些內外部經驗或行業規范來設計用例，如金融行業的合規性測試用例等。
測試用例的設計思路，每一條思路的詳解去黑馬程序員的論壇去看！文字看不懂也有課程，自己去官網找，或者對話框問問。哥們在黑馬學出來的，但是我說的這些都是免費的。都是我哥們在我當初找工作的時候推薦我看的。

⑥ 單元測試的測試用例設計主要依據是詳細設計說明嗎

單元測試所對應的是詳細設計環節，也就是說，單元測試的測試用例是和詳細設計一起出現的，在研發人員做詳細設計的時候，相應的測試人員也就把測試用例寫了出來（來自網路）

⑦ 測試用例設計的基本格式

軟體測試用例的基本要素包括測試用例編號、測試標題、重要級別、測試輸入、操作步驟、預期結果，下面逐一介紹。 如果我看得遠，那是因為我站在巨人的肩上 －－牛頓。
一般來說，每個軟體公司的項目可以分為固定的幾大類。可以按業務類型劃分，比如 ERP 軟體、產品數據管理軟體、通信軟體、地理信息系統軟體等等；可以按軟體結構來劃分，比如 B/S 架構的軟體、 C/S 架構的軟體、嵌入式軟體等等。參考同類別軟體的測試用例，會有很大的借鑒意義。如果，公司中有同類別的軟體系統，千萬別忘記把相關的測試用例拿來參考。如果，系統非常接近，甚至經過對測試用例簡單修改就可以應用到當前被測試的軟體。 「 拿來主義 」 可以極大的開闊測試用例設計思路，也可以節省大量的測試用例設計時間。 測試用例設計完畢後，接下來的工作是測試執行，測試執行中應該注意以下幾個問題：
搭建軟體測試環境，執行測試用例
測試用例執行過程中，搭建測試環境是第一步。一般來說，軟體產品提交測試後，開發人員應該提交一份產品安裝指導書，在指導書中詳細指明軟體產品運行的軟硬體環境，比如要求操作系統系統是 Windows 2000 pack4 版本，資料庫是 Sql Server 2000 等等，此外，應該給出被測試軟體產品的詳細安裝指導書，包括安裝的操作步驟、相關配置文件的配置方法等等。對於復雜的軟體產品，尤其是軟體項目，如果沒有安裝指導書作為參考，在搭建測試環境過程中會遇到種種問題。
如果開發人員拒絕提供相關的安裝指導書，搭建測試中遇到問題的時候，測試人員可以要求開發人員協助，這時候，一定要把開發人員解決問題的方法記錄下來，避免同樣的問題再次請教開發人員，這樣會招致開發人員的反感，也降低了開發人員對測試人員的認可程度。 測試環境搭建之後，根據定義的測試用例執行順序，逐個執行測試用例。在測試執行中需要注意以下幾個問題：
全方位的觀察測試用例執行結果： 測試執行過程中，當測試的實際輸出結果與測試用例中的預期輸出結果一致的時候，是否可以認為測試用例執行成功了？答案是否定的，即便實際測試結果與測試的預期結果一致，也要查看軟體產品的操作日誌、系統運行日誌和系統資源使用情況，來判斷測試用例是否執行成功了。全方位觀察軟體產品的輸出可以發現很多隱蔽的問題。以前，我在測試嵌入式系統軟體的時候，執行某測試用例後，測試用例的實際輸出與預期輸出完全一致，不過在查詢 CPU 佔用率地時候，發現 CPU 佔用率高達 90 %，後來經過分析，軟體運行的時候啟動了若干個 1ms 的定時器，大量的消耗的 CPU 資源，後來通過把定時器調整到 10ms ， CPU 的佔用率降為 7 %。如果觀察點單一，這個嚴重消耗資源的問題就無從發現了。
加強測試過程記錄： 測試執行過程中，一定要加強測試過程記錄。如果測試執行步驟與測試用例中描述的有差異，一定要記錄下來，作為日後更新測試用例的依據；如果軟體產品提供了日誌功能，比如有軟體運行日誌、用戶操作日誌，一定在每個測試用例執行後記錄相關的日誌文件，作為測試過程記錄，一旦日後發現問題，開發人員可以通過這些測試記錄方便的定位問題。而不用測試人員重新搭建測試環境，為開發人員重現問題。
及時確認發現的問題： 測試執行過程中，如果確認發現了軟體的缺陷，那麼可以毫不猶豫的提交問題報告單。如果發現了可疑問題，又無法定位是否為軟體缺陷，那麼一定要保留現場，然後知會相關開發人員到現場定位問題。如果開發人員在短時間內可以確認是否為軟體缺陷，測試人員給予配合；如果開發人員定位問題需要花費很長的時間，測試人員千萬不要因此耽誤自己寶貴的測試執行時間，可以讓開發人員記錄重現問題的測試環境配置，然後，回到自己的開發環境上重現問題，繼續定位問題。
與開發人員良好的溝通： 測試執行過程中，當你提交了問題報告單，可能被開發人員無情駁回，拒絕修改。這時候，只能對開發人員曉之以理，做到有理、有據，有說服力。首先，要定義軟體缺陷的標准原則，這個原則應該是開發人員和測試人員都認可的，如果沒有共同認可的原則，那麼開發人員與測試人員對問題的爭執就不可避免了。此外，測試人員打算說服開發人員之前，考慮是否能夠先說服自己，在保證可以說服自己的前提下，再開始與開發人員交流。 測試執行過程中，應該注意及時更新測試用例。往往在測試執行過程中，才發現遺漏了一些測試用例，這時候應該及時的補充；往往也會發現有些測試用例在具體的執行過程中根本無法操作，這時候應該刪除這部分用例；也會發現若干個冗餘的測試用例完全可以由某一個測試用例替代，那麼刪除冗餘的測試用例。
總之，測試執行的過程中及時地更新測試用例是很好的習慣。不要打算在測試執行結束後，統一更新測試用例，如果這樣，往往會遺漏很多本應該更新的測試用例。

⑧ 軟體測試用例的幾種設計方法

一、等價類劃分
等價類劃分主要適用於單個輸入條件，輸入為數值型的情況，如果輸入規定了輸入區間，可劃分出一個有效等價類，兩個無效等價類;如果輸入只規定了輸入范圍，可劃分出一個有效等價類，一個無效等價類。
二、邊界值
邊界值方法也是適用於單個輸入條件的情況，輸入類型可以數值、字元等，要測試的邊界包括上點、下點、離點。
三、錯誤推測法
錯誤推測法主要是測試設計人員的測試經驗相關,測試經驗不同,設計出來的測試用例也區別很大。
四、因果圖法
因果圖方法考慮輸入的組合，特別適用於多個輸入條件相關有關聯又相互約束的情況。
設計步驟：
1)羅列出輸入與輸出;
2)根據輸入與輸出畫出因果圖;
3)標出約束跟限制;
4)把因果圖轉化成判定表;
5)根據判定表的每一列設計測試用例。
五、判定表驅動法
判定表適合於解決多個邏輯條件的組合。將各種邏輯的組合羅列出來，避免遺漏。不能表達重復的操作。
判定表包括條件樁、條件項、動作樁、動作項。
條件樁：列出所有條件，次序無關;
條件項：列出所對應條件的所有可能情況下的取值;
動作樁：列出可能採取的操作，次序無關;
動作項：列出條件項各種取值情況下採取的操作。
設計步驟：
1)確定規則個數，條件及各條件取值的組合;
2)列出條件樁、動作樁;
3)列出條件項;
4)列出動作項;
5)初始化判定表;
6)規則簡化、合並。

⑨ 測試用例設計的基本原則是什麼

1、測試用例的代表性：能夠代表並覆蓋各種合理的和不合理、合法的回和非法的、邊界的和越界答的、以及極限的輸入數據、操作和環境設置等。
2、測試結果的可判定性：即測試執行結果的正確性是可判定的，每一個測試用例都應有相應的期望結果。
3、測試結果的可再現性：即對同樣的測試用例，系統的執行結果應當是相同的。

不管是從個人角度還是從公司角度，根據我這幾年的經驗我覺得case的設計應該符合以下幾點：
1、一個case一個功能點：每個case都要有個測點，找准一個測點則可，不能同時覆蓋很多功能點，否則執行起來牽連太大；
2、case的易讀：從執行者的角度去寫case，最好不要有太多的術語在裡面，如果要有最好指明具體位置；
3、case的執行粒度：粒度越小越好；
4、步驟清晰：一個case多個步驟，可一個重點，步驟指名人們怎麼去操作，expect則指明這樣操作之後應該看到什麼結果---最好不要用正確，正常，錯誤之類的含糊主觀的字眼。
5、總體設計：先正常，後異常，這樣可以確保正常情況下功能能夠走通。
總之：對於一個新來的tester，給他個case和我們的軟體，他就能順利取執行case.

⑩ 如何選擇測試用例設計方法

設計方法如何選擇
p當遇到需要輸入數據時，首先進行等價類和邊界值版，這是減權
少工作量和提高測試效率最有效方法
p用錯誤推測法再追加一些測試用例
p對照程序邏輯，如果存在組合，用判定表設計用例
p對於業務流清晰的功能，利用場景法貫穿整個測試案例過程，
再針對不同節點綜合使用其他測試方法
p 測試用例的設計方法不是單獨存在的
p 在實際測試中，往往是綜合使用各種方法才能有效提高測試
效率和測試覆蓋度。