1、創建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平台化，前置與后置機制（生成插件式管理）