淺談接口自動化測試

昨晚在某個測試交流羣,聽了一個測試老司機分享接口自動化測試的內容,對接口自動化有了更深的一些認識,也爲接下來公司的接口自動化實施,提供了更多的思路。html

這篇博客,就說說功能測試到接口自動化的進階,以及接口自動化的一些事。。。spring

 

前言數據庫

自動化測試,算是近幾年比較火熱的一個話題,固然,更是軟件測試將來的一個發展趨勢。將來,功能測試等非核心的測試工做,都將被外包。編程

想要在軟件測試這個行業繼續前行,就必須擁有核心競爭力,掌握自動化測試技術,是必不可少的一個技能。json

在《Google軟件測試之道》一書中有介紹到:在Google,70%的自動化測試工做集中於單元測試,20%集中於接口測試,剩下10%纔是UI測試。架構

誠然,咱們沒有Google那麼完善的機制和工程師文化,不必一切照搬Google,但Google做爲互聯網2.0時代最耀眼的一個公司,它的技術發展方向,流程管理等能夠說是不久的未來,框架

咱們也要到達的方向。選擇適合本身的,落地應用,是當下咱們應該作的。maven

目前國內的互聯網行業,大環境來講,還處在一個快速發展,須要流程化標準化的時期,如何跟上不斷變幻發展的節奏,除了不斷了解接觸新的東西,還須要不斷學習,提高自身,之內在編程語言

的驅動力,去緊跟時代浪潮。即便作不了弄潮兒,也不能變成時代淘汰的那一批。說到這裏,推薦2本書:吳軍的著做《浪潮之巔》、《硅谷之謎》,感興趣的童鞋能夠去看看。。。工具

 

1、接口測試的必要性和意義

接口,即API,應用程序編程接口,關於接口的介紹,以前的博客就有詳細介紹過,感興趣的童鞋能夠去看看:接口測試簡介

這裏主要說說接口測試的必要性和意義:

接口測試實施在多系統的平臺架構下,有着極爲高效的成本收益比(固然,單元測試收益更高,但實施單元測試的成本投入更大,技術要求更高,因此應該選擇更適合自身的纔是最好的方案)。

接口測試天生爲高複雜性的平臺帶來高效的缺陷檢測和質量監督能力,平臺複雜,系統越龐大,接口測試的效果越明顯。

總的來講,接口測試是保證高複雜性系統質量的內在要求和低成本的經濟利益驅動做用下的最佳方案,主要體如今以下三個方面:

一、節省了測試成本

   根據數據模型推算,底層的一個程序BUG可能引起上層的8個左右BUG,並且底層的BUG更容易引發全網的死機;接口測試可以提供系統複雜度上升狀況下的低成本高效率的解決方案。

二、接口測試不一樣於單元測試

   接口測試是站在用戶的角度對系統接口進行全面高效持續的檢測。

三、效益更高

   將接口測試實現爲自動化和持續集成,當系統複雜度和體積越大,接口測試的成本就越低,相對應的,效益產出就越高。

 

2、作接口測試須要哪些技能

關於這點,在以前的博客也說過,傳送門:作接口測試須要哪些技能

作接口測試,須要的技能,基本就是如下幾點:

業務流:瞭解系統及內部各個組件之間的業務邏輯交互;

數據流:瞭解接口的I/O(input/output:輸入輸出);

協議:包括http協議,TCP/IP協議族(以前的博客有系統的介紹過協議,傳送門:http協議:菜鳥入門系列

工具:工具能夠輔助咱們更好更高效的完成工做,經常使用的接口測試工具備:jmeter、loadrunner、soapui、postman等;

數據庫知識:不管是從數據庫獲取知識,仍是確認數據落地,抑或接口對數據執行了哪些操做,都須要確認,所以數據庫知識(其實就是增刪改查)就頗有必要;

補充:接口文檔的幾個必要點:完整性、一致性、容錯性

 

3、接口自動化測試

一、如何開展

首先,調試單個接口,保證單個接口的正確和通暢(相似於性能測試中的基準測試);

其次,明確數據流,業務流;

最後,將N個接口測試腳本串起來,執行便可;

最重要的一點,別想太多太複雜,先把最基礎最簡單的作起來,就成功一大半了,至於擴展性的第三方接口、https、定時任務、自動出測試報告、自動發郵件等等功能,這都是不斷累計和優化的,

行動起來就行,想太多不如行動起來,讓接口自動化測試落地,纔是咱們首先須要考慮的!

二、開展以前須要知道的

如今的測試對象包含幾個頁面?

每一個頁面涉及幾個接口?

分別在哪一步調用?

每一個接口包含哪些字段?

各個字段對應數據庫哪張表?

每一個表中各個字段是什麼意思?

各個接口對錶產生了怎樣的操做?

三、自動化框架

什麼是框架?你能夠理解爲一個完整的環,也能夠理解爲讓接口測試腳本運行的一整套環境,平臺,隨便什麼均可以;通常一個自動化測試框架包含如下幾點:

數據池:即測試數據的存儲管理,通常集成爲一個data包,其中包括:

       log(日誌文件)、report(測試報告文件,通常爲xml格式)、case-data(單個接口的測試數據,通常爲json格式)、server-data(接口業務串聯的數據,能夠用excel管理)

腳本管理中心:接口測試腳本的統一管理、存儲、調度中心,經常使用的工具備maven、ant等,或者可使用編程語言中的單元測試框架提供的功能,選擇本身適用的便可;

運行平臺:通常是藉助工具來運行這些測試腳本,工具可使用上面說起到的幾種(jemter、loadrunner、soapui等),一樣,選擇合適的很重要;

持續集成工具:最多見的就是Jenkins,它的做用就是監控外部程序的調用執行,定時或者觸發調度任務,測試腳本執行等功能;

通訊服務:dubbo、spring_boot、thrift等RPC、REST同步調用服務;

測試結果統計管理中心:好比testlink,目的是爲了測試結果自動更新上傳,更好的統計測試結果,以便後期的優化;

上面說了這麼多,實際上它的意義就是:數據與腳本分離,測試結果自動提交通知,提升測試腳本和測試數據的維護便利等等。。。

我正在使用的框架爲:jemter+maven+Jenkins+dubbo+MySQL......

 

關於接口自動化測試,基本就是上述的內容,固然,選擇適合自身實際狀況的框架,落地實施,纔是重點,行動起來,才能鹹魚翻身。。。

相關文章
相關標籤/搜索