軟體測試過程模型

2021-04-13 13:51:24 字數 3479 閱讀 5429

本篇文件是來自「中國軟體測試時代」,娟子收錄,以備學習之用

針對每個測試

級別,將適當的執行如下活動:

一、建立測試策略:

輸入:·   要求硬體和

軟體

元件的詳細說明,包括測試

工具

(測試環境,測試工具

資料

)。·   針對測試和進度約束(人員,進度表)所需資源的角色和職責說明

·   測試

方法

(標準)

·   應用

程式

功能

性和技術

需求

(需求,變更請求,技術性和功能性

設計

文件)·   系統無法提供的需求(

系統

侷限)輸出:

·  已批准和簽署的測試策略文件,測試計畫,測試

用例

·  需要

解決方案

的測試專案(通常要求客戶專案的

管理

層協調)

過程

:·   測試策略是關於

如何

測試系統xyz的正式描述,要求

開發

針對所有測試級別的測試策略。測試小組

分析

需求,編寫

測試策略並且和專案小組一起複審計畫。

·   測試計畫應該包括測試用例和條件,測試環境,與任務相關的測試,通過/失敗的準則和測試風險評估。測試進度表將識別所有要求有成功的測試成果的任務,活動的進度和資源要求。

二、建立測試計畫/設計

輸入:·   已批准的測試策略文件。

·   如果測試工具適用,

自動化

測試軟體和以前開發的測試指令碼

·   作為一種測試的結果(有關測試文件的

問題

),測試文件中沒有說明的問題

·   從概要和詳細設計文件(軟體設計,

**

和複雜的資料)中匯出的對軟體複雜性和模組路徑覆蓋的理解

輸出:·   設計時發現的問題反饋給開發人員(軟體設計,**問題)

·   已批准的測試場景,條件和指令碼(測試設計,用例和指令碼)

·   測試資料

過程:·   通過複審發布版本的功能需求和準備能夠更好的拆分為測試指令碼的業務功能邏輯集合,準備測試場景和用例。測試將定義為測試條件,用於測試的資料和期望的結果(

資料庫

更新,檔案輸出,報告結果等等)。將可能在

應用

程式中出現的既普通又異常的情況描繪為測試場景。

·   專案開發人員將定義

單元測試

需求和單元測試的場景/用例。在整合和系統測試之前,開發人員同時也負責執行單元測試用例。

·   在開發人員和客戶的協助下,測試小組將開發整合和系統測試的測試場景、用例。驗收測試用例將由客戶在專案和測試小組的幫助下開發。

·   通過

使用

測試指令碼執行測試場景。指令碼將定義用於執行乙個和多個測試場景的一系列步驟。測試指令碼通常描繪在一般的系統操作中會出現的事務或過程。測試指令碼包括用於測試過程或事務的特定資料。測試指令碼將覆蓋多個測試場景並且包括執行/執行/週期資訊。測試指令碼對映需求和用於保證任何測試都是在範圍內的追溯矩陣。

·   在測試之前,捕捉並且基線化測試資料。這些資料將作為單元和系統測試的基礎和在可控的環境下執行系統功能。為了以後的對照,一些輸出的資料也被基線化。在回歸測試時,基線化的資料用於支援以後的系統維護。

·   為評定應用程式的就緒情況、環境和被測試的資料,應召開測試準備會議。為了指出發本版本的入口標準狀態,應建立測試就緒文件。

三、執行測試

輸入:·    已批准的測試文件(測試計畫、用例、程式)

·    如果適用測試工具,自動化測試軟體和編寫好的指令碼

·    設計的變更(變更請求)

·    測試資料

·    測試和專案組的可用性(專案人員,測試小組)

·    概要和詳細設計文件(需求,軟體設計)

·    通過配置/構建人員能夠完全轉移到測試環境(單元測試過的**)的開發環境

·    測試就緒文件

·    修訂文件

輸出:·    **的變更(測試修復項)

·    作為一種測試的結果(測試文件問題),測試文件沒有說明的問題

·    設計時發現的問題,反饋給開發人員和客戶(需求,設計,**問題)

·    測試事故的正式記錄(問題跟蹤)

·    為向下一級別轉移而準備的基線化包(已測試的源**和物件**)

·    測試結果的日誌和總結

·    已批准和帶有修訂測試交付項的簽署文件(已更新的交付項)

過程:·    在執行階段中應召開checkpoint 會議。(如果由需要,)每天應召開checkpoint 會議

處理

和討論測試

中的

問題,狀態和活動。

·    通過採用系統的手段跟進測試文件來完成測試的執行。當執行測試程式的每乙個包時,為了記錄程式的執行和測試程式找出的任何缺陷,應該將問題記錄到測試執行日誌中。測試程式執行後的輸出當作測試結果。

·   為了確定是否可以得到預期的結果,測試結果應該由適當的專案組員評估(,適合於測試的所有級別)。記錄並和軟體開發經理/程式設計師討論所有差異/異常,為了以後的調查和解決應該將它文件化(每個客戶可能有不同的記錄日誌和報告bug/defect的過程,通過configuration management (cm)小組校驗這些過程)。通過/失敗的準則用來確定問題的嚴重級別,結果記錄到測試總結報告中。

·   根據客戶的風險評估來定義在系統測試中發現的問題嚴重級別並記錄到他們選擇的跟蹤工具中。

·   基於問題的嚴重級別有目的的修復並提交到測試環境中。被修改的問題應進行回歸測試並將沒有問題的修復項轉移到新的基線中。在測試完成後,測試組的成員應準備乙份總結報告。總結報告要由專案經理,客戶,sqa和/或測試組長複審。

·   在證實達到乙個指定的測試級別後,

配置

·   測試小組在複審測試和更新的文件中發現的測試文件的問題。有些問題可能是由於技術性和功能性之間的不一致或修改所造成的。

軟體測試過程模型

軟體測試過程模型 下圖描繪了常見的測試過程。針對每個測試級別,如下活動將被適當的執行 一 建立測試策略 輸入 要求的硬體和軟體元件的詳細說明,包括測試工具 測試環境,測試工具資料 針對測試和進度約束 人員,進度表 而需要的資源的角色和職責說明 測試方法 標準 應用程式的功能性和技術性需求 需求,變更...

軟體測試過程模型

針對每個測試 級別,將適當的執行如下活動 一 建立測試策略 輸入 要求硬體和 軟體 元件的詳細說明,包括測試 工具 測試環境,測試工具 資料 針對測試和進度約束 人員,進度表 所需資源的角色和職責說明 測試 方法 標準 應用 程式 的功能 性和技術 性需求 需求,變更請求,技術性和功能性 設計 文件...

軟體測試過程模型 W模型

w模型 概述 又稱 雙v 模型 由evolutif公司提出,相對於v模型,w模型增加了軟體開發各階段中同步進行的驗證和確認活動。基於兩個原則 v v 盡早地和不斷地進行軟體測試 驗證 verification 主要是評估系統在功能上是否和需求定義相一致,檢驗系統在技術上是否達到一定質量標準 可靠性 ...