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