軟件測試用例設計方法之切面設計

　　一、測試用例的切面設計

　　所謂測試切面設計，其實就是測試用例大項的劃分。測試用例劃分的經典方法是瀑布模型，也就是從上到下，逐漸細分，大模塊包括小模塊，小模塊包括更小的模塊。但僅僅如此是不夠的，我們還要從更多的角度切入系統，從不同的角度把系統切分成一塊一塊的，來進行測試，從而確保測試大項的完整性。

　　1、功能點切面

　　這是最常見的切面，通常我們認為頁面上的一個按鈕就是一個功能點。然后我們可以根據功能的復雜程度，按每個功能;或一個功能點分多頁;或多個功能點合成一頁來進行用例的撰寫。

　　2、特定切面

　　除此以外，還有一種特定切面的劃分方法，也是用例撰寫時經常會用到的。所謂的特定切面，就是忽略掉表面上的功能點，而關注測試對象的某一個面。比如我們的內部管理系統提供了銷售錄入導入、注冊錄入導入等功能，從菜單劃分上對應了七八個功能點。但這些功能處理后臺有個共同的處理項就是授權記錄的生成，這時我們就可以把“授權記錄生成”單獨拿出來做一個測試項，而在其它測試項中涉及這一部分的用例就不必再一一撰寫。此外象一些界面共通的操作用例單獨寫成一頁，也是一種特定切面。所以如果說將用例按功能點劃分是一種縱向劃分法，那么特定切面就是從橫向的角度分析所得到的切面。在普通功能點劃分上再根據實際情況設計特定切面，可以使我們的用例閱讀性、理解性、操作性更強。

　　3、隱含切面

　　這類用例是最容易被忽略的。它往往不是明顯的某個功能項，可能是功能項后臺的隱含處理，也可能是多個功能項之間的關聯處理，甚至可能是在某種特定情形下的處理。這都需要測試人員通過對軟件的學習了解，來進行挖掘。

　　(1)、后臺功能

　　常見的如一些定時自動啟動的服務;以及某種特定情況下自動執行的操作等。它們在界面上往往是不體現的，但許多在需求設計中還是會提到，也有一些比較細小的功能可能會被忽略，就需要測試人員根據對項目的了解程度來進行挖掘。所以說一個熟悉項目的和一個不熟悉的測試人員，寫出來的用例就完全是兩個層次的。

　　(2)、完整業務流程的測試

　　我們都知道測試用例的設計是從點、線、面三個層次去考慮的。完整的一個功能項是線，其中的某個按鈕是點，多個相關功能結合成完整業務流就是面。從實際來看這類用例往往被我們忽略。

　　事實上目前公司的軟件本來都是業務型應用軟件，將各種功能從業務流中切割出來單獨寫用例，肯定也會有涉及到整體流程的情況。若不加以區分，將細節與全局攪在一起，不僅思路混亂，也容易考慮不周。因此在系統測試階段，建議用例設計要有分有合，針對具體功能的就只圍著這個功能轉：而在業務流程測試項中，再完全從整體的業務流角度出發去考慮用例，這樣不僅不容易產生疏漏，用例閱讀與執行也更清楚。

　　(3)、某種特定情況下的系統運行

　　這類用例的設計往往與系統實際業務情況密不可分。比如財務軟件，通常需要在月尾一天、月頭一天、年尾一天、年頭一天，對所有相關功能中的日期處理進行測試;又比如WIN 2000環境開發測試的系統，要測試在98、XP、2003等操作系統下是否能運行自如;再有如存在大量動態圖片視頻等的網頁，在普通網速下的展現速度等等?？傊褪且M可能從實際應用的角度出發考慮，來進行測試補充。

　　(4)、其它相關系統

　　即指在當前項目中直接使用的其它成果，包括公司自有的系統模塊、組件、函數;以及購買或免費得到的一些功能組件。對這些內容需要預先與開發組長等討論清楚，是否需要測試。若時間緊張或其它原因決定不測的，應在測試計劃中說明。若需要測試的，則具體可根據實際情況來設計，可以是通過系統某個功能的測試來涉及，此時就不需要單獨劃分測試項;若相對比較獨立的，也可以通過單獨的測試項來對其專門進行測試。

　　(5)、除功能測試外的其它測試類型

　　包括可靠性、安全性、恢復性、配置安裝測試等等，這些測試類型都是一個單獨的測試項。

　　所謂好的開始是成功的一半，保證測試項劃分的完整、合理、正確，會直接影響到本次測試的成效。通常建議該階段工作要花1-2天的時間來考慮，并要在測試過程中隨著對軟件的深入了解，不斷進行調整補充?？汕f不要認為把分析設計中的功能模型圖搬搬過來就可以了。

　　二、詳細用例的設計

　　劃分好了測試項，接著就是針對各個測試項，考慮具體的測試用例了。根據測試項的特點，測試用例的設計角度也有所不同。下面我們就來看看通常的功能點測試用例，該從哪些角度出發來進行設計：

　　1、功能切面表面用例設計

　　(1)、具體

　　功能測試

　　根據需求分析設計，按頁面提供的各個功能項，采用黑盒測試的各種方法，設計用例。比如頁面提供了增、刪、改、查功能，那么這四個功能是否正確實現就是我要驗證的。這是最簡單、最基本，同時也是必須的測試用例，通常我們的編碼人員自測也就是做到這個程度。^_^

　　(2)、組合操作的測試

　　這是從上一角度擴展出來的，相對而言也是編碼人員不會去測試的，所以需要測試人員多作考慮。

　　所謂組合操作測試，也就是選擇某幾個操作項，按一定的順序進行操作，驗證系統不會出現意外錯誤。當然要將所有功能項排列組合一遍來測試不僅不必要，也是不可能的。所以具體要將哪些功能項進行結合，要按怎樣的步驟來操作，還是需要測試人員根據實際情況來作設計(所以說在IT業人才就是一切呀，呵呵：)。

　　一般來說我們會考慮功能項之間的數據是否會存在關聯，若有就需要考慮這種組合了。常見的如查詢功能，需要將各條件逐一累加進行測試;增完的數據能否改，改完能否刪，刪完能否再增，這之間能否查詢到正確結果;按鈕的連續多次點擊會否出現異常;有嚴格前后順序要求的幾個操作，嘗試顛倒順序去操作，系統能否控制等等。

　　不僅在某功能內部，擴展到有關聯的多個功能項之間，同樣有組合操作測試的存在。如申報完了能才反饋;如申報成功或失敗后再嘗試申報等。當然對于這類用例既可以寫到某個功能切面中，也可以單獨寫到完整業務流程的切面中，這就取決于可能涉及用例的數量了，若關系比較復雜，當然是單獨寫比較好;若也就是三五個用例數，那就直接在某個功能的用例中補充好了。

原文轉自：http://www.anti-gravitydesign.com