——寫在前面，本文是對《軟體測試的藝術（第3版）》的觀後總結，記錄方便日後查閱複習。本文中的一些圖片都是參照自《軟體測試的藝術（第3版）》。

相對於別的書來說，這本書的可讀性非常高，並且有許多實用的例子，之後可能會多次回顧，因此在此記錄一些重點，以便查閱。

C2十條軟體測試的原則

1、測試用例中一個必須部分是對預期輸出的定義
2、程式設計師應當避免獨立測試自己編寫的程式
3、編寫軟體的組織（開發組）不應當測試自己編寫的軟體
4、應當徹底檢查每個測試的執行結果
5、測試用例的編寫不僅應當根據有效和預期的輸入情況，而且也應當根據無效和未預料到的輸入情況
6、檢查程式是否沒做到需求只是一半，另一半是檢查是否做了不該做的。
7、應避免測試用例用後即棄，除非是一次性軟體
8、計劃測試工作時不應該默許假定不會出錯
9、程式某部分存在更多錯誤的可能性，與該部分已發現錯誤成正比
10、軟體測試是一項極富創造性、極具智力挑戰性的工作

C3程式碼檢查

程式碼審查清單，同前書，記錄在Xmind中。
分爲數據參照錯誤；
數據宣告錯誤；
運算錯誤；
比較錯誤；
控制流程錯誤；
介面錯誤；
輸入\輸出錯誤；
其他檢查。

C4測試用例設計

最關鍵的問題：在所有可能的測試用例中，哪個子集最有可能發現最多的錯誤！

先通過特定黑箱測試設計用例，再使用白盒測試對邏輯結構進行檢查、補充用例。

黑箱測試

四種方法：等價劃分、邊界值分析；因果圖分析；錯誤猜測。

等價劃分

兩個原則：
嚴格控制測試用例的增加！
覆蓋大部分其他可能的測試用例。

步驟：
1、確定等價類：
列一個表格

外部條件	有效等價類	無效等價類
可登記1-6人	1-6人	0人，6+人

2、生成測試用例：
設定編號；
編寫新用例覆蓋儘可能多的有效等價類，直到所有都被覆蓋；
編寫新用例覆蓋一個無效等價類直到所有都被覆蓋。

邊界值分析

考慮邊界上下值以及輸入/輸出邊界。
1、如果-1.0——1.0，則考慮1.0,1.001,0.999等

2、輸入值數量邊界

3、輸出結果、數量邊界

4、其他內部、外部邊界條件

因果圖

對輸入組合狀態進行劃分。
本質上是一種數位邏輯電路。

過程：1、將規格說明分解爲可執行片段。

2、確定規格說明中的因果關係。（系統轉換也是果，如數據庫、檔案修改等）

3、分析規格說明的語意內容並轉換成因果布爾圖。

4、給圖加上註解符號。

5、跟蹤圖中狀態變化情況，將因果圖轉換成一個有限項的判定表，每一列代表一個用例。

6、列轉換成測試用例。

基本符號，∩and ∪or ∽not ——identity

約束符號E：ab不能同時爲1
i：abc中至少有一個是1（不能全0）
o：ab有且僅有一個必須爲1
R：如果a 1則b必須1

可以只使用判定表不畫因果圖！
https://www.cnblogs.com/test-123/p/9686346.html

建立有限項判定表時，步驟爲：
1、選擇一個果爲當前狀態
2、回溯查詢所有導致該果爲1的因組合
3、每個因組合生成一列
4、對於每種因組合判斷，放置。

原則：或：
結果0列所有情況
結果1不考慮全1情況

與：
結果1列所有情況
結果0列一個爲0情況
和所有都爲0的情況

錯誤猜測

依賴直覺與經驗！

白盒測試

關注測試用例執行的程度及覆蓋程式邏輯結構的程度。

判定覆蓋

每個單元必須有是和否的結果，每個入口點都必須被呼叫一次。

條件覆蓋

確保每一個判斷的每一個條件的所有可能結果至少執行一次。

測試策略

1、如果規格說明中包含輸入條件組合，應使用因果圖分析法

