軟件測試用例的設計
一個測試用例,就是設定輸入數據,運行被測試函數,然后判斷實際輸出是否符合預期。輸入數據是測試用例的核心,輸入數據的定義是:被測試函數所讀取的外部數據及這些數據的初始值。
1、自動測試工具的選擇
目前通過使用自動化工具對于軟件的質量進行保障已經司空見慣,我們可以通過在測試中應用自動化工具來大幅度提高軟件測試的效率和質量。常用的白盒測試自動化工具有Telelogic公司的Logiscope軟件、Compuware公司的DevPartner軟件和IBM公司的Rational Purify等;而黑盒測試工具主要有IBM公司的Rational系列如TeamTest、Robot,Com-puware公司的QACenterm等。
2、測試用例中輸入數據的選擇
用一定的規則選擇有代表性的數據作為輸入數據,主要有三種:正常、邊界、非法輸入,每種輸入還可以分類,也就是平常說的等價類法,每類取一個數據作為輸入數據,如果測試通過,可以肯定同類的其他輸入也是可以通過的。下面舉例說明:
(1)正常輸入
例如字符串的Trim函數,功能是將字符串前后的空格去除,那么正常的輸入可以有四類:前面有空格;后面有空格;前后均有空格;前后均無空格。
(2)邊界輸入
例中空字符串可以看作是邊界輸入。再如一個表示成績的參數,它的有效范圍是0-100(百分制),那么邊界輸入有兩個:0和100。
(3)非法輸入
非法輸入是正常取值范圍以外的數據,或使代碼不能完成正常功能的輸入,如上例中表示成績的參數,小于0或大于100都是非法輸入,再如一個進行文件操作的函數,非法輸入有這么幾類:文件不存在;目錄不存在;文件正在被其他程序打開;權限錯誤。單元測試與代碼編寫是“一體兩面”的關系,編碼時對上述三種輸入都是必須考慮的,否則代碼的健壯性就會成問題。
在設計測試用例時,應當包括合理的輸入條件和不合理的輸入條件。合理的輸入條件是指能驗證軟件的輸入條件;不合理的輸入條件則是指異常的、臨界的、可能引起問題異變的條件。用不合理的輸入條件測試軟件能核實軟件的容錯能力和完全性,往往比合理的輸入條件能發現更多的錯誤。
3、預測輸出結果
合理設計測試用例,適當選擇測試方法完整的測試用例不但需要測試的輸入數據,而且需要對應這些輸入數據的預期輸出結果。
在使用白盒測試時,最理想的情況是希望能夠執行到每條路徑,但由于軟件需求的不完整性、軟件邏輯路徑的組合性、輸入數據的大量性及結果多樣性等因素,哪怕是一個極其簡單的程序,要想窮盡所有邏輯路徑,所有輸入數據和驗證所有結果是非常困難的一件事情。在這里我們舉一個簡單的例子。
#include <jostrcan。h> void main( ) { int a,b,c,t,I; cout<<”input x,y,z”<<endI; cin>>x>>y>>z; if (x>y) {t=x;x=y;y=t;} if(x>z) {t=x;x=z;z=t;} if(y>z) {t=y;y=z;z=t;} cout<<”the result is:”< <x< <y< <z< <endi;} |
這個例子基本上保證了每條路徑至少被執行了一次,代碼中沒有循環,只有三個if語句,它就是代碼中的多路徑源,共形成了6條路徑,如表1所示。
表1 三個if語句形成的6條路徑
條件 | If | If | If | 結果 |
x>y x<y x< >z x<z y>z y<z | x< >y | x<y | y< >z | x<y x>z x<z x<z x<y<z x<y<z |
為了測試這些數據,必須組織6組數據,每組數據測一條路徑。請看表2的測試套和期望結果。
表2 6組數據的測試套和期望結果
輸入 | 第一步 | 第二步 | 第三步 | 期望結果 |
5,4,6 4,5,6 6,5,4 5,6,4 4,6,5 6,4,5 | 4,5,6 4,5,6 5,6,4 5,6,4 4,6,5 4,6,5 | 4,5,6 4,5,6 4,6,5 4,6,5 4,6,5 4,6,5 | 4,5,6 4,5,6 4,5,6 4,5,6 4,5,6 4,5,6 | 4,5,6 4,5,6 4,5,6 4,5,6 4,5,6 4,5,6 |
4、妥善保留全部測試用例
軟件測試開發過程中,一定要做好測試用例的保存工作,這樣在測試人員發生變動或者開展回歸測試時會減少許多工作。我們在在程序改良或者Bug改正后需要重新測試時,就避免大量的枯燥乏味的重復工作,從而在提高測試效果的同時也相應的節省了軟件開發成本。
5、測試用例設計的誤區
在確定測試用例設計目標時,一些項目管理人員強調測試用例“越詳細越好”。這種做法和觀點最大的危害就是耗費了很多的測試用例設計時間和資源,可能等到測試用例設計、評審完成后,留給實際執行測試的時間所剩無幾了。因為當前軟件公司的項目團隊在規劃測試階段,分配給測試的時間和人力資源是有限的,而軟件項目的成功要堅持“質量、時間、成本”的最佳平衡,沒有足夠多的測試執行時間,就無法發現更多的軟件缺陷,測試質量更無從談起了。