軟件測試類型（共19種）

1.按照測試類型劃分：

功能測試(Function Testing)：測試軟件的功能是否符合功能需求，通常采用黑盒測試方式。一般由獨立測試人員執行。

性能測試(Performance Testing)：測試軟件在各種情況下的性能，如在正常情況下或者最大負載下的狀況。包括內存測試、CPU測試、響應時間測試、喚醒率測試、強度測試、容量測試、基準測試等。

安全測試(Security Testing )：測試該系統防止非法侵入的能力。在IT軟件產品的生命周期中，特別是產品開發基本完成到發布階段，對產品進行檢驗以驗證產品是否符合安全需求定義和產品質量標準的過程。（比如登錄，注冊功能等）

易用性測試：測試軟件是否易用，主觀性比較強。一般要根據很多用戶的測試反饋信息，才能評價易用性。

兼容性測試：測試該系統與其他軟件或者系統平臺（軟件/硬件）的兼容性。包括自身兼容性（歷史版本數據，功能兼容）、平臺兼容性（window平臺、linux平臺等的兼容）、設備兼容性（Android產品，IOS產品等的兼容）、與其他軟件兼容性等。

部署測試：也叫安裝測試，確保該軟件在正常或異常情況下都能進行安裝（進行首次安裝、升級、完整的或自定義的安裝--正常情況；磁盤空間不足，缺少目錄創建權限，安裝過程中關機重啟--異常情況）（部署方式：分布式部署，集中部署等）

文檔測試：檢驗樣品用戶文檔的完整性，正確性，一致性，易理解性，易瀏覽性。包括用戶手冊，配置手冊、安裝手冊，使用說明，用戶幫助文檔等。

本地化測試：不同區域不同版本的測試（中文版本測試，英文版本測試等）

無障礙測試：針對特定的用戶群體，比如老年人，殘疾人等類型的用戶

競品測試：同類產品在功能、性能等方面的對比測試。

開發文檔和源程序可以應用單元測試應用走查的方法。

2.按是否查看程序內部結構分類

黑盒測試（Black-Box Testing）：又稱數據驅動測試，從用戶角度出發，把測試對象比作黑盒，關注程序外部結構，不關注內部邏輯，針對輸入對應的輸出是否正確進行測試（是對功能的測試）。即針對軟件界面和軟件功能進行測試，以此來確認軟件的功能和界面是否正確或遺漏，數據庫訪問是否正常，會出現性能錯誤，初始化錯誤和程序終止錯誤等bug。

灰盒測試(Gray-Box Testing)： 是一種綜合測試方法，他將黑盒測試和白盒測試相結合，基于程序運行時的外部表現又結合內部邏輯結構來設計用例，執行程序并采集路徑執行信息和外部用戶接口結果的測試技術。

白盒測試(White-Box Testing)：結構測試或邏輯驅動測試，是一種按照程序內部邏輯結構和編碼結構，設計測試數據并完成測試的一種測試方法。

3.按是否運行程序分類

靜態測試(Static Testing)：指不運行被測程序本身，僅通過分析或檢查源程序的語法、結構、過程、接口等來檢查程序的正確性。對需求規格說明書、軟件設計說明書、源程序做結構分析、流程圖分析、符號執行找錯。技術應用包括控制流分析技術、數據流分析技術、信息流分析技術等。

軟件質量的衡量方面：功能性（Functionality）、可靠性(Reliability)、可用性(Usability)、有效性(Efficiency)、可維護性(Maintainability)、可移植性(Portablity)

動態測試(Dynamic Testing)：是指通過運行被測程序，檢查運行結果與預期結果的差異，并分析運行效率、正確性和健壯性等性能指標。組成部分：構造測試用例、執行程序 、分析程序的輸出結果。技術應用包括邏輯覆蓋率測試技術（分支測試技術、路徑測試技術等），程序插裝等。

4.按階段測試分類

單元測試(Unit Testing)：又稱模塊測試，是針對軟件設計的最小單位----程序模塊或功能模塊，進行正確性檢驗的測試工作。其目的在于檢驗程序各模塊是否存在各種差錯，是否能正確地實現了其功能，滿足其性能和接口要求。常用方法：白盒測試。

測試階段：編碼后

測試對象：最小模塊

測試人員：白盒測試工程師或開發工程師

測試依據：代碼和注釋+詳細設計文檔

測試方法：白盒測試

測試內容：模塊接口測試、局部數據結構測試、路徑測試、錯誤處理測試、邊界測試

集成測試(Integration Testing)：又叫組裝測試或聯合，是單元測試的多級擴展，是在單元測試的基礎上進行的一種有序測試。旨在檢驗軟件單元之間的接口關系，以期望通過測試發現各軟件單元接口之間存在的問題，最終把經過測試的單元組成符合設計要求的軟件。常用測試方法：灰盒測試。

測試階段：一般單元測試執行之后進行

測試對象：模塊間的接口

測試人員：白盒測試工程師或開發工程師

測試依據：單元測試的模塊+概要設計文檔

測試方法：灰盒測試（黑盒測試和白盒測試相結合）

測試內容：模塊之間的數據傳輸、模塊之間的功能沖突、模塊組裝功能正確性、全局數據結構、單模塊缺陷對系統的影響。

