軟件開發(fā)過程中常用的軟件測試方法

1、軟件開發(fā)過程中常用的軟件測試方法2010-3-29 10:09:22 作者：佚名一、目前項(xiàng)目中所使用的測試方法我目前所在的項(xiàng)目中（目前項(xiàng)目是一套C/S架構(gòu)的系統(tǒng)），所使用的 軟件測試方法為:單元測試，集成測試，功能測試，回歸測試，驗(yàn)收 測試。下面就上面的三種 軟件測試方法,分別做一下說明：（1）單元測試這個(gè)步驟主要是開發(fā)者針對開發(fā)過程中，程序內(nèi)部的函數(shù)、類、變量等等數(shù)據(jù)進(jìn)行正確性的測試。開發(fā)人員根據(jù)需求， 在經(jīng)過詳細(xì)設(shè)計(jì)之后，開始著手編寫代碼。一般情況下，每完成一個(gè)函數(shù)（類、變量）之后，就要進(jìn)行單元測試，以驗(yàn)證編寫的函數(shù)能完成詳細(xì)設(shè)計(jì)說明 中的功能。舉個(gè)例子：一個(gè)函數(shù)需要把一些重要的數(shù)據(jù)插入到

2、數(shù)據(jù)庫中。那在編寫完這個(gè)函數(shù)之后，就要進(jìn)行測試，以驗(yàn)證函數(shù)能正確帶出需要插入數(shù)據(jù)庫的數(shù)據(jù)變量帶出的數(shù)據(jù)可以正確 的插入需要插入的數(shù)據(jù)庫。在上述測試通過之后，再接著按照詳細(xì)設(shè)計(jì)說明進(jìn)行接下來的開發(fā)工作。（2）集成測試集成測試是在單元測試的基礎(chǔ)上，將所有模塊按照詳細(xì)設(shè)計(jì)的要求組裝成子系統(tǒng)或系 統(tǒng)，進(jìn)行集成測試。集成測試側(cè)重于模塊間的接口正確性以及集成后的整體功能的正確性。舉個(gè)例子：等一個(gè)個(gè)函數(shù)或者功能模塊的單元測試完成之后，就需要測試這些函數(shù)或者模塊之間的整體的數(shù)據(jù)流是否正確。（3）功能測試等開發(fā)人員開發(fā)完之后就要把最后開發(fā)、測試（單元測試，整合測試）完的 requirement release

3、給內(nèi)部QA人員去做功能測試。因?yàn)殚_發(fā)人員的單元測試、集成測試 只能保證release給QA的新的requirement的開發(fā)是可以正常運(yùn)行的，執(zhí)行起來的效率是 最高的，一些基本的功能（如：數(shù)據(jù)庫操作，通信,顯示， error handing ,信息反饋 ） 可以正常使用。但是對于特定需求的業(yè)務(wù)邏輯還不能完全保證其正確性，所以需要更加詳盡的功能測試過程。在功能測試過程里，需要測試人員嚴(yán)格的按照需求說明，測試新開發(fā)的requirement是否完全符合user的要求，是否符合行業(yè)的規(guī)范，是否符合實(shí)際的操作流程和業(yè)務(wù)邏輯。(4) 回歸測試回歸測試是指在發(fā)生修改之后重新測試先前的測試以保證修改的正確性。

4、理論上，軟件產(chǎn)生新版本，都需要進(jìn)行回歸測試，驗(yàn)證以前發(fā)現(xiàn)和修復(fù)的錯(cuò)誤是否在新軟件版本上再次出現(xiàn)。根據(jù)修復(fù)好了的缺陷再重新進(jìn)行測試?；貧w測試的目的在于驗(yàn)證以前出現(xiàn)過但已經(jīng)修復(fù)好的缺陷不再重新出現(xiàn)。一般指對某個(gè)已知已經(jīng)修正的缺陷再次圍繞它原來出現(xiàn)時(shí)的步驟重新測試。(5) 驗(yàn)收測試驗(yàn)收測試是 軟件測試過程中的最后一步。這時(shí)相關(guān)的user根據(jù)需求說明文檔對系統(tǒng)進(jìn)行測試和驗(yàn)收，決定是否接收系統(tǒng)。它是一項(xiàng)確定產(chǎn)品是否能夠滿足合同或用戶所規(guī)定需求 的測試。驗(yàn)收測試的目的是確保系統(tǒng)已經(jīng)準(zhǔn)備就緒，并且可以讓最終user使用新需求中的功能。二、軟件測試工具針對上述測試過程，單元測試和集成測試都是需要 軟件開發(fā)人員

