測試開發入門

推薦書籍：google軟體測試之道，測試工程師全棧技術進階與實踐

測試開發的意義：盡早發現問題，降低解決問題的成本

軟體開發模型：瀑布模型，V模型，W模型，靈活模型

軟體測試開發流程：

需求分析：分析功能點，核心競争力，Kano模型，馬斯洛需求分析，上下文分析法

制定測試用例：

使用思維導圖，先收後放。提煉重點，删除備援。

邊界值法，等價類劃分法，錯誤推測法，因果圖法

根據測試大綱制定測試用例，需包含子產品名，測試優先級，操作步驟，期望結果，測試結果

評審測試用例

執行測試

發現問題，保留現場

送出BUG，并推動BUG解決

送出BUG，詳細記錄測試步驟，劃分BUG等級

推動開發解決問題

回歸驗證

驗證已修複的BUG

對BUG所在子產品進行基本功能測試；整體進行冒煙測試，確定其他功能不會受影響

編寫并送出測試方法

使用金字塔原理設計測試報告，先總後分

彙總BUG，指定BUG發現及解決曲線圖

軟體測試方法

白盒測試

優點：增大代碼的覆寫率，提高代碼品質，發現代碼中隐藏的問題

缺點：系統龐大時，開銷大，難以測試所有路徑；測試基于代碼，無法驗證代碼合理性，可能會遺漏功能需求

黑盒測試

優點：較為簡單，與軟體内部實作無關；從使用者角度出發，實際考慮使用者使用的功能及可能的問題

等價類

等價類劃分：有效等價類和無效等價類

邊界值分析法：作為對等價類劃分的補充

錯誤猜測法：基于經驗

因果圖法：輸入條件之間的互相組合

場景分析法：根據使用者場景模拟使用者操作

大綱法：将需求轉化為大綱

随機測試法：完全站在使用者的角度測試

灰盒測試：白盒與黑盒之間

動态測試：實際運作程式，輸入用測，驗證程式的正确性，有效性和可靠性，并分析系統運作的效率和健壯性

α測試：一個使用者在開發環境下的受控測試，模拟實際操作環境

β測試：多個使用者在實際使用環境下進行的測試

冒煙測試：大規模測試前，先對基本，核心，主要功能進行測試

回歸測試：代碼修正後的測試

随機測試：純随機

探索測試：有思想的測試一些複雜，不常用的功能

引入自動化測試的原因：

降低成本

節省時間

CI和DevOps：持續內建，fail fast, fail early

準确，可靠

性能測試：可是同時模式數百萬使用者，手動測試做不到

增加對軟體的信心，確定所有事情按預期工作

衡量品質标準：代碼覆寫率，技術債，代碼語義檢查

總而言之，如果追求産品品質，自動化測試是必不可少的

自動測試架構：

基礎子產品

可重用元件：日志子產品，時間子產品

配置檔案：測試環境的配置和應用程式的配置

管理子產品

測試資料管理：實時建立，事先建立

測試檔案管理：Page類檔案，測試類檔案，對象庫檔案

統計子產品

測試報告：測試用例條數統計，測試用例成功失敗百分比，總執行時間。對每一條測試用例，要有測試用例ID、運作結果、運作時間、所屬子產品、測試失敗時刻系統截圖、測試的日志

日志子產品：出錯時進行排查和定位

運作子產品

測試用例排程，驅動機制

錯誤恢複機制

持續內建支援：測試架構應與CI系統低成本內建

常用的測試架構類型

子產品化測試架構：基于OOP思想和PO模式

一個業務或一個頁面，是一個Page對象，有一個Page類，類中存放着所有Page所屬的頁面對象和元素操作

頁面對象和元素操作組成測試類方法，供測試用例層調用

優點：友善維護，測試用例可以由不同的子產品和不同的對象組成

缺點：需要深入了解系統及子產品劃分

資料驅動架構

主要解決測試資料問題，python中DDT最為有名

關鍵字驅動架構：

把代碼封裝為關鍵字，通過組合關鍵字生成測試用例

混合模型

根據需求靈活選擇

測試架構設計原則：

清晰明了，學習成本低；代碼規範，子產品清晰明确

通用性強，可維護，可拓展

高效處理錯誤，系統日志清晰

運作效率高，支援測試環境切換，支援外部資料驅動，支援順序并發，遠端運作

支援版本控制——回溯複盤和持續內建

設計測試案例

「好的」測試用例一定是一個完備的集合，它能夠覆寫所有等價類以及各種邊界值，而跟能否發現缺陷無關。

一個“好的”測試用例，必須具備以下三個特征 。

整體完備性 ：「好的」測試用例一定是一個完備的整體，是有效測試用例組成的集合，能夠完全覆寫測試需求。

等價類劃分的準确性 ： 指的是對于每個等價類都能保證隻要其中一個輸入測試通過，其他輸入也一定測試通過。

等價類集合的完備性 ： 需要保證所有可能的邊界值和邊界條件都已經正确識别。

三種最常用的測試用例設計方法： 等價類劃分法、邊界值分析法、錯誤推測方法。

第一，等價類劃分法

隻要從每個等價類中任意選取一個值進行測試，就可以用少量具有代表性的測試輸入取得較好的測試覆寫結果。一個具體的例子：學生資訊系統中有一個考試成績的輸入項，成績的取值範圍是 0~100 之間的整數，考試成績及格的分數線是 60。為了測試這個輸入項，顯然不可能用 0~100 的每一個數去測試。通過需求描述可以知道，輸入 0~59 之間的任意整數，以及輸入 60~100 之間的任意整數，去驗證和揭露輸入框的潛在缺陷可以看做是等價的。那麼這就可以在 0~59 和 60~100 之間各随機抽取一個整數來進行驗證。這樣的設計就構成了所謂的“有效等價類”。

你不要覺得進行到這裡，已經完成了等價類劃分的工作，因為等價類劃分方法的另一個關鍵點是要找出所有「無效等價類」 。顯然，如果輸入的成績是負數，或者是大于100的數等都構成了“無效等價類”。

在考慮了無效等價類後，最終設計的測試用例為：

有效等價類1：0~59之間的任意整數；

有效等價類2：59~100之間的任意整數；

無效等價類1：小于0的負數；

無效等價類2：大于100的整數；

無效等價類3：0~100之間的任何浮點數；

無效等價類4：其他任意非數字字元。

第二，邊界值分析方法

邊界值分析是對等價類劃分的補充，你從工程實踐經驗中可以發現，大量的錯誤發生在輸入輸出的邊界值上，是以需要對邊界值進行重點測試，通常選取正好等于、剛剛大于或剛剛小于邊界的值作為測試資料。我們繼續看學生資訊系統中“考試成績”的例子，選取的邊界值資料應該包括：-1，0，1，59，60，61，99，100，101。

第三，錯誤推測方法

錯誤推測方法是指基于對被測試軟體系統設計的了解、過往經驗以及個人直覺，推測出軟體可能存在的缺陷，進而有針對性地設計測試用例的方法。** 這個方法強調的是對被測試軟體的需求了解以及設計實作的細節把握，當然還有個人的能力。

錯誤推測法和目前非常流行的“探索式測試方法”的基本思想和理念是不謀而合的，這類方法在目前的靈活開發模式下的投入産出比很高，是以被廣泛應用。但是，這個方法的缺點也顯而易見，那就是難以系統化，并且過度依賴個人能力。

總結：深入了解被測軟體需求的最好方法是，測試工程師在需求分析和設計階段就開始介入，因為這個階段是了解和掌握軟體的原始業務需求的最好時機。