確認測試：又稱有效性測試。任務是驗證軟件的功能和性能及其它特性是否與用戶的要求一致。對軟件的功能和性能要求在軟件需求規格說明書中已經明確規定。它包含的信息就是軟件確認測試的基礎。

系統測試(System Testing)：是為判斷系統是否符合要求而對集成的軟、硬件系統進行的測試活動、它是將已經集成好的軟件系統，作為基于整個計算機系統的一個元素，與計算機硬件、外設、某些支持軟件、人員、數據等其他系統元素結合在一起，在實際運行環境下，對計算機系統進行一系列的組裝測試和確認測試。

測試階段：集成測試通過之后

測試對象：整個系統（軟硬件）

測試人員：黑盒測試工程師

測試依據：需求規格說明書

測試方法：黑盒測試

測試內容：功能、界面、可靠性、易用性、性能、兼容性、安全性等。

驗收測試(Acceptance Testing)：以用戶為主的測試，軟件開發人員和質量保證人員參加，由用戶設計測試用例。不是對系統進行全覆蓋測試，而是對核心業務流程進行測試。

測試階段：系統測試通過之后

測試對象：整個系統（軟硬件）

測試人員：最終用戶或需求方

測試依據：用戶需求，驗收標準

測試方法：黑盒測試

測試內容：功能、界面、可靠性、易用性、性能、兼容性、安全性，程序設計文檔及說明書等。

alpha測試：用戶在開發環境下（模擬實操環境）進行測試，受開發方控制，用戶數量相對較少，時間比較 集中。目的是：評價軟件產品的FLURPS（即功能、局域化、可使用性、可靠性、性能和支持）測試時間：軟件正式發布前。測試對象：不能有程序員或測試員完成。

beta測試：用戶公司組織各方面的典型終端用戶在生產環境下進行，是一種驗收測試。用戶不受開發方控制，可以自由地測試，用戶數量相對較多，時間不集中。測試時間：alpha測試過后特點：測試規模大，測試周期長。

5.黑盒測試分類

功能測試：菜單、工具欄、快捷鍵、下拉框、按鈕、單選按鈕、復選按鈕、切換、鏈接（集成測試階段）、觸發鍵

1.邏輯功能測試：

2.UI界面測試：登錄界面、總界面、輸入/出界面（增刪改查）、處理界面、輸出界面、報表界面、提示界面

3.易用性測試：

4.兼容性測試：

5.接口測試：也叫業務流程測試（包括功能模塊之間、模塊與模塊之間、子系統之間），分為內部接口（即函數調用[導入導出]）和外部接口兩部分。服務器接口、外部接口、錯誤處理。接口測試工具：charles，postman,jmeter等。

注：

服務端一般會提供JSON格式的數據給客戶端，所以我們在服務端需要進行接口測試，確保服務端提供的接口并轉換的JSON內容正確，對分支、異常流有相應的返回值。此塊測試可以采用itest框架進行測試。最方便的是采用httpclient進行接口測試。進行服務端測試時，需要開發提供一份接口文檔。

6.容錯測試：數據長度、數據類型、非法操作等

性能（時間-、空間）測試：TPS吞吐量、響應速度、CPU占用率、內存占用率等

名詞解釋：

平均吞吐量：單位時間內處理事務的個數

平均響應速度：做一個事務處理所用時間

時間性能：軟件的一個具體事務的響應時間

空間性能：軟件運行時所消耗的系統資源

測試項目：

1.可靠性測試：硬件方面（材料等），如高低溫測試，防水防塵測試等。

2.穩定性測試：稍大于業務量的一個負載，對系統進行的一個持續的長時間的測試，比如24*5，連續5天施加壓力，確定系統能在較長時間運行下的系統穩定性的情況；1小時觸發600條信息，那么8個、10個等發信息的條數測試。

3.負載測試：確認系統正常指標下的最大負載。步驟：在測試過程中，逐步增加負載，并記錄被測系統響應的性能表現，最終確認出系統的最大負載。

4.壓力測試：確認系統所能承受的最大極限。是指在極限壓力情況下，系統崩潰的極限條件測試。大用戶測試（針對B/S而言）

5.容量測試：大數據量測試。

6.強度測試：系統續航量測試

7.安全性測試：

8.恢復測試：突然斷電（系統觸發正常啟動；數據包要在斷電的地方繼續進行處理）

9.標桿測試：

10.并發測試：指多個用戶在同一時間對同一條數據的刪除或者修改等處理

11.配置測試：分為最低配置和推薦配置兩種。

12.安裝測試：安裝過程和卸載過程

13.文檔測試：交給用戶的文檔。例如：系統幫助、用戶使用手冊、用戶安裝手冊

14.可用性測試：靠經驗。

15.初始化測試：是指系統剛剛安裝完成后，在數據位空的情況下，如果被調用的模塊為空，點擊調用模塊的時候，是否進行容錯的測試。

16.數據完整性測試：是指當主表的某一條件信息被刪除后，和這一條相關的從表的信息都應該被刪除。如果某些數據的主鍵是由數據庫本身而實現的，可以不用刪除，如果有些主從表是由程序員寫的代碼而實現，則要進行數據完整性的測試。

6.是否手工執行

手工測試(Manual Testing)：由人一個一個的輸入用例，然后觀察結果，和機器測試相對應，屬于比較原始但是必須的一個步驟。

