如何建立測試計劃?(示例模板,示例)
測試計劃
測試計劃是一個完整的文件,概述了實現軟體測試所需的測試策略、目標、時間表、估算、交付成果和資源。測試計劃幫助我們確定確認被測應用程式質量所需的工作量。測試計劃是作為定義過程進行軟體測試操作的藍圖,測試經理對其進行密切監控和控制。
根據 ISTQB 的定義,“測試計劃是一個詳細說明預期測試活動範圍、策略、資源和時間表的文件”。
讓我們來看一個測試計劃的示例/場景:你想在會議上與團隊成員討論測試計劃,但他們卻對此不感興趣。
在這種情況下你會怎麼做?
我是經理,請按照我的指示執行。
現在,讓我解釋一下為什麼需要測試計劃。
什麼是測試計劃以及它為什麼重要?
建立測試計劃文件有幾個好處。
幫助測試團隊以外的人員瞭解測試的細微差別,例如開發人員、業務經理和客戶。
我們的思考受到測試計劃的指導。它類似於必須遵循的一套規則。
測試計劃記錄重要的功能,例如測試估算、測試範圍和測試策略,以便管理團隊可以對其進行評估並在其他專案中重複使用。
編寫測試計劃的最佳方法是什麼?
您已經知道,測試管理流程中最基本的任務是建立測試計劃。要根據 IEEE 829 構建測試計劃,請遵循以下七個步驟。
檢查專案。
建立測試策略
建立測試目標列表。
指定測試標準
組織資源
構建測試環境
估算和計劃
建立測試交付成果
步驟 1 - 檢查專案
如果您不知道產品是什麼,如何測試它?答案是不可能的。在評估產品之前,您必須首先了解有關它的所有資訊。
測試產品是一個電子商務網站。您應該對您的客戶和終端使用者進行調查,以瞭解他們對應用程式的需求和期望。
誰將是網站的目標受眾?
它的目的是什麼?
它將如何運作?
產品使用了哪些軟體和硬體?
瀏覽此網站並檢視產品文件。檢視產品文件可以幫助您瞭解網站的所有功能以及如何使用它。如果您有任何疑問,您可以採訪客戶、開發人員或設計師以獲取更多資訊。
步驟 2 - 建立測試策略
在軟體測試中,確定測試策略是建立測試計劃的重要步驟。測試策略文件是一個高級別文件,通常由測試經理建立。本文包含以下定義 -
專案的測試目標和實現這些目標的方法
確定用於測試的時間和金錢數量。
回到您的專案,您需要為銀行網站建立測試策略。應遵循以下步驟 -
步驟 2.1 - 定義測試範圍
在開始任何測試活動之前,應確定測試範圍。您需要考慮一段時間。
定義要測試的系統“在範圍內”的元件(硬體、軟體、中介軟體等)。
還必須明確將不會測試的系統元件表徵為“超出範圍”。
為所有利益相關者定義測試專案的範圍至關重要。您將受益於擁有精確的範圍。
讓團隊中的每個人都對您正在執行的測試充滿信心並獲得準確的資訊。
團隊中的每個人都會知道正在測試什麼以及什麼沒有被測試。
您使用什麼標準來定義專案的範圍?
您必須 - 確定範圍。
客戶規範非常具體。
專案預算
產品規格
您的測試團隊的能力和才能
現在應明確定義測試的“在範圍內”和“超出範圍”。
根據軟體需求,專案僅專注於測試網站的所有功能和外部介面(在範圍測試)此時不會執行壓力、效能和邏輯資料庫測試。(不在本文件範圍內)
問題示例
客戶已要求您測試他的 API。但是,專案預算不允許這樣做。在這種情況下你會怎麼做?在這種情況下,您需要說服客戶,Api 測試是額外的工作,需要花費大量時間和資源。提供證據來支援您的說法。告訴他,如果將 Api 測試包含在範圍內,預算將增加 XYZ。
客戶同意,並建立了新的範圍和超出範圍的物件。
功能測試和 API 測試是在範圍內的示例。
資料庫測試、硬體和任何其他外部介面都不在範圍內。
步驟 2.2 - 確定測試型別
測試型別是一個常規的測試過程,它會產生可預測的測試結果。每種型別的測試都旨在查詢產品中的特定型別的問題。但是,所有型別的測試的目標都是相同的:“在將產品釋出給客戶之前儘早發現任何問題。”
下圖顯示了經常使用的多種測試形式 -
單元測試
API 測試
整合測試
系統測試
安裝/解除安裝測試
敏捷測試
對於軟體測試,有大量的測試型別可供選擇。您的團隊將無法以適當的努力處理所有型別的測試。作為測試經理,您必須優先考慮測試型別。
在 Web 應用程式測試中,應優先考慮哪種型別的測試?
為了節省資金,應該跳過哪種型別的測試?
步驟 2.3 - 記錄風險和問題。
風險是不可預測的未來事件,有可能發生並且存在損失的可能性。當危險發生時,它就變成了“問題”。
您之前在文章風險分析和解決方案中瞭解了“風險”分析並確定了專案中可能存在的危險。
您將在 QA 測試計劃中記錄這些風險。
| 風險 | 緩解措施 |
|---|---|
| 團隊成員缺乏網站測試所需的技能。 | 為您的團隊計劃培訓課程以提高他們的技能。 |
| 專案時間表非常緊湊;按時完成這項工作將很困難。 | 為每個測試活動建立測試優先順序。 |
| 測試經理是一個糟糕的經理。 | 經理應該接受領導力培訓。 |
| 缺乏協作會導致員工生產力下降。 | 鼓勵每個團隊成員完成他們的任務,並激勵他們更加努力地工作。 |
| 成本超支和預算估計錯誤 | 在開始工作之前,定義範圍,密切關注專案計劃,並定期跟蹤和衡量進度。 |
步驟 2.4 建立測試後勤
測試經理應在測試後勤中回答以下問題 -
誰將進行測試?
測試何時進行?
誰將進行測試?
雖然您可能不知道將執行測試的測試人員的確切身份,但可以識別測試人員的型別。
在為特定任務選擇合適成員時,您必須檢查他的專業知識是否合格並估算專案預算。
如果將錯誤的人員分配給任務,專案可能會失敗或延遲。
具有以下能力的人員最適合進行軟體測試 -
能夠理解客戶的觀點
對卓越的強烈熱情,以及對細節的敏銳觀察力和合作意願。
測試人員是專案中負責測試執行的團隊成員。您可以根據專案預算選擇內部測試人員或外包測試人員。
測試何時進行?
相關的開發工作必須與測試活動關聯。
當您擁有附圖中顯示的所有元素時,就可以開始測試了。
步驟 3 - 定義測試目標
測試執行的最終目的和成果稱為測試目標。測試的目的是發現儘可能多的軟體缺陷,並確保在釋出產品之前,被測產品沒有錯誤。
您應該執行以下兩個步驟來確定測試目標。
列出所有需要測試的程式方面(功能、效能、GUI 等)。
根據上述特徵定義測試的目標或目的。
讓我們使用這些步驟來弄清楚您的測試專案的測試目標是什麼。
您可以使用“自頂向下”技術來查詢需要測試的網站方面。使用此策略,您可以將被測程式分解為元件和子元件。
根據上面列出的功能,專案的測試目標可以定義如下 -
檢查網站的功能(帳戶、存款等)在真實的業務環境中是否按預期工作,並且沒有錯誤或缺陷。
檢查網站的外部介面,例如 UI,是否正常執行,以及它是否滿足使用者的需求。
檢查網站的可用性。這些功能是否可能對使用者有用?
步驟 4 - 定義測試標準
測試方法或測試判斷可以基於稱為測試標準的標準或規則。以下是兩種型別的測試標準
暫停標準
定義測試的關鍵暫停條件。如果在測試過程中滿足暫停條件,則活動測試周期將被中斷,直到解決暫停標準。
測試計劃示例 - 如果您的團隊成員指出 40% 的測試用例失敗,則應停止測試,直到開發團隊修復所有失敗的例項。
退出標準
它描述了確定測試階段是否已成功完成的標準。退出標準是測試的預期結果,在進入開發的下一階段之前必須滿足這些標準。例如,所有關鍵測試用例必須在 95% 的時間內透過。
確定退出標準的兩種方法是確定目標執行率和透過率。
執行率是指執行的測試用例數量與測試規範中測試用例總數的比率。例如,測試規範要求總共 120 個 TC,但測試人員僅完成了 100 個,導致執行率為 100/120 = 0.83。(83%)
透過率是指透過的測試用例數量與執行的測試用例數量的比率。例如,在執行的 100 多個 TC 中,有 80 個 TC 透過,導致透過率為 80/100 = 0.8(80%)。
步驟 5 - 組織資源
資源計劃是完成給定任務所需的所有資源的綜合列表。資源包括人力資源,以及執行工作所需的裝置和材料。
資源計劃是測試計劃的一個重要方面,因為它有助於確定專案將需要的資源(員工、裝置等)數量。因此,測試經理可以建立準確的專案計劃和估算。
本節列出了建議用於專案的資源。
人力資源管理
下表顯示了專案團隊的幾個成員。
| 序號 | 成員 | 任務 |
|---|---|---|
| 1 | 測試經理 | 監督整個專案。 定義專案的總體目標。 獲取必要的資源 |
| 2 | 測試人員 | 識別和表徵合適的測試方法、工具和自動化架構 審查和評估測試方法 執行測試、跟蹤結果並報告任何缺陷。 根據專案預算,測試人員可以是內部的,也可以是外包的。 為了節省專案的成本,我建議對低技能任務使用外包人員。 |
| 3 | 正在接受測試的開發人員 | 執行測試用例、測試程式和測試套件等。 |
| 4 | 測試管理員 | 建立和維護測試環境及其資產。 支援測試人員將在測試環境中執行測試。 |
| 5 | SQA 成員 | 負責質量保證。 檢查測試過程是否符合規範。 |
系統資源
您應該計劃如下表所示的測試 Web 應用程式的資源 -
| 序號 | 資源 | 描述 |
|---|---|---|
| 1 | 伺服器 | 安裝測試 Web 應用程式。 如果適用,這包括單獨的 Web 伺服器、資料庫伺服器和應用程式伺服器。 |
| 2 | 測試工具 | 測試工具的目的是自動化測試、複製使用者操作和生成測試結果。 您可以為此專案使用各種測試工具,包括 Selenium、QTP 等。 |
| 3 | 網路 | 為了模擬真實的企業和使用者環境,您將需要一個包含 LAN 和網際網路的網路。 |
| 4 | 計算機 | 人們經常用來連線到 Web 伺服器的計算機 |
步驟 6 - 計劃測試環境
什麼是測試環境?
測試環境是在測試團隊將執行測試用例的軟體和硬體配置。測試環境包括真實的業務和使用者環境,以及伺服器和前端操作環境等物理環境。
如何建立測試環境?
回到您的專案,您如何為這個電子商務網站建立測試環境?
完成此任務需要測試團隊和開發團隊之間良好的協作。
為了完全理解正在測試的 Web 應用程式,您應該向開發人員詢問一些問題。以下是一些需要考慮的問題。當然,如果需要,您可以詢問其他問題。
此網站可以處理的最大併發連線數是多少?
此網站安裝的硬體和軟體要求是什麼?
使用者的機器訪問網站是否需要任何特殊設定?
步驟 7 - 計劃和估算
在文章測試估算中,您已經使用了各種方法來估算完成專案所需的工作量。您現在應該將該估算以及時間表新增到測試計劃中。
假設您將整個專案分解成小的任務,並在測試估算階段包含每個任務的估算,如下所示。
| 任務 | 成員 | 估算工作量 |
|---|---|---|
| 建立測試規範。 | 測試設計人員 | 170 個工時 |
| 執行測試 | 管理員和測試人員 | 80 個工時 |
| 測試報告 | 測試人員 | 10 個工時 |
| 測試交付 | 20 個工時 | |
| 總計 | 280 個工時 |
之後,您制定一個完成這些任務的計劃。
在專案管理中,通常使用“制定時間表”這個詞。測試經理可以使用在測試計劃中建立的可靠時間表作為監控專案進度和控制成本超支的工具。
測試經理需要以下資訊來建立專案時間表
員工和專案截止日期 - 工作日數、專案截止日期和資源可用性都是影響時間表的一些因素。
專案估算:測試經理根據估算了解完成專案需要多長時間。因此,他將能夠建立適當的專案時間表。
瞭解專案風險使測試經理能夠在專案計劃中分配足夠的時間來應對風險。
步驟 8 - 測試交付物
測試交付物是指所有必須生成和維護以支援測試工作的文件、工具和其他元件的列表。
軟體開發生命週期的每個階段都有自己的一套測試交付物。
在測試過程之前提供測試交付物。
包含測試計劃的文件。
包含測試用例的文件
測試設計規範
在測試期間提供測試交付物。
測試指令碼
模擬器
測試資料
測試追溯矩陣
錯誤日誌和執行日誌
測試資料:在測試周期完成後提供測試交付物 -
測試報告/結果
缺陷報告
安裝/測試程式指南
釋出說明
資料結構
網路
關係資料庫管理系統
作業系統
Java
iOS
HTML
CSS
Android
Python
C 程式設計
C++
C#
MongoDB
MySQL
Javascript
PHP