2、任何情況下都要使用邊界值分析方法

3、應爲輸入和輸出確定有效和無效等價類，在必要時對測試用例進行補充

4、使用錯誤猜測進行補充

5、使用白盒\多重條件覆蓋準則進行邏輯結構的檢查

C5模組（單元）測試

從程式中的單個子程式或過程開始進行測試（可同時進行多個）。

白盒測試

基本上都是使用上文中的白盒測試方法等設計有效的測試用例集。

if的所有路徑遍歷及邊界條件

增量測試（整合）

增量測試即將下一步要測試的模組組裝到測試完成的模組集閤中再進行測試。
大爆炸測試則反之。

驅動模組和樁模組：前者是將數據傳給被測模組的主模組；後者是被測試模組呼叫的模組。

優缺點：
可以使用之前測試過的模組作爲驅動模組，減少工作量；
可以較早發現模組中介面與假設相關錯誤（整合測試）；
便於定位錯誤；
更徹底地進行測試（整體性）；
佔用機器時間和資源多；
在專案剛開始沒法使用（模組分離情況下）。

自頂向下與自底向上測試

這兩種都是屬於增量測試的方法。

具體不作介紹。

注意檢測軟體是否完成了一些不該有的功能！

C6更高級別的測試

根據軟體生命週期進行測試

功能測試

發現程式與其外部規格說明（從使用者角度對程式的精確描述）之間存在不一致的過程。

使用黑箱測試中的四種方法：等價類、邊界、因果圖、猜測。

系統測試

並非測試系統功能，而是將系統或程式與其初始目標（可度量的書面目標）進行比較。

可以根據下面 下麪的測試用例分類進行測試用例的檢查與補充。

驗收測試

從客戶角度驗證可用功能及易用性。

安裝測試

安裝時間、檔案是否完整。

制定測試計劃

測試計劃：
目標；
結束準則；
進度；
責任；
測試用例庫及標準；
工具；
計算機時間；
硬體設定；
整合；
跟蹤步驟；
偵錯步驟；
迴歸測試。

預測bug數量

通過發現與修復Bug的數量與預測的進行對比，再加上測試周期的長度來決定測試是否結束。

易用性（使用者體驗）測試

應該考慮的部分要素

由於使用者文化差異導致的理解偏差和環境偏差？
程式的輸出是否有意義、能被理解？
錯誤資訊是否易懂？
用戶介面語意等是否正確連貫一致？
使用者名稱密碼等輸入框是否有輸入驗證，大小寫提示？
無用選項？
對於使用者移動滑鼠等操作是否能可見，有互動？
操作是否易於上手，上下級返回，查詢？
快速來回切換是否有問題？
最終功能是否完成設計規格要求？

與使用者（不同領域）聯繫溝通問卷調查。
E = 100 * （1-（1-L）^n）
E爲找到錯誤的比例，n爲測試人數，L爲單個測試人員發現的易用性問題比例

偵錯

發現問題後就得進行偵錯

蠻力法偵錯

1、利用記憶體資訊輸出偵錯；
2、根據在程式中插入print來偵錯
3、使用自動化偵錯工具偵錯。

歸納法偵錯

步驟：

演繹法偵錯

從普通的理論或者前提出發，使用排除和精煉的過程，找到錯誤。

回溯法偵錯

按照邏輯一點點找，工作量大

測試法偵錯

使用不同的測試用例輔助偵錯

偵錯的原則

1、動腦
2、長時間無法解決則留到之後
3、與他人交流
4、不第一時間使用偵錯工具
5、避免使用測試法
6、避免引入新錯誤

錯誤分析

位置？人？內容？下次如何避免？發現時間的早晚長短？

C9 敏捷開發模式下的測試

隨着競爭不斷增加，現在軟體基本都是敏捷開發，週期短且品質要求高，對測試的要求也逐漸變高！

敏捷開發特徵

提倡迭代式和增量式，圍繞客戶爲中心、以客戶需求爲導向進行開發，不斷迭代提升客戶滿意度。

敏捷測試

協同測試的一種形式。

客戶通過定義用例及程式屬性參與設計、開發者和測試者共同打造自動化測試配件。

