軟體測試過程的持續改進

Author：袁琳
MSN：testwin@sohu.com

隨著國內軟體測試行業的逐漸發展，有越來越多的軟體企業更加重視軟體測試，並已經形成了一套基本的軟體測試流程。但是軟體測試所起的作用還沒有人們期望那樣顯著，因此，就需要繼續加大投入對軟體測試的關注程度，對軟體測試過程進行持續的改進。以下是本人在工作中的一些體會，介紹軟體測試過程中需要注重和改進的幾個環節，與大家分享。

1、 計劃與風險

專案計劃對專案過程的實施有著直接的指導作用，它的重要性是不言而喻的。我經歷過一些成功的專案，給我感受最深刻的就是計劃的充分性，以及根據專案過程中遇到的各種新情況，對計劃的及時變更做出反應的能力；我也經歷過一些失敗專案，由於專案計劃的不合理或混亂無序，經常會帶來嚴重的專案風險、以及開發成本，造成專案不斷延期、產品質量無法保證。對於軟體測試來說，測試計劃也是指導後續測試工作的基礎，在測試的計劃中，不僅需要明確測試的目的、測試的資源、測試的人員等等，更重要的是需要詳細明確並估計出在整個測試活動的任務和風險，比如：

測試需要做哪些工作？

整個測試活動估計需要多少工作日？

充分估計測試計劃、測試設計、測試執行、測試分析評估這些階段分別需要多少個工作日？

估計的測試用例規模是多少？

估計的測試進度時間又如何？

在測試過程中，可能會遇到哪些方面的問題？

可能存在的風險又有哪些？等等......

只有對過程中各任務的進行更詳細的計劃，才有利於在測試過程中對專案進度的把握有一個明確的目標；同時，風險策略的制定，也有利於對及早對測試過程中可能遇到的問題做出分析，以便在問題出現時能夠儘可能的減少規避風險的成本。

2、 評審

在測試過程中的每個階段結束前，都會輸出一些資源，文件、用例 等等.，這些資源往往是下一個測 試階段或軟體開發的下一個環節執行的依據，比如：測試報告，測試人員在完成測試並提交測試報告之後，測試報告裡說明已經沒有未解決的問題了，那麼是不是就應該結束測試呢？我們又如何來保證測試報告的準確性、充分性呢？這就需要組織參與專案的一些重要成員，專案經理、開發負責人、測試經理、QA等等對測試報告進行評審。評和審是結合在一起的，每個角色根據自己對專案的瞭解，從各自角度來稽核測試報告的充分性，對質量風險發表各種見解。最終，對報告的規範性也要進行考察。評審也有會議評審、線上評審等等好幾種方式，可以根據實際專案情況，對不同的專案、不同的文件、資源採用不同的方式評審。最後一點需要補充的是，對於測試發現的問題，一般是有爭議的問題，需要有評審。對於緊急的問題，一般採用線上方式由專家裁決；另外，也最好根據實際情況組織會議評審來對一定規模的問題統一評審。

3、 文件

文件的編寫對於測試人員來說是一個十分重要的任務，深入的、充分的投入測試的測試人員能寫出高質量的測試文件。所以，測試文件的質量，往往反映了測試人員執行測試的廣度和深度。而在文件的編寫方面，首先必須形成統一規範；另外，針對不同專案的測試，可以適當對文件標題、內容進行簡化。總之，文件模板一旦形成，必須嚴格遵守。

在編寫測試文件過程中需要注意的幾個問題：文件中描述的測試資料必須準確；必須詳細描述出測試的環境；測試報告中必須詳細描述測試的充分性、測試質量評價；等等......這裡不再一一列舉。

4、 方法與策略

測試方法和測試策略，測試的重中之重。這也是我個人非常樂於思考的，方法和策略的意義在於如何用最有效的辦法、花最少的成本、在有限的資源情況下儘可能以最高的質量的完成測試專案，並根據專案中遇到的突發情況，不斷制定新的策略。

測試的策略一般要求從全域性方面對測試的階段、每個階段的測試型別進行考慮、定義，比如：需要做哪些方面的測試？測試的順序是怎樣的？功能測試如何進行？效能測試何時進行等等。而測試的方法更多是體現在一個具體的測試中，採取怎樣的測試思路。另外，在測試過程中，對資源的協調也非常關鍵，需要能保證測試資源充分利用，每個測試人員都有適度並且相當的工作量。

在以往工作中，常常會進行交叉測試，這裡予以介紹：測試往往是一個長期的重複性工作，對於測試人員來說，一個測試人員一般長期從事一種產品或一個特性的測試，長期如此，測試人員往往會出現測試反感膩味倦怠。因此，適當的採用交叉測試，讓兩個或多個測試人員相互學習對方業務領域的知識、並執行測試，既有利於減少測試人員的倦怠心裡，使測試人員有一種新鮮感，也可能發現出前測試人員未發現的問題，也起到了互相監督的作用。

5、 總結測試經驗

在測試的過程中，測試人員應該及時總結髮現的錯誤並歸類，標明經常容易出錯的地方，將意見提交專案經理，稽核後，制定出一份統一標準並提供給開發人員，這樣就可以提前避免錯誤、避免重複錯誤和重複測試，提高測試效率。不僅如此，專案結束後的各項總結報告將是專案的後期維護或二次開發的寶貴參考資料。

另外，測試過程中，也可以將自己所負責特性、產品的體會、心得寫出來，做為測試指導書，以便有新員工加入時，使其迅速上手。

6、 缺陷分析、度量

對測試活動過程中發現的缺陷進行分析、度量，尋找軟體開發過程中存在的問題，並持續改進開發過程，提高質量。缺陷的分析、度量從時間上分為兩個方面，首先是在軟體開發過程中發現的缺陷進行分析、度量；然後就是，對軟體產品釋出後，對使用者提出缺陷進行統計、分析。

對測試過程中的缺陷需要分版本，並按不同模組、問題級別，對缺陷進行各種統計，並比較子版

本統計資料之間的差異，CQ在這方面已經提供了比較強大的統計功能，這裡不再贅述。進行分析，是因為開發修改後導致該模組不穩定，引發大量新問題；還是因為前期測試出現漏測（設計漏測、執行漏測）；或者是版本合入新增需求的功能導致。然後根據問題原因，提供改進建議。下面對幾個引數進行說明：

TFVUD 是使用者發現缺陷數（ Total Field Valid Unique Defects ）：即由使用者發現的經過了確認的、非重複的、非使用者錯誤操作的、非建議型別的所有缺陷；（總數、按模組統計）

PDD 是測試發現缺陷數（ Post Development Defects ）：即在開發完成後的測試周期中發現的缺陷數，但它不包括那些向使用者釋出後發現的缺陷；（分別按模組、級別、時間 統計）

DDR是開發缺陷率（Developer Defect Ratio）：一定週期內缺陷總數與程式碼行數的比率。

Trackback: http://tb.blog.csdn.net/TrackBack.aspx?PostId=472334