優點：自動化無法替代探索性測試、發散思維類無既定結果的測試。

缺點:執行效率慢，量大易錯。

自動化測試(Automation Testing)：在預設條件下運行系統或應用程序，評估運算結果，預先條件應包括正常條件和異常條件。即模仿人的動作和行為。一般常用的自動化測試如功能測試自動化（默認）、性能測試自動化、安全測試自動化等

7.其他測試類型

回歸測試(Regresson Testing )：對軟件版本的新版本進行測試時，重復執行上一個版本測試時的用例。在發生修改后重新測試新版本的軟件以保證修改的正確性，以及修改后沒有引發新的錯誤。回歸測試是開發人員修改已提交的bug后，測試人員進行再一輪的測試，主要是檢測bug是否被修復，bug相關功能是否被影響。

冒煙測試(Smoke Testing)：對一個系統進行大規模的測試之前，先驗證一下軟件的基本功能是否實現，是否具備可測性。冒煙測試又稱為版本驗證測試，他的對象是每一個新編譯的需要正式測試的軟件版本，目的是確認軟件的基本功能正常，可以進行后續的正式測試工作。冒煙測試是在開發人員交付軟件時進行的大體預測，主要是針對整體流程和主體功能進行測試。

隨機測試(Ad-hoc Testing)：

恢復測試()：

探索性測試(Exploratory Tesing)：是一種測試思維技術（方式）。他強調的是測試人員的主觀能動性，拋棄繁雜的測試計劃和測試用例設計過程，強調在碰到問題時及時改變測試策略。

返測：針對程序員修改的錯誤進行測試，驗證錯誤是否被修正。

注：

1.單元測試

• 模塊接口的測試
• 局部數據結構的測試
• 獨立路徑測試
• 錯誤處理測試
• 邊界測試

單元測試的模塊

• 被測模塊：被測試的程序的模塊
• 驅動模塊：用來模擬測試模塊的上一級模塊，相當于被測模塊的主程序
• 樁模塊：用來模擬被測模塊工作過程中所調用的模塊
• 單元測試的工具：Junit相關的概念：以插入斷言的方式進行測試（類似黑盒測試）
• 針對被測代碼或者被測的功能點先創建測試類，然后在類里面創建一個個測試方法。通過實例化對象調用被測方法，用斷言進行實際值預期值比較。
• 單元測試的方法：以白盒測試法為主（覆蓋），先靜態檢查代碼是否符合規范，再動態運行代碼，檢查結果。除了需要驗證結果是否正確，還需要檢查程序的容錯能力、邊界值處理等問題。

2.集成測試

• 一次性的集成big-bang：把所有通過了單元測試的模塊按設計要求一次全部組裝起來，然后進行整體測試。時間隨變短了但急于求成。
• 漸進地集成
• 自上而下：從主程序模塊開始按深度或廣度優先策略邊組裝邊測試
• 自下而上：從最底層模塊開始組裝和集成測試
• 漢堡包：兩者進行結合，樹狀圖每層畫線，頂層采用自頂向下，底層采用自底向上
• 相鄰的集成：上下三層進行集成
• 成對集成：先成對再相鄰
• 基于MM路徑的集成：MM路徑不是可執行路徑，描述單元之間的控制轉移。
• 最終得到調用圖，然后就會到基本路徑測試，找復雜度，找路徑，得到測試用例的套路
•  

3.系統測試

• 方法：黑盒測試
• 內容：易用性、國際化本地化、性能、功能、界面、兼容性、安全性、文檔、安裝

白盒測試用例設計方法

1.基本路徑測試

2.邊界值分析

3.邏輯覆蓋率測試（分支測試、路徑測試）

4.循環測試

5.數據流分析技術測試

6.程序插樁測試

7.變異測試

8.控制流分析技術測試

9.信息流分析技術測試

依據：詳細設計說明書及其代碼構架。

優點：1.迫使測試人員去仔細的思考軟件的實現；2.可以檢測代碼中的每條分支和路徑；3.揭示隱藏在代碼中的錯誤；4.對代碼的測試比較徹底；5.實現代碼最優化。

缺點：1.價格昂貴；2.無法檢測代碼中遺漏的路徑和數據敏感性錯誤；3.不驗證規格的正確性。

注：

1.邏輯覆蓋

語句覆蓋->判定覆蓋->判定/條件覆蓋->條件組合覆蓋->路徑覆蓋
 _條件覆蓋/

• 語句覆蓋：每條語句執行一次
• 判定覆蓋：每個判定分支至少執行一次
• 條件覆蓋：每個判定條件應取到各種可能的值
• 判定/條件覆蓋：同時滿足判定和條件
• 條件組合覆蓋：每個判定條件的每一種組合各出現一次
• 路徑覆蓋：每一條可能的路徑至少執行一次

關系：

• 條件組合覆蓋＞判定覆蓋＞語句覆蓋(即如果達到條件組合覆蓋，就達到判定覆蓋和語句覆蓋：如果達到判定覆蓋，就達到語句覆蓋，下面類似理解)。
• 條件組合覆蓋＞條件覆蓋。
• 條件覆蓋不一定包含判定覆蓋、語句覆蓋。
• 判定覆蓋不一定包含條件覆蓋。
• 路徑覆蓋，判定覆蓋＞語句覆蓋。

2.基本路徑測試

