本文章已正式進入實戰階段，本文章主要會講解接口測試中的一些接口概念，同時也會簡單介紹一下即將要進行測試的項目，除此之外下方有系列文章的傳送門，還在持續更新中，感興趣的小伙伴也可以前往查看，話不多說，讓我們一起看看吧~
系列文章：
系列文章1：【Python自動化測試1】遇見Python之美
系列文章2：【Python自動化測試2】Python安裝配置及PyCharm基本使用
系列文章3：【Python自動化測試3】初識數據類型與基礎語法
系列文章4：【Python自動化測試4】字符串知識總結
系列文章5：【Python自動化測試5】列表與元組知識總結
系列文章6：【Python自動化測試6】字典與集合知識總結
系列文章7：【Python自動化測試7】數據運算符知識合集
系列文章8：【Python自動化測試8】流程控制語句講解
系列文章9：【Python自動化測試9】函數知識合集
系列文章10：【Python自動化測試10】文件基礎操作
系列文章11：【Python自動化測試11】模塊、包與路徑知識合集
系列文章12：【Python自動化測試12】異常處理機制知識合集
系列文章13：【Python自動化測試13】類、對象、屬性與方法知識合集
系列文章14：【Python自動化測試14】Python自動化測試基礎與進階練習題
系列文章15：【Python自動化測試15】unittest測試框架的核心概念與作用
系列文章16：【Python自動化測試16】測試用例數據分離
系列文章17：【Python自動化測試17】openpyxl二次封裝與數據驅動
系列文章18：【Python自動化測試18】配置文件解析與實際應用
系列文章19：【Python自動化測試19】日志系統logging講解
系列文章20：【Python自動化測試20】接口自動化測試框架模型搭建
筆者曾經寫過一篇專門關於接口基礎內容與其相關概念的講解，整體比較詳細，地址參考：你真的了解接口測試嗎？
該項目是一個Web管理後台，有基礎信息、用戶操作、郵件管理、訂單管理等多個模塊，在項目實戰中，盡可能以最簡單、最高效的方式講解到最深層次的內容，讓大家能夠充分理解該項目，以及如何使用實戰所講解的內容應用到自己公司或是私人項目當中。
該項目擁有一份詳細的接口文檔，文檔中包括對應的請求頭、請求體、請求方式、請求參數、成功示例反饋等內容，包括全後台的所有模塊，均擁有對應詳細的接口信息，在實踐過程中，筆者會根據具體情況截圖、梳理、匯總，如下只展示其中一個接口作為示例
我們搭建框架很顯然是為了進行自動化測試的，包括但不限於接口自動化、Web自動化、App自動化，UI自動化測試等等方式，有一部分和功能測試會比較相似，各個公司上可能也會存在差異，但大體不變，現在來介紹下自動化測試的流程：
""" 第一步：需求評審 -- 自動化測試同功能測試，第一步都需要進行需求評審，評審期間熟悉需求，找到需求缺陷，以此為需求分析做好鋪墊 第二步：需求分析 -- 需求分析階段主要是自動化測試人員單獨對需求進行分析，進行需求拆解，詳細理解需求，為測試用例的設計做好鋪墊 第三步：接口文檔 -- 熟悉需求後知道大概要負責的內容，在接口自動化測試階段就需要了解接口文檔，有哪些參數，請求頭、請求體、請求方式、請求參數等 如果公司沒有接口文檔，通常去找開發詢問，讓開發給一份文檔，如果還是無果，需要自己通過抓包的方式獲取接口並梳理成文檔 第四步：測試計劃 -- 大致梳理你個人的測試計劃，用例設計需要的時間，什麼時候設計，預計什麼時候能夠測試通過，哪個環節是否采用自動化技術 考慮測試的優先級等，如果你是對應的測試負責，還需要考慮任務的人力分配等問題 第五步：計劃評審 -- 當你梳理出一個計劃後，還要與小組成員進行確認討論，查看計劃是否存在文檔，是否有可改進的地方，關於小組成員是否對此有一些疑問 第六步：測試用例 -- 熟悉需求和接口文檔後且擁有了測試計劃，那麼就到了測試用例的設計環節，設計接口自動化的測試用例 第七步：用例評審 -- 接口測試用例設計完成後進入用例評審階段，確認測試用例中是否有遺漏，是否不規范，是否便於自動化的讀取、使用等 第八步：用例執行 -- 通過接口自動化測試用例來進行代碼的編寫及梳理，在此期間可以搭建測試框架或在此之前已經擁有了一個框架執行即可 第九步：測試報告 -- 當執行完成測試用例後，即可輸出對應的測試報告結論，同業務，包括質量情況、問題分布， 第十步：集成部署 -- 當測試框架搭建完成後並且能夠順利的執行測試用例，產出對應的測試報告時，考慮進行集成部署，通過定時任務，按周或按月冒煙執行 """
測試金字塔主要分為三個階段，最底層是單元測試/組件測試，也就是代碼相關的檢查測試，但因國內敏捷開發以及測試能力的限制，故此在大多數的公司測試並不會進行單元測試，往往在此階段是由開發進行自測完成。
金字塔的中間層是API方面的測試，也就是接口相關的測試，接口測試沒有單元測試更加專業，但可以發現手工測試中無法發現的異常和問題。
最上層是用戶界面上的測試，也可以理解為手工測試，手工測試僅能發現一些表層次問題，但大多數的需求僅通過表層的功能測試也能夠防止絕大多數問題的產生，也是非常重要的一環，越靠近上層的測試，越能夠接近業務層面的內容，也能夠明顯的反映出真實的需求。
不僅如此，越靠近金字塔的底端測試方式效率更高、缺陷更容易被定位、測試成本更低，而越靠近金字塔的頂端，則修復效率越慢，成本更高且缺陷更不容易被定位，這也是為什麼測試需要盡早介入的原因。
我們知道自動化測試能夠提升工作效率，雖說如此，但什麼情況下都適合做自動化嗎？顯然並不是的，只有符合下列條件的情況下，筆者認為更適合做自動化測試：
""" 符合下列條件，更適合做自動化測試工作： 1、需求文檔，不會頻繁變更需求 -- 在不變更需求的情況下，功能模塊相對穩定，腳本編寫後無需花費大量的時間修改及維護 2、研發和測試周期長，需要頻繁進行回歸測試、冒煙測試 -- 例如每周的模塊進行冒煙測試，頻繁的出現某一個運營活動 3、需要在多種平台上重復運行多個測試場景 4、某些測試項目的測試內容通過功能測試無法實現，或功能測試非常耗時 5、被測系統的開發較為規范，能夠保證系統的可行性 """
有部分同學在面試自動化測試工程師之後負責人還會讓他繼續做功能測試，他也很奇怪，表示迷茫？自動化測試工程師還需要做功能測試嗎？
答案很明顯是需要的，一個自動化的測試人員在進行自動化測試前必定是需要熟悉業務的，而熟悉業務的最佳方式就是先做一些功能測試或體驗測試的內容，快速幫助自動化測試人員來熟悉業務，以便更好的測試。
好啦~以上就是本次文章分享的全部內容啦，你學會了嗎？希望能給大家帶來幫助哦！
