介面測試框架實踐

iTesting，愛測試，愛分享

2，3年以前給大家分享過如何用jmeter做介面測試，但工具畢竟有限制，所以在真實的項目中，大家還是用自研的框架多。 我之前寫過一個簡單的基於unittest+request的介面測試框架，也分享給大家過，最近在免費直播中我也有講到，但直播畢竟講不透徹，還是有很多同學不是特別清楚，到底如何做一個介面測試框架，今天我們再次詳細解釋下，如何生成自己的介面測試框架。

關於介面測試，基本概念請點擊這裡，介面測試我們一般先手工做，然後再自動化，無論手工還是自動化，介面測試的步驟都大致如下：

1. 根據介面文檔/規範及介面功能來設計測試用例，設計法則參考黑盒測試和白盒測試方法。

2. 準備測試數據，用工具（Postman， fiddler， soapui等）或代碼（python+requests或其它語言），根據測試用例構造請求，發請求。

3. 檢查伺服器返回的結果。 包括狀態碼和返回值的檢查。 各種合法非法的請求介面能否正確處理，要特別注意安全性（僅前端校驗，後端忘記校驗），authentication，性能（特別是並發），數據一致性，完整性方面（冪等）的問題。

介面測試的檢查點，一般如下：

手工如何測試，很清楚了，那麼我們講介面測試自動化框架，從哪裡開始呢？

既然是自動化，那麼就必須不需要人工干預，框架如何做到不需要人工干預呢？竊以為有如下方面：

用例的自動收集。 就是要自動接受用戶輸入，自動分析並查找待跑用例。什麼意思呢？你跑自動化時候，一般需要指定跑那些case，這些case屬於哪個類別（regression， smoke， unit test？）框架需要能根據用戶輸入快速找到要跑到用例集，並把它加到待跑用例的列表裡。如果你不指定，框架會跑默認文件夾下的用例集。

用例的運行方式。 就是組織查找到的用例集合，你想怎麼運行？ 順序執行還是並發執行，執行過程中要不要記log，有錯誤是要繼續還是要停止運行？運行失敗要不要重新跑一遍？執行完畢後要不要收集執行結果？

測試報告。所有用例執行完畢後需要有整個運行情況的報告，包括整體運行結果，執行的用例列表，用例中成功百分比，失敗百分比，失敗的用例，框架有沒有在它發生錯誤的時候截圖？有沒有記log，在失敗的用例上點擊用例名稱，能不能通過鏈接的方式快速定位截圖，log？ 你想要txt格式的報告還是更user friendly的HTML格式？

前面3部分有了，一個測試框架的殼子就出來了，但還不夠好，還需要加上：

自動觸發運行。 何時運行這個框架？每次有代碼改動？發版前？還是每日定時？

環境配置。基本上公司的測試環境不可能只有一個，那麼如何配置同樣的腳本跑在不同的環境上？

Data provider (數據生成)。環境不一樣，測試數據不能一樣吧？如何提供不同環境的數據且不更改自動化代碼？

郵件發送。 自動化測試結束後自動發送測試報告到相應人的郵箱。

日誌，錯誤處理。運行中記錄運行情況，錯誤情況及出錯後的處理。

下面，我們就以我實現的EasyAPIFramework（Python＋Unittest＋HTMLTestRunner）為例，詳細說明下框架是如何一步步搭建起來的。

Unittest。unittest是python語言里使用最廣泛的一個框架，看名字就知道它本來做unit test用的，但因為太強大了，所以也被拿來做功能自動化，介面自動化。

unittest有四個重要的概念：

test fixture：represents the preparation needed to perform one or more tests(setup, teardown)。

setUp(): 每次執行測試用例之前調用。無參數，無返回值。該方法拋出的異常都視為error，而不是測試不通過。沒有默認的實現。

tearDown(): 每次執行測試用例之後調用。無參數，無返回值。測試方法拋出異常，該方法也正常調用，該方法拋出的異常都視為error，而不是測試不通過。只用setUp()調用成功，該方法才會被調用。沒有默認的實現。通過setup 和 tesrDown組裝一個module成為一個固定的測試裝置。注意：如果setup運行拋出錯誤，則測試用例代碼則不會執行。但是，如果setpu執行成功，不管測試用例是否執行成功都會執行teardown。

test case：獨立測試的單位，一般一個testcase完成一個功能。注意兩點：

1. testcase通常繼承自測試類，測試類一般繼承自unittest.TestCase。測試類里通常實現了setup(), teardown(), 及測試用例。

2. test case要以test開頭。

test suite：A test suite is a collection of test cases, test suite。通常用來聚合測試用例， 並且test suites可以嵌套。

test runner：A test runner is a component which orchestrates the execution of tests and provides the outcome to the user.運行測試用例的驅動類，可以執行TestCase，也可執行TestSuite。執行後TestCase和Testsuite會自動管理TestResult。簡單來說就是run（），裡面就是手工測試的步驟代碼化。

除了上述概念，unittest里還有幾個概念需要你知道：

TestLoder：是用來載入 TestCase到TestSuite中，其中有幾個loadTestsFrom_()方法，就是從各個地方尋找TestCase，創建他們的實例，然後add到TestSuite中，再返回一個TestSuite實例

TextTestRunner：是來執行測試用例的，其中的run（test）會執行TestSuite/TestCase中的run(result)方法。

TextTestResult：測試結果會保存到TextTestResult實例中，包括運行了多少用例，成功與失敗多少等信息

一般來說，unittest執行測試的流程如下：

創建好TestCase，然後由TestLoader載入（也可以用TestDiscover指定文件夾的方式Load）TestCase到TestSuite，然後由TextTestRunner來運行TestSuite，運行的結果保存在TextTestResult中，整個過程集成在unittest.main模塊中。

