AAA系統android應用V1.0.0測試計劃
版本控制
版本號 日期 作者 審覈人 說明
V1.0
目錄
產品v1.0.0測試計劃模板 1
1 項目簡介部分 2
1.1 文檔編寫目的 2
1.2 測試項目背景描述 2
1.3 測試工作內容和範圍 2
2 測試文檔 2
2.1 測試所需參考文檔 2
2.2 測試需提交文檔 3
3 測試安排和計劃 3
3.1 項目整體計劃 3
3.2 測試工作量評估 5
3.3 測試資源安排 5
3.3.1 人力資源分工 5
3.3.2 測試環境安排和使用 6
3.3.3 所需的合作方配合 6
3.3.4 測試所需工具 7
4 風險預估和應對 7
5 冒煙測試測試方案 8
6 功能測試方案 9
6.1 測試規範 9
6.2 測試需求分析和策略制定 9
6.2.1 分功能測試需求分析 9
6.2.2 測試工具需求 10
7 性能測試方案[可裁減]—根據項目情況而定，不需要可刪除第7節 10
7.1 性能測試工具需求 10
7.2 場景名xxx1 11
7.2.1 場景概述 11
7.2.2 執行策略設計 11
7.2.3 測試數據需求 11
7.2.4 性能測試結果分析方法和預期 12
7.3 壓力測試場景設計 12
7.3.1 場景名XXX 12
1項目簡介
1.1編寫目的
AAA系統android應用測試方案目的，確定現有項目的信息和應測試的軟件構件。列出推薦的測試需求（高級需求）。推薦可採用的測試策略，並對這些策略加以說明。確定所需的資源，並對測試的工作量進行估計。預估項目的風險和成本，對制定應對措施。列出測試項目的可交付元素]
1.2背景描述
對測試對象（應用程序、模塊、子模塊、系統等）及其開發設計目標進行簡要說明。需要包括的信息有：主要的功能和性能、測試對象的構架以及項目的簡史、測試對象的設計開發初衷和目標。
1.3內容和範圍
[AAA系統android應用測試階段：需求評審、需求分析、測試設計、設計評審（包括用例）、冒煙測試、系統測試、迴歸測試、自動化測試、鏡像環境性能測試、驗收測試。
AAA系統android應用測試範圍：根據產品需求指定這期需要上線的功能（寫一級模塊）；
簡要地列出測試對象中將接受測試或將不接受測試的那些性能和功能。
如果在編寫此文檔的過程中做出的某些假設可能會影響測試設計、開發或實施，則列出所有這些假設。
列出可能會影響測試設計、開發或實施的所有風險或意外事件。
列出可能會影響測試設計、開發或實施的所有約束。]
2測試文檔
2.1測試所需參考文檔
下表列出了制定和實施該測試方案時所需要使用的相關文檔，並標明瞭各文檔的可用性：
[注：列表中爲文檔項，需要具化，可適當地刪除或添加文檔項。]
文檔[具體的文檔名稱和列表（版本/日期）] 已創建或可用 已被接收或已經過複審 作者或來源[角色和姓名] 備註
背景相關資料 是□否□ 是 否□
調研相關資料 是□否□ 是 否□
需求文檔 是□否□ 是□否□
概要設計 是□否□ 是□否□
詳細設計 是□否□ 是□否□
接口文檔 是□否□ 是□否□
接口測試報告 是□否□ 是□否□
產品性能要求 是□否□ 是□否□
運維部署文檔 是□否□ 是□否□
上線步驟 是□否□ 是□否□
產品總測試方案（性能） 是□否□ 是□否□
測試工具參考文檔 是□否□ 是□否□
測試報告 是□否□ 是□否□
2.2測試需提交文檔
下表列出了制定和實施該測試方案時測試所需要提交的相關文檔，並標明瞭各文檔的可用性：
[注：列表中爲文檔項，需要具化，可適當地刪除或添加文檔項。]
文檔[具體的文檔名稱和列表（版本/日期）] 已創建或可用 已被接收或已經過複審 作者或來源[角色和姓名] 備註
需求文檔、詳細設計等評審批註意見 是□否□ 是 否□
接口測試設計（接口測試報告） 是□否□ 是□否□
測試方案（性能） 是□否□ 是□否□
測試計劃 是□否□ 是□否□
測試設計 是□否□ 是□否□
測試報告（功能、性能、自動化） 是□否□ 是□否□
項目總結 是□否□ 是□否□
缺陷分析和測試設計補充 是□否□ 是□否□
缺陷記錄表 是□否□ 是□否□
3測試安排和計劃
3.1項目整體計劃
項目階段 時間段 參與人員 測試工作內容安排 產出 備註
調研階段 參與調研討論
需求評審階段 1.瞭解項目背景資料
2.閱讀mrd
3.反饋評審問題
4.參與需求評審
5.確認評審結論
6.初步評估測試計劃 評審批註反饋
初步測試計劃
詳細設計階段 1.分析產品功能，確認測試需求
2.進行測試點拆分
3.反饋評審問題
4.參與設計評審
5.確認設計評審結論
6.確定測試初步方案 評審批註反饋
測試框架
功能點拆分文檔
測試點拆分文檔
初步測試方案
測試計劃調整
開發階段 1.確定測試方案
2.確定自動化測試點
3.撰寫測試case和相關關鍵字
4.準備測試數據
5.自動生成自動化case
6.開發測試工具
7.測試方案和測試設計評審 關鍵字列表
Case書寫規範
測試case文檔
自動化case
測試工具和程序
冒煙測試階段 1.環境部署
2.冒煙測試 測試環境
冒煙測試報告
第一遍全面測試 1.執行手工測試
2.執行自動化case
3.性能測試
4.完善自動化case 手工測試結論
部分關鍵字
完善或新補充的自動化case
性能測試結果
自動化case結果
Bug迴歸測試 1.確認bug修復情況
2.執行自動化case
3.完善自動化case
4.性能測試 Bug確認結論
部分關鍵字
完善或新補充的自動化case
自動化case結果
性能測試結果
全面迴歸測試 1.執行手工迴歸測試
2.執行自動化casee
3.性能測試 測試結論和測試報告
交叉自由測試 1.PM、RD、QA交叉自由測試
2.常規檢查自動化case執行 測試結論和測試報告
上線階段 1.上線輔助
2.線上檢查
3.Bug迴歸 Bug迴歸
項目總結階段 1.相關總結；
2.Case和框架合併；
3.自動化case管理
3.2測試工作量評估
[列出產品當前版本需要實現的功能所需測試時間]
功能模塊 描述 執行人 時間 備註
[注：一、二級模塊] [每個模塊的所有功能點都實現]
[注：根據項目情況天/小時]
詳細測試計劃請參加《xx項目v0.0.0_測試計劃》文檔
3.3測試資源安排
3.3.1人力資源分工
下表列出了在此項目的人員配備方面所作的各種假定。
[注：可適當地刪除或添加角色和人員項。]
角色 人員 所推薦的投入 主要職責或註釋[需要具化]
項目負責人 80%—100% 處理插入事務
協調項目安排
分析測試需求
制定測試方案和測試計劃
負責管理文檔資料、case、程序、工具
測試全程參與
測試工程師 50%—100% 測試全程參與
分析測試需求
撰寫測試case（即自動化case）
提出關鍵字和自動化工具需求
完善補充自動化case並執行測試
測試分析和測試報告
輔助測試開發工程師 10%—30% 參與測試工作
輔助關鍵字、工具開發、執行問題修復
輔助自動化框架制定和實施
3.3.2測試環境安排和使用
[網絡硬件，如拓撲圖、硬件設備、規格、數量、配置等信息；
網絡軟件，如協議、通訊和連接方式等信息。]
下表列出了測試的系統環境
硬件環境（服務器、網絡、虛擬機等需求）
軟件環境（相關操作系統、軟件及環境配置等）
3.3.3所需的合作方配合
配合方 配合人員 希望提供的資源 希望的配合工作 配合階段 配合時間 備註
PM 人員 資源協調和推動
交叉自由測試安排 全程
RD/FE 利於測試的程序、頁面及其部署安裝文檔 分階段提供被測程序
在開發週期的後20%前提供頁面 測試設計和測試執行
XX產品QA Xx服務器的xx服務、xx數據
人員 聯調環境準備；
聯調資源提供
聯調問題輔助定位 測試執行（聯調測試）
3.3.4測試所需工具
項目中需要用到的輔助性測試工具所作的各種假定。
工具 獲取和訪問地址 用途 支持人員 備註
4風險預估和應對
下表列出了在此項目的測試工作所存在的各種風險的假定，需要考慮項目測試過程中可能發生的具體事務，分別分析並加以應對，然後體現在測試計劃中。
[注：可適當地刪除或添加風險項。]
風險類型 風險責任方 風險內容 相應處理優先級 可能發生的階段 可能發生的時間段 應對所需資源 應對措施[只是建議，需要具化] 備註
時間計劃 提測計劃延期，或者冒煙測試頻繁不通過 參考3.1.1計劃和階段 參考3.1.1計劃和階段 合理計劃
及時調整
人員風險 請假、離職、調離等意外情況 充分估計
預留buffer
及時調整
資源協調 測試數據提供補充分 充分估計
預留buffer
及時調整
插入事務 使用第三方數據或者服務器故障 預留buffer
及時調整
任務超預期 需求有較大變動 及時調整
[注：各個風險類型解釋如下。
時間計劃：關鍵milestone無法匹配的延期風險。諸如項目存在deadline、計劃受到客觀條件限制、非己方責任導致地被動延期等等；
人員風險：測試人員和需配合方的人員的變動導致的工作任務無法按計劃完成或者完成質量無法保證的風險，包括新人風險、人員變化、投入不足、投入質量不高等；
資源協調：包括所需資源不能如期到位，或者資源質量低於預期等風險。比如測試工具開發的風險、各個階段交付物的質量風險等。
插入事務：包括臨時插入高優先級的事務，打亂原有計劃等風險。
任務超預期：實際執行時的工作複雜程度、結果的質量同預期不符所帶來的風險。屬於不可預期的風險，只能待出現時及時合理地調整。
風險分爲可預期的和不可預期的，對於可預期的風險，可以要求資源，制定提前的應對措施。但是對於不可預期的風險，只能待出現時，充分考慮各方因素，及時調整。所以，對於可預期的風險，需要的能力是充分預估，對於不可預期的風險，需要的是及時察覺並調整應對。
]
5冒煙測試測試方案
[本節可根據是否做冒煙測試進行裁減]
說明准入測試中各測試內容的LIST和預期結果，其它內容可選
]
分類 測試內容（可分級描述） 輸入（可選） 操作步驟（可選） 預期結果 輔助工具（可選）
環境搭建 依據上線步驟成功搭建測試環境 環境搭建成功
功能測試 測試數據加載成功 測試輸入數據 冒煙用例 加載成功、日誌記錄準確 ***腳本
6功能測試方案
6.1測試規範
[參考文檔 《測試規範-171103.docx》]
6.2測試需求分析和策略制定
6.2.1分功能測試需求分析
[
根據測試框架中的各個部分，進行測試需求分析，確定測試內容和測試方法。
]
6.2.1.1XX功能模塊
1.主要功能描述
[
根據需求和設計，將該部分的功能做簡要描述。
]
2.測試點分析
測試點 所需迴歸的相關測試點 測試方法類型 測試方法詳述
A[依據該功能分析可以測試的點] [依據測試框架所選擇的複用case的測試點列表] 手工測試
自動化測試
自動化輔助測試
新舊版本對比測試 [描述依據測試類型而選擇的測試策略，包括需要準備的數據，需要使用的輔助工具，需要使用的自動化方法，以及需要抽象的關鍵字等等]
[注：各個測試方法類型解釋如下。
手工測試：採用人工操作，並人工觀察確認測試結果的測試方法。如無特別的創新方法，諸如數據準備和場景描述策略等，此方法可以一筆帶過。
自動化測試：使用提前準備好的自動化case完全無人工干預的測試。該方法如果需要特別的工具、關鍵字開發，需要註明。
自動化輔助測試：使用工具，將測試的部分過程，比如結果保存（抓圖）、數據上傳、結果驗證等用程序自動化實現，但是部分過程還需要人工驗證的測試。該方法可以提高部分效率，但是或許需要人工去分析嚴重結果。
新舊版本對比測試：在版本升級測試中，如果有兩套環境，可以通過同樣的輸入和操作來對比驗證結果的方式來進行測試和自動化測試，自動化測試可以使用coco2.0工具，常用與規避數據計算邏輯複雜的結果對比測試。
]
6.2.2測試工具需求
[測試工具需求的列表，可以單獨文檔進行描述]
7性能測試方案
7.1性能測試工具需求
[測試工具需求的列表，可以單獨文檔進行描述]
7.2場景名xxx1
7.2.1場景概述
[此處概要說明此場景對應的業務流程，如果多個場景業務流程一致，只是數據方面的差異，可將場景概述提前在所有場景前進行統一描述。
例如：用戶登錄系統->進入系統->退出系統]
7.2.2執行策略設計
[此處描述對於這一場景的執行策略，如併發用戶數量、重複次數、性能測試執行時間等內容，同時說明性能測試過程中重點監控的性能指標。爲便於說明，可採用如下表格的形式，例如：]
性能場景 執行策略（併發數、時長） 備註
登錄系統，進入考場 10用戶併發，登錄系統，進入系統 ，重複操作15分鐘，退出。 得到不同併發數下系統的性能指標
對系統的容量做出估計
列出測試的數據指標項有哪些，值在什麼區間內
20用戶併發，登錄系統，進入系統，重複操作15分鐘，退出。
40用戶併發，登錄系統，進入系統，退出。重複操作15分鐘
7.2.3測試數據需求
[測試數據準備需求說明]
7.2.4性能測試結果分析方法和預期
[性能測試結果分析方法和預期的整體目標]