測試用例設計的價值與誤區
測試用例是一系列特定的軟件行為,用于驗證軟件的某特定功能、檢查軟件能否正確處理某種出錯行為、或者檢查其他一些軟件質量衡量的屬性 (如性能、安全、可靠性等)。 一個測試用例是一個正式的文件或記錄,描述了測試活動是怎樣具體執行的。測試用例設計的目的就是發現缺陷,但是測試用例的用處遠遠超出發現缺陷。
測試用例文檔的一些好處如下:
1、歷史借鑒:測試用例的存在要遠遠超過產品發布。持續工程(Sustained engineering)以及產品未來版本的負責人往往需要借用測試用例來了解測試過什么,以及是如何測試的。測試用例文檔和一個有組織的儲存系統對長期支持或修訂產品的一部分是至關重要的策略。----注----為了便于后來者對于測試用例的使用和借鑒,測試用例設計要盡量描述準確、步驟清晰。
2、測試進展跟蹤:通過測試用例文檔,可以跟蹤一些額外的屬性,如測試用例的執行數目,測試用例的通過或失敗數目,以及每個功能領域的測試用例總數。 ----注----在測試用例管理系統中要準確且實際地描述用例的執行結果,包括其他必填的屬性,便于分期人員從各個屬性和維度進行測試過程分析。
3、可重復性:好的測試用例文檔可以由任何人在任何時候執行。這同樣適用于自動和手動的測試用例。重復準確地執行同樣的測試對重現步驟或檢測回歸是至關重要的。 ----注----測試用例的描述要準確、全面,要能保證除自己以外的測試人員能正確理解和執行該用例。
測試用例文檔也有缺點:
1、建立文檔的時間:如果建立測試用例文檔的時間比運行測試用例所需的時間還長,建立測試用例文檔也許就沒有意義了。經常有這樣的情況,即測試用例只需要在一個單一的環境下執行寥寥幾次。 ----注----但是從測試用例價值的角度來考慮,建立測試用例文檔卻是個不可裁剪的過程。但是,這個缺點會隨著用例設計的熟練程度的提高以及用例設計平均時間成本的減小而逐漸減弱。
2、功能變化引起測試用例過期:建立測試用例所需的時間很可能因功能經常變化而增加,以至于失去控制。如果測試用例的功能領域變化頻繁,建立測試用例文檔就不一定是明智的。這種場景之一是嘗試寫測試用例以驗證用戶界面組件。 ----注----功能需求或者設計和實現的變化常常導致測試用例需要調整和修改,甚至有時候修改用例的時間會超過新建用例的時間。因此,在用例設計過程中,保持與設計、開發人員的密切溝通,及時了解功能變化的情況十分必要。否則后期再修改用例的時間成本很大。當然,在軟件開發后期,軟件需求和設計盡量保持穩定是最合適的。
3、很難設想讀者的知識:寫測試用例的人往往極為熟悉被測試的功能。這些人常犯的錯誤是在測試用例中使用術語或縮寫,而將來運行測試用例的人很可能看不懂這些測試用例。出現這種情況出現時,測試用例已不再能準確地重復,測試用例也失去了這關鍵屬性之一。 ----注----為了用例便于后來者正常使用該用例,用例設計應盡量避免使用只有自己熟悉的專業詞匯和縮寫詞,或者存在用例描述太簡潔但自己能理解的情況。
測試用例設計的誤區
創建好的測試用例是一個困難的過程。即使一個錯誤就可以毀掉測試用例的意圖。一些易出問題的領域如下:
1、步驟缺乏: 匆忙建立的測試用例或假設測試用例的一些步驟會被執行而未將它們包括在測試用例里是非常常見的錯誤, 它造成不能準確地重復。----注----必要的用例步驟不能省,避免在執行用例的時候出現描述不清導致模棱兩可的情況發生,從而影響案例執行進度。
2、太多細節: 雖然提供具體和足夠的信息很重要,不必要的字詞或冗長的解釋,會使測試用例難以遵循。僅需包含足夠的信息以便精確地運行測試用例。 ----注----太多的細節描述會增加案例設計的成本,適可而止即可。
3、行話太多: 不要以為運行測試用例的人(包括產品技術支持和持續工程)都知道所有你寫的縮略語,代號和縮寫。闡明任何對整個產品生命周期有價值和必要的信息。 ----注----同上缺點3的注釋。
4、不明確的通過/失敗標準: 如果運行測試后,不清楚測試是否通過或失敗,那測試用例是毫無用處的。----注----測試用例的預期結果一定要準確和清晰。對于測試后存在不符合預期結果的情況,即可判斷為失敗,全部符合預期結果則為成功。
posted on 2014-09-26 10:06 順其自然EVO 閱讀(164) 評論(0) 編輯 收藏 所屬分類: 測試學習專欄