軟件測試過程的持續改進介紹

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

1、   計劃與風險

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

測試需要做哪些工作？

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

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

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

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

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

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

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

2、   評審

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

3、   文檔

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

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

4、   方法與策略 

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

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

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

5、   總結測試經驗

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

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

6、   缺陷分析、度量

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

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

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

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

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

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

原文轉自：http://www.anti-gravitydesign.com