如何更進一步設計完善的測試用例設計

自動化測試的方式，將測試策略1、測試策略2和測試策略3按先后順序循環執行多次或10小時以上，尋找測試策略1、測試策略2和測試策略3所能覆蓋的邏輯處理代碼中是否有內存泄漏的情況。

到目前為止，我們已在最開始的測試設計基礎上進行了很多的擴展。那么我們現在是否還可以有新的測試策略來進一步提高測試用例的質量呢？

測試策略5--模擬資源緊張情況下的測試

長時間（10小時以上）同步模擬服務器和客戶端在各自接收端口和發送端口同時受到網絡攻擊，在有限的通信系統資源緊張的情況下是否還能進行正常的文本通信，而不出現異常。

測試策略6--真實環境測試

將服務器和客戶端掛在Internet上進行真實環境的測試，驗證是否會有在真實環境應用中我們未想到的測試情形。

我們現在還能繼續設計新的測試策略嗎？只要你堅信測試無止境，堅持凡事精益求精，向自己的思維潛力挑戰，肯定還可以設計出新的測試策略。

筆者于是在前面已有的測試策略的基礎上又有新的突破，秉承對功能測試質量精益求精的態度，繼續對該模塊進行測試方法的挖掘。

測試策略7--安全性測試

服務器和客戶端在通信過程中進行安全性測試。當兩端正在持續正常通信過程中，同時啟動對服務器和客戶端的各類安全性測試攻擊。例如：通過向接收端進行偽造的源IP數據攻擊；向接收端發送一些畸形的數據文件格式；向接收端發送一些錯誤的協議報文等方式，來判斷接收端是否會出現異常。

最后限于筆者對即時通信軟件客戶端與服務器通信測試的有限功力，這個功能點的測試設計先到此為止。希望通過這個案例如何進行精益求精設計的過程，來讓讀者體會"精益求精"對于提升測試用例設計水平的意義和價值。讀者如果感興趣，還可以在此基礎上提出更多好的測試策略，不斷完善這個案例的測試用例設計。

測試用例設計的精益求精除了多創造測試方法外，還有另一個很重要的領域--在測試用例設計規范上追求精益求精。筆者曾見過不少測試用例由于寫得過于草率和簡單，導致執行測試的人在工作時壓力非常大，需要花費很大的精力和時間來啃測試用例中描述的真實含義。請大家不要誤認為這只是因為我們中國測試起步晚，才有這樣的現象。筆者曾見過兩家歐美頂尖電信設備公司老外工程師寫的測試用例，其測試方法過于簡單，測試步驟描述基本沒有，基本上每個執行這些測試用例的中國工程師都叫苦連天。

你說這些歐美企業沒有規范的流程嗎？可他們是CMMI5（軟件能力成熟度模型集成模型5級）都過了的，這些測試用例也是經過了每一個需要評審的流程才正式進入測試用例庫的。那為什么這些外國人寫的用例方法如此簡單？因為測試流程和測試規范只關注測試用例的骨架是否完成，而附著在骨架上的肌肉狀況，則很難由流程來規范和考評。這樣有的老外就偷懶，用一句簡單的句子就描述完了一個測試方法，給后來者帶來了極大的痛苦。

據筆者所知，后來在這兩家歐美企業的中國工程師一改他們的老外同事留下的弊病，在寫測試方法時，盡量做到非常詳細的文字描述，并盡可能地把所有的操作步驟和命令都補充在對應的測試步驟后面。使用這種精益求精的態度寫出的測試用例，完全可以讓任何一位測試用例執行者只看一遍測試用例即可完成測試用例的執行。測試用例設計工程師通過自己多付出些時間來完善和豐富測試用例的描述，不但大大提高了未來測試用例執行的效率，而且為公司節省了時間和成本。