軟件測試管理_第1頁
軟件測試管理_第2頁
軟件測試管理_第3頁
軟件測試管理_第4頁
軟件測試管理_第5頁
已閱讀5頁,還剩49頁未讀 繼續免費閱讀

下載本文檔

版權說明:本文檔由用戶提供并上傳,收益歸屬內容提供方,若內容存在侵權,請進行舉報或認領

文檔簡介

1、軟件測試管理軟件測試管理張三目標 與軟件企業項目管理人員、測試管理人員對測試管理進行交流。 提高對測試工作、測試管理的重要性的認識,以改進我們的測試過程。 從理論角度來認識軟件測試和測試管理。主要內容 團隊建設(組織結構、人員組成、規模、人員培訓) 過程規劃(軟件過程、測試過程、測試的階段、規劃自己的過程) 測試過程實施(計劃、設計、實施、執行、評估、缺陷跟蹤) 過程改進(成熟度模型、改進) 測試工具(一)團隊建設 測試部門的組織形式 測試組的人員組成 測試組的規模 測試人員的培訓組織形式測試人員的位置一個好的組織結構,可以更好的發揮人員的能動性,使工作更有效率,也使工作的質量更高。在一個單位

2、內測試人員處于什么位置?屬于那個部門?質量管理?開發組?測試組?適用的就是最好的。組織形式煙囪測試組 測試人員由臨時人員組成,通常有2-5人組成,直接向項目經理負責。大型的組可以劃分為幾個小組,設測試經理。項目經理負責制定測試計劃文檔。企業沒有正規的方法將測試程序、方法、相關的知識經驗傳遞下去,測試質量難以保證。優點是成本低,不需要對測試人員提供培訓、生活保障等服務。組織形式企業或項目組織結構樣例 項目組織產品組經理項目經理開發經理質量保證經理開發工程師測試人員流程經理設計經理組織形式企業或項目組織結構樣例 一種常見的組織軟件開發組織客戶服務項目管理質量管理開發規范、CMM、質量保證測試組織形

3、式企業或項目組織結構樣例 又一軟件開發組織客戶服務項目管理質量管理開發規范、CMM、質量保證測試人員組成測試組組成 測試經理:負責測試流程、溝通、測試工具的引入、人員管理、測試計劃/設計/開發及執行。 測試組長:溝通、測試工具引入、人員管理、費用/過程狀態報告、測試計劃/設計/開發及執行。 測試工程師:執行測試計劃,進行設計/開發及執行。測試組規模影響因素 企業文化或測試成熟度 測試需求范圍 工程師技能水平 測試工具及應用水平 業務知識 組織形式 測試工作介入時間測試組規模確定方法(一) 開發比例法:根據開發人員數量按照一定比例來確定測試工程師的數量。開發人員指進行設計、開發、編譯以及進行單元

4、測試的人員。測試組規模確定方法(二) 百分比法:根據測試人員應該占到項目組中人員的百分比數量。測試組規模確定方法(三) 測試程序法:根據測試程序數量,以及每個程序可能的執行時間,計算出人小時,再根據完成周期計算測試組規模。測試組規模確定方法(四) 任務計劃法:根據歷史記錄中類似項目工作量,比較新項目同歷史項目的工作量,歷史項目乘以相應的因子。 步驟:先將任務分解,根據歷史記錄乘以一個因子,計算出新項目的所以任務工作量。再根據該工作量和完成周期計算測試組規模。人員培養人員要求 適應各種環境的知識背景 學習速度快 組織能力 解決問題的能力 創造性 分析/編程能力 業務領域的知識 交流與協調能力 測