• 基于程序圈復雜度產生的測試方法，畫出控制流程圖，算圈復雜度，找到獨立路徑并壓縮為基本路徑集合，根據集合中每條路徑設計用例。把復合邏輯表達式拆成單個表達式
• 圈復雜度用于計算程序的基本的獨立路徑數目（每條新的獨立路徑都必須包含一條新的有向邊，從入口到出口互不相同的路徑數）
• 圈復雜的V(G) = e - n + 2p【邊-節點+2*連接區域數，連接區域p通常為1】=P+1【判定節點數+1】
• 一般來說，一個單元模塊的最大復雜度V(G)<10
• 如果把覆蓋的路徑數壓縮到一定限度內，例如程序中的循環體只執行0次和1次，就成為基本路徑測試，通過導出基本路徑集合，從而設計測試用例，保證這些路徑至少通過一次

3.基于數據流的測試

• 基于真的數據定義到數據的使用來進行測試，需要找到定義的節點（包括賦值的和比較的）和使用的節點。
• 定義節點DEF：輸入語句、賦值語句、循環語句和過程調用；變量的值會發生變化的語句
• 使用節點USE：數出語句、賦值語句、條件語句、循環控制語句、過程調用
• 需要找到所有這段功能代碼從哪里開始定義，到哪里開始執行，把路徑找出來。什么是定義使用路徑（某一變量在最初節點定義到最終節點被使用）、定義清除路徑（某一個變量從它的定義節點到使用節點這個過程中沒有對這個變量進行二次定義）

4.循環測試

• 前提是程序是結構化的。
• 簡單循環測試
• 0次通過循環
• 1次通過循環
• 2次通過循環
• m次通過循環（m<=循環最大次數）
• m-1，m，m+1次通過循環

黑盒測試用例設計方法

1.基于用于需求的測試

2.功能圖分析方法

3.等價類劃分方法

4.邊界值分析方法

5.錯誤推測方法

6.因果圖方法

6.判定表驅動分析方法

7.正交試驗設計方法

依據：用戶需求規格說明書和詳細設計說明書

注：

1.常見的邊界值

• 16bit整數32767～-32768
• 報表第一行和最后一行
• 屏幕光標最左上和最右下
• 數組的第一個和最后一個
• 循環的第0、1、倒數第一、倒數第二次

2.決策表

適合于問題有多個條件，條件有多種組合執行不同操作

判定表
| 條件樁 | 條件項 | ... | 動作項 |
| 動作樁 | 動作項 | ... | 動作項 |

規則：條件的任意組合，判定表中的一列（貫穿條件項和動作項）。判定表有多少列就代表有多少條規則。

規則的化簡：有的規則相互包含，可以化簡

3.因果圖

找出所有的原因，找出結果，可能還有中間結果的產生，在畫因果圖時注意。

從輸入考慮

I：連虛線出去，如連到ab，表示ab中至少有一個必須成立

E：連虛線出去，如連到ab，表示ab不能同時成立

R：如處于a指向b的虛線三角箭頭上，表示a出現時b也必須出現，不可能一個出現一個不出現

從輸出考慮

M：如處于a指向b的虛線三角箭頭上，表示a為1時b必須為0，a為0時b值不定

連線：恒等

～：非

∨：或

∧：且

ci：原因

ei：結果

畫出因果圖后，根據圖得到決策表從而得到相應的測試數據：原因節點+中間節點為條件樁，結果結點為動作樁。

什么是軟件？

軟件=文檔+程序+數據

文檔： 是與開發、維護和使用有關的圖文資料。

程序： 是按實現設計的功能和性能要求執行的指令序列。

系統軟件

window、Linux、DOS系統、ios系統等。

應用軟件

王者榮耀、wechat、淘寶、圖書館管理系統等。

軟件缺陷（Enhancemental--Bug）

1.未實現產品說明書要求功能

2.出現說明書中指明不應出現的錯誤

3.實現了說明書中未提及的功能（畫蛇添足）

4.未實現產品說明書未提及，但是應實現的功能

5.難以理解，不易使用，運行緩慢

軟件BUG等級劃分標準

測試BUG等級劃分標準

1.Blocker（崩潰）【Fatal致命的】：阻礙開發或測試工作的問題；造成系統崩潰、死機、非法退出、死循環，導致數據庫數據丟失，與數據庫連接錯誤，主要功能喪失，基本模塊缺失等問題。如：代碼錯誤、死循環、數據庫發生死鎖、系統關鍵性能不達標，數據通信錯誤或接口不通等

2.Critical（嚴重）：系統主要功能部分喪失、數據庫保存調用錯誤、用戶數據丟失，一級功能菜單不能使用但是不影響其他功能的測試。功能設計與需求嚴重不符，模塊無法啟動或調用，程序重啟、自動退出，關聯程序間調用沖突，安全問題、穩定性等。如：軟件中數據保存后數據庫中顯示錯誤，用戶所要求的功能缺失，程序接口錯誤，數值計算統計錯誤、服務程序頻繁需要重啟(每天2次或以上)、周邊接口出現故障(需考慮接口時效/數量等綜合情況)等（該等級問題出現在不影響其他功能測試的情況下可以繼續該版本測試）。

