2010年軟考軟件評測師軟件測試的分類及方法(10)

　　需求測試用例通常是按照需求執(zhí)行的功能逐條地編寫輸入數(shù)據(jù)和期望輸出。一個好的需求用例是可以用少量的測試用例就能夠覆蓋所有的程序功能�！　≡O計測試用例檢測的是代碼和設計是否完全相符。是對底層設計和基本結構上的測試。設計測試用例可以涉及到需求測試用例沒有覆蓋到的代碼空間(例如界面的設計)。

　　代碼測試用例是基于運行軟件和數(shù)據(jù)結構上的。它要保證可以覆蓋所有的程序分支、最小的語句和輸出。

　　以上三種用例所用的數(shù)據(jù)又可分為正常數(shù)據(jù)、邊緣數(shù)據(jù)和錯誤數(shù)據(jù)。

　　*正常數(shù)據(jù)：在測試中所用的正常數(shù)據(jù)的量是最大的，而且也是最關鍵的。少量的測試數(shù)據(jù)不能完全覆蓋需求，但我們要從中提取出一些具有高度代表性的數(shù)據(jù)作為測試數(shù)據(jù)，以減少測試時間。

　　*邊緣數(shù)據(jù)：邊緣測試是界于正常數(shù)據(jù)和錯誤數(shù)據(jù)之間的一種數(shù)據(jù)。它可以針對某一種編程語言、編程環(huán)境或特定的數(shù)據(jù)庫而專門設定。例如若使用SQL Server數(shù)據(jù)庫，則可把SQL Server關鍵字(如：‘;AS;Join等)設為邊緣數(shù)據(jù)。其它邊緣數(shù)據(jù)還有：HTML的HTML;<>等關鍵字以及空格、@、負數(shù)、超長字符等。邊緣數(shù)據(jù)要靠測試人員的豐富經(jīng)驗來制定。

　　*錯誤數(shù)據(jù)：顯而易見，錯誤數(shù)據(jù)就是編寫與程序輸入規(guī)范不符的數(shù)據(jù)從而檢測輸入篩選、錯誤處理等程序的分支。

　　由于執(zhí)行測試用例的數(shù)據(jù)量巨大以及還要進行回歸測試，所以可以考慮使用自動測試工具，但提取測試數(shù)據(jù)仍要依靠編寫測試用例人員的經(jīng)驗。并且，我們還要注意到自動測試也許不能找到程序中所有錯誤，手動測試所找到的錯誤會比自動測試所找到的要多。

　　有了測試用例，我們就可以進行測試了吧?許多公司也是這樣做的，但在這里我建議大家最好要先進行代碼的審議。通過代碼審議找到的錯誤可以比測試用例測試所能找到的錯誤更加深入，并且發(fā)現(xiàn)錯誤的時間也比測試用例要早。代碼審議要以代碼標準(根各公司具體情況自行制定)為依據(jù)，一般情況下要檢查以下幾點：

　　* 代碼風格和規(guī)則審核

　　* 程序設計和結構的審核

　　* 業(yè)務邏輯的審核

　　代碼風格和規(guī)則的審核是在每個程序員完成一個模塊或類的 時候要進行編碼規(guī)范的檢查。要召開審核會議讓所有的項目組人員都參加。在會前項目經(jīng)理要做一個檢查表，以表的內(nèi)容為檢查依據(jù)，檢查表的內(nèi)容主要是檢查的要點。在審核會上項目組的每一個人員都能看到自己和其他人員的編碼問題，從而起到預防的作用。這些問題都要被解決，并且解決的結果要在審議會上被確認。

　　進行程序設計和結構的審議是因為開發(fā)工具的不同和項目時間的限制而造成設計不詳細。比較深入的設計通常是在編碼階段完成的，但由于程序人員和設計人員的經(jīng)驗是不同的，所以會出現(xiàn)很大的問題。我們引入了程序設計和結構審核來保證質(zhì)量。審核人員要有先進的技術開發(fā)經(jīng)驗。在審核之前也要一個審核列表，列出主要幾項，如：程序的概要、詳細設計。但僅局限于列表是不夠的，審議人員 還要審議程序的精巧度和具有創(chuàng)造力的方面，這只能靠經(jīng)驗而不能只靠列表中的內(nèi)容來審議。對于不同的程序員所檢測代碼的寬度和深度也是不同的。項目經(jīng)理可以根據(jù)程序員經(jīng)驗的不同制定被審議人員的寬度和深度。例如：年輕的程序員要審議所有代碼。但有經(jīng)驗的就可適當減少。

　　業(yè)務邏輯性審議必須要在代碼完成后審議。業(yè)務邏輯審議實際上是審議單元模塊的功能。這些功能是以系統(tǒng)說明為依據(jù)的。審議人員要有開發(fā)的經(jīng)驗并且對系統(tǒng)也要熟悉。審議人員通過執(zhí)行程序從而了解底層代碼的狀態(tài)。這階段的審議實際也包含了前兩種審議，因為審議者也可以通過最后的結果檢測單元模塊設計和結構的準確性。