# 測試計劃書

## 1.簡介
#### 測試計畫將測試方法傳達給團隊成員, 計畫內容包含目標，範圍，時間表，風險和方法。並將清楚地確定測試交付物將是什麼以及在範圍之內和之外的範圍。

### 1.1 目的
#### 依劇各專案或產品<font color=#0000FF>目的、特性、以及交付性質</font>來決定專案和產品的特性方針、以確認專案或產品的品質如預期交付給客戶。

### <div id='scope'>1.2 範圍</div>
基於客戶提供的文件以及當下現有的專案或產品系統，進行初步的了解，並分析專案及產品系統的功能以及測試所需的含蓋範圍。提供一個初步測試計畫書， 其中會說明測試的範圍、功能、及項目，並與客戶做確認(參考如下) 。客戶可以以下項目， 決定是否成為該次測試範圍之一。
* 建立測試案例
* 手動執行測試案例
* 產生自動化程式 (Robot Framework + python) (Cypress + JavaScript)
* 回歸測試 (Regression Testing)
* 驗證問題 (Bug verification)
* 壓力測試 (Performance testing)
* 效能測試 (Stress testing)
* 多國語系測試 (Localization)
* 負面測試 (Negative Testing, e.g. 連不到資料庫或者外部使用者無法連到網站…等)
* 多瀏覽器測試 (e.g Chrome, Firefox, Edge, safari…)
* 手機測試 (e.g. Apple, Android)

### 1.3 角色和責任

| 角色 | 負責工作 |
| ---------|-------- |
| * 專案經理<br> * 開發工程師 <br> * 品保主管| 1.負責提供相關文件 <br> 2.提供現有的專案或產品系統 <br>3.提供測試(品保)人員所需測試資料
| 測試(品保) 人員 | 依照測試範圍進行，並產出<font color=#0000FF>測試報告</font>

### <div id='scope1'>1.4 前置作業 及 預期的測試執行</div>
此章節主要目的是在於確認測試（品保）人員在測試前， 若需要設置環境，則提前準備測試環境。 以及理解客戶所提供的文件和系統環境能夠正常瀏灠。
在測試當中, 若遇到因為系統錯誤, 或者對於功能/系統 行為有不理解的地方，客戶端需要能夠回覆測試者的疑問。 若測試者無法得到相關資訊， 則會導致某些測試案例無法往下執行

### 1.5 測試前的驗收標準
此章節列出測試前需要通過的測試案例，否則開發人員需要發佈／修改新版本。若可提供穩定測試環境， 則可忽略此章節

## 2.測試方法與環境

### 2.1方法
測試方法會依照客戶所選擇的測試範圍 (<a href="#scope">參考1.2範圍</a>) 以及提供測試時間來做規劃。 主要目的是要盡量建立出含蓋所有功能的測試案例。
建立功能測試案例的方法分成：等類分割、邊界值分析、因果圖、與決策表等四類。（參考: [軟體動態測試](https://chenfuguo.gitbooks.io/fundamentalsoftwaretesting/content/DynamicTesting/Dynamic_Testing.html/)
以上方法會在依照實際專案或產品系統狀況，來採用那些方法可應用在開立測試案例。

### 2.2 測試環境
會依照測試者手邊有的測試機器來做測試。若客戶有其他需求，會在前置作業(<a href="#scope1">參考1.4前置作業及預期的測試執行</a>) 準備，以便進行相關測試工作。

### 2.3 測試管理工具和問題追蹤
* 測試管理工具：主要目的在於建立及管理測試案例。(建議使用工具: Test Rail),主要內容包含
* 標題
* 測試步驟
* 預期結果

* 問題追蹤：主要目的在於在測試過程中， 若發現有任何問題， 則可將問題上到系統並做持續追蹤。(建議使用工具：VIP)
* 主要內容包含
* 測試環境
* 問題標題
* 問題描述
* 預期結果
* 實際結果

<font color=red>**</font>若客戶端本身己經有測試管理工具或者問題追蹤管理系統，將資訊傳遞給測試（品保)人員，以便作業。

## 3.測試時程與交付事項
此章節會依照測試的範圍、系統複雜度、以及測試案例個數…等去做整體評估，並與客戶做個溝通協商而做最後決定。
基本上會交付:
* 測試計畫
* 測試案例
* 測試報告
剩餘的項目(如自動化程式, 壓力測試, 效能測試….等) 會依照客戶是否有採用(購買) 此服務來決定是否需要交付這些項目的文件以及程式碼。

## 4. 測試案例、問題優先順序、及問題嚴重程度
測試案例以及問題可分成優先順序與嚴重程度，此分類在測試環節是重要是一環。若在時間以及資源有限情況下， 可依照優先順序以及嚴重程度進行測試以及解決問題。
* 測試案例的優先順序定義

| 優先順序 |優先等級 | 優先順序的描述 |
| -------- | -------- | -------- |
|P1 |重要 |此類測試案例必須先執行， 若此類型的測試案例執行失敗，會造成使用者無法使用，甚至嚴重影響到客戶。|
|P2|中等|該測試用例是為了確保功能已穩定並且必須在可行的情況下運行。但用戶可能會遇到錯誤訊息。
|P3|次等|在時間允許，可以進行這些測試。若時間緊迫下，則不必完成這些測試。此類的測試案例發生錯誤時，對客戶影響不

* 問題優先順序定義

| 優先順序 | 優先等級 | 優先順序的描述 |
| -------- | -------- | -------- |
| P1 | 緊急 | 需要立即修復，此問題讓使用者無法繼續使用，必須立馬修復發佈新版本。 |
|P2 |高度 |此問題不會防礙測試，但會影響到某些主要功能讓測試者中斷測試。可以修復於下個版本。|
|P3 |中等 |此問題不會防礙測試，但會影響到次要功能使用。可以修復於下個版本|
|P4 |低 |此問題屬於文字上錯誤, 可於日後修改|
|P5 |建議 |建議事項，專案內部成員決定是否需要修正。無需立即修改。|

* 問題嚴重程度定義

|嚴重順序 | 嚴重等級 | 嚴重順序的描述 |
| -------- | -------- | -------- |
| S1 | 緊急 | 系統產生此等問題時，會造成系統損壞、資料異常(如數劇丟失)、或文件遺失等情況而需深入調查原因或重啟伺服器等。 |
|S2|高度 |主要系統功能因某些原因， 導致測試者無法繼續執行下去。例如：功能不足、錯誤訊息不足或者不清楚。此嚴重程度是可以利用某些方式讓測試者繼續往下執行，但此方式只是暫時性。但利用其他方式往下執行是存在相對困難度。|
|S3| 中等|功能上不能正常運作， 但可以使用其他方式讓測試者順利往下執行。|
|S4|低 |文件或者文字上的錯誤|

## 5. 測試案例描述
此章節在測試者會依據目前對於專案或產品系統的了解, 列出大方向的功能和測試案例。
描述的內容：
* 類型：正反向測試案例 (Positive or Negative)
* 測試優先順序 (P1~P3)
* 類型 (UI or Functions)
* 標題 (Title)