如何構建規范的軟件測試過程:軟件測試體系構建方法指南(3)

　　在各個測試階段確定需要多少測試人員，各需掌握那些技巧。

　　多少人做自動測試，是哪些人。

　　列出項目參與人員的聯系方式包括 E-mail 和電話。

　　3.6 相關信息保存的位置

　　測試服務器的相關信息;

　　測試文檔保存的位置;

　　測試工具保存的位置;

　　測試中需要使用的軟硬件的存放地點;

　　Bug如何記錄，存放的位置。

　　3.7 測試時間安排

　　包括主要時間點的安排，如各個測試階段的開始，截至日期，產品預計發布日期等。

　　3.8 缺陷處理

　　測試過程中可衡量的是發現的缺陷的狀況。因此缺陷的報告和管理必須寫成書面文檔。

　　3.8.1 Bug 數據庫管理

　　提示和技巧：

　　誰負責創建數據庫?

　　誰有權限增加數據庫的帳號?

　　誰有權使用哪類帳號?

　　數據庫使用過程中出了問題和誰聯系?

　　誰負責數據庫備份?

　　多長時間備份一次?

　　由誰使用數據庫?

　　缺陷管理應該與開發部門的負責人一起討論。

　　3.8.2 缺陷處理過程

　　提示和技巧：

　　解釋缺陷報告和分配過程。

　　缺陷標題、測試環境應如何填寫。

　　解釋如何輸入，解決，重新打開，關閉和重新即或一個缺陷。

　　讓測試人員清楚一個缺陷從擊活到解決的全過程。

　　缺陷必須指定由誰負責解決。

　　定義優先級、嚴重級別等。

　　在項目結束時，如何解決這些缺陷。

　　如果有Bug管理工具，只需遵照工具的流程執行。

　　3.9.測試過程控制

　　在測試過程中，通過對缺陷數據庫進行分析可以確定測試的狀態。另外，通過讓測試人員填寫測試工作周報，可以對項目進展狀況進行反饋。

　　3.9.1 缺陷數據分析

　　提示和技巧：

　　在開發過程和穩定階段是否有過多的未處理缺陷，這可能說明開發的資源不夠，或者有其它問題。

　　如何確定項目中是否有過多的缺陷。

　　測試人員是否積極發現缺陷，或者過分積極。

　　在每個時間點上，系統是否穩定。

　　系統哪些部分的缺陷最集中。

　　在系統發行時修復了多少缺陷。

　　哪些類型的缺陷最普遍。

　　3.9.2 測試工作周報

　　提示和技巧：

　　周報中應包括哪些信息。

　　如何填寫工作周報。

　　誰負責查看工作周報。

　　以上詳細的描述了，測試過程中可能遇到的或者必須提前安排的工作內容，有一些項是要在工作過程中陸續充實的，有一些是需要提前給出解決辦法的，在制定計劃過程中，請依據實際情況進行書寫。

　　4 測試計劃

　　4.1 整體測試策略

　　本節的目的是說明計劃中使用的基本的測試過程。

　　提示和技巧：

　　是否使用里程碑技術和在測試過程中驗證每個模塊?或者是什么都不做，只是普通的測試而已。

　　測試人員是否在項目開發初期就開始工作?或者測試人員只在系統開發完后，才開始測試。

　　是否明顯的界定出單元，集成，系統，驗收測試階段?

　　自動測試工作是否進行?

　　對于像壓力，性能，兼容性等的測試項目，放到那一個測試區間內，有什么質量要求?

　　4.2 測試范圍

　　通常說明什么是要測試的，什么是不要測試的是非常重要的。明確規定這些問題后，測試人員對該做什么有一個清晰的認識。

　　提示和技巧：

　　需要特別測試那些部分?

　　那些部分不需要測試，為什么?

　　測試人員是否需要測試內容以及相關部分?

　　是否要驗證每個模塊的穩定性?

　　是否有理論上應該測試的，但是測試環境無法進行測試的內容?

　　對于產品附帶的文檔，測試人員是否需要檢查?

　　4.3 質量目標

　　圍繞軟件質量，有幾種不同的說法。第一個是質量是一種絕對的標準，對所有的系統必須等同處理。事實上，質量是相對的而且是和產品相關的概念。例如，多媒體產品的質量目標傾向于精美的表示和適當的內容，而應用系統可能傾向于易用性、健壯性和適用于不同的任務。質量目標可能是動態的。在項目進行過程中，會由于市場壓力、新的機會和功能改變而重新設定質量目標。

　　另一種有關軟件質量的說法是，定義和衡量系統質量是測試部門一個部門的事。實際上，建立質量標準是所有職能部門共同努力的結果。測試、開發、系統使用部門、用戶教育、系統支撐必須為建立和維護系統的質量標準做出自己的貢獻。每個部門必須對自己最了解的部分做出相應的質量定義。例如，測試和開發部門對系統質量的衡量標準主要是健壯性和正確性。用戶部門可能對易用性方面比較熟悉。

　　最后，質量不僅是衡量系統的功能或性能是否正常。對系統來說，在開發過程中盡早建立全面的質量標準與系統的及時發布是一樣重要的。質量目標是一個強有力的工具，應該在系統開發過程中盡早建立。一個定義準確的質量目標在以后的產品開發過程中幫助決策。例如，系統是否能夠正式發行?在代碼完成后，應該修復那些缺陷?在系統完成后那種類型的測試是最合適的。

　　提示：

　　質量目標應該是一個確實可行的軟件質量描述，在確定之前應該同相關人員達成一致的意見，不要等到發貨的時候才發現大家對其的理解有分歧，這時測試人員會非常被動，在達成一致意見后，當開發人員和測試人員有分歧時，可以使用質量目標作為衡量的標準。

　　4.4 測試計劃

　　一般情況下測試活動大致分成四個部分：單元測試，集成測試，系統測試，驗收測試。下面具體介紹一下測試計劃的書寫方法，工作過程中可以依據實際情況進行刪減和補充。

　　4.4.1 單元測試

　　單元測試是代碼一級的測試，主要依賴于開發人員進行。

原文轉自：http://www.kjueaiud.com