一個成功軟件測試項目的經驗[1]

　　一個成功軟件測試項目的經驗[1]  項目管理　　

      本文以一個工作流測試項目為例， 總結了在測試過程中積累的經驗，探討了目前國內軟件開發企業在軟件測試過程中遇到的問題以及解決的方法。

　　測試項目背景和實施情況工作流在某公司軟件產品線中占有重要地位。

　　Workflow項目是5系列中的一個小版本，主要增加了任務代辦、任務代理、以及任務交接等功能，同時還修復了一些易用性和功能性的Bug。下面，我們大概介紹一下這個項目的實施情況：

　　● 項目規模與測試人員配置：

　　○ 項目代碼行數：5萬行

　　○ 開發人員配置：開發人員5名、實習生1名

　　○ 測試人員配置：測試設計人員1名、測試執行人員2名、實習生1名

　　● 項目測試時的系統部署情況:

　　● 測試預期與測試執行情況整個測試項目是比較成功的，項目的時間執行情況和預期的測試指標度量都比較接近。發現Bug總數和缺陷密度都達到了要求的標準。當然，測試周期的實際值比計劃值晚了兩周，原?因是在系統測試后期，為了滿足PSO部門提出的定時器需求造成了一定的延期?；仡櫿麄€項目的測試過程，我有幾點小小的感悟，愿在此和大家一起分享。

　　測試如何盡早介入

　　基于以前的測試經驗，我們也越來越認識到測試人員應該盡早介入項目的重要性。簡單地沿用測試V模型往往出現很多問題，特別是在項目進度拖延的情況下更是如此。如果測試人員一味固執地被要求嚴格按照V模型定義的標準來開展測試工作的話，則結果往往是在項目初期測試人員工作量極度不飽和(很多測試人員無所事事)，而到了項目后期，一旦項目經理決定壓縮測試時間，測試人員就不得不加班加點地工作。但是，不少朋友實踐“測試人員盡早介入”的效果并不理想，例如：

　　● 測試人員參加項目前期的各種會議，會被當作“專職的”會議記錄員。   軟件測試　

  　● 測試人員參加代碼評審，又不甚了解程序開發語言，浪費了時間其丟失了自信。那么，在這個XXX5.2 Workflow項目中我們是怎么做的呢?實際上，在項目開發初期，測試人員可以開展很多有價值的工作，例如：

　　● 評審需求文檔的正確性和可測試性;根據需求文檔整理和分析測試需求，清晰明確的測試需求是測試設計的基礎。

　　● 在開發設計過程中，根據需求文檔和設計文檔進行測試設計，測試設計方案是測試用例的保證。

　　● 和項目團隊中的集成組和開發組協?商軟件版本的編譯方式和編譯進度以及測試人員提取版本的方式和進度。

　　● 開發人員每天下午4：30之前提交所有可編譯的代碼，每天晚上進行日編譯;

　　● 開發經理根據版本穩定情況，每周提交測試申請單。

　　● 測試人員根據測試進度需要，提取測試版本。

　　● 提前準備測試環境，包括數據庫環境，操作系統和web應用服務器，以及復雜集群環境。

　　● 如果項目需要，還可以在此階段研究一下自動測試工具，包括一些準備外包測試的工作。根據產品的成熟度調整測試策略開發測試一盤棋。測試經理應該有大局觀，保持測試策略總與開發的進展相一致，保證最終的軟件成果最佳(而不是測試部發現Bug數最多)。在這個XXX5.2 Workflow項目過程中，我們合理制定了不同階段的測試策略，收到了很好的效果。

　　產品開發期同情的測試

　　要忍!要在這個能夠發現大批Bug的黃金時段學會做減法。就現實而言，這個階段的產品，大多難以滿足系統測試的條件。如果進行窮兵黷武式的測試，無疑會加重開發人員的焦慮心情，甚至對測試產生逆反心理。另一方面，測試工作不應停滯，特別是不少測試人員對產品的了解還流于皮毛，抓緊時間進行“測試練兵”非常有必要。因此，“產品開發期”的測試切忌生硬。其實，此時程序人員也知道產品還不成熟，所以要告訴測試執行人員：

　　● 這個階段不要提交界面簡單錯誤和易用性方面的Bug(可以先記錄下來到項目末期提交)，否則會使開發人員質疑測試人員只會發現簡單的Bug。

　　● 換位思考，了解此時開發人員最關心的是功能是否能正確運行，多對基本功能進行測試。

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