在這種測試中，測試者不能僅僅找出錯誤，還需要協助開發修復bug、改變需求設計以及效能品質的提升。

極限程式設計和測試

輕量、敏捷，最大程度利用API進行程式設計。

關注點：
開發與客戶協同；
根據客戶指定規格說明和用例；
不斷測試程式碼庫；
尋求反饋（結對程式設計）。

其中測試很重要，首先要建立單元測試和驗收測試，再進行程式碼庫的建立。

極限單元測試

單元測試爲極限測試中的主要測試方法，有兩條簡單的規則：

所有程式碼模組在編碼開始之前必須設計好單元測試用例並在產品發佈之前通過。

C10網際網路應用測試

網際網路作爲最火熱的C/S模式程式，對於效能、易用性等要求非常高（使用者粘性弱）。

三層C/S架構可以當做三個具有清晰介面定義的黑盒，改變每一層都不會影響其他層。

第一層——Web伺服器，也被叫做表示層，主要是將內容視覺化後呈現給使用者。
第二層——業務層，執行應用伺服器（軟體），負責事務處理、使用者身份鑑定、數據確認和日誌。
第三層——數據儲存。

網際網路測試的特殊

1、使用者羣龐大且五花八門；
2、業務環境複雜；
3、使用者地點；
4、安全性；
5、測試環境;
6、相容性。

第一印象非常重要，因此首先進行測試的是易用性和人機互動介面。
對於伺服器、日誌、系統資源和備份的監控也非常重要，確保不出問題。
如果出了問題，也要使平均故障間隔時間最大（MTBF）並且平均故障恢復時間（MTTR）最小。

以下爲檢測三層一些常用的測試用例。

表示層的測試內容

1、內容測試；
2、Web站點結構測試（鏈接、圖形、檔案）；
3、使用者環境（相容性和操作系統）；

使用白盒測試的理論以及邏輯順序的全覆蓋來進行網頁GUI的測試。
確定需要支援的瀏覽器，注意一些比較容易出現問題的程式碼和控制元件的使用：
ActiveX、Html5、JavaScript、Adobe Flash、VBS、PHP、Java applets

業務層的測試內容

網際網路應用系統的業務邏輯中的錯誤，與測試單機程式類似，黑白盒共同使用。
如果是內部開發，則白盒優先，如果是外包則黑盒優先，從單元開始再進行系統測試。

主要測試項：
效能、數據有效性、事務。

效能測試
頁面載入時間，事務處理時間；一般用響應時間和吞吐率來進行定量衡量。
壓力測試也是進行效能測試的一種很好的方式（臨近失效點）。

數據驗證
主要判斷數據採集與真實值有無差別。

事務測試
是一種業務層專屬的系統測試，需要對內部業務和外部服務都進行完整的測試，確保內外正確通訊。

數據層的測試

主要是對應用系統用於儲存和獲取資訊的數據庫管理系統的測試。
最大的挑戰是複製應用系統的執行環境（設定）；
其次測試響應時間、數據完整性、容錯性和可恢復性（最大化MTBF最小化MTTR）

C11移動應用測試

挑戰主要在裝置和移動環境兩個方面。

移動環境

首先考慮裝置連線問題、網路速度、有效區域（偏遠地區）以及網路延時；
其次關注裝置多樣性、限制（記憶體快取尺寸操作系統多工等）、輸入手段等；
最後確認以何種方式安裝和維護應用程式。

裝置

主要分爲四類挑戰

裝置多樣性

具體同上述第二條所述，引出兩種不同的測試方法：真機和模擬器測試。

運營商網路基礎設施

支援不同運營商，不同地區使用的測試。

指令碼程式設計

對於模擬器可以較爲方便地進行自動化指令碼的編寫，對於真機除了必要的步驟進行手工操作，也得嘗試進行自動化指令碼的編寫。

易用性測試

使用者角度進行操作嘗試。

測試方法

借鑑網際網路測試第二第三層的測試方法，從效能規格、數據有效性以及事務處理元件進行測試；以及響應時間、數據完整性、容錯性以及可恢復性進行測試。