下面我們舉個例子來看下，一個簡單的unittest的測試用例長什麼樣子：

好，看上圖，這裡我實現了一個測試類，它繼承了unittest.TestCase.然後再測試類里實現了setup(), test_XXX(), teardown()方法，有的測試方法上我加個了@unittest.skip(). 說這個什麼意思呢？我開始說測試框架要實現查找測試用例集，unittest幫我們把測試用例標記好了，所有的測試用例要以test開頭，當你調用TestLoder（defaultTestLoader()類，通過該類下面的discover()方法可自動根據測試目錄start_dir匹配查找測試用例文件（test*.py），並將查找到的測試用例組裝到測試套件）查找測試用例集的時候，所以test開頭的會被自動加入測試用例集。哪些被標記為unittest.skip（）的則不會。 第2，我想實現跑某些用例，怎麼辦呢？unitest 不支持按照標籤運行，但是它提供了testsuite概念，你可以把一個測試類的幾個測試用例添加到testsuite里。這樣unitest就實現了框架的第一要素，測試用例集的查找。

那麼用例集查找好了，你定義的test_XXX()的方法最終都會在TextTestRunner的run（）方法中被執行到。也就是說，通過TextTestRunner我們實現了用例的順序執行。（並發執行unittest貌似不支持，並發執行可以用pytest）

看，利用unittest我們可以輕易開發出一個測試用例並實現了用例收集和用例執行。那麼測試報告如何生成呢？我們可以藉助HTMLTestRunner來實現。

HTMLTestRunner is an extension to the Python standard library』s unittest module. It generates easy to use HTML test reports

下載地址:(http://tungwaiyip.info/software/HTMLTestRunner.html), 下載好後放到放在C:Python37Lib目錄下。具體用法參考我代碼，稍後放出。

好， 有了unittest +HTMLRunner，測試框架所需要的１２３就有了，後面的６到８（自動觸發運行，環境配置，Data provider (數據生成)，郵件發送，日誌，錯誤處理），其中（自動觸發運行，環境配置，郵件發送）可以通過集成Jenkins的方式實現，Data provider (數據生成)，日誌，錯誤處理，需要我們代碼實現。

我們再回過來看這個簡單的框架。

這個框架分了幾個部分（以前寫的英文版我就不翻譯了哈）：

"Common": --Common methods to facilitates the whole project.

html_report: To generate HTML report after test cases run.

shared_api: Import method like post/get to serve all the API requests.

txt_report: Independent way to run all the cases under test and generate simple txt format report.

主要來說就是一些公用的library，包括如對selenium的二次封裝（web自動化），對API調用的二次封裝（API自動化），datadriven讀文件方法及項目所用到的公用庫文件。

shared_api里包含了我對requests的封裝，其實，針對webservices（一般為？wsdl文件）的API，也可以寫個公用方法包括在內，可以看看它長什麼樣子：

如果你要做web自動化框架，那麼就寫個Selenium_helper，包括你所有對selenium的wrap方法，然後你在測試類的setup（）， teardown（）兩個類下調用（看出來了吧，框架本身應該和什麼類型的測試無關，框架就是用來幫你組織你的測試用例的）。

"Page": --The page under test.

in this file, only store the page related function/method/date

test case related to this page should not be included here.

different page should have separated pages.

真正你要測試的項目（如果是功能自動化，你需要利用page object模式實現頁面元素，和定位元素的loactor分離（其實測試數據，邏輯，業務都應該分離並可重用））。一個完整的頁面或功能我們組織在一起叫一個page，這個page應該包括這個頁面的元素，及針對元素的操作，但測試業務邏輯不般不包括。

一個page通常是什麼樣子呢？

"Settings": --Global settings & configuration & global data.

__init__:

data_source: all the account, common test data.

test config: environment, domain or other common config.

這裡就是整個項目的配置文件，包括數據配置也可以放置在內，一般會有變數來接受來自jenkins的環境變數。如果沒有就設置default值。 Test_config里應該包含你測試的數據，不同環境區分開，也可以寫到外部excel或者xml了，然後利用common方法里的datadriven方法讀出。 我們就是通過這個來實現環境及數據的切換。

"test" -- Test cases inherited from pages, this is the cases under test.

each test file should have a page file accordingly.

framework will only search the cases under this folder

就是你測試類和測試方法所在，通常你測試類的名稱要和你測試對象的名稱一樣，只是在前面加test（注意unittest只有以test開頭的測試用例才會被執行）。

注意，setup（）應該包括測試用例的數據準備（比如你需要打他driven，這次的數據就應該包括進來），還有selenium調用及browser的initial（針對web功能自動化），requests介面的初始化（API自動化）等。teardown（）里，要做好相應的銷毀動作。

"main" -- Load & run all of the test cases defined in test folder.

System will automated search all the test method defined in test folder and run them.

當然你也可以通過TestDiscover及testsuite的addTest來篩選你需要執行的用例，我簡化為搜索所有test文件夾下的用例了（直接利用discover方法）。

好了，到這裡為止，我們就實現了一個基本的介面測試框架，是不是感覺非常簡單啊？（介面框架代碼Github：https://github.com/Light07/EasyAPIAutomationFramework）

其實，在真正的項目實踐中，要考慮到比這個要複雜的多，起碼並發執行我們沒實現啊，數據驅動我們也沒實現。失敗rerun也沒有。後續我會重新實現一個開源的介面測試框架給大家，把我提及的全部功能都實現，當然，大家也可以直接選用pytest，我後續也會寫下pytest教程，敬請期待。

- End -

作者：

Kevin Cai, 江湖人稱蔡老師。

兩性情感專家，非著名測試開發。

技術路線的堅定支持者，始終相信Nobody can be somebody。

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！