二、什么叫測試用例
測試用例(Test Case)目前沒有經(jīng)典的定義。比較通常的說法是:指對一項特定的軟件產(chǎn)品進行測試任務的描述,體現(xiàn)測試方案、方法、技術(shù)和策略。內(nèi)容包括測試目標、測試環(huán)境、輸入數(shù)據(jù)、測試步驟、預期結(jié)果、測試腳本等,并形成文檔。
不同類別的軟件,測試用例是不同的。不同于諸如系統(tǒng)、工具、控制、游戲軟件,管理軟件的用戶需求更加不統(tǒng)一,變化更大、更快。筆者主要從事企業(yè)管理軟件的測試。因此我們的做法是把測試數(shù)據(jù)和測試腳本從測試用例中劃分出來。測試用例更趨于是針對軟件產(chǎn)品的功能、業(yè)務規(guī)則和業(yè)務處理所設計的測試方案。對軟件的每個特定功能或運行操作路徑的測試構(gòu)成了一個個測試用例。
三、編制測試用例
著重介紹一些編制測試用例的具體做法。
1、測試用例文檔
編寫測試用例文檔應有文檔模板,須符合內(nèi)部的規(guī)范要求。測試用例文檔將受制于測試用例管理軟件的約束。
軟件產(chǎn)品或軟件開發(fā)項目的測試用例一般以該產(chǎn)品的軟件模塊或子系統(tǒng)為單位,形成一個測試用例文檔,但并不是絕對的。
測試用例文檔由簡介和測試用例兩部分組成。簡介部分編制了測試目的、測試范圍、定義術(shù)語、參考文檔、概述等。測試用例部分逐一列示各測試用例。每個具體測試用例都將包括下列詳細信息:用例編號、用例名稱、測試等級、入口準則、驗證步驟、期望結(jié)果(含判斷標準)、出口準則、注釋等。以上內(nèi)容涵蓋了測試用例的基本元素:測試索引,測試環(huán)境,測試輸入,測試操作,預期結(jié)果,評價標準。
2、測試用例的設置
我們早期的測試用例是按功能設置用例。后來引進了路徑分析法,按路徑設置用例。目前演變?yōu)榘垂δ、路徑混合模式設置用例。
按功能測試是最簡捷的,按用例規(guī)約遍歷測試每一功能。
對于復雜操作的程序模塊,其各功能的實施是相互影響、緊密相關(guān)、環(huán)環(huán)相扣的,可以演變出數(shù)量繁多的變化。沒有嚴密的邏輯分析,產(chǎn)生遺漏是在所難免。路徑分析是一個很好的方法,其最大的優(yōu)點是在于可以避免漏測試。
但路徑分析法也有局限性。在一個非常簡單字典維護模塊就存在十余條路徑。一個復雜的模塊會有幾十到上百條路徑是不足為奇的。筆者以為這是路徑分析比較合適的使用規(guī)模。若一個子系統(tǒng)有十余個或更多的模塊,這些模塊相互有關(guān)聯(lián)。再采用路徑分析法,其路徑數(shù)量成幾何級增長,達5位數(shù)或更多,就無法使用了。那么子系統(tǒng)模塊間的測試路徑或測試用例還是要靠傳統(tǒng)方法來解決。這是按功能、路徑混合模式設置用例的由來。
3、設計測試用例
測試用例可以分為基本事件、備選事件和異常事件。設計基本事件的用例,應該參照用例規(guī)約(或設計規(guī)格說明書),根據(jù)關(guān)聯(lián)的功能、操作按路徑分析法設計測試用例。而對孤立的功能則直接按功能設計測試用例;臼录臏y試用例應包含所有需要實現(xiàn)的需求功能,覆蓋率達100%。
設計備選事件和異常事件的用例,則要復雜和困難得多。例如,字典的代碼是唯一的,不允許重復。測試需要驗證:字典新增程序中已存在有關(guān)字典代碼的約束,若出現(xiàn)代碼重復必須報錯,并且報錯文字正確。往往在設計編碼階段形成的文檔對備選事件和異常事件分析描述不夠詳盡。而測試本身則要求驗證全部非基本事件,并同時盡量發(fā)現(xiàn)其中的軟件缺陷。
可以采用軟件測試常用的基本方法:等價類劃分法、邊界值分析法、錯誤推測法、因果圖法、邏輯覆蓋法等設計測試用例。視軟件的不同性質(zhì)采用不同的方法。如何靈活運用各種基本方法來設計完整的測試用例,并最終實現(xiàn)暴露隱藏的缺陷,全憑測試設計人員的豐富經(jīng)驗和精心設計。
相關(guān)推薦:考試吧策劃:2010年軟件水平考試完全指南北京 | 天津 | 上海 | 江蘇 | 山東 |
安徽 | 浙江 | 江西 | 福建 | 深圳 |
廣東 | 河北 | 湖南 | 廣西 | 河南 |
海南 | 湖北 | 四川 | 重慶 | 云南 |
貴州 | 西藏 | 新疆 | 陜西 | 山西 |
寧夏 | 甘肅 | 青海 | 遼寧 | 吉林 |
黑龍江 | 內(nèi)蒙古 |