2.1、軟體測試概念

​ 從需求開始，貫穿整個研發過程，不只是找出軟體錯誤，更是軟體研發每一個環節一系列的總稱，包含研發過程中的改進，軟體質量的評定。軟體測試人員是參與研發每個環節的關鍵角色。

軟體測試目的：

1. 為了發現程式中的錯誤，以及按照產品需求執行軟體的過程
2. 保障軟體研發過程中文件的質量
3. 分析錯誤的產生原因、發展趨勢，提出軟體研發過程中改進意見
4. 未發現錯誤的軟體測試也是有價值的，測試是評定軟體質量的有效方法

軟體測試物件：

​ 程式和文件

軟體測試的價值：

1. 質量檢測--儘可能的發現版本的缺陷
2. 質量改進--完善軟體研發過程
3. 質量鑑定--證明軟體版本是可以成功釋出的
4. 質量督導--提升團隊能力成熟度（默契）

軟體測試七大原則：

• 軟體測試應儘早執行，貫穿軟體整個生命週期
• 窮舉測試是不可能的，任何軟體任何時間都有缺陷
• 充分注意測試中的叢集現象，缺陷多的地方往往遺留的問題、缺陷也會更多
• 缺陷二八定律，80%的缺陷出現在20%的功能模組中
• 嚴格執行測試計劃，排除測試的隨意性
• 注意合法合理的輸入，注意非法非預期的輸入
• 殺蟲劑悖論（抗藥性）反覆相同的測試用例，會使軟體產生抗藥性，此時可以換不同的測試方法或者換個軟體測試人員，重新殺蟲

2.2、軟體測試型別和測試方法

2.2.1型別

​ web測試：網頁測試

​ client測試：客戶端測試

​ moble測試：客戶端測試如webapp，app

​ Git/C2 整合測試：

​ E2E測試：在真實情況下把所有的真時情況全部模擬

​ alpha測試：在系統測試後，使用者在開發環境下測試

​ beta測試：在alpha測試後，使用者生產環境即線上環境進行測試

​ 相容性測試：檢查軟體在不同硬體、軟體平臺上是否可以正常執行，即軟體的可移植性

2.2.2測試方法

等價類：

等價類分有效和無效兩類

有效是對程式的規範是有合理輸入資料所構成的集合，無效是對程式的規範不合理或無意義的資料所構成的集合.

設計原則：

1. 每個等價類規定唯一的編號、
2. 設計一個新的測試用例儘可能的覆蓋沒有被覆蓋的有效等價類，重這一步直到所有的等價類都被覆蓋
3. 設計一個新的測試用例，使其覆蓋一個尚未被覆蓋的無效等價類，重複這一步驟直至無效等價類被覆蓋

邊界值：

• 內點：可以不測，區間內的點
• 上點：邊界上的點
• 離點：離邊界值最近的且與上點不在同一等價類的點（小數無離點）
• 【a,b】閉區間即和這個 （離點- ?） a<= age<= b （? -離點），a、b為上點，a、b之間為內點
• （a,b）開區間即和這個 a< （離點-1 ）（內點+2） age （內點-2） （離點-1）<= b ，a、b為上點

場景測試：

​ 運用場景對系統的功能點或業務流程的描述，從而提高測試效果的一種方法

​ 一般包括：從一個流程開始途中經過用例的每條路徑，都可以用基本流和備選流表示。

錯誤推斷法：

​ 基本思想-列舉出所有可能出現的錯誤和發生錯誤的特殊情況，根據這些輸入設計測試用例。

​ 常見依據

• 在單元測試中理出模組常見的錯誤
• 在之前產品發現的錯誤
• 客戶使用中發生的錯誤
• 公共模組的功能
• 修復BUG的功能模組

正交法：

​ 是研究多因素、多水平的一種試驗法，利用正交表對試驗進行設計，通過少數試驗替代全面的試驗，根據正交表的正交性，從之前的試驗中挑出適量有代表性的點進行試驗，這些代表的點具備了均勻分散、整齊可比的特點。

​ 正交法主要用於時間緊，任務重的專案中。

2.2.3軟體測試分類

軟體測試

開發階段分

