軟件測試中測試用例設計的精益求精
1.1.1 測試用例設計的精益求精
測試用例設計工作本身是一個很難直接定量的工作，也不可能像開發代碼一樣，只要編譯通過可執行就認為完成了任務。那么在測試用例設計過程中，我們如何才能促進測試用例設計水平的提高呢？測試用例的設計和編寫基本上只有依靠測試工程師自己精益求精的態度才能保證測試用例設計的質量。測試人員自身精益求精的態度，不但影響著測試用例的設計質量，而且直接影響著測試人員之間測試水平的高低。
在設計測試用例時，精益求精的精神需要我們在完成每一個功能測試點的基本測試方法設計后，再繼續投入時間和大腦，并繼續發散思維，在基本測試方法的基礎上多寫出一兩倍的測試方法，希望所設計的用例能發現更多的bug，使測試的質量取得更好的效果。有一天你會發現正是這些多寫出的測試方法更容易發現bug，幫助測試人員提高自己績效的同時得到測試的樂趣。因為最基本的應用模式，90%的人都會比較容易地想到和覆蓋到；而質量提升的最后10%，則可能只有很少的人，也許是10%的人才能去實現和達到。所以當我們在進行功能測試的測試用例設計時，每多想一個測試方法，就越接近99%的質量目標。
案例
一個即時通信產品的服務器與客戶端通信功能模塊的測試用例
基本測試要求：服務器與客戶端之間傳送文本信息的功能測試（不包括壓力測試和性能測試）。
大多數人很容易就想到如下測試方法：
（1）服務器向客戶端發送一段文字，如果客戶端能收到完整的信息，則驗證通過。
（2）客戶端向服務器發送一段文字，如果服務器端能收到完整的信息，則驗證通過。
倘若只是進行最基本的通信功能驗證，好像如上兩個測試方法已經覆蓋了服務器與客戶端通信的全部功能�？墒�，如果我們能追求測試用例設計的精益求精，則該功能的測試用例還可以再進行如下補充。
測試策略1--測試數據集
服務器與客戶端通信的測試數據分為：全中文（不同編碼格式）、英文、日文、中英文+數字+其他符號（@、#、!、～、&等）的組合、以數字及各類符號作為傳送信息的最后一個字符。
以服務器能輸入字符信息的最大數量為依據，輸入一個最大化的數據，判斷客戶端能否完整顯示。
以客戶端能輸入字符信息的最大數量為依據，輸入一個最大化的數據，判斷服務器能否完整顯示。
應用測試策略1，服務器端與客戶端1:1同時進行雙向通信。
應用測試策略1，服務器端與客戶端1:n同時進行雙向通信。
應用測試策略1，服務器端與客戶端n:1同時進行雙向通信。
測試策略2--臨界狀態測試
在服務器和客戶端同時發送空數據信息給對方。
在服務器和客戶端同時發送滿數據信息給對方。
在服務器和客戶端啟動過程中，分別向對方發送空信息、滿信息。
測試策略3--異常處理
模擬雙向數據傳輸時，傳輸過程中不斷發生傳輸中斷和恢復，服務器和客戶端不發生不合理的現象。
數據發送瞬間，接收端發生意外關閉、正常關閉或接收端重啟，是否服務器和客戶端不發生異常，接收端能正常接收完整的發送信息。
在對端軟件未啟動和傳輸通信不通時，如果數據發送失敗，發送方進行合理處理。
測試策略4--長時間工作
通過轉換為自動化測試的方式，將測試策略1、測試策略2和測試策略3按先后順序循環執行多次或10小時以上，尋找測試策略1、測試策略2和測試策略3所能覆蓋的邏輯處理代碼中是否有內存泄漏的情況。
到目前為止，我們已在最開始的測試設計基礎上進行了很多的擴展。那么我們現在是否還可以有新的測試策略來進一步提高測試用例的質量呢？
測試策略5--模擬資源緊張情況下的測試
長時間（10小時以上）同步模擬服務器和客戶端在各自接收端口和發送端口同時受到網絡攻擊，在有限的通信系統資源緊張的情況下是否還能進行正常的文本通信，而不出現異常。
測試策略6--真實環境測試
將服務器和客戶端掛在Internet上進行真實環境的測試，驗證是否會有在真實環境應用中我們未想到的測試情形。
我們現在還能繼續設計新的測試策略嗎？只要你堅信測試無止境，堅持凡事精益求精，向自己的思維潛力挑戰，肯定還可以設計出新的測試策略。
筆者于是在前面已有的測試策略的基礎上又有新的突破，秉承對功能測試質量精益求精的態度，繼續對該模塊進行測試方法的挖掘。
測試策略7--安全性測試
服務器和客戶端在通信過程中進行安全性測試。當兩端正在持續正常通信過程中，同時啟動對服務器和客戶端的各類安全性測試攻擊。例如：通過向接收端進行偽造的源IP數據攻擊；向接收端發送一些畸形的數據文件格式；向接收端發送一些錯誤的協議報文等方式，來判斷接收端是否會出現異常。
最后限于筆者對即時通信軟件客戶端與服務器通信測試的有限功力，這個功能點的測試設計先到此為止。希望通過這個案例如何進行精益求精設計的過程，來讓讀者體會"精益求精"對于提升測試用例設計水平的意義和價值。讀者如果感興趣，還可以在此基礎上提出更多好的測試策略，不斷完善這個案例的測試用例設計。
測試用例設計的精益求精除了多創造測試方法外，還有另一個很重要的領域--在測試用例設計規范上追求精益求精。筆者曾見過不少測試用例由于寫得過于草率和簡單，導致執行測試的人在工作時壓力非常大，需要花費很大的精力和時間來啃測試用例中描述的真實含義。請大家不要誤認為這只是因為我們中國測試起步晚，才有這樣的現象。筆者曾見過兩家歐美頂尖電信設備公司老外工程師寫的測試用例，其測試方法過于簡單，測試步驟描述基本沒有，基本上每個執行這些測試用例的中國工程師都叫苦連天。
你說這些歐美企業沒有規范的流程嗎？可他們是CMMI5（軟件能力成熟度模型集成模型5級）都過了的，這些測試用例也是經過了每一個需要評審的流程才正式進入測試用例庫的。那為什么這些外國人寫的用例方法如此簡單？因為測試流程和測試規范只關注測試用例的骨架是否完成，而附著在骨架上的肌肉狀況，則很難由流程來規范和考評。這樣有的老外就偷懶，用一句簡單的句子就描述完了一個測試方法，給后來者帶來了極大的痛苦。
據筆者所知，后來在這兩家歐美企業的中國工程師一改他們的老外同事留下的弊病，在寫測試方法時，盡量做到非常詳細的文字描述，并盡可能地把所有的操作步驟和命令都補充在對應的測試步驟后面。使用這種精益求精的態度寫出的測試用例，完全可以讓任何一位測試用例執行者只看一遍測試用例即可完成測試用例的執行。測試用例設計工程師通過自己多付出些時間來完善和豐富測試用例的描述，不但大大提高了未來測試用例執行的效率，而且為公司節省了時間和成本。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