5、試經驗 關注細節 書寫與語法技能一個好的測試人員一個好的測試人員更難得更難得人員培養成長的路徑 初級測試工程師測試工程師高級測試工程師測試組負責人測試負責人測試經理產品/業務經理。 技術技能:測試工具測試自動化編程編程語言操作系統網絡、數據庫測試生存周期 (1-2年)年) 測試過程:評審、制訂和改進過程,指導初級工程師工作,了解業務領域。 (3-4年)年) 測試組工作:任務安排、跟蹤和報告,監管測試工程師,掌握測試周期支持工具。(4-6年)年) 項目管理:管理項目,與客戶交流,管理測試人員。(6-12年)年) 產品管理:項目或產品研發指導、促進產品銷售、確定業務機會、承擔盈虧責任。(12年以上

6、)年以上)(二)測試過程規劃 軟件過程 測試過程 測試的階段 規劃測試過程軟件過程定義 目的:測試過程是軟件過程的組成部分,明確自己的軟件過程,才能明確自己的測試過程。 軟件生存周期指軟件從出現一個構思之日起,直到最后決定停止使 用之時止。包括可行性與計劃研究、需求分析、設計 、實現 、測試、運行與維護等階段。 軟件過程是指開發和維護軟件及相關產品(如項目計劃、文檔、代碼、手冊等)的一套行為、方法、實踐及變換過程。軟件過程是軟件生存周期的框架。軟件過程常見軟件過程與模型(一) 瀑布模型、原型模型、演化模型、增量模型、螺旋模型、噴泉模型等等。 敏捷方法(如XP、功能驅動等) 統一過程(RUP)

7、GB/T 8566-2001 信息技術 軟件生存周期過程 過程裁減 7 .生 存 周 期 組 織 過 程 5 .生 存 周 期 基 本 過 程 合 同 視 圖 5 .1 獲 取 過 程 招 標 準 備 啟 動 合 同 準 備 和修 訂 驗 收 和 完 成 監 督 供 方 5 .2 供 應 過 程 啟 動 準 備投 標 簽 定合 同 編 制計 劃 實 施 和控 制 交 付 和完 成 評 審 和評 價 工 程 視 圖 5 .3 開 發 過 程 軟 件 需求 分 析 軟 件 結構 設 計 軟 件 詳細 設 計 軟 件集 成 軟 件 鑒定 測 試 系 統 需求 分 析 系 統 結構 設 計 系 統集

8、成 系 統 鑒定 測 試 過 程實 施 軟 件安 裝 軟 件 驗收 支 持 軟 件 編 碼 和 測 試 運 作 視 圖 5 .4 運 作 過 程 過 程實 施 運 行測 試 系 統運 行 用 戶支 持 5 .5 維 護 過 程 過 程實 施 修 改實 施 移 植 問 題 和 修改 分 析 維 護 評 審/ 驗 收 軟 件 退 役 6 .生 存 周 期 支 持 過 程 6 .1 文 檔 編 制 過 程 6 .2 配 置 管 理 質 量 管 理 視 圖 6 .3 質 量 保 證 過 程 6 .4 驗 證 過 程 6 .5 確 認 過 程 6 .6 聯 合 評 審 過 程 6 .7 審 核 過 程

9、6 .8 問 題 解 決 過 程 7 .2 基 礎 設 施 過 程 管 理 視 圖 7 .1 管 理 過 程 啟 動 和 范 圍 定 義 執 行 和 控 制 評 審 和 評 價 結 束 規 劃 7 .3 改 進 過 程 7 .4 培 訓 過 程 過 程 建 立 過 程 評 估 過 程 改 進 各 項 活 動 的 位 置 順 序 并 不 意 味 時 間 順 序 。 開 發 過 程 中 的 活 動 名 稱 并 不 是 開 發 階 段 的 名 稱 。 軟件過程常見軟件過程與模型(二) 敏捷方法中的測試:在極限編程中提出測試驅動開發。提倡在開發前,先考慮測試,先完成測試用來和代碼。 統一過程中的測試:

