說到測試用例的設計，我想每個有過測試經歷的測試工程師都會認為很簡單，不就是：按需求或概要設計，得到軟體功能劃分圖，然後據此按每個功能，採用等價類劃分、臨界值、因果圖等方法來設計用例就行了。
但事實上撇開測試資料的設計不談，僅就測試項來說，我們發現，對同乙個專案，有經驗的測試人員，在寫用例或測試時總會有更多的測試考慮點，從而發現更多的問題;而有些測試人員測試用例的撰寫卻只有那麼三板斧，表面看好象已經把頁面所有資訊的測試都考慮到了，實際上卻還是遺漏了大量測試覆蓋點，導致其測試出來的程式總是比較脆弱。
究其原因，我覺得還是測試用例的撰寫水平不到位，更確切地說是測試用例的覆蓋度太低。說實話我認為系統測試用例真正做到 100%覆蓋是很難的。難道說按設計中的功能劃分，每個功能都寫到了這個用例就覆蓋完整了?
錯，這還遠遠不夠。因為我們知道還有大量的內部處理、轉換、業務邏輯、相互影響的關係等都是需求或設計中所不會點明的。而這些一方面需要靠測試人員對專案本身的了解，另一方面要靠測試人員的經驗，來一一找到這些隱藏點並予以測試，才能真正地保證我們的測試覆蓋度。
所以本文拋開具體的測試資料設計方法，主要從測試覆蓋度的角度來介紹用例設計時，如何才能考慮地更周全，如何才能將隱藏的測試項一一找出，從而使我們的測試更全面更完整。
想法雖然美好，可是畢竟每個測試的專案都是各不相同，針對不同專案我們的經驗也會告訴給我們不同的想法，這些想法通常很感性，很難用嚴密的邏輯理論來把它昇華。因此本文的內容仍是很簡陋且不成熟，只是希望能以本文為磚，引起大家的思考，一起來補充完善，以使我們的測試用例設計水平不斷提高。
測試用例的切面設計
所謂測試切面設計，其實就是測試用例大項的劃分。測試用例劃分的經典方法是瀑布模型，也就是從上到下，逐漸細分，大模組包括小模組，小模組包括更小的模組。但僅僅如此是不夠的，我們還要從更多的角度切入系統，從不同的角度把系統切分成一塊一塊的，來進行測試，從而確保測試大項的完整性。
1、功能點切面
這是最常見的切面，通常我們認為頁面上的乙個按鈕就是乙個功能點。然後我們可以根據功能的複雜程度，按每個功能;或乙個功能點分多頁;或多個功能點合成一頁來進行用例的撰寫。
2、特定切面
除此以外，還有一種特定切面的劃分方法，也是用例撰寫時經常會用到的。所謂的特定切面，就是忽略掉表面上的功能點，而關注測試物件的某乙個面。比如我們的內部管理系統提供了銷售錄入匯入、註冊錄入匯入等功能，從選單劃分上對應了七八個功能點。
但這些功能處理後台有個共同的處理項就是授權記錄的生成，這時我們就可以把「授權記錄生成」單獨拿出來做乙個測試項，而在其它測試項中涉及這一部分的用例就不必再一一撰寫。此外象一些介面共通的操作用例單獨寫成一頁，也是一種特定切面。所以如果說將用例按功能點劃分是一種縱向劃分法，那麼特定切面就是從橫向的角度分析所得到的切面。
在普通功能點劃分上再根據實際情況設計特定切面，可以使我們的用例閱讀性、理解性、操作性更強。
3、隱含切面
這類用例是最容易被忽略的。它往往不是明顯的某個功能項，可能是功能項後台的隱含處理，也可能是多個功能項之間的關聯處理，甚至可能是在某種特定情形下的處理。這都需要測試人員通過對軟體的學習了解，來進行挖掘。
(1)、後台功能
常見的如一些定時自動啟動的服務;以及某種特定情況下自動執行的操作等。它們在介面上往往是不體現的，但許多在需求設計中還是會提到，也有一些比較細小的功能可能會被忽略，就需要測試人員根據對專案的了解程度來進行挖掘。所以說乙個熟悉專案的和乙個不熟悉的測試人員，寫出來的用例就完全是兩個層次的。
(2)、完整業務流程的測試
我們都知道測試用例的設計是從點、線、面三個層次去考慮的。完整的乙個功能項是線，其中的某個按鈕是點，多個相關功能結合成完整業務流就是面。從實際來看這類用例往往被我們忽略。
事實上目前公司的軟體本來都是業務型應用軟體，將各種功能從業務流中切割出來單獨寫用例，肯定也會有涉及到整體流程的情況。若不加以區分，將細節與全域性攪在一起，不僅思路混亂，也容易考慮不周。因此在系統測試階段，建議用例設計要有分有合，針對具體功能的就只圍著這個功能**
而在業務流程測試項中，再完全從整體的業務流角度出發去考慮用例，這樣不僅不容易產生疏漏，用例閱讀與執行也更清楚。
(3)、某種特定情況下的系統執行
這類用例的設計往往與系統實際業務情況密不可分。比如財務軟體，通常需要在月尾一天、月頭一天、年尾一天、年頭一天，對所有相關功能中的日期處理進行測試;又比如win 2000環境開發測試的系統，要測試在98、xp、2003等作業系統下是否能執行自如;再有如存在大量動態****等的網頁，在普通網速下的展現速度等等。總之就是要盡可能從實際應用的角度出發考慮，來進行測試補充。
(4)、其它相關系統
即指在當前專案中直接使用的其它成果，包括公司自有的系統模組、元件、函式;以及購買或免費得到的一些功能元件。對這些內容需要預先與開發組長等討論清楚，是否需要測試。若時間緊張或其它原因決定不測的，應在測試計畫中說明。
若需要測試的，則具體可根據實際情況來設計，可以是通過系統某個功能的測試來涉及，此時就不需要單獨劃分測試項;若相對比較獨立的，也可以通過單獨的測試項來對其專門進行測試。
(5)、除功能測試外的其它測試型別
包括可靠性、安全性、恢復性、配置安裝測試等等，這些測試型別都是乙個單獨的測試項。
所謂好的開始是成功的一半，保證測試項劃分的完整、合理、正確，會直接影響到本次測試的成效。通常建議該階段工作要花1-2天的時間來考慮，並要在測試過程中隨著對軟體的深入了解，不斷進行調整補充。可千萬不要認為把分析設計中的功能模型圖搬搬過來就可以了。
功能測試測試用例設計
註冊 登陸測試用例 一 註冊測試用例 測試編號 001 測試目標 驗證系統是否對必填項為空時做出正確的響應 測試環境 windows xp作業系統和瀏覽器ie6.0 測試步驟 1 開啟瀏覽器，在瀏覽器的位址列中輸入 使用者註冊 頁面的url，單擊 轉到 按鈕 2 在 使用者註冊 介面什麼都沒有輸入，...
實訓題目 邏輯覆蓋測試用例設計上機
實訓目的 1 一步熟悉黑盒測試和白盒測試的方法和策略 2 點掌握邏輯覆蓋的測試用例設計方法 3 增強測試經驗 實訓地點 機房 實訓課時 2課時 實訓重點 難點 邏輯覆蓋測試用例設計 實訓安排 首先講解邏輯覆蓋測試設計測試用例的步驟，要求學生注意總結方法和技巧，然後布置上機任務，要求學生對照課件和課本...
0407 測試理論 設計測試用例
為了實施測試而向被測試系統提供的輸入資料 操作或各種環境設定以及期望結果的乙個特定集合 組織性 避免盲目測試，提高測試效率 功能覆蓋 確保功能不被遺漏 重複性 專案進行期間對不同軟體版本進行多次重複執行測試 跟蹤 通過對測試用例統計，確定測試重點 測試確認 通過測試用例對測試過程進行監督，有效評估測...