《測試之美》筆記

一、美麗的測試員

1.缺陷偵測率：

DDP = 找到的臭蟲數 / 出現的臭蟲數


2.使用者驗收測試（UAT）與部署前最後階段測試的缺陷偵測率：

DDP = 測試臭蟲數 / 測試臭蟲數 + 上線後臭蟲數


3.測試與品質中三個主要的成本：

（1）偵測成本（cost of detection）

（2）內部失效成本（cost of internal failure）：因為找到臭蟲造成的測試與開發成本。

（3）外部失效成本（cost of external failure）：當發行的產品不是無臭蟲的完美版本時，可能產生的支援、測試、開發等成本。


4.測試臭蟲的平均成本：

ACTB = (偵測成本 + 內部失效成本) / 測試臭蟲數


5.正式環境平均臭蟲成本：

ACPB = 外部失效成本 / 正式環境中臭蟲數


6.測試投資報酬率：

Test ROI = (ACPB - ACTB) x 測試臭蟲數 / 偵測成本


7.自動化迴歸測試比率：

RTA = 自動化迴歸測試數量 / (人工迴歸測試數量 + 自動化迴歸測試數量)


8.迴歸風險涵蓋率：

RRC = 覆蓋的迴歸風險數 / 已知的迴歸風險數


9.迴歸測試加速度：

ART = (人工迴歸測試時間 - 自動迴歸測試時間) / 人工迴歸測試時間




二、美麗的程序

1.模糊測試（fuzzing test）是一種利用隨機更換或擾亂輸入資料測試程式的方法，包含：

（1）常規模糊：對某個輸入資料摧毀或修改，再用結果進行測試。

＊使用時機：模擬其他辦公室應用程式的行為以及隨機的的損毀。

（2）客制模糊：深入功能與格式之中，整合對應用程式與檔案格式的特定知識到測試程序之中。

＊使用時機：當常規模糊的效果開始衰退時。

（3）隨機模糊：不要求任何輸入格式，即可測試。

＊使用時機：非結構性或不規則的輸入。


2.一件缺陷報告是發現缺陷的人與擁有專業能夠修正的人之間溝通的管道，所有的缺陷追蹤系統要追蹤誰登錄缺陷、誰修正缺陷，與誰驗證了缺陷修正完畢。


3.缺陷報告應包含的資料：

（1）描述。

（2）細節描述。

（3）優先順序。

（4）嚴重程度。


4.要分析測試逃逸臭蟲，要將每隻臭蟲依下列成因分類：

（1）誤報臭蟲。

修正行動：將臭蟲移轉到正確的狀態，需要強調臭蟲回報準則，並教育回報人員如何正確回報臭蟲。

（2）不完整測試案例。

修正行動：檢查測試案例相關的功能面，加強並重設設計測試案例。

（3）無測試案例。

修正行動：根據造成臭蟲原因的功能實作測試案例。

（4）測試執行問題。

修正行動：檢查執行程預或相關軟 / 硬體。

（5）錯誤測試案例。

修正行動：檢查測試的功能，是否在測試案例完成後有所更動。

（6）錯誤功能規格。

修正行動：聯絡設計人員 / 開發人員，檢查功能規格審查程序，是否太過模糊？


5.自動化測試的生命週期：

（1）撰寫自動測試。

（2）選擇測試與測試的平台。

（3）執行測試。

（4）搜集報表需要的測試結果。

（5）回報新臭蟲與已修正的臭蟲。


6.要將原本效率不彰的系統轉變為美麗系統的步驟：

（1）撰寫更好的測試，同時確認測試命令稿與程式都納入原始碼控制系統，以及測試會通過某形式的持續整合程序，確保測試品質與一致性都達到要求。

（2）設定執行自動化測試的基礎設施，找出將測試分派到這些主機執行的方法。

（3）收集與統整簡單的高階測試結果，找出將測試失敗記錄到臭蟲資料庫的方法。

（4）研究如何才能自動地分析失敗報告，區分出新的失敗與原有的錯誤。

（5）找出為了讓系統正常運作，測試人員需要花費大量時間與精力維護的地方，找出自動化這些工作的方法。


7.變更中心式測試是捕捉所有程式碼變更對最終執行檔直接與間接影響，執行能夠保證覆蓋累積所有變更的測試案例。


8.變更中心式測試步驟：

（1）瞭解執行檔中各函數 / 方法間的呼叫者-被呼叫者相依關係。

（2）瞭解原始碼檔案與測試案例的對應以及涵蓋率。


9.效能測試通常聚焦在交易的執行時間；多使用者測試中，目標並不在時間，而在於多個使用者同時執行動作時所產生的效果。


10.具有可讀性的範例包含了五點特質：

（1）宣告：表達該做什麼，而非如何做。

（2）簡潔：只包含不可或缺的內容。

（3）清楚：兩個人能到相同的理解。

（4）自主：有獨立性，不需要其他實例解釋。

（5）錯誤：完整包含情境。

（6）定位清楚：有組織且可搜尋。


11.不要在真正開始開發之前，太早開始規劃主題雨情記優先權可能會改變，而且當你開始處理這些情境時，需要有最新的資訊。


12.SLIME 測試程序：

（1）S：安全

（2）L：語言

（3）I：需求

（4）M：測量

（5）E：現存