介面測試自動化極緻應用：Postman＋Jenkins＋Github一路整合

前言

軟體測試是軟體開發的重要組成部分，是貫穿整個軟體生命週期，對軟體產品進行驗證和確認的活動過程，其目的是儘早發現軟體產品中存在的各種問題，如與使用者需求、預先定義不一致等問題。隨著技術的發展，測試從手動向自動化轉變，從使用者介面（User Interface，UI）層測試向單元測試接近。接下來，先回顧幾個概念。

單元測試：對軟體中的最小可測試單元進行檢查和驗證。實際來說就是開發者撰寫一小段程式，用於檢驗被測程式的一個很小的、很明確的功能是否正確。通常而言，一個單元測試是用於判斷某個特定條件（或場景）下某個特定函數的行為。

整合測試：它是在單元測試的基礎上，將所有的軟體單元按照概要設計規格說明的要求組裝成模組、子系統或系統，並測試該過程中各部分工作是否達到或實現對應技術指標及要求。也就是說，在整合測試之前，單元測試應該已經完成。這一點很重要，因為如果不經過單元測試，那麼整合測試的效果將受到很大影響，並且會大幅增加軟體單元程式校正的代價。

系統測試：將需測試的軟體，作為整個以電腦系統為基礎的元素，與電腦硬體、外接裝置、某些支援軟體、資料和人員等其他系統元素及環境結合在一起測試。系統測試的目的在於透過與系統的需求定義作比較，發現軟體與系統定義不符合或矛盾的地方。

再來看看經典的測試分層金字塔圖。

其中Unit 代表單元測試，Service 代表服務整合測試（或介面整合測試），UI 代表頁面系統測試。單元測試需要強大程式能力，很多測試人員還沒有能力去執行，因此目前大多數公司還處於開發自測的階段；隨著開放原始碼UI 自動化測試架構Selenium 的發展，Web UI 自動化測試近幾年已趨於成熟（Appium 是行動端UI 自動化測試的代表架構），但其有3 個明顯的缺點：第一，UI 測試介入測試時機較晚，修復發現的漏洞成本較大；第二，UI 測試很難發現底層邏輯問題；第三，頁面元素經常轉換，導致自動化產出、投入比偏低；而這些剛好是介面自動化測試所能解決的問題。關於介面自動化測試，目前在業內有兩大類解決方案，一種是透過程式撰寫介面測試架構，實現介面自動化測試，其要求測試人員掌握紮實的程式設計基礎；另一種是借助介面測試工具，配合Postman 等整合工具實現介面自動化測試持續整合。前者更靈活，但後者的學習成本更低，適合新人上手。介面測試工具有很多，其中Postman 安裝簡單、使用方便、功能強大，另外，這也是開發人員常用的介面偵錯工具，使用相同的工具測試出來的問題就更有說服力了。本書將借助該工具，帶領大家了解介面測試持續整合的流程。

目前，很多專案都需要執行介面測試，很多讀者也想了解介面測試方面的知識，但市面上與介面測試相關的書卻很少，於是我根據自己的學習經驗和工作累積寫了這本書。

讀者在了解基本概念，了解介面測試原理後，下載並安裝Postman 工具，跟隨書中的範例進行練習，並把自己所學知識應用到目前從事的專案中。

由於本人水準有限，讀者們在學習過程中，如發現任何疑問，可發郵件至apitest100@163.com，期待獲得你的真摯回饋，讓我們在技術之路上共同進步。感謝天怡和其他編輯的耐心指導；感謝讀者的信任；感謝BestTest 測試教育訓練機構提供的介面專案範例；感謝安大叔的教導；感謝家人的大力支持。

Storm