測試用例設計和執行是測試工作的核心，也是工作量最大的任務之一。測試用例(test case) 目前沒有經典的定義。比較通常的說法是：指對一項特定的軟體產品進行測試任務的描述，體現測試方案、方法、技術和策略。內容包括測試目標、測試環境、輸入資料、測試步驟、預期結果、測試指令碼等，並形成文件。測試用例其實就是乙個個你測試的想法，你有了這些想法之後，詳細地寫下來，就成了測試用例。
測試用例編寫準備:
1.從配置管理員處申請軟體配置：《需求規格說明書》和《設計說明書》；
2.根據需求規格說明書和設計說明書，詳細理解使用者的真正需求，並且對軟體所實現的功能已經準確理解，然後著手制訂測試用例。
測試用例制定的原則:
測試用例要包括欲測試的功能、應輸入的資料和預期的輸出結果。
2.測試資料應該選用少量、高效的測試資料進行盡可能完備的測試。
用例覆蓋:
正確性測試：輸入使用者實際資料以驗證系統是滿足需求規格說明書的要求；測試用 例中的測試點應首先保證要至少覆蓋需求規格說明書中的各項功能，並且正常。
容錯性（健壯性）測試：程式能夠接收正確資料輸入並且產生正確（預期）的輸出， 輸入非法資料（非法型別、不符合要求的資料、溢位資料等），程式應能給出提示 並進行相應處理。把自己想象成一名對產品操作一點也不懂的客戶，在進行任意操作。
完整（安全）性測試：對未經授權的人使用軟體系統或資料的企圖，系統能夠控制的程度，程式的資料處理能夠保持外部資訊（資料庫或檔案）的完整。
介面間測試：測試各個模組相互間的協調和通訊情況，資料輸入輸出的一致性和正確性。
壓力測試：輸入10條記錄執行各個功能，輸入30條記錄執行，輸入50條記錄進行測試。
效能：完成預定的功能，系統的執行時間（主要是針對資料庫而言）。
可理解（操作）性：理解和使用該系統的難易程度（介面友好性）。
可移植性：在不同作業系統及硬體配置情況下的執行性。
如何編寫測試用例：
測試用例有幾個重要的組成部分：簡明扼要的標題，詳細的步驟，正確的預期結果。 例如：
測試步驟：
執行記事本程式。
切換到中文輸入法，輸入中文「學習編寫」。
切換到英文輸入法，輸入英文testcase。
儲存檔案，檔名為testcase.txt。
關閉記事本程式。
雙擊testcase.txt以開啟檔案。
預期結果：
檔案的內容是「學習編寫testcase」。
測試用例的優先順序：
測試用例還有乙個優先順序的概念，就是用來區分哪些用例更重要。一般可以分為5個級別，分別用0 ~ 4來表示。數字越小表示優先順序越高。如果專案小，優先順序的好處不容易顯現出來。當專案比較大，時間又不寬裕時，可能只能執行更重要的測試用例，這個時候優先順序的重要性就體現出來了。
a good test case should include:
如何執行測試用例：
如果你是一位軟體測試的入門者，你到單位報到後接手的第一項工作很可能是執行軟體測試用例，而不是去編寫。你不要因此而鬱悶，這樣的安排是合理的，因為你畢竟是乙個新手，執行測試用例是乙個迅速熟悉當前測試工作的好機會，而且壓力也不大。因為在英語中執行測試用例是run test case，所以有些公司把執行測試用例叫做「跑case」，想來也是比較形象的。
我們還以驗證記事本程式可以編輯中英文混合的內容為例。當我們面對這個用例的時候，我們首先要做的是清晰且正確地理解用例，不帶半點含糊。測試的特點就是嚴謹，你來執行乙個測試用例就是要貫徹用例編寫者的測試思想，不能誤解或曲解，不能用自己的主觀意志去代替原來的意思。例如，第一步「執行記事本程式」，你就應當清楚地知道「記事本」是哪個程式，如果有疑問馬上問清楚，否則，如果真的吧測試的產品弄錯了，一切就都白忙了，還浪費了時間。這個例子因為淺顯，所以出現誤解的可能性很小，而在實際的工作中，還是會有很多模稜兩可的地方，這個時候我們不能偷懶，要勤學多問。
執行用例不能走樣。例如第二步，要求輸入「學習編寫」四個字，如果你為了省事，拷貝了這幾個字，每次都是貼上過來，快是快樂，卻違背了原著的意思，這樣式不行的。用例編寫者要求用輸入法來輸入，肯定是有道理的。如果哦你發現沒有檢測「貼上」的測試用例，可以建議增加，但不能再執行的時候就偏離了用例的本意。說乙個萬一的事兒，如果這個軟體通過了你的測試，發布給使用者，使用者卻發現不能輸入，只能貼上，這個責任你能負的起嗎？
大家可能都知道，做軟體測試要細心，這個要求在執行用例的過程中表現得很明顯。我們在執行乙個測試用例的時候，不但要注意實際結果是否與預期結果是一致的，而且在整個過程中都要保持觀察。例如上例中，如果第四步執行儲存後，你發現檔名並不是自己輸入的testcase.txt，這時你就應當停下來，因為這就是bug。
我們執行測試用例的目的是什麼？就是發現bug，所以，我們在執行測試用例的過程中，要收集好發現的問題，不能有洩露。在實際工作中， 執行測試用例的過程一般都是緊張的，工作量很大，並不像我們今天在這裡討論的這麼輕鬆，因為你要不停地往前趕，所以容易出現一些遺漏的問題。每當發現乙個問題，我們都要做好記錄，而不要總以為自己能記得住，好記性不如爛筆頭。bug是最能證明測試工程師工作成績的東西，好不容易發現了，如果還被自己遺漏了，豈不令人懊悔？而且，還給產品留下了乙個隱患。
測試用例（四）測試用例編寫
一.測試用例編寫方法 1.等價類劃分 如何選擇適當的資料子集，來代表整個資料集。通過降低測試的資料去實現 合理的 覆蓋，覆蓋了更多的可能資料，以發現更多的軟體缺陷 邊界值分析法 2.邊界值分析 使用邊界值分析方法設計測試用例時一般與等價類劃分結合起來，但它不是從乙個等價類中任選乙個例子作為代表，而是...
測試用例編寫
一 測試用例編寫準備 從配置管理員處申請軟體配置 需求規格說明書 和 設計說明書 根據需求規格說明書和設計說明書，詳細理解使用者的真正需求，並且對軟體所實現的功能已經準確理解，然後著手制訂測試用例。二 測試用例制定的原則 測試用例要包括欲測試的功能 應輸入的資料和預期的輸出結果。測試資料應該選用少量...
測試用例編寫
一 測試 用例編寫準備 從配置管理員處申請軟體配置 需求規格說明書 和 設計說明書 根據 需求規格說明書和設計說明書，詳細理解使用者的真正需求，並且對軟體所實現的功能已經準確理解，然後著手制訂 測試用例。二 測試用例制定的原則 測試用例要包括欲測試的功能 應輸入的資料和預期的輸出結果。測試資料應該選...