---
tags: 學習筆記, 效能
---
測試是什麼？有什麼用嗎？
=============================

## 功能面的測試

### V Model


#### 需求分析(Requirement Analysis)

需求分析階段是專案定義階段中的第一個階段，此階段要分析用戶的需要，整理出系統的需求(功能需求)。

此階段著重的是建構出要實現的理想系統，但不用決定軟體的設計方式。一般而言，此階段會和用戶進行需求訪談。

##### 角色

- User/BA：提出需求的角色。
- SA：要去分析釐清需求的苦命人。

##### 產出物

- SA 文件
- 各種與使用者討論的信件往來、會議紀錄
- ~~瘋掉的 SA 屍體~~

#### 系統設計(System Design)

系統設計是系統設計師根據用戶需求文件，分析並理解要開發系統的業務流程的階段。

此階段會列出要實現用戶需求需要的技術以及可能性。若有些用戶需求不可行，會反應給用戶，針對此需求的最後處理方式也會列在用戶需求文件中。

##### 角色

- SA：把整理分析好的需求給 SD。
- SD：理解 SA 的需求，設計成可以動的系統。

##### 產出物

- SD 文件
- ERD 等各種實體圖
- DD 文件(數據字典)
- ~~被時程壓瘋的 SD~~

#### 架構設計(Architecture Design)

這個階段會設計計算機系統結構及軟體架構，也稱為高階設計。

選擇架構的基準是應該可以實現所有模組的列表：

- 模組的簡單機能
- 介面關係
- 相依性
- 資料庫
- 資料庫表
- 架構圖
- 技術細節等

##### 角色

- SD：與架構師共同討論整個系統的全貌。
- 架構師：從軍火庫中挑選出最適合的產品。

#### 模組設計(Module Design)

模組設計階段也稱為低階設計。

會將設計的系統拆解為較小的單元或是模組，也會說明每一部份的內容，讓程式設計者可以直接寫程式。

低階設計文件或是程式規格書會包括模組的邏輯細節，可能會以偽代碼的方式表示。

##### 角色

- SD：依據 SA 文件，跟架構師決定好的架構設計。
- 資深 PG：：依據 SA 文件，跟架構師決定好的架構設計。

##### 產出物

- SD 文件
- 資料庫表，其中有所有的元素、型態以及大小。
- 完整應用程式接口程式的介面細節
- 所有相依性的議題
- 錯誤訊息列表
- 模組的所有輸入及輸出
- ~~被時程壓瘋的 IT~~

#### 程式開發(Coding)

##### 角色

- PG：毫無反應，就是塊會 Coding 的肉。

##### 產出物

- 有效率的程式
- 會動的程式
- ~~不知道幹嘛用的程式~~
- ~~壞掉的程式~~
- ~~瘋掉的 PG~~

### 系統開發與測試的分隔線

#### 單元測試(Unit Testing)

單元測試計劃的目的是要消除程式碼層級及單元層級的錯誤。

單元是程式中可以獨立存在的最小程式體，例如程式模組。單元測試是驗證最小的程式體在和其他程式隔離的情形下，是否可以正常運作。

##### 角色

- PG

##### 任務目標

- Mock 其他功能，只關注自己的 Method(確保自己開發的程式正確)

#### 整合測試(Integration Testing)

整合測試會驗證這些獨立創建、獨立測試過的模組是否可以共存，互相交換訊息。

##### 角色

- QA
- SD

##### 任務目標

- 確認功能是否正確運作(是否有預期的輸出，是否有正確地進行 DB 讀寫)
- 關注的是實現功能的各個模組，而非 User 實際使用的功能。
- 驗證帳號是否已被註冊
- 產生帳號
- 註冊帳號

#### 系統測試(System Testing)

系統測試不同於單元測試及整合測試，系統測試計劃會由用戶的團隊來進行。

系統測試會確保所開發的軟體符合預期的需求，會測試整個軟體的機能、相互依存以及通訊。

##### 角色

- SA

##### 任務目標

- 以使用者的角度測試各個功能是否有正確運作(各個模組之間的關係是否正確)
- 建立帳號
- 登入

#### UAT(User Acceptance Test)

用戶驗收測試會在用戶的環境下進行，設法模擬實際產品的環境，也會使用實際的數據。

##### 角色

- BA或是使用者

##### 任務目標

- 整個系統的情境，各個功能互相之間的關係
- 未建立帳號前是否可以登入
- 建立帳號
- 是否能用剛剛建立的帳號登入

## 非功能面的測試

### 效能測試

使用者或使用者代表提出的非功能性需求，應該要有個驗收的標準。
例如：交易最晚三秒鐘要完成

- 要考慮三秒鐘指的是最常用的功能或是最複雜的功能
- 是在怎樣的情境下的效能(一百人使用、五百人使用)

### 負載測試

目的是要確認系統在持續的忙碌中是否能如常的運作。
例如：不間斷每秒 100 筆交易持續 7 天

- 測試系統的穩定性
- 可能找出的問題
- Memory Leak 或是其他各種資源不足：持續不斷的運行，可以暴露出系統中是否有資源被持續占用無法釋放。
- DB 資料量多與少會明顯的影響到交易速度
- 根據問題(各種資源監視器)找出效能瓶頸並考慮提升的辦法
- CPU
- 記憶體
- DB

### 壓力測試

目的是找出系統的上限，到達哪種程度系統會開始出現狀況。
例如：逐漸提升交易量，每小時一百筆->每小時兩百筆->每小時三百筆。
確認系統開始出現問題時，每小時的交易量及資源使用狀況，以考量交易巔峰時的處理方案。

### 效能

對於系統來說有許多的資源指標，
這些指標不單純指硬體，也包含許多不同的設定，
他們分別影響到系統的不同表現，且互相關聯。
因此效能出現問題應該先觀察出**瓶頸落在哪**。

- CPU：具體影響到交易效能，當效能變慢會導致一筆交易本來一秒可完成，現在變成要兩秒甚至三秒，進一步導致同時需要被處理的交易數量持續上升，許多資源被占用無法釋放。
- 硬碟：每一筆 Log 的紀錄都會消耗硬碟 I/O，需要適時的考量這些 Log 的必要性。
- DB Connection(或其他任何網路 I/O)：也許 CPU、記憶體都充足，但系統本身設定的 DB Connection 只有五條，因此不管你 CPU 跑多快，記憶體有多大，最多能同時處理的交易數量也有限，必須不斷的排隊等待 DB 連線。
- Thread：一個超人高速的處理交易或是很多個人慢慢地處理
- 記憶體