5、去控制和把關(guān)的。 一個(gè) 好的開發(fā)人員肯定也是一位好的單元測試、集成測試人員，因?yàn)樵陂_發(fā)的過程中時(shí)刻都需要進(jìn)行單元測試和集成測試。雖然單元測試有專門的測試、(需要購買相應(yīng)的license),但是我覺得在目前項(xiàng)目的 開發(fā)過程中不是非常有必要，這個(gè)在開發(fā)人員開發(fā)的時(shí)候就可以去把關(guān)卡住，不需要QA再通過相關(guān)的自動(dòng)化測試工具去做復(fù)雜的白盒測試。對于功能測試，特別針對于我們現(xiàn)在的項(xiàng)目，我們可以設(shè)計(jì)一套測試系統(tǒng)去測試每條 message處理邏輯的正確性。這個(gè)測試系統(tǒng)成立的前提條件是，我們在需求成立的時(shí)候就把相關(guān)的測試用例設(shè)計(jì)出 來，針對于目前項(xiàng)目中的 message來說，就是在send給SERVEFM體 m

6、essage的時(shí)候，就能 把相關(guān)replay的信息預(yù)知出來；這個(gè)前提條件其實(shí)完全可以做到，就是在正真開發(fā)之前先模擬一遍開發(fā)完成后的實(shí)際的需求，通過在數(shù)據(jù)庫運(yùn)行具體的sql邏輯、改變數(shù)據(jù)庫數(shù)據(jù)等等方法先把新requirement中的邏輯事前模擬一遍，然后根據(jù)模擬出來的具體值編寫測試用例。等到單元測試、集成測試完之后就運(yùn)用測試系統(tǒng)去運(yùn)行事前已經(jīng)編寫好的測試用例，如果得到的結(jié)果符合測試用例的值，那么說明這次測試時(shí)通過的。這個(gè)測試工具需要針對目前項(xiàng)目的每條message編寫不同的處理邏輯（因?yàn)槊總€(gè)message各不相同），然后匹配事前已經(jīng)定義好的測試用例來驗(yàn)證功能是否符合需求。三、幾個(gè)不能覆蓋到的地方

7、1、 因?yàn)檫@個(gè)測試系統(tǒng)只能根據(jù)message的replay值來進(jìn)行匹配驗(yàn)證，所以如果一條message的功能主要放在邏輯處理上（TP,數(shù)據(jù)庫操作 ）.而不是放在 message replay上的話，那樣就不能通過message replay的信息中得到預(yù)定的值來進(jìn)行功能驗(yàn)證。2、replay的信息量很大的話，也不能進(jìn)行驗(yàn)證。四、release的時(shí)候所遇到的問題的分析1、在release給QA之前就存在問題這個(gè)問題主要體現(xiàn)在單元測試，集成測試的時(shí)候沒有覆蓋到很多臨界數(shù)據(jù)、特殊數(shù)據(jù)。 這些臨界的數(shù)據(jù)或者需要特別處理的數(shù)據(jù)往往導(dǎo)致操作失敗或者系統(tǒng)崩潰，所以在進(jìn)行單元測試、整合測試的時(shí)候設(shè)計(jì)這些數(shù)據(jù)是很有必要的。2、QA release給user的時(shí)候存在的問題這個(gè)部分是因?yàn)闆]有把所有的操作都進(jìn)行完整的測試，沒有完全覆蓋到需求說明中的所有業(yè)務(wù)邏輯導(dǎo)致的。3、已經(jīng)修改過的錯(cuò)誤再次發(fā)生這是因?yàn)闆]有進(jìn)行回歸測試。4、最終user報(bào)需求不符合要求，使用不習(xí)慣，有很多 bug這個(gè)原因比較復(fù)雜，其