接口自動化平臺搭建（二），搭建django項目與接口自動化平臺的由來與功能特徵

 一、建立django項目

　　a.使用命令建立，安裝完django以後就有django-admin命令了，執行命令建立便可，命令以下:

　　

django-admin startproject my_django#最後面的是項目名稱，能夠隨便起

　　b.使用pycharm建立，打開pycharm以後，選擇新建項目，而後選擇django項目，在路徑寫上項目名稱，再填一個應用的名稱建立就能夠了，實質上用pycharm建立的項目它也是在調用django-admin命令

　　

 

 

點擊create新建，pycharm會自動生成相應目錄

 

2.背景

當前市面上存在的接口測試工具已經很是多，常見的如Postman、JMeter、RobotFramework等，相信大多數測試人員都有使用過，至少從接觸到的大多數簡歷的描述上看是這樣的。除了這些成熟的工具，也有不少有必定技術能力的測試（開發）人員自行開發了一些接口測試框架，質量也是良莠不齊。

可是，當我打算在項目組中推行接口自動化測試時，蒐羅了一圈，也沒有找到一款特別滿意的工具或框架，老是與理想中的構想存在必定的差距。

那麼理想中的接口自動化測試框架應該是怎樣的呢？

• 測試或開發人員在定位問題的時候，想調用某個接口查看其是否響應正常；
• 測試人員在手工測試某個功能點的時候，須要一個訂單號，而這個訂單號能夠經過順序調用多個接口實現下單流程；
• 測試人員在開始版本功能測試以前，能夠先檢測下系統的全部接口是否工做正常，確保接口正常後再開始手工測試；
• 開發人員在提交代碼前須要檢測下新代碼是否對系統的已有接口產生影響；
• 項目組須要天天定時檢測下測試環境全部接口的工做狀況，確保當天的提交代碼沒有對主幹分支的代碼形成破壞；
• 項目組須要定時（30分鐘）檢測下生產環境全部接口的工做狀況，以便及時發現生產環境服務不可用的狀況；
• 項目組須要不按期對核心業務場景進行性能測試，指望能減小人力投入，直接複用接口測試中的工做成果;
• 測試人員能夠查看詳細的接口報告，包含響應時間，返回報文，請求報文，請求頭，請求方法，狀態碼，返回類型等等信息；
• 在各個接口有不少公共的請求參數，重複的輸入會形成時間上的浪費，咱們須要一種插件，把公共參數輸入一次，在接口中直接複用；　　

能夠看到，以上羅列的場景你們應該都很熟悉，這都是咱們在平常工做中常常須要去作的事情。可是在沒有一款合適工具的狀況下，效率每每十分低下，或者就是某些重要工做壓根就沒有開展，例如接口迴歸測試、線上接口監控等。

先說下最簡單的手工調用接口測試。可能有人會說，Postman就能夠知足需求啊。的確，Postman做爲一款通用的接口測試工具，它能夠構造接口請求，查看接口響應，從這個層面上來講，它是知足了接口測試的功能需求。可是在具體的項目中，使用Postman並非那麼高效。

不妨舉個最多見的例子。

某個接口的請求參數很是多，而且接口請求要求有MD5簽名校驗和AES加密；簽名的方式爲在Headers中包含一個sign參數，該參數值經過對URL、Method、Body的拼接字符串進行MD5計算後獲得。

回想下咱們要對這個接口進行測試時是怎麼作的。首先，咱們須要先參照接口文檔的描述，手工填寫完全部接口參數；而後，按照簽名校驗方式，對全部參數值進行拼接獲得一個字符串，在另外一個MD5的函數獲得其MD5值，將簽名值填入sign參數；最後，纔是發起接口請求，查看接口響應，並人工檢測響應是否正常。最坑爹的是，咱們每次須要調用這個接口的時候，以上工做就得從新來一遍。這樣的實際結果是，面對參數較多或者須要簽名驗證的接口時，測試人員可能會選擇忽略不進行接口測試。

除了單個接口的調用，不少時候咱們也須要組合多個接口進行調用。例如測試人員在測試借貸系統時，常常須要一個特定組合條件下生成的訂單號。而因爲訂單號關聯的業務較多，很難直接在數據庫中生成，所以當前業務測試人員廣泛採起的作法，就是每次須要訂單號時模擬下單流程，順序調用多個相應的接口來生成須要的訂單號。能夠想象，在手工調用單個接口都如此麻煩的狀況下，每次都要手工調用多個接口會有多麼的費時費力。

再說下接口自動化調用測試。這一起大多接口測試框架都支持，廣泛的作法就是經過代碼編寫接口測試用例，或者採用數據驅動的方式，而後在支持命令行（CLI）調用的狀況下，就能夠結合Jenkins或者unittest實現持續集成，或者定時接口監控的功能。

思路是沒有問題的，問題在於實際項目中的推進落實狀況。要說自動化測試用例最靠譜的維護方式，仍是直接經過代碼編寫測試用例，可靠且不失靈活性，這也是不少經歷過慘痛教訓的老手的感悟，甚至網絡上還出現了一些反測試框架的言論。但問題在於項目中的測試人員並非都會寫代碼，也不是對其強制要求就能立刻學會的。這種狀況下，要想在具體項目中推進接口自動化測試就很難，就算我能夠幫忙寫一部分，可是不少時候接口測試用例也是要結合業務邏輯場景的，我也的確是無法在這方面投入太多時間，畢竟對接的項目實在太多。因此也是基於這類緣由，不少測試框架提倡採用數據驅動的方式，將業務測試用例和執行代碼分離。不過因爲不少時候業務場景比較複雜，大多數框架測試用例模板引擎的表達能力不足，很難採用簡潔的方式對測試場景進行描述，從而也無法很好地獲得推廣使用。

能夠列舉的問題還有不少，這些也的確都是在互聯網企業的平常測試工做中真實存在的痛點。

基於以上背景，我產生了開發一套基於djangoweb框架與httprunner爲核心的自動化測試平臺的想法。

對於此測試平臺的定位，與其說它是一個工具或框架，它更多的應該是一套接口自動化測試的最佳工程實踐，而簡潔優雅實用應該是它最核心的特色。

核心特性

接口平臺的核心特性概述以下：

• 支持API接口的多種請求方法，包括 GET/POST/HEAD/PUT/DELETE 等
• 測試用例與代碼分離，測試用例維護方式簡潔優雅
• 測試用例描述方式具備表現力，可採用簡潔的方式描述輸入參數和預期輸出結果
• 接口測試用例具備可複用性，便於建立複雜測試場景
• 測試執行方式簡單靈活，支持單接口調用測試、批量接口調用測試、定時任務執行測試
• 測試結果統計報告簡潔清晰，附帶詳盡日誌記錄，包括接口請求耗時、請求響應數據等
• 身兼多職，同時實現接口管理、接口自動化測試、接口性能測試（結合Locust）
• 具備可擴展性，便於擴展實現Web平臺化，前置與後置機制（生成插件式管理）