前言
軟體測試是軟體開發的重要組成部分,是貫穿整個軟體生命週期,對軟體產品進行驗證和確認的活動過程,其目的是儘早發現軟體產品中存在的各種問題,如與使用者需求、預先定義不一致等問題。隨著技術的發展,測試從手動向自動化轉變,從使用者介面(User Interface,UI)層測試向單元測試接近。接下來,先回顧幾個概念。
單元測試:對軟體中的最小可測試單元進行檢查和驗證。實際來說就是開發者撰寫一小段程式,用於檢驗被測程式的一個很小的、很明確的功能是否正確。通常而言,一個單元測試是用於判斷某個特定條件(或場景)下某個特定函數的行為。
整合測試:它是在單元測試的基礎上,將所有的軟體單元按照概要設計規格說明的要求組裝成模組、子系統或系統,並測試該過程中各部分工作是否達到或實現對應技術指標及要求。也就是說,在整合測試之前,單元測試應該已經完成。這一點很重要,因為如果不經過單元測試,那麼整合測試的效果將受到很大影響,並且會大幅增加軟體單元程式校正的代價。
系統測試:將需測試的軟體,作為整個以電腦系統為基礎的元素,與電腦硬體、外接裝置、某些支援軟體、資料和人員等其他系統元素及環境結合在一起測試。系統測試的目的在於透過與系統的需求定義作比較,發現軟體與系統定義不符合或矛盾的地方。
再來看看經典的測試分層金字塔圖。
其中Unit 代表單元測試,Service 代表服務整合測試(或介面整合測試),UI 代表頁面系統測試。單元測試需要強大程式能力,很多測試人員還沒有能力去執行,因此目前大多數公司還處於開發自測的階段;隨著開放原始碼UI 自動化測試架構Selenium 的發展,Web UI 自動化測試近幾年已趨於成熟(Appium 是行動端UI 自動化測試的代表架構),但其有3 個明顯的缺點:第一,UI 測試介入測試時機較晚,修復發現的漏洞成本較大;第二,UI 測試很難發現底層邏輯問題;第三,頁面元素經常轉換,導致自動化產出、投入比偏低;而這些剛好是介面自動化測試所能解決的問題。關於介面自動化測試,目前在業內有兩大類解決方案,一種是透過程式撰寫介面測試架構,實現介面自動化測試,其要求測試人員掌握紮實的程式設計基礎;另一種是借助介面測試工具,配合Postman 等整合工具實現介面自動化測試持續整合。前者更靈活,但後者的學習成本更低,適合新人上手。介面測試工具有很多,其中Postman 安裝簡單、使用方便、功能強大,另外,這也是開發人員常用的介面偵錯工具,使用相同的工具測試出來的問題就更有說服力了。本書將借助該工具,帶領大家了解介面測試持續整合的流程。
目前,很多專案都需要執行介面測試,很多讀者也想了解介面測試方面的知識,但市面上與介面測試相關的書卻很少,於是我根據自己的學習經驗和工作累積寫了這本書。
讀者在了解基本概念,了解介面測試原理後,下載並安裝Postman 工具,跟隨書中的範例進行練習,並把自己所學知識應用到目前從事的專案中。
由於本人水準有限,讀者們在學習過程中,如發現任何疑問,可發郵件至apitest100@163.com,期待獲得你的真摯回饋,讓我們在技術之路上共同進步。感謝天怡和其他編輯的耐心指導;感謝讀者的信任;感謝BestTest 測試教育訓練機構提供的介面專案範例;感謝安大叔的教導;感謝家人的大力支持。
Storm