3.Major（一般）：功能沒有完全實現但是不影響使用，功能菜單存在缺陷但不會影響系統穩定性。如：操作時間長、查詢時間長、格式錯誤、邊界條件錯誤，刪除沒有確認框、數據庫表中字段過多、 數據來源不正確;、無數據有效性檢查或檢查不合理等(該問題實際測試中存在最多，合理安排解決BUG，解決率關系版本的優化程度)

4.Minor（次要）：界面、菜單布局錯誤或不合理、焦點控制不合理、性能缺陷，光標,滾動條定位錯誤，建議類問題，不影響操作功能的執行，可以優化性能的方案等。如：錯別字、界面格式不規范，頁面顯示重疊、不該顯示的要隱藏，描述不清楚，提示語丟失，文字排列不整齊，光標位置不正確，用戶體驗感受不好，可以優化性能的方案等（此類問題在測試初期較多，優先程度較低；在測試后期出現較少，應及時處理）

5.Negligible（輔助性缺陷）： 建議優化類、缺少產品使用、幫助文檔、系統安裝或配置方面需要信息、長時間操作未給用戶進度提示、顯示格式不規范、長時間操作未給用戶進度提示等

BUG狀態標準

待處理（new）：測試人員或用戶發現新問題后提交的狀態

已確認（open）：經測試人員及研發人員討論后確認是BUG，提交的狀態，由測試人員來設置。

已處理（fixed）：經研發人員確認是BUG后修復的狀態，修改還沒有驗證，由開發人員來設置。

已修改（closed）：測試人員認為問題已經修改，通過驗證，由測試人員設置。

仍存在（reopened）：測試人員認為BUG未修復成功，問題仍然存在，由測試人員設置。

不是問題（reject）：研發人員確認不是BUG，或者建議與意見決定不采納。

暫不處理（hold）：當前版本不做修改，后續版本再考慮，由研發人員或測試人員設置。

（1）激活狀態(Active或Open)。

（2）已修正狀態(Fixed或Resolved)。

（3）關閉或非激活狀態(Close或Inactive)。

軟件測試前期重點工作

正確評估和區分軟件缺陷的嚴重性和優先級。

嚴重性：

A類：Blocker（崩潰）【Fatal致命的】

B類：Critical（嚴重）

C類：Major（一般）

D類：Minor（次要）

E類：Negligible（可忽略的）

優先級：

P1類：立即解決

P2類：高優先級

P3類：正常排隊

P4類：低優先級

優先級確定方法：

1.二八原則

2.ABC原則

3.四象限原則（輕重緩急）

軟件缺陷類型：

1.功能缺陷

2.系統缺陷

3.加工缺陷

4.數據缺陷

5.代碼缺陷

軟件測試

為了發現程序中的錯誤而執行程序的過程，即對軟件（程序）的漏洞進行檢查發現，衡量軟件質量，并對其能否滿足規定的需求或弄清預期結果和實際結果的差別。

測試對象

程序、數據、文檔

測試過程模型

缺陷具有放大的特點，隨著階段的推進發現bug的成本會指數型上升，所以并不是代碼級的測試才叫測試，而是開發過程各個階段越早開始測試越好。

1.瀑布模型：1.需求分析->2.設計（概要、詳細）->3.編程->4.測試（單元、集成、系統）->5.維護

2.V模型（瀑布-改）：1.需求分析--2.概要設計--3.詳細設計--4.軟件編碼--5.單元測試--6.集成測試--7.系統測試--8.驗收測試

3.W模型：1.需求分析--需求測試--2.概要設計--功能測試--3.詳細設計--設計測試--4.軟件編碼--5.單元測試--6.集成測試--7.系統測試--確認測試--8.驗收測試

4.H模型：無實際意義，僅說明可以獨立測試。

軟件測試原則

1.測試來源于需求原則

2. 8-2原則：

• 測試中發現的錯誤80%很可能起源于程序中的20%
• 提前測試可發現80%，系統測試找出剩余bug的80%（總體的16%），最后的4%可能只有用戶大范圍長時間使用后才暴露出來
• 80%的工程用在20%的需求上（即關鍵需求）

3.軟件缺陷的寄生蟲性：找到的缺陷越多說明軟件遺留的缺陷越多

4.避免自己測試自己的程序

5.回歸測試：避免引入新的錯誤。

軟件測試注意事項

• 測試不是開發后期的一個階段
• 測試入門其實稍容易，但要求技術一樣高
• 測試多數情況下不能覆蓋所有輸入
• 不要“有時間多測，沒時間少測”
• 軟件測試不止是測試人員的事，也是開發人員的事
• 調試和測試不一樣
• 測試絕非只運行一下軟件看結果對不對
• L10N：本地化測試
• I18N：國際化測試

交互對象

1.系統管理或是運維人員

2.開發人員

3.測試人員

4.其他對測試環境或相關技術有影響的人員

5.用戶對象

常見軟件測試錯誤情況占比

屬于需求分析和軟件設計錯誤的約占64%，屬于程序編寫錯誤的僅占36%。

軟件快速應用開發模型

V模型：又叫RAD模型（Rap Application Development Model，快速應用開發模型），構型類似V。其開發階段為：1.需求分析--2.概要設計--3.詳細設計--4.軟件編碼--5.單元測試--6.集成測試--7.系統測試--8.驗收測試

測試意義

1.解放程序員和售后服務人員

