在上一份工做中,我有一部分工做是在維護一套接口自動化測試,這一篇文章,我來介紹這套接口自動化框架的設計思路。php
咱們來看一個簡單的PHP實現的超簡單的接口。數據庫
... //報名驗證 private function apply_verify() { $raid = $this->input->get_post('raid'); $mid = $this->input->get_post('mid'); if (!$raid || !$mid) { $this->ret_json(10021, '參數錯誤'); } $this->load->model('enlist_model'); $result = $this->enlist_model->get_enlist_by_raid_mid($raid, $mid, true); if (!empty($result)) { $this->ret_json(10101, '你已經報過名'); } }
說明:編程
get_enlist_by_raid_mid
方法查詢是否爲空,若是不爲空返回:你已經報過名了。接下來要作的事情不是寫用例,而是構造一條已經報名的數據。json
建立 xx_enlist_test_data.php
文件架構
array( 'table_name'=>'xx_enlist', 'data'=>array( array('eid'=>1,'raid'=>99,'mid'=>150,'phone'=>'01234567890'), ) )
當自動化在執行以前,會先到數據庫的 xx_enlist
表插入這條數據,爲何要初始化數據?固然是爲了保證接口測試用例的穩定性。好比,我在調用接口時,傳入 raid=99, mid=150
。若是數據庫是表空的?那麼,用例確定失敗了!如何保證這條用每次運行 100% 成功呢?固然是每次執行以前再對應的表中初始化這麼一條數據了!app
定義的數據怎麼插入到數據庫中,固然是有一層解析的,將上面的數據庫轉成一條SQL語句執行。上面的數據固然比原生的一條插入SQL語句好寫。框架
最後,纔是開始寫用例。建立interface_enlist_test.php
測試文件。微服務
class Interface_enlist_test extends InterfaceTestCase { //初始化數據 public function db_fixtures() { return array( array( 'data_file' => 'xx_enlist_test_data.php', 'truncate' => true ), ); } /* * 報名驗證 * raid不傳 */ public function test_post_enlist_raid_null() { $result = $this -> request('enlist/apply_verify',array(),array('mid'=>150)); $this->assertEquals($result['status'],'10021'); $this->assertEquals($result['message'],"參數錯誤"); } /* * 報名驗證 * mid不傳 */ public function test_post_enlist_mid_null() { $result = $this -> request('enlist/apply_verify',array(),array('raid'=>99)); $this->assertEquals($result['status'],'10021'); $this->assertEquals($result['message'],"參數錯誤"); } /* * 報名驗證 * 用戶已報名 */ public function test_post_enlist_verify_success() { $result = $this -> request('enlist/apply_verify',array(),array('raid'=>99, 'mid'=>150)); $this->assertEquals($result['status'],'10101'); $this->assertEquals($result['message'],"你已經報過名"); } }
這裏的用例我就作過多解釋了。調用接口寫斷言。post
我知道大家大概會有哪些疑問,接下來,我將試着解答這些疑問。學習
一、我怎麼知道接口調用了哪些表?
首先你要懂PHP編程,而後熟悉Web開發框架,申請代碼查看權限,閱讀接口處理邏輯,天然就知道接口調用哪些表。
二、看不懂開發代碼怎麼辦?
學唄!我當年也不是一會兒就看懂PHP代碼的,先後也學了兩三個月。
三、往數據庫裏面插入測試數據,有重複的怎麼辦?
咱們當時的設計是,框架在運行時會自動化的修改被測試的接口項目將數據庫指到我本地,也就是說我本地有一個跟測試環境如出一轍的數據庫,每次在插入數據以前先清空表。
要保證本地數據庫的表結構和測試環境是同樣的。這其實也不難,開發若是改到表會上傳SQL腳本,我只須要在本地數據庫執行一下就好了。
四、這樣作接口測試有什麼好處?
- 首先,接口用例超級穩定,穩定是自動化測試的 大敵 ,作過自動化的同窗知道我在說什麼。在保證數據的基礎上,若是用例失敗了, 100% 是接口邏輯被改動到了。
- 不依賴接口文檔,有幾個公司的接口文檔是很是詳細,且及時維護的?我這種方式不須要接口文檔。
- 不
盲測
,盲測就是把接口的參數,每一個類型試一遍,而後再排列組合,若是你不知道接口要調用哪一個表的哪一個字段來判斷條件,那麼這種盲測依然覆蓋不到接口的全部處理邏輯。- 固然更裝X(玩笑~!),實際狀況是你測試接口的水平即全面又深刻,比只會用 postman 盲測的同窗厲害多了。
- 反向促進接口代碼質量,由於的接口用例編寫是基於閱讀接口代碼的,有一個新來的PHP開發被我叫到面前幾回,並直接指出對方的代碼邏輯錯誤以後(分分鐘教他怎麼作開發,哈哈!),它的接口提測質量一會兒提升了許多。
五、這樣作接口測試的缺點是什麼?
- 不適合全部團隊,不是每一個測試都懂開發代碼的,好比,咱們如今的接口用GO,若是我如今想達到無障礙閱讀GO接口代碼,也須要較高的學習成本。
- 不適合大型項目,我以前之因此可在這麼玩,主要也是由於PHP項目不大,若是是一個大型項目的話就不適合了,在微服務的架構下,你甚至很難理清一個接口的調用關係。
不過,我仍然認爲這是一個優秀的接口測試工程師應該努力的方法。接口測試平臺解決的只是測試效率問題,如何把一個接口測好?固然是理解好需求,並有能力閱讀接口處理邏輯,設計出有效和全面的接口用例。
其實,這篇文章所傳達的思想,我在《Web接口開發與自動化測試--基於Python語言》一書都有介紹,只是換了個語言和框架而已。