產(chǎn)品測試過程總結(jié)

第第頁產(chǎn)品測試過程總結(jié)

319個測試用例。

非（功能測試）規(guī)模：

測試類型名稱

測試規(guī)模

國際化支持

需在進行測試的環(huán)境：

3種關(guān)系數(shù)據(jù)庫（Oracle/My（SQL）/SQLServer）；

3種應(yīng)用服務(wù)器（Tomcat、（Web）logic、Websphere）。

安裝卸載測試

需在進行測試的環(huán)境：

2種操作系統(tǒng)（Windows2000/2023）；

3種關(guān)系（數(shù)據(jù)庫）（（Oracle）/MySQL/SQLServer）；

3種應(yīng)用（服務(wù)器）（Tomcat、Weblogic、Websphere）。

文檔測試

需要進行驗證的文檔包括：

安裝手冊；

用戶手冊；

系統(tǒng)在線文檔；

產(chǎn)品介質(zhì)中的readme文件。

性能測試

共7個測試腳本，其中5個腳本需要參數(shù)化DocId。

計劃工作量(人˙天)

實際工作量(人˙天)

10

12

20

21

120

181

10

15

5

8

5

4

最初未做計劃

4

2

2

247人˙天

下面是產(chǎn)品各輪測試所產(chǎn)生bug的數(shù)量圖：

直到產(chǎn)品的第四輪測試，產(chǎn)品的部分功能，還沒有按預(yù)定的計劃提供。在產(chǎn)品β版本發(fā)布評審時，討論了這個問題，要求盡快提供功能，避免產(chǎn)品后期的風(fēng)險。但由于涉及到產(chǎn)品開發(fā)組與其他產(chǎn)品組的工作協(xié)調(diào)問題，還是決定到最后幾個版本的時再提供（事實證明，這給產(chǎn)品后期的測試，帶來了不良影響）。

產(chǎn)品β版本發(fā)布后，測試組除了進行常規(guī)的功能測試外，開始進行自動化測試編碼、文檔測試、各個環(huán)境的安裝卸載測試工作。

（自動化）測試是在第五輪測試的時候開始的。測試組做了前期部分工作，在第五輪測試開始后，測試組內(nèi)的兩名同事開始分別編寫不同模塊的測試腳本。（自動化）測試腳本完成后，能夠完成占全部功能測試執(zhí)行工作量30%左右的工作。在后期的幾輪測試中，自動化腳本起到了縮短測試周期的作用。

在實施這次測試自動化的時候，組內(nèi)的人員沒有實際的測試自動化實施經(jīng)驗，只是有一些概念上的認識。（自動化測試）是對手工測試的程序化，是開發(fā)性質(zhì)的工作。測試自動化編碼需要積累實際的經(jīng)驗，包括：腳本中變量的抽??；操作步驟之間wait時間的設(shè)置；checkpoint的選取和設(shè)置；測試組主要進行的是以下三項工作：

（性能測試）；試數(shù)據(jù)的準備、恢復(fù)；腳本的解釋及文檔說明；腳本的可維護性，等等。編寫自動化腳本，應(yīng)該作為一項基本技能來掌握，并且必須要經(jīng)過一次項目的實踐。我們現(xiàn)在實施自動化測試的很多顧慮和風(fēng)險，其實根源就在于我們自動化測試實現(xiàn)水平的限制。通過這次實踐，測試組以后在考慮怎樣實施自動化測試時會更有經(jīng)驗。

產(chǎn)品的國際化支持測試，這項工作在最初的測試計劃中沒有考慮，是在測試后期補充的。國際化支持測試，在同開發(fā)人員討論后，決定從數(shù)據(jù)庫、Web頁面顯示2個方面進行測試，選取了中國國際廣播電臺網(wǎng)站上的40多種語言進行了測試。這項測試，沒有寫到原來的測試計劃中，而是制定了單獨的計劃。這項測試工作在我們以后大多數(shù)應(yīng)用產(chǎn)品的測試中可能都會涉及到，這份測試計劃在以后可作為參考。

到了產(chǎn)品測試的最后階段，主要進行以下幾項工作：

版本更新后的完整功能測試。

性能測試。性能測試的數(shù)據(jù)準備花費了不少時間，用2天多時間才完成測試數(shù)據(jù)的準備。在性能測試過程中，發(fā)現(xiàn)和改進了系統(tǒng)中存在的3個性能問題?，F(xiàn)在感覺，本次產(chǎn)品的性能測試進行的有些晚，應(yīng)該提前到beta版本發(fā)布后就開始著手進行，這樣可以盡早發(fā)現(xiàn)問題，盡早解決。

后期提供功能的測試。在測試后期產(chǎn)品組提交了2個模塊，通過測試組的測試，發(fā)現(xiàn)這兩個模塊在功能上存在不少問題。在產(chǎn)品臨近發(fā)布的幾次迭代測試過程中，多數(shù)的bug都出自這兩個模塊或與之相關(guān)聯(lián)的模塊。這種臨近產(chǎn)品發(fā)布才提交的功能，風(fēng)險確實很大，以后對這種情況要注意。

版本更新后的完整功能測試。接近測試結(jié)束，在每次版本更新后，測試組都要進行完整的功能驗證。每輪測試，系統(tǒng)都會由于修正bug或多或少的又出現(xiàn)一些新bug。這個時候，更能體會到自動化測試帶來的好處。在產(chǎn)品的最后階段，如果是影響不大的bug，為了保證產(chǎn)品的穩(wěn)定，是否要進行修改,需要權(quán)衡。

回顧產(chǎn)品的整個測試過程，當(dāng)初制定的測試計劃，內(nèi)容是基本符合的，但實際進度比計劃延遲了32個工作日。導(dǎo)致這種狀況的原因：首先，測試組這邊在測試安排上存在問題，包括：版本更新時的工作安排不合理；某些測試工作的安排滯后（比如性能測試。測試安排的原則應(yīng)該是當(dāng)一項工作可以進行的時候，盡早盡快執(zhí)行）、對測試工作量的預(yù)測不夠準確，等等。其次，就整個過程來說也存在一些問題，包括：產(chǎn)品設(shè)計、功能的變更；產(chǎn)品部分模塊提供測試過晚；產(chǎn)品部分版本的bugreopen率比較高，等等。

還有一個問題應(yīng)該引起重視——測試組和開發(fā)組溝通協(xié)調(diào)的問題。首先，信息應(yīng)該對稱。（測試人員）要站在用戶的角度考慮問題，但（測試人員）又高于一般的用戶，所以產(chǎn)品的相關(guān)信息，測試組需要充分了解。其次，變更的控制，這里主要指的是開發(fā)組對產(chǎn)品變更的控制，從產(chǎn)品內(nèi)部設(shè)計的變更，到界面