軟體測試分類體系，系統學習

一、軟體測試定義、目的、原則

1.定義

定義一:維基百科

是在規定的條件下對程式進行操作，以發現程式錯誤，衡量軟體品質，并對其是否滿足設計要求進行評估的過程。

定義二:IEEE

是使用人工或自動手段對系統運作或測試的過程，其目的在于檢驗系統是否滿足規定的需求，或弄清預期結果與實際結果之間的差别。

get到這些點:

規定的條件--》一定的環境下（開發環境、測試環境、真實環境）

目的:衡量軟體品質;是否滿足規定的需求

方式:人工、自動化

周期:過程（測試需求分析、測試計劃、測試設計、測試執行、測試i評估)

2.目的

軟體測試為了發現程式存在的代碼或業務邏輯錯誤

軟體測試為了檢驗産品是否符合使用者需求

軟體測試為了提高使用者的體驗

3.原則——經驗性原則

1.所有的測試活動都應以使用者需求（軟體需求規格說明書)為标準

2.應盡早地和不斷進行軟體測試，越早發現缺陷，修複缺陷的成本就越低

3.程式員應避免檢查自己的程式，測試人員應避免執行自己寫的測試用例

4.盡量避免測試的随意性

5.測試的"殺蟲劑效應"——改變思維方式、操作習慣

6.完全(窮舉)測試是不可能的，測試需要終止——時間，成本,組合太多(無法全部覆寫)

7.二八原則(聚集效應)——大部分bug集中在少部分的子產品

8.對錯誤結果要進行一個确認過程

9.制定嚴格的測試計劃

10.設計測試用例時應該考慮到合法的輸入和不合法的輸入，以及各種邊界條件，特殊情況下還要知道極端狀态和意外狀态

11.妥善儲存測試過程中的所有文檔

二、軟體測試對象

≥軟體、系統、項目、産品―》程式、文檔和資料

1.程式（源碼、子產品、部件、軟體)

2．文檔（需求規格說明書、概要設計說明書、詳細設計說明書、使用者手冊（幫助文檔)等)

3.資料(字元、圖檔、視訊、音頻等等)

60%以上的軟體錯誤并不是程式錯誤，而是分析和設計錯誤。

測試概念擴大化，提倡軟體全生命周期測試的理念。

三、測試分類（政策）

1、按測試技術劃分

白盒測試、黑盒測試、灰盒測試

白盒測試&黑盒測試

黑盒測試:不關心軟體内部，隻關心輸入輸出，主要測試依據是需求文檔。

白盒測試:關心軟體内部設計和程式實作，主要測試依據是設計文檔。

灰盒測試:灰盒測試介于白盒測試與黑盒測之間的測試—―接口測試

關注輸出對于輸入的正确性;同時也關注内部表現

2、按測試階段劃分

單元測試、內建測試、系統測試、驗收測試（正式驗收測試、Apha測試、Beta測試)

【軟體測試階段】

單元測試、內建測試、系統測試、驗收測試是“從小到大”、“由内至外”、“循序漸進"的測試過程，展現了“分而治之”的思想。

【軟體測試階段詳解】

單元測試的粒度最小，一般由開發小組采用白盒方式來測試，主要測試單元是否符合“設計”。

內建測試界于單元測試和系統測試之間，起到“橋梁作用”，一般由開發小組采用白盒加黑盒的方式來測試，既要驗證“設計”又要驗證“需求”。

——子產品(多個單元組成，單元與單元之間的調用與被調用，通道==》接口測試)

系統測試的粒度最大，一般由獨立測試小組采用黑盒方式來測試，主要測試系統是否符合“需求規格說明書”——系統

驗收測試與系統測試非常相似，主要差別是測試人員不同，驗收測試由使用者執——黑盒測試

【α測試/β測試】

大型通用軟體，在正式釋出前，通常需要執行Alpha和Beta測試。

目的是從實際終端使用者的使用角度，對軟體的功能和性能進行測試，以發現可能隻有最終使用者才能發現的錯誤。

Apha測試: α測試是使用者在開發環境下進行的測試，也可以是公司内部的使用者在模拟實際操作環境下進行的測試。這是在受控制的環境下進行的測試。——遊戲内測

Beta測試: β測試是使用者在實際使用環境下進行的測試。與α測試不同的是, 開發者通常不在測試現場。因而，β測試是在開發者無法控制的環境下進行的軟體現場應用。——遊戲公司

正式驗收測試:使用者在實際使用環境下進行的測試。

3、被測試對象是否運作劃分

動态測試、靜态測試(文檔檢查、代碼走查、界面檢查)

【軟體測試階段對照表】

靜态測試指不運作程式，對程式和文檔進行分析與檢查

程式檢查:程式員交叉檢查彼此的代碼--》發現代碼層面的問題

文檔檢查:文檔測試（術語、圖檔、操作流程）--》測試人員

動态測試

動态測試是指通過人工或使用工具運作程式進行檢查分析程式的執行狀态和程式的輸出>白盒測試、黑盒測試、灰盒測試都屬于動态測試

