1 測試過程
1.1 測試階段划分
測試階段划分：需求測試（重點）、單元測試、集成測試、系統測試（重點）、驗收測試、回歸測試
需求測試
定義：通過評審來測試需求（通過不同級別不同類型的評審來避免人員意見）
單元測試
定義：針對軟件基本組成單元（軟件的最小組成單元：函數，語句塊等）來進行正確性檢驗的測試工作
目的：檢測軟件模塊對《詳細設計說明書》的符合程度
集成測試
定義：將所有模塊按照《概要設計說明書》的要求組裝成子系統或者系統，驗證組裝后的功能以及模塊間接口是否正確的功能
目的：檢測軟件模塊對《概要設計說明書》的符合程度
系統測試
定義：將已經集成好的軟件系統，作為整個基於計算機系統的一個元素，與計算機硬件、外設、某些支持軟件、數據和人員（用戶）等其他系統元素結合在一起，在實際運行（使用）環境下，對計算機進行一系列的測試工作
目的：通過與《需求規格說明書》作比較，發現軟件與系統需求定義不符合或與之矛盾的地方
回歸測試
定義：軟件在測試或其他活動中發現的缺陷經過修改后，應該進行回歸測試（Regression Testing）
目的：驗證缺陷得到了正確的修復，同時對系統的變更沒有影響以前的功能
回歸測試可以發生在任何一個階段，包括單元測試、集成測試和系統測試
回歸測試過程信息流：
回歸測試策略：
完全重復測試：重新執行所有在前期測試階段建立的測試用例，來確認問題修改的正確性和修改的擴散局部影響性。
選擇性重復測試：（新發現的缺陷用例，和覆蓋主要功能的用例）有選擇性重新執行部分在前期測試階段建立的測試用例，來測試被修改的程序。
選擇性重復測試的方法：
① 覆蓋修改法：針對被修改的部分，選取或重新構造測試用例，驗證有沒有錯誤再次發生的用例選擇方法；
② 周邊影響法：該方法不但要包含覆蓋修改法確定的用例，還需要分析修改的擴散影響，對那些受到修改間接影響的部分選擇測試用例驗證它沒有受到不良影響。周邊覆蓋法比覆蓋修改法更充分一點；
③ 指標達成方法：這是一種類似於單元測試的方法，在重新執行測試前，先確定一個要達成的指標，如修改代碼部分100%的覆蓋、與修改有關的接口60%的覆蓋等，基於這種要求選擇一個最小的測試用例集合。
回歸測試的流程：（以下流程適合單元測試、集成測試和系統測試）
① 在測試策略制度階段，制定回歸測試策略；
② 確定需要回歸測試的版本；
③ 回歸測試版本發布，按照回歸測試策略執行回歸測試；
④ 回歸測試通過，關閉缺陷跟蹤單；
⑤ 回歸測試不通過，缺陷跟蹤單返回開發人員，開發人員重新修改問題，再提交測試人員回歸測試。
回歸測試自動化：
① 回歸測試是重用以前成果的測試，很難預料要經過多少次回歸系統才能達到滿意的水平，結果，這種回歸測試將可能演變成為一種重復的、令人心煩意亂的工作，效果與人員的積極性大打折扣，因此，在回歸測試道路上的自動化便是我們工作的追求；
② 回歸測試的自動化法包括測試程序的自動運行、自動配置，測試用例的管理和自動輸入，測試的自動執行，測試信息與結果的自動采集，測試結果的自動比較和結果的自動輸出，尤其前面提到的各類數據的共享決策；
③ 對系統測試功能比較簡單、測試界面相對穩定並且測試用例良好組織的測試來說，采用“捕捉回放”工具比較合適，這類工具有QTP、Robot、SilkTest等；
④ 為了實現測試用例的自動化並實現測試結果的自動判斷，腳本話的、包含控制結構、內部實現結果判斷的測試用例是唯一的選擇，此類腳本語言有TCL、Python、Perl等；
⑤ 對特定系統的、復雜的測試來講，如果沒有通用的商用工具可供選擇，探索開發專用的自動化測試工具是靈活且 易於擴充的方法；
⑥ 回歸測試的自動化（或者說工具化）的問題是一個需要盡早考慮的問題，在做測試方案時就要考慮這種可能性，必要時要投入資源進行開發，能形成可供繼承的工具則是最終目的。
單元測試、集成測試和系統測試是軟件開發過程中在軟件組織內部進行的測試階段。軟件發布前還可能進行用戶參與的其他一些測試，如：驗收測試、α測試、β測試。
驗收測試
在通過了系統內部測試及配置審查之后，就可以開始驗收測試。
驗收測試是以用戶為主的測試，驗收組應該由項目組成員、用戶代表等組成。
驗收測試原則在用戶所在地進行，如經用戶同意也在公司內模擬用戶環境進行。
驗收測試根據合同、《需求規格說明書》或驗收測試計划對成品進行驗收測試。
驗收測試的結果有兩種情況：
① 軟件功能、性能等質量特征與用戶要求的一致，軟件可以接受；
② 軟件功能、性能等質量特征與用戶要求有差距，不被用戶接受。
α測試
定義：用戶在開發環境進行的測試，也可以是開發機構內部的用戶在模擬實際操作環境下進行的測試。是可控制環境，開發測試人員可以修改控制的環境。α測試時，軟件在一個自然狀態下使用，開發者在旁，隨時記錄錯誤情況和使用中的問題。這是在受控的環境下進行的測試。
目的：評價軟件產品的FLURPS（功能，局域化，可用性，可靠性，性能和技術支持）
β測試
定義：由軟件的多個用戶在一個或多個用戶的實際環境下進行的測試。與α測試不同的是，β測試時開發者通常不在現場，因而，β測試是在開發者無法控制的環境下進行的軟件現場應用。
單元測試，集成測試，系統測試的比較
測試方法不同
單元測試屬於白盒測試
集成測試屬於灰盒測試
系統測試屬於黑盒測試
考察范圍不同
單元測試主要測試單元內部的數據結構，邏輯控制，異常處理 等
集成測試主要測試模塊之間的接口和接口數據傳遞關系，以及模塊組合后的整體功能
系統測試主要測試整個系統相對於需求的符合度
評估基准不同
單元測試的評估基准主要是邏輯覆蓋率
集成測試的評估基准是接口覆蓋率
系統測試的評估基准主要是測試用例對需求規格的覆蓋率
1.2 測試過程模型
測試過程階段划分
測試計划階段：測試計划
測試設計階段：測試方案
測試實現階段：測試用例、測試規程
測試執行階段：測試報告
主要的測試文檔
測試計划：指明測試范圍、方法、資源，以及相應測試活動的時間進度安排表的文檔
測試方案：指明為完成軟件或軟件集成特征的測試而進行的設計測試方法的細節文檔
測試用例：指明為完成一個測試項的測試輸入、預期結果、測試執行條件等因素的文檔
測試規程：指明執行測試時測試活動序列的文檔
測試報告：指明測試執行結果的文檔
測試日報：每天測試執行情況的記錄和總結
常見測試過程模型：瀑布模型、H模型、V&V模型
瀑布模型
H模型：
H模型測試分兩類活動：
① 測試准備活動，包括測試需求分析、測試計划、測試設計、測試編碼、測試驗證
② 測試執行活動，包括測試運行、測試報告、測試結果分析等
H模型的特點：
① 軟件測試不僅僅指測試執行，還包括許多其他測試活動
② 測試是一個獨立的流程，貫穿產品整個周期，與其他流程並發地進行
③ 測試要盡早准備，盡早執行
④ 各個不同階段的測試除了簡單的時間上的先后關系外，還存在觸發、反復、迭代和增量關系
V&V模型
V&V模型的特點
① 實現了測試設計和測試執行相分離
② 揭示了軟件測試活動分層和分階段的本質特性，測試執行的順序與開發活動相反
驗證與確認：
驗證（Verification）：
① 保證軟件正確地實現特定功能的一系列活動
② 檢測每一階段形成的工作產品是否與前一階段定義的規格相一致
確認：
① 保證所生產的軟件可追溯到用戶需求的一系列活動
② 檢測每一階段的工作產品是否與最初定義的需求規格相一致
驗證與確認的關系圖
1.3 測試過程規范
CMM關於過程的要素
角色、入口准則、輸入、活動、輸出、出口准則、評審和審計等
集成測試過程
概要設計——詳細設計——執行集成測試
概要設計
輸入：SRS、系統測試計划
輸出：集成測試計划、系統測試方案、系統測試用例、預測試項、規程、階段報告
詳細設計
輸入： SRS、系統測試計划、系統測試方案、集成測試計划
輸出：單元測試計划、集成測試方案、集成測試用例、集成測試規程、階段報告
執行集成測試：
輸入： 單元測試報告、集成測試計划、集成測試方案、集成測試用例、集成測試規程
輸出：集成測試報告、階段報告
集成測試過程與開發階段
概要設計（集成測試計划）——詳細設計（集成測試設計、實現）——集成測試執行
集成測試各階段的輸入、輸出
集成測試計划階段：
輸入：軟件測試計划、概要設計說明書（HLD）
輸出：集成測試計划
集成測試設計階段：
輸入：概要設計說明書（HLD）、集成測試計划
輸出：集成測試方案
集成測試實現階段：
輸入：軟件測試計划、詳細設計說明書
輸出：單元測試計划
集成測試執行階段：
輸入：詳細設計說明書、單元測試計划
輸出：單元測試方案
單元測試過程
詳細設計——編碼——執行單元測試
單元測試各階段的輸入、輸出
單元測試計划階段：
輸入：軟件測試計划、詳細設計說明書（LLD）
輸出：單元測試計划
單元測試設計階段：
輸入：詳細設計說明書（LLD）、單元測試計划
輸出：單元測試方案
單元測試實現階段：
輸入：單元測試計划、詳細設計說明書、單元測試方案
輸出：單元測試用例、單元測試規程
單元測試執行階段：
輸入：單元測試方案、單元測試計划、單元測試用例、單元測試規程
輸出：單元測試報告、缺陷報告
需求分析階段的主要任務
① 需求分析，完成SRS
② SRS的評審
③ 進行需求跟蹤
④ 系統測試計划
⑤ 系統測試計划的評審
需求階段的角色和職責
軟件測試工程師：
① 參與SRS評審工作
② 協助軟件測試項目經理完成軟件系統測試計划寫作
③ 參加系統測試計划的評審
④ 完成本階段測試需求跟蹤
概要設計階段的主要任務
① 完成HLD
② 概要設計的評審
③ 系統測試方案、用例的設計
④ 系統測試方案、用例的評審
⑤ 需求跟蹤更新
⑥ 集成測試計划
⑦ 集成測試計划評審
概要設計階段的角色和職責
軟件測試工程師：
① 參與HLD評審
② 參與集成測試計划的評審
③ 進行系統測試方案、用例的設計
④ 參與系統測試方案、用例的評審
⑤ 完成本階段測試需求跟蹤
詳細設計階段的主要任務
① 進行軟件詳細設計，完成LLD
② 詳細設計的評審
③ 集成測試的方案、用例的設計
④ 集成測試的方案、用例的評審
⑤ 需求跟蹤更新
⑥ 單元測試計划
⑦ 單元測試計划評審
詳細設計階段的角色和職責
軟件測試工程師：
① 進行軟件詳細設計，完成LLD文檔
② 詳細設計的評審
③ 集成測試方案、用例的設計
④ 集成測試方案、用例的評審
⑥ 需求跟蹤更新
⑦ 單元測試計划
⑧ 單元測試計划評審
軟件編碼階段的主要任務
① 軟件編碼
② 代碼靜態質量檢查
③ 代碼評審
④ 單元測試方案、用例設計
⑤ 單元測試方案、用例評審
軟件編碼階段的角色和職責
軟件測試工程師：
① 參與代碼評審
② 進行單元測試方案、用例設計
③ 單元測試方案、用例評審
④ 完成本階段測試需求跟蹤
集成測試執行階段的主要任務
① 集成測試用例執行
② 集成測試缺陷記錄、修復
③ 集成測試日報寫作
④ 集成測試缺陷的回歸測試
UT/IT/ST執行階段的角色和職責
軟件測試工程師：
① 搭建測試環境
② 執行測試用例
③ 發現缺陷后提交缺陷報告
④ 回歸測試
⑤ 每天提交測試日報
⑥ 測試報告及系統測試預測試報告寫作
⑦ 參與測試報告的評審
⑧ 參與轉系統測試評審
2 測試方法
測試方法的分類：
按方法區分：白盒測試、灰盒測試、黑盒測試
按照是否執行被測程序區分：靜態測試、動態測試
根據執行測試的方式區分：人工測試、自動化測試
2.1 白盒測試
定義：依據被測軟件分析程序內部構造，並根據內部構造設計用例，來對內部控制流程進行測試，可完全不顧程序的整體功能的實現情況。白盒測試是基於程序結構的邏輯驅動測試。
為什么要進行白盒測試
它一般在測試前期進行，通過達到一定的邏輯覆蓋率使軟件內部邏輯控制結構上的問題能夠基本得到消除
保證內部邏輯結構達到一定的覆蓋程度，能夠給予軟件代碼質量更大的保證，白盒測試發現問題后解決問題成本較低
白盒測試的常用技術
靜態分析技術：控制流分析技術，數據流分析技術，信息流分析技術（不執行代碼）
動態分析技術：邏輯覆蓋率測試（分支測試，路經測試），程序插裝
控制流相關概念
程序元素：一個程序元素通常是一個條件，一個簡單的語句或者一塊語句（多個連續語句）
控制流關系：一個程序的控制流關系，敘述了程序元素和它們執行的次序之間的聯系
控制流圖：對應於控制流關系的圖
控制流矩陣：由控制流圖得到，反映相鄰程序元素之間的先后順序關系
控制流分析的步驟
1.確定所有程序元素
2.根據程序元素之間的相互關系得到控制流圖
3.將控制流圖轉換成控制流矩陣
4.通過數據結構的形式把控制流矩陣表示出來
控制流分析能發現的問題
轉向並不存在的標號
沒有用的語句標號
從程序入口進入后無法達到的語句
不能達到停機語句的語句
數據流相關概念
數據定義：如果程序中某一語句執行時能改變某程序變量V的值，則稱V是被該語句定義的
數據的引用：如果一語句的執行引用了內存中變量V的值，則說該語句引用變量V
數據流分析步驟
1.根據代碼得到數據流表
2.分析數據流表找到以下兩種錯誤：
3.變量未定義但被引用
4.變量定義但未被引用
信息流分析
可以導出程序的信息流的關系，為軟件開發的確認提供了工具。
通過以下三個關系表給出：
輸入變量和語句關系：輸入變量直接或間接影響語句的執行
語句和輸出變量關系：語句執行直接或間接影響變量的輸出
輸入和輸出變量關系：輸入變量直接或間接影響輸出變量
信息流分析步驟
根據代碼得到三個關系表
分析輸入變量和語句關系表
分析語句和輸出變量關系表
分析輸入和輸出變量關系表
邏輯覆蓋測試
根據覆蓋的對象不同：
語句覆蓋
判定覆蓋
條件覆蓋
判定—條件覆蓋
路徑覆蓋
,,,,,,
程序插裝
我們在調試程序，常常要在程序中打印一些語句，其目的在於，希望執行程序時，打印出我們最關系的信息。進一步通過這些信息了解執行過程中程序的一些動態特征。比如，程序實際執行路徑，或是特定變量在特定時刻的取值。
從這一思想發展出的程序插樁技術能夠按用戶的要求，獲取程序的各種信息，成為測試工作的有效手段。程序插樁簡單地說就是借助往被測程序中插入操作來實現測試目的的方法。
白盒測試的特點
優點：
1.迫使測試人員去自覺地思考軟件的實現
2.可以檢測代碼中的每條分支和路徑
3.揭露隱藏在代碼中的錯誤
4.對代碼的測試比較徹底
5.實現代碼結構上的最優化
缺點：
1.昂貴
2.無法檢測代碼中遺漏的路徑和數據敏感性錯誤
3.不驗證規格的正確性
2.2 黑盒測試
定義：只考慮其整體特性，不考慮其內部具體實現，是基於規格的測試
對象: 系統，子系統，子模塊，函數
黑盒測試類型和質量模型
來源於質量模型
將軟件的特性和質量特性結合起來就得到了測試類型
一個軟件特性可以和一個質量特性結合得到一個測試類型
一個軟件特性可以和多個不同的質量特性結合得到多個不同的測試類型
常見的黑盒測試方法
等價類划分法
邊界值分析法
因果圖分析法
判定表法
狀態遷移法
錯誤猜測法
………
注：不管是什么測試方法，都是為了減少測試時的測試用例數，都是為了用盡量少的測試用例去完成測試，去發現更多問題。
黑盒測試的特點
1.對於更大的代碼單元來說，比白盒測試效率更高
2.測試人員不需要了解實現細節
3.測試人員和編碼人員彼此獨立
4.從用戶和編碼人員視角進行測試，很容易被大家理解和接受
5.有助於暴露任何規格不一致或有歧義的問題
6.測試用例可以再規格完成之后馬上進行
7.只有一小部分可能的輸入被測試到 ，要測試每個可能的輸入流幾乎是不可能的
8.沒有清晰和簡明的規格，測試用例很難設計
9.溝通不到位會有問題
10.會有很多程序路徑沒有被測試到
11.不能直接針對特定的程序段，這些程序段可能非常復雜
2.3 灰盒測試
既利用被測對象的整體特性信息，又利用被測對象的內部具體實現信息，如:集成測試和系統測試時借助Log信息
2.4 靜態測試和動態測試
靜態測試：不運行被測試軟件系統，而采用其他手段和技術進行檢測的一種測試技術。例如：代碼走讀、文檔評審、程序分析
動態測試：按照預先設計的數據和步驟去運行被測軟件系統，從而對被測軟件系統進行檢測的一種測試技術。常用技術有動態分析技術。
靜態分析技術
定義：不通過執行程序而分析程序執行的技術
功能：檢查軟件的表示和描述是否一致，沒有沖突或者沒有歧義，它糾正軟件系統在描述、表示和規格上的錯誤，因此是任何進一步測試執行的前提
三種不同的程序測試可能性：
考慮程序是否滿足編碼規則，語法上是否具有一致性和完整性
考慮文檔描述是否規范、准確、便於查詢
考慮程序和文檔之間的一致性
靜態分析技術結構
手工靜態分析-同行評審
靜態分析技術中的一個重要的手工技術是同行評審，根據形式正規程度分為：正規檢視、技術評審和走查。
同行評審的對象：計划、需求文檔、設計圖、代碼等
自動化靜態分析
靜態驗證：檢測規格到程序實現之間轉換上的問題，驗證器需要有形式化的規格和規格的形式化定義，靜態驗證比較程序提供的實際值和在規范文檔中被預定義的目標值。
語法分析器：是一個基本的自動化靜態分析工具，把程序、文檔文本分解成獨立的語句。當在內部檢查程序、文檔文本的時候，語句一致性被進行了檢查。
符號執行器：在符號短語中分析一個程序在給定路徑上做的事情，它模擬程序的執行，計算程序在不同位置上變量的事，適合於相數學算法的分析。
動態分析技術
定義：對軟件系統運行行為進行分析，包含程序在受控的環境下使用特定的輸入進行正式的運行，和期望的結果比較以檢查系統運行是正確還是不正確。
常用的動態分析技術
路徑測試
分支測試
性能測試
……
常用動態分析類型及功能
| 動態分析類型 |
功能 |
| 測試覆蓋率分析 |
測試對代碼的檢測范圍 |
| 跟蹤 |
跟蹤程序執行期間的所有路徑，如變量的值 |
| 調整 |
度量程序執行過程中使用的資源 |
| 模擬 |
模擬系統的一部分，如無法獲得的代碼或硬件 |
| 斷言檢查 |
測試在復雜邏輯結構中是否某個條件已經被給出 |
人工測試和自動化測試
人工測試：測試活動由人來完成，狹義上是指測試執行由人工完成
自動化測試：指通過計算機模擬人的測試行為，替代人的測試活動，狹義上是指測試執行由計算機來完成
注：適用於重復多次、機械化的操作、大量的數據執行等。
適合自動化的活動
自動化測試執行
自動化測試檢查
自動化測試的意義
對程序新版本前一版本執行的測試，提高回歸測試效率
可以運行更多更頻繁的測試，如冒煙測試
可以執行手工測試困難或不可能做的測試，如大量的重復操作或集成測試
更好地利用資源，如測試儀器或被測對象
自動化測試的限制
不能取代手工測試，只能提高測試效率，不能提高測試有效性（不能發現更多缺陷）
手工測試比自動化測試發現的缺陷更多
對測試設計依賴性極大，測試設計的不好會遺漏問題
自動化測試對軟件開發具有很大的依賴性，開發上出現變更可能導致前面的自動化測試完會失效
工具本身並不具備想象力，工具不具有智能