軟體測試技術
軟體測試技術
軟體的概念：資訊處理系統的所有或部分程式、規程、規則和任何相關的文件的集合。
程式：源程式+目標程式
源程式：高階語言、組合語言編寫的程式
目標程式：源程式經編譯或解釋加工以後可以由計算機直接執行的程式
文件：用自然語言或形式化語言所編寫的文字資料和圖表，用來描述程式的內容、組成、設計、功能規格、開發情況、測試結果以及使用方法。
軟體測試包括：源程式+目標程式+文件
軟體測試的定義：使用人工或者自動手段，來執行或測試某個系統的過程。其目的在於檢測它是否滿足規定的需求或弄清預期結果與實際結果之間的差別。
測試過程（瞭解） 每一階段都要從頭來一次
需求測試：需求文件的測試
測試的計劃：對測試過程的整體設計，確定測試範圍，制定測試策略，安排測試資源，進度制定，風險評估，應對策略
測試設計及用例：測試設計，用例設計，用例評估
測試的執行：用例的選擇（難得?複雜的？優先順序高的？），測試環境的搭建，每日構建
測試的記錄和跟蹤：Bug記錄，Bug管理，Bug的報告（溝通，評審，提交），Bug的跟蹤
迴歸測試：再測一次
測試總結和報告：缺陷的分類報告，客觀全面的報告生成，經驗總結
測試的分類
按測試的方法分類：
靜態測試和動態測試，白盒測試，黑盒測試，灰盒測試，冒煙測試，迴歸測試，功能測試與效能測試，壓力測試和負載測試，配置測試，文件測試，相容性測試，安全測試，恢復測試，可移植性測試，引導測試，隨機測試，手動和自動測試，通過/失敗測試，錯誤猜測，易用性，安裝性，介面性。
按測試的階段分類：單元測試，整合測試，（確認測試），系統測試，（驗收測試 a測試，b測試）
測試的原則：
投入和產出平衡（當有兩次bug趨於0，當第三次出現就停止測試繼續開發）
二八原則
儘早的和不斷開展測試
錯誤的地方多投入
同化問題：交叉測試，利用不同人的觀點
需求的測試
需求佔缺陷比例高達56%
需求可能存在的問題
需求文件編寫有問題、功能不明確，流程不清晰，不正確佔50%，餘下50%是需求的遺漏造成的。
拿著一線文件（需求卡片），需求規格說明書和卡片進行對比，所有規格都已經有了，再使用檢查列表對需求說明書進行優化，看有沒有歧義，語法上的錯誤，再結合所有的專案組人員進行討論，評審，修訂，看看需求規格說明書上有沒有什麼不能實現，需不需要再找客戶。
檢查列表
第一步：對比需求
第二步：檢查列表檢查需求
第三步：根據定稿的需求規格說明書來分析我們測試用例，以備測試
測試計劃
測試計劃的內容（瞭解）：
確定測試範圍
制定測試策略
測試資源安排
進度及安排
風險及對策
測試範圍:功能，效能
策略：測試方法
資源進度安排：人，物，時間。細化到最小顆粒逐漸反推相加
測試用例設計
基於需求的測試用例設計：
驗證需求是否正確，完整性，無二義性，並且邏輯一致性
從黑盒角度設計出充分並且必要的測試集
基於需求的測試需要工具支援，比如QC
測試用例設計：
等價類劃分法
邊界值分析法
因果圖法
基本路徑分析法
場景設計法
錯誤猜測試
正交分解法
……..
黑盒測試的基本概念:
窮舉輸入測試是不實現的。這就需要我們認真研究測試方法，以便能開發出儘可能少的測試用例，發現儘可能多的軟體故障。
常用的黑盒測試方法有等價類劃分，邊界值分析，決策表測試等，每種方法各有所長，我們應針對軟體開發專案的具體特點，選擇合適的測試方法，有效地解決軟體開發中的測試問題。
等價類劃分：
等價類劃分是一種典型的黑盒測試方法，它完全不考慮程式的內部結構，只根據程式規格說明書對輸入範圍進行劃分，把所有可能的輸入資料，即程式輸入域劃分為若干個互不相交的子集，稱為等價類，然後從每個等價類中選取少數具有代表性的資料作為測試用例，進行測試。
在確立了等價類之後，可按下表的形式列出所有劃分出的等價類表
等價類表
同樣，也可按照輸出條件，將輸出域劃分為若干個等價類
在設計測試用例時應同時考慮有效等價類和無效等價類測試用例的設計。根據等價類表設計測試用例，具體步驟如下：
- 為每個等價類規定一個唯一的編號
- 設計一個新的測試用例，儘可能多的覆蓋尚未被覆蓋的有效等價類，重複這一步，直到測試用例覆蓋了所有的有效等價類。
- 設計一個新的測試用例，使其覆蓋並且只覆蓋一個還沒有被覆蓋的無效等價類。重複這一步，直至測試用例覆蓋了所有的無效等價類。
邊界值分析法
健壯性邊界值測試將會產生4n+1個測試用例
健壯性測試最有意義的部分不是輸入，而是預期的輸出，觀察例外情況如何處理
等價類劃分+邊界值法
因果圖法
因果圖法的原理
因果圖法測試用例的設計步驟
- 確定軟體規格中的原因和結果。分析規格說明中哪些是原因（即輸入條件或輸出條件的等價類），哪些是結果(即輸出條件)，並給每個原因和結果賦予一個識別符號。
- 確定原因和結果之間的邏輯關係。分析軟體規格說明書中的語義，找出原因與結果之間，原因與原因之間對應的關係，根據這些關係畫出因果圖。
- 確定因果中的各個約束。由於語法或環境的限制，有些原因與原因之間，原因與結果之間的組合情況不可能出現。為表明這些特殊情況，在因果圖上用一些記號表明約束或限制條件。
- 把因果圖轉化為決策表
- 根據決策表設計測試用例
決策表法（不會考）
決策表通常由條件樁，條件項，動作樁和動作項4部分組成。
因果圖+決策表
動作項和條件項緊密相關，指出在條件項的各組取值情況下應採取的動作。
生成的決策表
練習：見測試方法.doc 和 PPT上的例子，實驗報告中的例子
場景設計法
大部分軟體是由事件觸發來控制流程的，事件觸發時的情景就是所謂的場景
根據需求規格說明書中的用例規約來設計，正常的流程，異常分支應該怎麼做。主要是測流程，沒有測細節，還是要用等價類劃分來測試。
錯誤猜測法
是基於經驗的直覺推測程式中可能發生的各種錯誤，有針對性設計測試用例。
優點：充分發揮個人的經驗和潛能，命中率高
缺點：覆蓋率難以保證；過多的依賴個人的經驗。
注意：最重要的是要思考和分析測試物件的各個方面，多參考以前發現的Bug的相關資料，總結的經驗，個人多考慮異常的情況，反面的情況，特殊的輸入，以一個攻擊者的態度對待程式，那麼就能設計出比較完善的測試用例。
正交分解法
正交表法是一種有效減少測試用例個數的設計方法。
有效減少測試用例個數的測試用例方法。單因素覆蓋，成對覆蓋，三三組合覆蓋
PICT工具
測試的執行，測試的管理工具
BUGFREE的工作流程
在這個平臺上提交你的需求，比如說提交你發現的BUG，指派給某一個開發人員來完成，基本上指這個功能的開發人員，他在這個平臺上接到通知之後，對其進行修復，修復完成之後就會提醒測試人員，我已經修復好了請再測試一次，如果通過就把這個Bug關閉掉，如果沒有通過，就再次發給開發人員來進行修復。
BUG的狀態
測試執行中的關鍵
測試環境的準備
構建測試執行的平臺和安裝需要的軟硬體系統。
人員的安排
不僅包括指定哪些人蔘加功能測試，哪些人蔘加系統測試和誰負責測試環境的維護等，還要包括人員的培訓，知識的傳遞。
測試用例包括哪些內容：測試功能（目標），測試環境，測試要錄入的資料，測試的具體操作，預期結果，不包括實際結果。
測試執行的準備
培訓和知識傳遞
測試任務安排
測試環境的建立
測試環境的設定
測試自動化執行平臺
白盒測試
靜態白盒測試和動態白盒測試
靜態白盒測試：主要測三個方面軟體的設計，體系結構和程式碼。從而找出軟體缺陷的過程，有時也稱為結構化分析
原因：儘早發現軟體錯誤；為黑盒測試人員提供建議
方式：1.確定問題2.遵守規則3.準備期間4.編寫報告
方法：互查，走查，會議評審。
互查：小組之間成員之間交流互相交流原始碼，怎麼去呼叫原始碼，對方如何呼叫處理，增進感情。
走查：每個專案會派出代表，或者專案主的每個成員都會出來陳述程式碼第一步怎麼做，第二部怎麼做……，或者用什麼樣的演算法去提高底層的效率。
好處：檢查程式碼的註釋是否寫好，效率是否有問題。把控整個小組的程式碼風格（如命名風格，申明變數的風格）。
會議評審:公司的高層會派一個專家組進駐你的專案，然後看看你的專案設定或者編碼情況。但是成本高。因為專家進來之前對這個專案不是很熟悉，專家組需要一定的時間來了解這個專案。
動態白盒測試
檢查程式碼並觀察執行狀況
利用檢視程式碼（做什麼）和實現方法（怎麼做）得到的資訊來確定哪些需要測試，哪些不要測試，如和開展測試
又稱為結構化測試
動態白盒測試期望達到的目的
所有獨立路徑至少都能測試一遍
所有邏輯判斷都能測試True和False兩條路徑；
所有迴圈結構都能測試到邊界和迴圈域內的情況；
確保內部資料結構的有效性。
白盒測試主要的方法
邏輯覆蓋測試法
基本路徑測試法
迴圈路徑覆蓋法
邏輯覆蓋測試法
語句覆蓋：每條語句至少執行一次
判定覆蓋：每個判定的每個分支至少執行一次
條件覆蓋：每種條件下的語句都應該被執行
判定/條件覆蓋：同時滿足判定覆蓋和條件覆蓋
條件組合覆蓋：每個判定中，各條件的每一種組合至少出現一次。
路徑覆蓋：程式中每一條可能的路徑至少執行一次。
基本路徑測試法（閱讀程式碼->畫出流程圖->圈複雜度->設計測試用例->進行相關測試）
基本路徑測試法是在程式控制流圖的基礎上，通過分析控制構造的環路複雜性，匯出基本可執行路徑集合，從而設計測試用例的方法。
路徑是控制流程圖中節點的順序，始於入口節點，止於出口節點
程式可能通過的路徑是：
路徑 1：1 – 11
路徑 2：1 – 2 – 3 – 4 – 5 – 10 – 1 – 11
路徑 3：1 – 2 – 3 – 6 – 8 – 9 – 10 – 1 – 11
路徑 4：1 – 2 – 3 – 6 – 7 – 9 – 10 – 1 – 11
圈複雜度的計算：
- 邊-節點+2
- 封閉+1
- 矩陣模型（可以不用掌握）
迴圈路徑覆蓋法
五種測試用例
- 整個跳過迴圈
- 只有一次通過迴圈
- 兩次通過迴圈
- m次通過迴圈,m<迴圈最大次數
- n-1,n,n+1次通過迴圈
實際運用中，基本路徑+迴圈使用的最多
將測試進行分段
測試越早發生越好
程式碼分段構件和測試，最後合在一起形成更大的部分
單元測試：介面，資料邊界，路徑，異常，區域性變數（資料）
可測可不測:條件組合，效能，功能
單元測試概念
定義:單元測試時對軟體基本組成單元進行的測試
時機：在程式碼完成後由開發人員完成，QA人員輔助
意義：儘早發現錯誤，發現的越早成本越低
單元測試內容
執行單元程式有時需要基於被測單元的介面，開發相應的驅動模組和樁模組
驅動模組
驅動模組：對底層或子層模組進行測試所編寫的呼叫這些模組的程式。
樁模組:對頂層或上層模組進行測試時所編寫的替代下層模組的程式。
整合測試
對於傳統軟體來說，按整合粒度不同，可以把整合測試分為3個層次，即:
- 模組間整合測試
- 子系統內整合測試
- 子系統間整合測試
整合測試的模組
漸增式測試模組與非漸增式測試模組
非漸增式測試模式：先分別測試每個模組，再把所有模組按設計要求放在一起結合成所要的程式，如大棒法(先測試最小模組，再測試最大的模組)
大棒方式的優缺點
好處：非常快捷
壞處：容易出錯，一旦出現錯誤，不知道是哪個模組出現的錯誤
漸增式測試模式：把下一個要測試的模組同已經測試好的模組結合起來進行測試，測試完以後再把下一個應該測試的模組結合進來測試。當使用漸增方式把模組結合到程式中去時，有自頂向下和自底向上兩種整合策略和混合
自頂向下的優缺點
優點：可以縱觀全域性，很快的發現軟體測試文件出現的問題
自底向上的優缺點：
效率高，但是需要大量的驅動
自頂向下和自底向上整合策略
驅動程式/驅動模組(driver)，用以模擬被測模組的上級模組。驅動模組在整合測試中接收測試資料，把相關的資料傳送給被測模組，啟動被測模組，並打印出相應的結果。
樁程式/樁模組(stub)，也有人稱為存根程式，用以測試被測模組工作過程中所呼叫的模組。樁模組由被測模組呼叫，它們一般只進行很少的資料處理，例如列印入口和返回，以便於檢測被測模組與其下級模組的介面。
系統測試
需求分析階段：測試需求規格說明書，是否與使用者要求一致
概要設計階段：測試概要設計說明中是否覆蓋了所有已確定的需求，是否考慮了後期維護
詳細設計階段：資料結構，演算法是否正確，編碼規範
編碼階段： 單元測試，整合測試
系統驗收階段：測試系統是否完成了需求規格說明書中的所有內容
系統測試概念
使用人工或自動手段來執行或測試某個系統的過程，其目的在於檢驗它是否滿足規定的系統需求或是弄清預期結果與實際結果之間的差別。系統測試在真實環境下進行
驗證(Verificaiton)
驗證確定工作產品正確反應了它們的規定需求。換言之，驗證保證"你正確地構件了它"
確認(Validation)
確認確定提供的產品將滿足其預期使用。換言之，確認保證"你構建了正確的產品"
為了發現發現卻缺陷並度量產品質量，按照系統的功能和效能需求進行的測試
一般使用黑盒測試技術
一般由獨立的測試人員完成
對於模組之間互動性比較強的軟體，還會有單獨的整合測試，用來發現模組介面之間的錯誤。
系統測試的內容(瞭解哪個是那個)
功能測試
恢復性測試（災難測試，容錯測試）
可用性測試
安全性測試
介面測試
GUI測試
安裝/升級測試
配置測試/相容性測試
國際化（語言）測試
使用者文件測試
……
效能測試
壓力測試
容量測試
可靠性測試
邊界測試
……….
冒煙測試
迴歸測試
隨機測試
硬體系統專有測試
可靠性試驗
可產生性測試
可維護性測試
自動化測試
效能測試包括以下幾個方面
評估系統的能力。測試中得到的符合和相應時間等資料可以被用於驗證所計劃的模型的能力，並幫助做出決策。
識別系統中的弱點。受控的負荷可以被增加到一個極端的水平並突破它，從而修復系統的瓶頸或薄弱的地方。
系統調優。重複執行測試，驗證調整系統的活動得到了預期的結果，從而改進效能，檢測軟體中的問題。
效能測試的概念
效能測試主要驗證軟體是否達到需求規格說明書中規定的各類效能指標，並滿足一些行效能相關的約束和限制條件。
主要有：響應時間，併發使用者，吞吐量，伺服器效能，點選率，響應成功率
效能測試的分類（誰是誰，有什麼區別）
壓力測試
負載測試
併發測試
配置測試
負載測試
負載測試是通過逐步增加系統工作量，測試系統能力的變化，並最終確定在滿足功能指標的情況下，系統所承受的最大工作量的測試。
壓力測試實質上就是一種特定型別的負載測試
併發測試是一種測試手段，在壓力測試中可以利用併發測試來進行壓力測試
負載測試是模擬實際軟體系統所承受的負載條件的系統負荷，通過不斷載入（如逐漸增加模擬使用者的數量）或其它載入方式來觀察不同負載下系統的響應時間和資料吞吐量、系統佔用的資源（如CPU、記憶體）等，以檢驗系統的行為和特性，以發現系統可能存在的效能瓶頸、記憶體洩漏、不能實時同步等問題。負載測試更多地體現了一種方法或一種技術。
壓力測試是在強負載（大資料量、大量併發使用者等）下的測試，檢視應用系統在峰值使用情況下操作行為，從而有效地發現系統的某項功能隱患、系統是否具有良好的容錯能力和可恢復能力。壓力測試分為高負載下的長時間（如24小時以上）的穩定性壓力測試和極限負載情況下導致系統崩潰的破壞性壓力測試。
壓力測試可以被看作是負載測試的一種，即高負載下的負載測試，或者說壓力測試採用負載測試技術。通過壓力測試，可以更快地發現記憶體洩漏問題，還可以更快地發現影響系統穩定性的問題。
效能測試的流程
自動化效能測試原理
首先保證一個使用者能正常訪問，記錄訪問過程，記錄通訊包
通過測試工具模擬更多使用者同時發通訊包，後臺無法區分是人或工具
通過測試工具模擬大量使用者同時向後臺發出請求，來達到產生壓力和指定壓力的目的，在產生指定壓力的同時監控後臺系統的資源消耗情況，監控客戶端的請求處理時間
複製出客戶端發往服務端的請求，模擬使用者
關注的是通訊包，協議，不關心客戶端形式
關於LoadRunner
LoadRunner是Mercury Interaction公司開發一款成熟的效能測試工具，LoardRunner作為效能測試的實現者，涉及效能測試流程，效能測試技術和軟體系統架構等眾多方面的知識點。
LoardRunner提供的解決方案
LoadRunner的過程
指令碼生成器Virtual User Generator
VuGen提供了基於錄製的視覺化圖形開發環境，可以方面簡潔地生成用於負載的效能指令碼。
壓力排程和監控系統Controller
負責對整個負載的過程進行設定，制定負載的方式和週期，同時提供了系統監控的功能。
壓力生成器Load Generator
負責將VuGen指令碼複製成大量虛擬使用者對系統生成負載。
結果分析工具Analysis
通過Analysis我們可以對負載生成後的相關資料進行整理分析。
自動化測試的步驟：
錄製一個操作的過程，稱為指令碼
回放一下，驗證指令碼是否正確
指令碼增強(引數化如密碼，使用者名稱。在指令碼中設定檢查點，檢查執行過程中是否執行成功，如果成功了就會出現字串或圖片。)
設定自動化測試執行的策略
事務，設定我們的場景（一開始多少執行緒啟動，做什麼樣的事情，到達某一時刻執行緒，其他一些零界點做什麼事情，執行緒在什麼時候停止，在什麼時候再啟動）在測試過程中觀察引數的變化（相應時間，等）
分析報告，在報告中我們檢視某個功能執行時間效率是否達到我們之前的設定，或者方差是我們期望的，否則進行調優。