軟體測試流程及方法詳解
軟體測試型別（共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）:用於代替所測模組呼叫的子模組。樁模組可以做少量的資料操作，不需要把子模組所有功能都帶進來，但不容許什麼事情也不做。
打樁：一般在做單元或整合測試時，如果某個程式單元的某條語句，需要呼叫的一個外部函式還沒有設計、編碼、除錯完成的話，可以只讓它簡單地返回幾個支援測試用例的值就可以了，這種狀態的外部函式一般就叫做“打樁”。