​ 單元測試（Unit Testing）:對於軟體最小可測單元進行測試
​ 整合測試（Integration Testing）：單元測試基礎上，對兩個已測單元或者多個單元進行組裝測試，測試單元之間的介面：單元測試的擴充套件
​ 系統測試（System Testing）：整合測試，對於軟體所有功能、安全性、效能、相容性進行測試
​ UTA驗收測試.（Acceptance Testing）：系統測試之後，由使用者或者第三方驗收公司，對軟體進行測試，已檢視是否符合使用者需求（α、β）

是否執行分

​ 靜態測試（Static Testing）
​ 動態測試（Dynamic Testing）

是否檢視程式碼分

​ 白盒測試（White-box Testing）
​ 黑盒測試（Black-box Testing）
​ 功能測試（Functional Testing）
​ 介面測試（GUI Testing）
​ 冒煙測試（Smoke Testing）
​ 迴歸測試（Regression Testing）
​ 業務邏輯測試
​ 相容性測試
​ 易用性測試
​ 效能測試（Performance Testing）
​ 負載測試：對系統指標不斷施壓，達到飽和
​ 壓力測試：對系統不斷施壓直至系統崩潰
​ 併發測試：某個業務、相同業務同時訪問使用者的支援數量；最大併發=總使用者/10
​ 穩定性測試
​ 灰盒測試（Gray-box Testing）

是否手工分

​ 手工測試（Manual Testing）
​ 自動化測試（Automation Testing）

其他

​ 使用者驗收測試
​ α測試（Alpha Testing）
​ β測試（Beta Testing）
​ 迴歸測試
​ 隨機測試等等

2.3、軟體測試的流程

流程：

​ 需求分析（需求串講、反串講）-

​ 測試計劃（背景、時間節點、人員安排、風險、退出機制（測試結束的標誌））-

​ 測試分析（思維導圖）-

​ 測試設計（測試功能節點）-

​ 用例編寫（規範，提高測試用例的覆蓋度，用力的評審）-

​ 環境搭建

​ 用例執行

​ 缺陷提交

​ 迴歸測試（對缺陷修復後重新測試）-

​ 測試報告（測試環境、測試方法、測試用例、執行情況、缺陷分佈情況、處理情況、測試結論（是否可以釋出））

退出機制：

1. 測試用例覆蓋度100%
2. 用例執行率100%
3. 缺陷2%~5%
4. 遺留的缺陷都要用合理的解決方案

2.4、測試用例的標準（規範）

• 測試用例標題必須驗證二字開頭
• 測試用力字數不可超過30個
• 測試標題不可出現二義性（如可不可以）
• 測試用例必須給出明確的結果
• 測試用例步驟必須給出實際資料
• 測試用例標題不能重複

2.5、測試用例要素和缺陷生命週期和要素

測試要素：

1. 用例編號（模組、子模組、測試場景）
2. 用例標題
3. 優先順序
4. 前提條件
5. 執行步驟
6. 期望結果

缺陷要素：

1. 缺陷編號（模組、子模組、測試場景）
2. 缺陷標題
3. 缺陷優先順序
4. 缺陷等級
5. 重現步驟
6. 期望結果
7. 實際結果
8. 附件（截圖、日誌）

缺陷生命週期：

提交（測試、開發）-確認（測試經理）-分配（測試組長）-修復（開發）-驗證（測試人員）-關閉（測試人員）

什麼是缺陷？

1. 不符合客戶要求
2. 超過客戶要求
3. 不符合客戶習慣
4. 缺少對異常處理的反饋即頁面提示

嚴重性分級：

• 致命：功能直接沒有實現
• 嚴重：重要模組功能沒有
• 一般：部分功能不直接影響整體軟體執行
• 輕微：例如頁面字型、顏色不對

軟體測試誤區：

1. 軟體測試對程式的的測試
2. 軟體測試在軟體開發後進行
3. 軟體質量只是測試的問題和責任
4. 軟體釋出後的缺陷都是測試人員的問題錯誤
5. 軟體測試對軟體人員的要求不高
6. 軟體測試是測試的事情和開發無關

2.6、真實軟體專案情況

1. 一般來說一個專案有十多個模組，每個模組大概有十五個介面
2. 開發測試的比例1:2~1:5之間
3. 實際一千行程式碼缺陷大概有10~20個
4. 每個開發平均每天寫100行程式碼
5. 測試每天編寫或執行的用例數量大概80~100，邏輯複雜的大概30多個
6. 測試人員每天發現缺陷3~5個左右
7. 一個迭代一般情況下1到2個月左右