2.軟件測試可以降低軟件質量風險，使程序員能夠更專心于解決程序的算法和效率；同時經過嚴格檢驗的完整產品也減輕了售后服務人員的工作量。

測試設備

PC 、手機、平板、嵌入式設備等

測試網絡

1.本地網絡

2.云平臺網絡

3.本地和云的混合網絡

4.WiFi網絡

軟件開發環境

1.開發環境（開發人員）

2.測試環境（測試人員）

3.生產環境（又叫正式環境，是指客戶使用的環境）

軟件測試的目的

1.為了發現程序員在開發中存在的代碼以及邏輯錯誤。

2.為了審核產品的完成是符合用戶的需求的。

3.為了提高客戶的體驗。

4.為了交付更高質量的產品。

測試結果書面材料

測試報告

測試數據管理方法

測試數據包括業務測試數據、基礎數據（配置數據等）

1.測試基礎數據可備份和還原

2.測試數據的原子化，可高度復用

3.測試數據的可定制

4.測試數據的可自動化維護（包括但不限于配置、業務測試數據等等）

測試環境管理的難點

1.高效的規劃好可用的資源（團隊資源利用率）

2.混合環境的管理（云技術、云+私有服務）

3.復雜環境管理（業務、服務、部署、跨團隊協作等）

4.復雜的配置（基礎環境更多和技術應用更廣）

管理測試環境的技巧

1.在初始化測試環境前，應當全面的檢測環境的連通性

2.檢查所有的硬件、軟件、需求、配置等，并形成checklist

3.確定所有測試設備、瀏覽器等版本信息，并形成checklist

4.嚴格規劃測試環境的使用計劃，例如準入準出原則，什么適合更新，什么時候發布，什么節點清理等等

5.盡可能的自動化進行管理維護

軟件測試的流程

需求分析

制定測試計劃

設計測試用例與編寫（一個好的高質量的測試用例在于能發現至今未發現的錯誤，一個成功的測試是發現了至今未發現的錯誤的測試）

實施測試

提交缺陷報告

生成測試總結和報告

Web程序bug分析定位技巧

web前端包括：JAVAScript、ActionScript、css、html、Flash、交互式設計、視覺設計等。

bug定位通用思路：現象-->原因-->驗證字段-->結論-->現象。

bug定位歸因

1.測試環境方面

• 是否安裝了flash及flash的版本--可能導致部分頁面顯示出問題，目前常用的版本為flash10
• 是否開啟了瀏覽器插件--插件可能導致瀏覽器行為的變化，除非測試要求，否則一律禁用插件。
• 是否開啟了安全軟件--可能會截包、彈窗攔截、防釣魚等。

2.瀏覽器方面

• 不同瀏覽器的支持標準--不同內核的瀏覽器對js及各種標準的支持不同，因此頁面解析出來的效果可能不同。如【IE：trident】、【Firefox：gecko】、【Chrome：webkit】、【Safari：webkit】。
• 瀏覽器的設置--禁用js；禁用彈窗；禁用cookie等。
• 瀏覽器cache策略---js,css,圖片等都有可能被cache住。CTRL+F5：強制刷新請求。
• cookie問題----跨域，過期等。

3.網絡方面

• 是否發出了正確的請求--請求url、參數變量。content數據。
• 是否得到了正確的應答---HTTP的返回值：200-正確；302--對象已移動；404--沒找到頁面。返回數據體。
• 是否性能問題--異步請求的數量過多；網速過慢。

4.字符編碼方面

• 頁面亂碼--百度后端存儲基本上使用的是GBK編碼，前端提交可能是UTF-8編碼，后端對非GBK編碼一般采取實體儲存。可能出現編碼沒有轉換。轉換的時候沒有判斷半個漢字（轉掉了半個漢字導致崩潰）
• url錯誤---URL路徑中漢字編碼使用的shi是UTF-8編碼，參數中使用系統默認編碼，flash腳本中使用的都是UTF-8編碼。

安全方面

• Xss漏洞--輸入一些特定的字符頁面出現錯亂或有惡意代碼被執行，RD未對特殊字符轉義完整。

性能方面

• 圖片數量---頁面中同一個域的圖片的數量控制在16個以下，IE會控制同一個域圖片并行的下載數量。
• 頁面抖動--異步請求的數量過多
• 加載失敗--限速情況下，超時。

bug定位常用工具：

Firfox--firebug、web developer、live http headers、http fox ;

IE插件--HTTPwatch

第三方工具---fiddler

慢速網模擬工具---firefox throttle.

Web后端bug分析

后端包含運行在服務器上的程序、腳本和服務。例：各種羅及處理系統、數據存儲系統等。

后端可能發現的問題--邏輯、數據、策略、接口、性能等。

測試bug定位歸因

1.數據流方面

• 上下游模塊是否正常連接---模塊的ip和端口的配置，白/黑名單配置，session授權等。
• 模塊的數據發送接收是否正常--日志是否有滾動，是否顯示發送了數據或接收到數據，數據是否完整，跨機房，負載均衡算法（從哪些機器上獲取數據）。
• 非socket的數據傳輸--共享內存（是否分配，key的配置等），cache（是否創建、臟數據等），數據庫（配置，連接，表，觸發器，存儲過程）、文件（大小、訪問權限）
• 模塊之間的接口--協議的一致性（mcpack1,mcpack2等），字段的一致性（一個按signed解析，一個按unsigned解析），字段復用等。