【代碼走查（走讀)實踐】

請走讀下列Bash源代碼，找出裡面的問題，并提供修改建議

代碼需要實作的功能:提示使用者輸入确認資訊(Y)，如果使用者入的是Y，程式輸出Yes，否則輸出No

【需求評審實踐】

需求:系統中有一個日期輸入框，根據實際業務，有下列需求:

1.要求使用者輸入以年月表示的日期

2.日期限定在1990年01月~2049年12月

3.日期由6位數字字元組成，比如20140713

4.前4位表示年

5.後2位表示月

4、按不同的測試手段劃分

手工測試、自動化測試

【手工測試&自動化測試】

5.按軟體測試品質特性劃分

【系統測試類型】

功能測試、性能測試、界面測試、安全測試、相容性測試、易用性測試、壓力測試、負載測試、恢複測試

功能測試基本方法

構造正常/異常輸入檢查輸出是否與期望的相同。如果兩者不一緻，即表明功能有誤

功能測試重點在于正确的了解使用者需求和如何構造有效的測試資料。

性能測試

測試軟體處理業務的速度

檢驗性能是否符合需求

得到某些性能資料供人們參考（例如用于宣傳)

【界面測試】

我們去關注産品界面UI顯示，顔色搭配，布局，偏主觀性。可以參考同類型的軟體

【安全性測試】

是指防止系統被非法入侵的能力，既屬于技術問題又屬于管理問題

資訊安全性測試有如下步驟:

1.為非法入侵設立目标，例如“盜竊某個檔案”或“更改資料庫記錄”等

2.邀請(或懸賞）一些人扮演黑客，讓他們想盡辦法入侵系統，實作“目标"

3.如果有人成功了，請他詳述入侵的過程

【相容性測試】

又把它叫做平台的移植性，不同作業系統，不同的分辨率，不同的浏覽器

【易用性測試】

主觀測試，好不好用，是否容易使用，是否符合大衆習慣（比如：是在左邊、否在中間、取消在最右邊）

【壓力測試】

屬于性能測試的一種，對于系統不斷的施加壓力，發現它的弱點在哪裡，然後修複的一個過程。

【負載測試】

也是屬于性能測試的一個内容

【恢複測試】

恢複能力，比如系統藍屏，會有倒計時重新開機恢複。

充當使用者暴力的使用，到崩潰，能否恢複，恢複的時間是多少。

6.其他測試

主要講三個，冒煙測試、回歸測試、探索性測試(測試思維)

【冒煙測試】

這一術語源自硬體行業。對一個硬體或硬體元件進行更改或修複後，直接給裝置加電。如果沒有冒煙，則該元件就通過了測試。

在軟體中，“冒煙測試”這一術語描述的是在将代碼更改嵌入到産品的源樹中之前對這些更改進行驗證的過程。在檢查了代碼後，冒煙測試是确定和修複軟體缺陷的最經濟有效的方法。冒煙測試設計用于确認代碼中的更改會按預期運作，且不會破壞整個版本的穩定性。

v01-->冒煙測試--》通過--》正式系統測試--》出具版本報告--》pass-->驗收測試--》fail--》打回給開發，修改bug,重新發版本--》

V02(修改bug,增加新的需求)-->冒煙測試--》通過--》--》回歸測試（1:驗證bug是否被修改，2:送出bug的周邊的功能進行簡單測試，确認是否有引入新的bug)--》正式系統測試--出具報告

V03(修改bug)-->冒煙測試--》通過--》--》回歸測試（1:驗證bug是否被修改，2:送出bug的周邊的功能進行簡單測試，确認是否有引入新的bug）--》出具版本報告.....

後期:基本穩定,bug沒有修改

【回歸測試】

回歸測試是指修改了I舊代碼後，重新進行測試以确認修改沒有引入新的錯誤或導緻其他代碼産生錯誤。自動回歸測試将大幅降低系統測試、維護更新等階段的成本。

回歸測試作為軟體生命周期的一個組成部分，在整個軟體測試過程中占有很大的工作量比重,軟體開發的各個階段都會進行多次回歸測試。

驗證bug是否被修改是否引入新的bug

【探索性測試】

測試人員在測試程式中可以天馬行空地想怎麼測就怎麼測，利用應用程式所提供的資訊自由發揮，沒有限制，不受任何限制地探索程式的各種功能。——項目後期，時間充足，人員技術能力比較高。

那麼這個就是本章《軟體測試分類體系，系統學習》所有的内容

在這一章中間，夥伴們重點要掌握的第一個是概念，軟體測試的定義、目的。

軟體測試經驗性原則，是我們在軟體測試工作中需要去遵循的，都是前輩們留下來的寶貴經驗。

對于測試分類，這一系列的類别中間，工作中可能你們都會用到，至少你要知道有哪些類别，在哪一個階段用哪一種技術，。

相容性測試測什麼，界面測試是測試什麼，這些都是必須要掌握的。

微信公衆号：程式員一凡