###### tags: `軟體測試`
# 軟體測試
需求分析練習溝通
#### 需求
自己對軟體的想像&客戶對軟體的需要
需求分析

#### 設計
把整個方案規劃好，提供框架、規範與準則（設計圖）給其他參與者（團隊成員）參考，藉此讓彼此的產出能夠成功整合，確保專案完整非零散，避免多頭馬車的情況。

#### 測試
問題偵查班，早點發現bug，避免被客戶發現，讓大家安全下庄。

#### 專案管理
開會追進度，確保專案不會開天窗，能對客戶有所交代。
進度有到拍拍手，進度沒到要出手。

## 軟體測試
* 發現錯誤：測試與除厝（debug）不同
* 評估品質
1. 是否符合客戶需求與起初設計目的
2. 效能OK，夠安全，使用者經驗好
* 建立信心：大丈夫？

### 為什麼錯誤沒被測試出來？
1. 沒思考系統怎麼被使用
2. 腳本（cenario）未能完善
3. 未能完善壓力測試

### 誰來~~找砸~~測試
1. 開發人員：對自己軟體負責，抓出基本的錯誤來提升開發效益。
2. 整合負責人：把開發人員的成品整合起來測試，例如把後端接起來測試後，再把前端搭進來實測。
3. 測試人員：肩負有效抓出問題的重任，因著與開發人員角度不同，可以突破開發者的盲點，有效找出問題。
4. 系統使用者（客戶、業主）：驗收，以自己的驗收準則來看開發商端出來的產品是否符合你要付的這筆錢。

### 窮舉性測試 vs. 選擇性測試
* 窮舉性測試雖然可以達到完善、詳盡，但會測到崩潰（哭喔），實務上不可行
* 選擇性測試可以花有限的時間與成本，以最有效率的方式來找出軟體錯誤
* 越早發現錯誤，修正成本越低
* 沒找到錯誤：測式無效QQ

### 白箱測試 vs. 黑箱測試
#### 白箱測試
* 了解軟體內部結構後進行測試
* 優點：可有效測試程式細節
* 缺點：成本高、無法測試需求部分與介面部分的錯誤
* 適用範圍：演算法的測試
* 白箱測試覆蓋準則
1. 敘述覆蓋
2. 分支決策覆蓋
3. 條件覆蓋
4. 決策/條件覆蓋
5. 多重條件組合覆蓋
6. 全面路徑覆蓋

#### 敘述覆蓋（Statement Coverage）
* 設計測試案例，使每一條指令敘述至少執行一次
* 測試方法較不嚴謹
* 敘述覆蓋為最弱邏輯覆蓋準則，白箱測試至少要做到此測試。

#### 分支決策覆蓋（Branch Coverage or Decision Coverage）

## JUnit
以下註釋是加在public void method()之前：
@Test <-測試這裡
@Before <-在每個Test方法之前執行，以便執行測試某些必要的先決條件
@After <-在每個Test方法之後執行

以下註釋是加在public static void method()之前：
@BeforeClass <-以靜態方式先行載入並執行，但僅執行一次
@AfterClass <-以靜態方式在最後面執行，僅執行一次
@Ignore <-想暫時禁用特定的測試執行可以使用，被注解為@Ignore的方法將不被執行

執行順序：
1. beforeClass()
2. before()
3. testA()
4. after()
5. before()
6. testB()
7. after()
8. afterClass()

@BeforeClass及@AfterClass在一個Test Case只會被執行一次。
而@Before和@After會在每一次測試方法@Test前後各執行一次。

## Jmeter
網站下載
https://jmeter.apache.org/download_jmeter.cgi

Day 20 Jmeter 壓力測試工具
https://ithelp.ithome.com.tw/articles/10203900?sc=hot

## Git
Git安裝下載
https://git-scm.com/download/win

Github網站
https://github.com/