2.處理邏輯方面

• 程序的各種配置--功能是否kai開啟/關閉，詞表是否加載，各種閾值的配置，超時配置等。
• 程序日志--日志級別，交互的流程，處理的流程等。
• 各種邊界--數據邊界（int，long），文件邊界（空文件，分文件的邊界），時間邊界等。
• 各種資源的使用--cache是否遺留臟數據，并發和鎖死。

3.系統和環境方面

• 系統資源--CPU、IO、句柄、內存、網絡狀態、數據庫狀態，數據庫連接數。
• 環境資源---程序版本、內核版本，網絡（外網）訪問權限，系統動態庫不一致等

4.程序和代碼方面

• 確認問題出現的位置--日志中的代碼行，gdb中的代碼行，拋出異常顯示的代碼行
• 獲取當時的運行時信息--Gdb core文件 ，gdb attach到進程，查看堆棧，查看寄存器，設置breakpoint,watchpoint ,查看內部數據。
• 獲取程序和系統信息---Strace查看系統調用，系統狀態獲取（ps,top,/proc/pid/*,vmstat,netstat）
• 更深入的手段--反匯編（IL Spy）、查看寄存器，gdb高級應用

注：

gdb工具：UNIX及UNIX-like下的調試工具，像VC、BCB等IDE的調試。

后端測試bug定位

日志查看命令

• 查看壓力--tail -f as.log | grep '^NOTICE' | awk '{print $3}' |uniq -c
• 排除日志中的特定內容——grep -v 'pattern' as.log
• 只輸出感興趣的內容——grep -o 'proctime:toal:d+' as.log；grep -o 'proctime:toal:d+' as.log | grep -o 'd+ '；grep -o 'proctime:toal:d+' as.log | grep -o 'd+ ' | sort -n | uniq -c
• 將wf日志歸類——grep -o 'w+.(cpp|h):d+' as.log.wf | sort | uniq -c

gdb常用命令

• bt——查看堆棧信息
• print——打印某變量值
• break——設置斷點
• x/i——翻譯當前指令為匯編
• info thread——查看所有線程，星號*標記的是當前線程
• thread num——切換到線程號為num的線程
• set scheduler -locking on——鎖定在線程：輸入continue命令以后，當前線程繼續執行，其它線程不執行
• set scheduler-locking off——這是默認設置，輸入continue命令以后，所有線程都繼續執行

性能測試

• 旨在獲取系統在特定一種或多種環境下，在不同的外部輸入壓力(包含極限)的條件下的系統各項指標的測試
• 進程相關——ps，top，/proc/pid/*
• 系統相關——vmstat,top,iostat,sar,df,lsof
• 網絡相關——netstat

bug定位歸因：

1.壓力工具方面

• 工具的功能和性能--能否達到預期壓力，啟動壓力的機械性能，壓力工具是否有異常連接關閉，壓力工具如何處理異常，長連接短連接，并發個數
• 工具運行環境--壓力機器的帶寬，是否跨機房。

2.被測試系統方面

• 機器性能--系統所在機器性能，機器網絡帶寬，機器的內存，SD卡，硬盤等
• 系統本身--系統的下游模塊的性能，系統的配置，系統的數據量，系統的特點狀態（cache、dump、merge），系統的部署，程序的bug等

3.環境方面

• 操作系統相關---是否和線上一致，內核版本，刷臟葉時間，有沒有調用directIO
• 查看系統狀態--Ps,top,/proc/pid/*,vmstat,netstat.

注：

正確的思路+豐富的業務知識+豐富的技術背景知識+較好的調試和開發能力 = 強大的bug定位能力。

Web測試流程

功能測試

1.鏈接測試：鏈接測試必須在集成測試階段完成

2.表單測試：提交信息

3.Cookies測試：Cookie是指網站用于辨別身份，進行會話（session）跟蹤而存儲在客戶端的數據。源頭：服務器產生并發送給客戶端的。用途：提供一個方便的功能以簡化用戶輸入，節省訪問頁面的時間。

cookies創建對象類型：JavaScript、VBScript等HTLM頁面中的客戶端腳本，使用MS win32 Internet函數（Internetsetcookie和Internetgetcookie）的win32程序、JSP/ASP等頁面中的服務器端腳本。

禁用Cookie：1.可能會導致某些web系統無法正常運行 2.使用戶無法進行匿名訪問3.使web系統無法跟蹤用戶的瀏覽習慣。

第三方Cookie和第一方Cookie：1.第一方cookie是與宿主域名相關聯的cookie2.第三方cookie是來自任何其他域名的cookie

持久Cookie和會話Cookie：會話cookie是Cookie存儲在內存中，持久cookie是cookie儲存在硬盤中，被寫入用戶配置文件夾下的cookie文件夾，瀏覽器臨時文件索引會使用指向cookie文件的指針進行更新。

cookie測試：

a.會話cookie測試：重新登錄時沒有上次操作的痕跡。

b.持久cookie測試的常規測試：重新登錄時保留上次操作的痕跡。

c.持久cookie測試的更新測試：重新登錄前進行其他操作，檢查是否仍保留上次操作的痕跡。

d.持久cookie測試的設置測試：在瀏覽器中對cookie是否禁用或者cookie的使用級別進行測試。如在IE瀏覽器的“選項”功能中，“安全”選項卡和“隱私”選項卡就可以對cookie進行設置。

4.設計語言測試：版本的差異可以引起客戶端或服務器端嚴重的問題。除了 HTML 的版本問題外，不同的腳本語言，例如 Java 、 JavaScript、 ActiveX 、 VBScript 或 Perl 等也要進行驗證。

5.數據庫測試：數據庫為Web提供空間，在 Web 應用中，最常用的數據庫類型是關系型數據庫，可以使用 SQL 對信息進行處理。兩大錯誤類型：數據一致性錯誤和數據輸出錯誤。

數據一致性錯誤：主要是由于用戶提交的表單信息不正確而造成的

輸出錯誤：主要是由于網絡速度或程序設計問題等引起的。

性能測試（測試工具：LoadRunner）

1.連接速度測試：用戶連接到 Web 應用系統的速度根據上網方式（電話撥號、寬帶上網）的變化而變化。另有超時限制等。

2.負載測試：測量 Web 系統在某一負載級別上的性能，以保證 Web 系統在需求范圍內能正常工作。負載級別可以是某個時刻同時訪問 Web 系統的用戶數量，也可以是在線數據處理的數量。

3.壓力測試：壓力測試是測試系統的限制和故障恢復能力，也就是測試 Web 應用系統會不會崩潰，在什么情況下會崩潰。黑客常常提供錯誤的數據負載，直到 Web 應用系統崩潰，接著當系統重新啟動時獲得存取權。壓力測試的區域包括表單、登陸和其他信息傳輸頁面等

4.網頁性能Firefox插件：Yslow，Findbug，PageSpeed

5.Dynatrace檢查網頁性能（性能分析工具）

6.LoadRunner性能測試工具原理：錄制+回放模擬用戶實際操作場景，監控并分析運行結果。

可用性測試

1.導航測試： Web 應用系統的用戶趨向于目的驅動，很快地掃描一個 Web 應用系統，看是否有滿足自己需要的信息，如果沒有，就會很快地離開。導航的另一個重要方面是 Web 應用系統的頁面結構、導航、菜單、連接的風格是否一致。確保簡潔明了。

2.圖形測試：一個 Web 應用系統的圖形可以包括圖片、動畫、邊框、顏色、字體、背景、按鈕等，確保圖形有明確的用途。作用：廣告宣傳、美化頁面。格式：一般用JPG或GIF壓縮。

3.內容測試：用來檢驗 Web 應用系統提供信息的正確性、準確性和相關性。（商品價目表、office糾錯功能、網頁拓展鏈接功能）

4.整體界面測試：指整個 Web 應用系統的頁面結構設計，是給用戶的一個整體感。方式：調查問卷形式。

兼容性測試

1.平臺兼容性測試：操作系統類型windows 、 Unix 、 macintosh 、 Linux等，與用戶系統的配置有關。

2.瀏覽器測試：瀏覽器是 Web 客戶端最核心的構件，來自不同廠商的瀏覽器對 Java 、 JavaScript 、 ActiveX 、 plug-ins 或不同的 HTML 規格有不同的支持。包括瀏覽器類型及版本測試。另外，框架和層次結構風格在不同的瀏覽器中也有不同的顯示，甚至根本不顯示。不同的瀏覽器對安全性和 Java 的設置也不一樣。方式：創建兼容性矩陣。

ActiveX 是 Microsoft 的產品，是為 Internet Explorer 而設計的；
JavaScript 是 Netscape 的產品；
Java 是 Sun 的產品

安全性測試

1.測試區域：Web 應用系統基本采用先注冊，后登陸的方式。測試重點內容：必須測試有效和無效的用戶名和密碼，要注意到是否大小寫敏感，可以試多少次的限制，是否可以不登陸而直接瀏覽某個頁面等。

2. Web 應用系統是否有超時的限制，即登錄超時提醒。

3.保證 Web 應用系統的安全性，保留日志文件。實現測試信息記錄及可追蹤性。

4.當使用了安全套接字時，還要測試加密是否正確，檢查信息的完整性。

5.服務器端的腳本常常構成安全漏洞，這些漏洞又常常被黑客利用。需測試沒有經過授權，就不能在服務器端放置和編輯腳本的問題。

自動化測試

主要方式：錄制+回放+腳本。

常用的自動化測試工具：

功能測試工具：QTP

性能測試工具：LoadRunner

• 寫腳本或者錄制腳本
• 使用用戶自定義參數
• 場景設計
• 產生虛擬用戶的機制：使用控制器，來控制模擬多少用戶。
• 使用監聽器，查看測試結果

(1)、驅動模塊（driver）：相當于所測模塊的主程序。它接收測試數據，把這些數據傳送給所測模塊，最后再輸出實際測試結果；

(2)、樁模塊（stub）:用于代替所測模塊調用的子模塊。樁模塊可以做少量的數據操作，不需要把子模塊所有功能都帶進來，但不容許什么事情也不做。

打樁：一般在做單元或集成測試時，如果某個程序單元的某條語句，需要調用的一個外部函數還沒有設計、編碼、調試完成的話，可以只讓它簡單地返回幾個支持測試用例的值就可以了，這種狀態的外部函數一般就叫做“打樁”。