10、測試是其核心工作流程之一 GB/T 8566-2001標準中的測試(如下圖): 沒有單獨的測試過程。 測試開始于編碼。 不足以指導測試工作。測試過程測試生命周期 維護 需求定義應用定義應用開發 修訂 建立 建立執行. 執行執行.測試計劃缺陷跟蹤測試開發測試設計評估測試過程幾個亮點 測試工作開始于需求分析之后。 測試經過評估后,達到了結束的標準后才能結束。 測試也是迭代過程。 測試需求來自于軟件需求。測試過程活動 計劃 設計 準備 執行 評估 缺陷跟蹤測試過程與開發過程的關系 都是軟件過程的有機組成部分。 與開發過程同步進行。 與開發過程相互依賴,又相互獨立。 開發過程、測試過程、項目管理過程以

11、及其他支撐過程相互交織共同組成了軟件過程。測試階段V模型測試階段四個階段 清晰直觀 階段劃分 單元測試 集成測試 系統測試 驗收測試 同開發的對應關系測試階段甄別 開發和測試并不是線性關系。 測試工作不是開始于代碼完成之后。 測試具有階段性,但各階段之間沒有鴻溝。尤其是單元測試和集成測試。規劃測試過程 分析項目總體需求(概覽) 分析項目特點(如類型、規模、人員、客戶、風險、進度、成本等等) 確定自己的軟件過程 確定自己的開發方法和模型 規劃測試階段 構建測試過程(三)測試過程實施 制訂測試計劃 設計測試 測試準備 執行測試 評估測試結果 缺陷跟蹤制訂測試計劃定義 什么是測試計劃:測試計劃測試計

12、劃包含項目范圍內的測試目的和測試目標的有關信息。此外,測試計劃還將確定實施和執行測試時所使用的策略以及所需資源。測試計劃包括測試主計劃和階段計劃。 項目開始時制訂測試主計劃。根據開發的迭代過程和測試主計劃對測試計劃進行細化,制訂各個階段的測試計劃。 制訂測試計劃內容 1. 簡介(目的、背景、范圍、使用的文檔) 2. 測試需求(確定被測試的對象、內容和范圍,來源于用戶需求,包括功能性需求和非功能性需求。) 3. 測試策略 測試的項目、測試的主要方法、完成標準、使用的工具、特殊事項等) 4. 資源(人員組成、任務和職責、環境、人員培訓等) 5. 項目進度表(階段) 6. 可交付工件(測試模型、測試

13、記錄、缺陷報告等等) 7. 附錄 A:項目任務制訂測試計劃步驟(一) 確定測試需求:確定測試對象以及測試工作的范圍和內容。測試需求應是可核實的。測試需求可來源于軟件需求列表、用例、用例模型、用例實現、補充規約、設計需求、商業理由、法規、標準、最終用戶訪談以及對現有系統的復審。 被確定的測試需求項必須是可核實的。即,它們必須有一個可觀察、可評測的結果。無法核實的需求不是測試需求。 制訂測試計劃步驟(二) 評估風險:測試工作需要平衡資源約束和風險,以確定測試的優先級。從三個方面分析: 影響:失效后將造成的影響或后果 原因:失效所導致的非預期結果 可能性:用例失效的可能性 根據風險分析情況,確定測試

14、執行的優先級。通常分為高、中、低三種。進而安排測試的先后順序。制訂測試計劃步驟(三) 制定測試策略:描述測試活動的一般方法和目標。包括測試的階段、類型、技術、測試完成的標準、特殊要求、可能存在的影響等。 確定資源 人力資源(人員數量和技能) 測試環境(包括硬件和軟件) 工具 數據 創建時間表:估計測試工作,制訂時間進度。參考軟件開發進度、項目工作計劃等。 生成測試計劃 :復審相關材料,確定交付的內容,將計劃提交相關的人員。制訂測試計劃主計劃和階段計劃 階段計劃的測試需求應是對主計劃中的測試需求的分解。 階段計劃的工作進度安排應盡可能同主計劃相一致。 階段計劃的制訂應能保證主計劃能夠完滿執行。測

