產品測試過程總結

MILY: 宋體">測試規模

功能測試規模：

319 個測試用例。

非功能測試規模：

  測試過程各類活動的工作量

測試過程回顧

4 月初，測試組開始和開發組接觸。測試組先閱讀了產品的相關文檔，同時也通過從其他渠道了解產品的信息。之后測試組和開發組進行了初步溝通，確定如下問題：產品架構；測試的大致范圍；產品性能要求；測試環境；提交第一個介質的時間；工作交互的人員接口。由于產品的相關文檔所能提供的信息有限，測試組要求開發組提供了一個產品的臨時演示環境，以使測試組能夠更好的學習這個產品。

4 月 10 號左右，測試組完成初步的測試計劃，開始編寫產品的測試用例。測試用例的編寫工作用了 2 周左右的時間（ 2 名測試人員完成）。測試用例編寫完成時，測試計劃經多次調整后，也在 4 月底定稿，相關人員對測試計劃進行了評審。

4 月 25 日，開發組正式提交產品的第一個測試版本。這個版本沒有制作安裝程序，需要通過手工進行部署。測試組要求開發組下一個版本必須提供安裝程序。第一個版本提交后，測試組認為其中一個功能設計過于復雜，和開發組討論這個問題。開發組認為目前設計比較合理，待收到用戶的實際反饋后再做決定。測試組在第一輪測試過程中發現 260 個 bug ，占 bug 總數的 28% 。

開發組在提交第二輪測試的介質時，提供了正式的安裝程序。由于其他來源的意見，開發組對測試組原來提出修改意見的部分進行了調整（降低了操作的復雜度），測試組據此調整了相應的測試用例。測試組在第二輪測試過程中發現了 163 個 bug ，占 bug 總數的 17% 。

由于測試組發現系統在進行全文檢索時結果不正確，開發組在提交的第三輪測試介質中，修改了系統后臺進行全文檢索信息的設計策略。這個修改是后臺處理的變化，對系統前端沒有產生影響。測試組在第三輪測試過程中，發現 96 個 bug ，占 bug 總數的 10% 。

在第四輪測試過程中，測試組發現 140 個 bug ，占 bug 總數的 15% 。

截至到第四輪測試結束，測試組共發現 659 個 bug ，占最終 bug 總數的 70% 。由于前線對產品需求比較緊急，第四輪測試結束后，經過評審，發布了產品 的 β 版本。

下面是 產品 各輪測試所產生 bug 的數量圖：

圖 3 － 1 各輪測試 bug 數量

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

產品 β 版本發布后，測試組除了進行常規的功能測試外，開始進行自動化測試編碼、文檔測試、各個環境的安裝卸載測試工作。

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

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

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

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

到了產品測試的最后階段，主要進行以下幾項工作：
  性能測試

后期提供功能的測試；

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

性能測試。性能測試的數據準備花費了不少時間，用2天多時間才完成測試數據的準備 。在性能測試過程中，發現和改進了系統中存在的3個性能問題�，F在感覺，本次 產品 的性能測試進行的有些晚， 應該提前到beta版本發布后就開始著手進行，這樣可以盡早發現問題，盡早解決。

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

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

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

還有一個問題應該引起重視——測試組和開發組溝通協調的問題。首先，信息應該對稱。測試人員要站在用戶的角度考慮問題，但測試人員又高于一般的用戶，所以產品的相關信息，測試組需要充分了解。其次，變更的控制，這里主要指的是開發組對產品變更的控制，從產品內部設計的變更，到界面上一個 GUI 元素的位置變化，在每輪測試提交介質前，建議開發組能提交一個變更清單。測試組這邊則可以根據清單相應的進行測試用例、自動化測試腳本的更新。

關于對這個 產品 測試過程的總結，就是以上這些內容。