測試用例設計——如何提高測試覆蓋率
前言
說到測試用例的設計，我想每個有過測試經歷的測試工程師都會認為很簡單，不就是：按需求或概要設計，得到軟件功能劃分圖，然後據此按每個功能，采用等價類劃分、臨界值、因果圖等方法來設計用例就行了。
但事實上撇開測試數據的設計不談，僅就測試項來說，我們發現，對同一個項目，有經驗的測試人員，在寫用例或測試時總會有更多的測試考慮點，從而發現更多 的問題；而有些測試人員測試用例的撰寫卻只有那麽三板斧，表面看好象已經把頁面所有信息的測試都考慮到了，實際上卻還是遺漏了大量測試覆蓋點，導致其測試 出來的程序總是比較脆弱。
究其原因，我覺得還是測試用例的撰寫水平不到位，更確切地說是測試用例的覆蓋度太低。說實話我認為系統測試
所以本文拋開具體的測試數據設計方法，主要從測試覆蓋度的角度來介紹用例設計時，如何才能考慮地更周全，如何才能將隱藏的測試項一一找出，從而使我們的測試更全面更完整。
想法雖然美好，可是畢竟每個測試的項目都是各不相同，針對不同項目我們的經驗也會告訴給我們不同的想法，這些想法通常很感性，很難用嚴密的邏輯理論來把 它升華。因此本文的內容仍是很簡陋且不**，只是希望能以本文為磚，引起大家的思考，一起來補充完善，以使我們的測試用例設計水平不斷提高。
正文
一、測試用例的切面設計
所謂測試切面設計，其實就是測試用例大項的劃分。測試用例劃分的經典方法是瀑布模型，也就是從上到下，逐漸細分，大模塊包括小模塊，小模塊包括更小的模 塊。但僅僅如此是不夠的，我們還要從更多的角度切入系統，從不同的角度把系統切分成一塊一塊的，來進行測試，從而確保測試大項的完整性。
1、功能點切面
這是最常見的切面，通常我們認為頁面上的一個按鈕就是一個功能點。然後我們可以根據功能的復雜程度，按每個功能；或一個功能點分多頁；或多個功能點合成一頁來進行用例的撰寫。
2、特定切面
除此以外，還有一種特定切面的劃分方法，也是用例撰寫時經常會用到的。所謂的特定切面，就是忽略掉表面上的功能點，而關註測試對象的某一個面。比如我們 的內部管理系統提供了銷售錄入導入、註冊錄入導入等功能，從菜單劃分上對應了七八個功能點。但這些功能處理後臺有個共同的處理項就是授權記錄的生成，這時 我們就可以把“授權記錄生成”單獨拿出來做一個測試項，而在其它
3、隱含切面
這類用例是最容易被忽略的。它往往不是明顯的某個功能項，可能是功能項後臺的隱含處理，也可能是多個功能項之間的關聯處理，甚至可能是在某種特定情形下的處理。這都需要測試人員通過對軟件的學習了解，來進行挖掘。
（1）、後臺功能
常見的如一些定時自動啟動的服務；以及某種特定情況下自動執行的操作等。它們在界面上往往是不體現的，但許多在需求設計中還是會提到，也有一些比較細小 的功能可能會被忽略，就需要測試人員根據對項目的了解程度來進行挖掘。所以說一個熟悉項目的和一個不熟悉的測試人員，寫出來的用例就完全是兩個層次的。
（2）、完整業務流程的測試
我們都知道測試用例的設計是從點、線、面三個層次去考慮的。完整的一個功能項是線，其中的某個按鈕是點，多個相關功能結合成完整業務流就是面。從實際來看這類用例往往被我們忽略。
事實上目前公司的軟件本來都是業務型應用軟件，將各種功能從業務流中切割出來單獨寫用例，肯定也會有涉及到整體流程的情況。若不加以區分，將細節與全局 攪在一起，不僅思路混亂，也容易考慮不周。因此在系統測試階段，建議用例設計要有分有合，針對具體功能的就只圍著這個功能轉：而在業務流程測試項中，再完 全從整體的業務流角度出發去考慮用例，這樣不僅不容易產生疏漏，用例閱讀與執行也更清楚。
（3）、某種特定情況下的系統運行
這類用例的設計往往與系統實際業務情況密不可分。比如**軟件，通常需要在月尾一天、月頭一天、年尾一天、年頭一天，對所有相關功能中的日期處理進行測試；又比如WIN 2000環境開發測試的系統，要測試在98、XP、2003等操作系統下是否能運行自如；再有如存在大量動態圖片視頻等的網頁，在普通網速下的展現速度等等。總之就是要盡可能從實際應用的角度出發考慮，來進行測試補充。
（4）、其它相關系統
即指在當前項目中直接使用的其它成果，包括公司自有的系統模塊、組件、函數；以及**或免費得到的一些功能組件。對這些內容需要預先與開發組長等討論清 楚，是否需要測試。若時間緊張或其它原因決定不測的，應在測試計劃中說明。若需要測試的，則具體可根據實際情況來設計，可以是通過系統某個功能的測試來涉 及，此時就不需要單獨劃分測試項；若相對比較獨立的，也可以通過單獨的測試項來對其專門進行測試。
（5）、除功能測試外的其它測試類型
包括可靠性、安全性、恢復性、配置安裝測試等等，這些測試類型都是一個單獨的測試項。
所謂好的開始是成功的一半，保證測試項劃分的完整、合理、正確，會直接影響到本次測試的成效。通常建議該階段工作要花1-2天的時間來考慮，並要在測試過程中隨著對軟件的深入了解，不斷進行調整補充。可千萬不要認為把分析設計中的功能模型圖搬搬過來就可以了。
二、詳細用例的設計
劃分好了測試項，接著就是針對各個測試項，考慮具體的測試用例了。根據測試項的特點，測試用例的設計角度也有所不同。下面我們就來看看通常的功能點測試用例，該從哪些角度出發來進行設計：
1、功能切面表面用例設計
（1）、具體功能測試
根據需求分析設計，按頁面提供的各個功能項，采用黑盒測試的各種方法，設計用例。比如頁面提供了增、刪、改、查功能，那麽這四個功能是否正確實現就是我要驗證的。這是最簡單、最基本，同時也是必須的測試用例，通常我們的編碼人員自測也就是做到這個程度。^_^
（2）、組合操作的測試
這是從上一角度擴展出來的，相對而言也是編碼人員不會去測試的，所以需要測試人員多作考慮。
所謂組合操作測試，也就是選擇某幾個操作項，按一定的順序進行操作，驗證系統不會出現意外錯誤。當然要將所有功能項排列組合一遍來測試不僅不必 要，也是不可能的。所以具體要將哪些功能項進行結合，要按怎樣的步驟來操作，還是需要測試人員根據實際情況來作設計（所以說在IT業人才就是一切呀，呵 呵：）。
一般來說我們會考慮功能項之間的數據是否會存在關聯，若有就需要考慮這種組合了。常見的如查詢功能，需要將各條件逐一累加進行測試；增完的數據 能否改，改完能否刪，刪完能否再增，這之間能否查詢到正確結果；按鈕的連續多次點擊會否出現異常；有嚴格前後順序要求的幾個操作，嘗試顛倒順序去操作，系 統能否控制等等。
不僅在某功能內部，擴展到有關聯的多個功能項之間，同樣有組合操作測試的存在。如申報完了能才反饋；如申報成功或失敗後再嘗試申報等。當然對於 這類用例既可以寫到某個功能切面中，也可以單獨寫到完整業務流程的切面中，這就取決於可能涉及用例的數量了，若關系比較復雜，當然是單獨寫比較好；若也就 是三五個用例數，那就直接在某個功能的用例中補充好了。
（3）、GUI界面的測試
這類測試是測試人員的強項，具體測試項目如限長、非法輸入等等，就不必贅述了。要提醒的是在測試時，一定要從實際使用者的操作習慣出發。要知道 界面原型所能確定的也只是頁面的擺放顯示，而實際操作時的控制實現仍是編碼人員自行實現的，即使有編碼指南，其所及範圍也是十分有限。而許多編碼人員在用 戶操作方便性上的考慮往往差強人意。所以測試人員就必須要把好這一關。
（4）、數據初始化情況測試
不該為空的數據是否有校驗；該有默認值的數據默認值是否正確；引用其它功能生成的數據，是否會實時刷新；頁面關閉或系統重啟後，數據的初始化設置等都是這類用例。
（5）、業務需求實現是否正確
這類問題往往是由於我們的需求說明欠詳細，而編碼人員的需求了解程度又較低造成。作為測試人員自然要對需求進行深刻研究，來對軟件實現進行把關。這裏常見的一些關註點有：
●數據的長度、類型控制是否合理（比如控制納稅人識別號只能為數字，但實際業務中是會有字母出現的）；
●業務邏輯控制是否合理（比如某數據項不提供修改，但實際業務中該數據項經常會需要改動）；
●提供的實現方式是否合理（比如只在某一頁面提供某數據的獲取功能，但根據業務劃分有些人員不能操作此頁面，卻必須要能看到該數據）；
●所做的數據控制是否合理（比如必須在A功能中新增數據，然後才能在B功能中操作，但實際業務中有可能會出現相反操作）；
●所做的數據控制是否完整（如授權的方式有普通按月、有買斷、有按數量控制，那麽當同一企業嘗試同時存在以上幾種授權方式時，系統是否能有必要的控制）；
●還有其它一些操作細節上的滿足（如業務上需要批量操作的數據有否提供批量操作功能、導入失敗的結果文件是否能修改後直接再導入等）。
對於不滿足的需求，經開發組長、需求經理等確認不作修改的，就要作為軟件的缺限或限制在測試報告中進行說明民。
2、功能切面隱含測試項用例設計：
（1）、數據完整性的測試
當某數據被其它功能引用；或當前功能要引用其它來源的數據，就會涉及到數據完整性的測試。最常見的如被引用的數據刪除了，或關鍵字被修改了，引 用的數據會否出錯；兩個途徑進入的數據會否沖突或重復；此外還有因為相關的幾個功能由不同人員編碼，從而導致彼此的控制不一致，如A功能進入的數據在可允 許的**情況下，到B功能中引用會否異常（最常見如用戶名錄入時允許長度10，但引用到某個單子填寫時允許長度是8，此時就會異常了）。
（2）、後臺的特殊處理
是指某功能除了表面所見以外的程序處理。比如訂單錄入，表面所見的就是訂單的保存，但後臺還會有重復數據的判斷、非法數據的處理、業務邏輯上沖 突情況的處理以及其它種種根據需求設計所特有的處理。又比如備份功能，在備份前可能有數據的清空、備份目錄的清空、備份目標是否存在的校驗、備份文件重復 時的處理等等。類似這些在分析設計中就未必會寫全了，還是要測試人員多花心思去思考挖掘。
（3）、功能業務之間的關聯與轉換
相關聯的幾個功能之間數據的傳遞，會否產生影響。比如新增錄入的某種特殊字符，要查詢時會引起查詢SQL語句異常；又如某下載文件名中存在中文 等字符，下載時由於編碼問題導致亂碼的出現；再有報表填寫時到小數點後四位，生成報文時會不會被忽略成兩位了等等。象這種問題，通常只能是在每個功能設計 用例時，盡量保證用例中的數據能涉及到允許範圍的各種情況，即充分運用等價類劃分+邊界值的方法設計出各種“稀奇古怪”的數據，並需驗證這些數據從頭流到 尾，都還是能保持其正確性，而不僅僅是在當前功能中正確。
（4）、從設計實現發掘測試點
這個就是我們測試中最難捉的BUG了，它往往是由編碼人員自己在編碼時創造出來的，連設計人員都不會知道。
比如內部管理系統中，正常的產品，其類別通常是2位數字；如果是模塊，其類別就以產品代碼來取代。這時如何來判斷該產品是模塊呢？最保險的當然 是校驗其產品類別字段的值能否在產品表中找到；也有比較簡單的方法就是直接判斷類別代碼大於2位還是小於等於2位。此時若能確切知道采用的是哪種實現方 法，就可以直接找到其漏洞所在。比如采用後一種方法，當產品類別長度變化時，明顯系統會出錯。那麽即使確認該實現方式不改，測試人員也應將其作為限制寫入 測試報告，。讓大家知道這個產品類別長度是不能隨意變化的。
而讓人郁悶的是，類似這樣的實現，有太多的編碼人員都是隨性處理的，它們細而隱蔽，在系統數據正常情況下根本不會被發現；而在漫漫的軟件使用道 路中，由於需求變更等原因對原有一些設計做維護變化，這種問題就會突然暴發出來讓人措不及防。所以要杜絕這類漏洞，除了測試人員要做土撥鼠，不停地對軟件 各功能的實現細節進行挖掘外，也要多給編碼人員灌輸完美實現的理念，多用復雜但抗壓性高的代碼，來替代簡單但依賴性強的代碼。
（5）、並發操作時的測試
即兩個或多個用戶同時操作同一功能時，會否引起數據的混亂。通常在C/S結構下，如果有同時操作的可能，是需要作此測試的；而在B/S結構下由 於其特殊性，此問題通常難以解決。除非就是某用戶一旦使用過某功能後，在一定時間內鎖定不允許再用，但這也會帶來實際應用中的不便，所以除非是特別核心的 數據，一般我們也不會去做此控制，當然對於可能出現的並發沖突也就作為系統的限制進行遺留了。
3、特定切面用例設計
所謂特定切面，其實就是從另一個角度切割出來的用例面，所以具體的用例撰寫方式其實與功能切面是一致的。
4、隱含切面用例設計
隱含切面分以下幾種情況：
（1）、無界面的後臺功能
對這類測試項，需要通過參數設置、代碼調用等方式來實現測試，但具體的測試設計其實與普通功能測試並無二致。這裏要註意，因為測試時往往前臺、 後臺是分開來分別進行的，而實際運行時兩者很可能是交集的，所以測試時要多註意後臺功能的執行與前臺的一些功能執行會否產生沖突？比如後臺有個文件搬運的 服務，那有沒有可能在前臺文件生成過程中，後臺執行文件搬運了？若有可能就要註意會否出現問題了。
（2）、與業務流相關的測試
這類測試用例的設計，就要從完整業務角度來設計數據了。從理論上來講，應該要將各個功能可能出現的各種數據排列組合到一起，按業務流程逐一進行 測試。但實際上我們不可能去做全覆蓋。所以設計這類用例時，最好有一張草稿，將所有相關功能按業務流程逐一列示，然後再將每個功能可能出現的特定數據一一 標上，最後將圖中最可能出現的、最可能出錯的、最核心的數據取出來，分別組合成一個個完整的業務數據用例，來進行測試。這樣就可以按清晰的思路，找出最實 用、最有效的測試數據。
（3）、其它測試類型
這一類的測試通常都有其特定的方法。如要測可靠性就準備大量數據不停地執行；要測安全性就考慮數據的加密、數據的傳輸、數據的破壞；恢復性一般 從網絡、電源方面著手；配置安裝則根據系統可支持的配置，搭建相應環境進行功能驗證，此處的驗證也要掌握技巧，即要多測試那些涉及到：數據庫讀寫、磁盤文 件讀寫、文件上傳下載、文件加解密、數據統計、圖表展現、打印等方面的功能。
三、測試數據的設計
每一個測試思路最終都要轉化成具體的數據才能來執行。關於測試數據設計的方法也不外乎那幾種，就不再贅述了。此處單就一些經常易犯的錯誤，提出一些註意點，作為用例數據設計時的參考：
1、盡量避免可能出現歧義測試結果的數據：即你設計的數據必須能唯一正確地反映出你所希望測試的結果。比如一組測試數據，有可能得到結果A或結果B，此時單用此數據來測試預期結果為A的用例，那明顯就產生了歧義。
2、對於不便具體列示的數據，則必須詳細描述其各項特性：有時我們在設計用例時為節約時間，不一定要到具體的一個數值，這也是允許的，但前提是 你必須要詳細描述清楚你要測試的數據特性。比如數據庫字段限長20，要測試超長數據時，可以描述為：嘗試輸入長度為21位的半角英文字符；嘗試輸入長度為 19位的半角英文字符，然後切換到中文全角再輸入一位全角字符等。千萬不能寫成：嘗試輸入超長字符，因為這只能是測試方案，作為方案是可以這樣寫，但到用 例階段，必須要是具體的、明確的、可操作的。
3、測試數據的設計必須有明確目的性：即測試數據是從測試方案衍生而來的。如上例測試方案是測超長字符輸入控制，所以測試數據就要根據具體字段 長度來錄入超長數據，如果一味錄入長15位、長16位的數據那就沒意義了。好的測試數據是可以同時針對多個測試方案的，此時可以在用例邊註明一下該數據的 測試目的，因為隨著時間推移，對著具體的數據你也許會忘了它到底是測什麽的，而這對你最後總結測試，查驗測試覆蓋率是非常不利的，所以隨時記下你的思路想 法吧，好記性不如爛筆頭。
4、測試數據可省略描述：測試數據描述以能讓人看懂為準則。所以寫用例時當碰到連續幾個用例，僅某幾個關鍵數據值改動，其余均是一樣的情況下， 不必每個用例都要重復描述所有數據，可以在第一個用例描述完整之後，其余用例中僅列示不同的數據，並標明其余數據同上第X個用例，即可。這樣測試時仍能復 原測試數據，且該用例的測試目的一眼就明，增加了用例的清晰性。
至些，我根據測試用例設計的順序，從測試數據的切面設計（即測試項劃分），到詳細測試用例設計，再到測試數據設計三個層面，逐一介紹了如何來提 高測試用例的覆蓋度。因為具體項目中的具體情況太多，以上敘述的內容也只能是管窺蠡測。至於其中的疏漏錯誤之處應也難免，只希望各位閱後能打開思路，從自 己多年的測試經驗中多總結、提煉出一些想法思路，進一步補充完善這個文檔，使大家的測試用例設計能力都能進一步提升。
測試用例設計——如何提高測試覆蓋率