軟件測試過程模型

領測軟件測試網 測試環境針對每個測試級別，將適當的執行如下活動：      一、創建測試策略： 輸入： ·            要求硬件和軟件組件的詳細說明，包括測試工具（測試環境，測試工具數據）。 ·            針對測試和進度約束（人員，進度表）所需資源的角色和職責說明 ·            測試方法（標準） ·            應用程序的功能性和技術性需求（需求，變更請求，技術性和功能性設計文檔） ·            系統無法提供的需求（系統局限） 輸出： ·            已批準和簽署的測試策略文檔，測試計劃，測試用例 ·            需要解決方案的測試項目（通常要求客戶項目的管理層協調）   過程： ·            測試策略是關于如何測試系統XYZ的正式描述，要求開發針對所有測試級別的測試策略。測試小組分析需求，編寫測試策略并且和項目小組一起復審計劃。 ·            測試計劃應該包括測試用例和條件，測試環境，與任務相關的測試，通過/失敗的準則和測試風險評估。測試進度表將識別所有要求有成功的測試成果的任務，活動的進度和資源要求。   二、創建測試計劃/設計 輸入： ·              已批準的測試策略文檔。 ·              如果測試工具適用，自動化測試軟件和以前開發的測試腳本 ·              作為一種測試的結果（有關測試文檔的問題），測試文檔中沒有說明的問題 ·              從概要和詳細設計文檔（軟件設計，代碼和復雜的數據）中導出的對軟件復雜性和模塊路徑覆蓋的理解   輸出： ·              設計時發現的問題反饋給開發人員（軟件設計，代碼問題） ·              已批準的測試場景，條件和腳本（測試設計，用例和腳本） ·              測試數據   過程： ·              通過復審發布版本的功能需求和準備能夠更好的拆分為測試腳本的業務功能邏輯集合，準備測試場景和用例。測試將定義為測試條件，用于測試的數據和期望的結果（數據庫更新，文件輸出，報告結果等等）。將可能在應用程序中出現的既普通又異常的情況描繪為測試場景。 ·              項目開發人員將定義單元測試需求和單元測試的場景/用例。在集成和系統測試之前，開發人員同時也負責執行單元測試用例。 ·              在開發人員和客戶的協助下，測試小組將開發集成和系統測試的測試場景、用例。驗收測試用例將由客戶在項目和測試小組的幫助下開發。 ·              通過使用測試腳本執行測試場景。腳本將定義用于執行一個和多個測試場景的一系列步驟。測試腳本通常描繪在一般的系統操作中會出現的事務或過程。測試腳本包括用于測試過程或事務的特定數據。測試腳本將覆蓋多個測試場景并且包括運行/執行/周期信息。測試腳本映射需求和用于保證任何測試都是在范圍內的追溯矩陣。 ·              在測試之前，捕捉并且基線化測試數據。這些數據將作為單元和系統測試的基礎和在可控的環境下執行系統功能。為了以后的對照，一些輸出的數據也被基線化。在回歸測試時，基線化的數據用于支持以后的系統維護。 ·              為評定應用程序的就緒情況、環境和被測試的數據，應召開測試準備會議。為了指出發本版本的入口標準狀態，應創建測試就緒文檔。 三、執行測試 輸入： ·              已批準的測試文檔（測試計劃、用例、程序） ·              如果適用測試工具，自動化測試軟件和編寫好的腳本 ·              設計的變更（變更請求） ·              測試數據 ·              測試和項目組的可用性（項目人員，測試小組） ·              概要和詳細設計文檔（需求，軟件設計） ·              通過配置/構建人員能夠完全轉移到測試環境（單元測試過的代碼）的開發環境 ·              測試就緒文檔 ·              修訂文檔   輸出： ·              代碼的變更（測試修復項） ·              作為一種測試的結果（測試文檔問題），測試文檔沒有說明的問題 ·              設計時發現的問題，反饋給開發人員和客戶（需求，設計，代碼問題） ·              測試事故的正式記錄（問題跟蹤） ·              為向下一級別轉移而準備的基線化包（已測試的源代碼和對象代碼） ·              測試結果的日志和總結 ·              已批準和帶有修訂測試交付項的簽署文檔（已更新的交付項）   過程： ·              在執行階段中應召開Checkpoint 會議。(如果由需要，)每天應召開Checkpoint 會議處理和討論測試中的問題，狀態和活動。 ·              通過采用系統的手段跟進測試文檔來完成測試的執行。當執行測試程序的每一個包時，為了記錄程序的執行和測試程序找出的任何缺陷，應該將問題記錄到測試執行日志中。測試程序執行后的輸出當作測試結果。 ·              為了確定是否可以得到預期的結果，測試結果應該由適當的項目組員評估（，適合于測試的所有級別）。記錄并和軟件開發經理/程序員討論所有差異/異常，為了以后的調查和解決應該將它文檔化（每個客戶可能有不同的記錄日志和報告bug/defect的過程，通過Configuration Management (CM)小組校驗這些過程）。通過/失敗的準則用來確定問題的嚴重級別，結果記錄到測試總結報告中。 ·              根據客戶的風險評估來定義在系統測試中發現的問題嚴重級別并記錄到他們選擇的跟蹤工具中。 ·              基于問題的嚴重級別有目的的修復并提交到測試環境中。被修改的問題應進行回歸測試并將沒有問題的修復項轉移到新的基線中。在測試完成后，測試組的成員應準備一份總結報告�？偨Y報告要由項目經理，客戶，SQA和/或測試組長復審。 ·              在證實達到一個指定的測試級別后，配置經理應根據配置管理計劃中的要求整理發布的軟件組件并轉移到下一個測試級別。軟件只有在客戶正式驗收之后才可以轉移到生產環境中。 ·             測試小組在復審測試和更新的文檔中發現的測試文檔的問題。有些問題可能是由于技術性和功能性之間的不一致或修改所造成的。

文章來源于領測軟件測試網 http://www.kjueaiud.com/

TAG: 過程模型 軟件測試