15、試設計(一) 分析程序工作流程。目的在于確定并說明系統與外部交互時的操作和步驟。以進一步用于確定與描述測試用例。 確定并說明測試用例 詳細分析應用程序工作流程與操作步驟。 確定并說明測試用例 確定測試用例數據測試設計(二) 確立并結構化測試執行過程 確定本測試執行過程與其他測試執行過程(或生成的測試腳本之間)的關系或順序。 確定本測試執行過程的起始條件/狀態與結束條件/狀態。 指明本測試執行過程(或生成的測試腳本)要執行的測試用例。 結構化的方式固化測試執行過程。測試設計(三) 復審并評估測試覆蓋 確定測試覆蓋評測方法:基于代碼覆蓋和基于需求的覆蓋。基于代碼覆蓋的方法只有在代碼完成后才能進行。

16、 生成測試覆蓋報告測試準備 記錄、生成或通過編程創建測試腳本 確定軟件設計與實施模型中的專用于測試的功能。 建立外部數據集 樁模塊與驅動模塊設計 執行前的準備工作執行測試 單元測試和集成測試時有開發人員的參與可能更有效,但應避免開發人員測試自己的程序。 驗收測試應由測試組、用戶和相關的專家完成。 測試的執行應該遵循如下的過程:設置測試環境,執行測試過程,核實測試結果,評估測試的執行情況。評估測試結果 分析測試結果并提交變更請求 評估基于需求的測試覆蓋 評估基于代碼的測試覆蓋 分析缺陷 確定是否達到了測試的完成標準和成功標準 生成測試評估摘要 缺陷跟蹤 缺陷等級(嚴重、主要、次要、輕微等)與優先

17、級(高、中、低等)分類 缺陷修改應遵循一定的流程(提交任務分配修改回歸測試) 缺陷趨勢分析 不易修改的缺陷的處理配置管理主要實現軟件版本控制和軟件變更管理測試過程中形成的文檔、用例、數據、測試用程序等也存在配置管理的問題應和開發中的配置管理共同進行,并互相關聯。過程改進測試能力成熟度模型初始 階段定義 集成 管理與度量優化、缺陷預防和質量控制過程改進測試能力成熟度等級一 無序 測試和調試沒有區分 測試只在編碼后進行 無專業的測試人員/沒有測試工具 測試的目的是為了證明軟件和系統能夠正常工作。過程改進測試能力成熟度等級二 將測試同調試區分開來 測試是編碼后的一個已定義的階段 具有基本的測試方法和技術以及標準的測試過程 測試的目的是為了確認程序能夠滿足要求過程改進測試能力成熟度等級三 測試分布于軟件的整個生命周期 有固定的測試組織(能夠提供人員培訓、監督和控制測試過程、引入自動化測試工具) 基于系統需求進行測試 管理層已認識到測試是一項專業性的活動過程改進測試能力成熟度等級四 測試是一個可測量和量化的過程 產品的質量特性如可靠性、可用性、可維護性等都被測試 測試用例被良好

溫馨提示

  • 1. 本站所有資源如無特殊說明,都需要本地電腦安裝OFFICE2007和PDF閱讀器。圖紙軟件為CAD,CAXA,PROE,UG,SolidWorks等.壓縮文件請下載最新的WinRAR軟件解壓。
  • 2. 本站的文檔不包含任何第三方提供的附件圖紙等,如果需要附件,請聯系上傳者。文件的所有權益歸上傳用戶所有。
  • 3. 本站RAR壓縮包中若帶圖紙,網頁內容里面會有圖紙預覽,若沒有圖紙預覽就沒有圖紙。
  • 4. 未經權益所有人同意不得將文件中的內容挪作商業或盈利用途。
  • 5. 人人文庫網僅提供信息存儲空間,僅對用戶上傳內容的表現方式做保護處理,對用戶上傳分享的文檔內容本身不做任何修改或編輯,并不能對任何下載內容負責。
  • 6. 下載文件中如有侵權或不適當內容,請與我們聯系,我們立即糾正。
  • 7. 本站不保證下載資源的準確性、安全性和完整性, 同時也不承擔用戶因使用這些下載資源對自己和他人造成任何形式的傷害或損失。

評論

0/150

提交評論