1. 程式人生 > 其它 >介面學習筆記-介面測試(一)

介面學習筆記-介面測試(一)

一、介面測試描述

介面測試是測試系統元件間介面的一種測試。介面測試主要用於檢測外部系統與系統之間以及內部各個子系統之間的互動點。測試的重點是要檢查資料的交換,傳遞和控制管理過程,以及系統間的相互邏輯依賴關係等。 

  一般來說,測試介面,就是指測試介面的功能,效能和穩定性測試,當然可能還有安全性測試。這個入門系列會讓你掌握介面的功能測試。一般,來說我們聽說到的介面基本上都是指HTTP或者HTTPS協議的介面測試,也就是一些web服務請求。一個軟體專案中,

有很多介面,少的有幾十個,多的有幾百上千個介面。這個時候,我們沒有軟體介面,沒有具體的測試場景,只有一個介面描述文件。我們需要把介面這樣抽象的東西,通過軟體測試的理論和方法去測試介面,找出介面的功能和安全性的缺陷。介面有內部介面和外部

介面。內部介面就是開發人員自己開發的介面。外部介面,好比網站呼叫微信支付和支付寶支付介面。還有一些模組與模組之間的介面。

二、為什麼要做介面測試

·

1、現在很多系統前後端架構是分離的,因為不同端(前段,後端)的工作進度不一樣,所以我們要針對最開始出來的介面,以及需要呼叫其他公司的(銀行,支付寶,微信,qq等)一些介面進行介面測試及驗證資料,從安全層面來說,   只依賴前端進行限制已經完全不能滿足系統的安全要求(繞過前端太容易了), 需要後端同樣進行控制,在這種情況下就需要從介面層面進行驗證。在這種情況下就需要從介面層面進行驗證。前後端傳輸、日誌列印等資訊是否加密傳輸也是需   要驗證的,特別是涉及到使用者的隱私資訊,如身份證,銀行卡等。    2、如今系統越來越複雜,傳統的靠前端測試已經大大降低了效率,而且現在我們都推崇測試前移也叫測試左移
,希望測試能更早的介入測試,那介面測試就是一種及早介入的方式。例如傳統測試,你是不是得等前後端都完成你才能進行測試,才能進行自動化程式碼編   寫。 而如果是介面測試,只需要前後端定義好介面,那這時自動化就可以介入編寫介面自動化測試程式碼,手工測試只需要後端程式碼完成就可以介入測試後端邏輯而不用等待前端工作完成。      測試左移這個是一次偶然的機會在群裡看到的,孤陋寡聞的我,第一次看到,也是一知半解,後來查了一些資料供大家參考。      測試左移的原則支援測試團隊在軟體開發週期早期和所有干係人合作。因此他們能清晰地理解需求以及設計測試用例去幫助軟體“快速失敗”,促使團隊更早的修改所有的bug。        測試左移
並沒有什麼獨特的,只是讓測試人員在軟體開發生命週期內更早的參與進來,同時讓他們去理解需求、軟體設計、軟體架構以及軟體功能,也讓他們去向客戶、商業分析師和開發人員問問題,尋找答案,提供反饋結果已達到支援團隊的工作得可能性。參   與和理解會使測試人員獲取產品完整的知識,徹底想清楚各種場景,根據軟體行為設計實時的場景,這些都會幫助團隊在編碼完成之前識別出一些缺陷。這樣也可以更好的的體現我們作為一個QA的價值體    三、                                                       
金字塔模型 通過之前對金字塔結構的學習,大概瞭解到了金字塔模型想告訴我們的幾個道理:     1.越底層,越穩定。   金字塔主要觀點認為單元測試的穩定性高,需要多投入。     2.越底層,越高效。   程式的問題,最終還得落在具體的程式碼上,所以底層的測試更容易發現問題。     3.越底層,越低成本。   越底層測試能越早發現問題,越早發現問題,修復的成本自然越低。     4.越底層,越難實施。   越底層的實現對技術專業性要求越高,這點跟第三點有點矛盾,往往越專業的人才也意味著人力成本越高。     綜合下金字塔模型,隨著前後端分離越來越清晰,我個人愚見提出了燈籠模型,拿介面測試和UI層測試以及單元測試做了比較,從圖中各部分所佔有的比重,可以一目瞭然的看出並最終認定介面(API)測試可以獲得較高的投資回報。                                                                                    

 


    燈籠模型   個人愚見,如有過錯,請批評指正:

  介面將前端和後端進行很好的分離,幫前後端實現資料互動,這樣在專案初期就可以和前端工程師討論需要的後端資料,然後後端根據需求開發後接口,將資料返回給前端,測試人員提前進入測試介面,前後端然後在各自開發自己模組。

 專案遷移,以及後期維護,介面帶來的便利性,試想一下,如果沒有專案交付以後,後端人員將資料庫的某個欄位的長度、型別修改後發版,而由於某些原因沒有及時通知前端工程師,而此時前端的獲取的這個欄位的型別、長度是以前的,那麼就可能引發線上事故。如

果前端技術牛叉,儲存獲取欄位是一個變數,工作量還小點。只需要改變變數型別、長度即可,如果是一個差一點的沒有用變數,而前端又是好幾百個頁面都用到這個欄位,這樣就造成後果無法想象的,但是用到介面就有不一樣了,如果出現類似的情況,後端人員只需

要將這個欄位通過介面做處理是返回的欄位保持一致即可,也就是分分鐘的事,可能使用者都沒有察覺就修復了。而且前端、後端、測試也很好排查問題,跑一下介面,檢視介面文件返回資料有差異,修給介面就可以,這樣處理問題效率也會大大提高。

  簡單概括:

①.越底層發現bug,它的修復成本是越低的。

②.前端隨便變,介面測好了,後端不用變,前後端是兩撥人開發的。

③.檢查系統的安全性、穩定性,前端傳參不可信,比如京東購物,前端價格不可能傳入-1元,但是通過介面可以傳入-1元。

④.如今的系統複雜度不斷上升,傳統的測試方法成本急劇增加且測試效率大幅下降,介面測試可以提供這種情況下的解決方案。

⑤. 介面測試相對容易實現自動化持續整合,且相對UI自動化也比較穩定,可以減少人工迴歸測試人力成本與時間,縮短測試周期,支援後端快速發版需求。介面持續整合是為什麼能低成本高收益的根源。

⑥.   現在很多系統前後端架構是分離的,從安全層面來說:

(1)、只依賴前端進行限制已經完全不能滿足系統的安全要求(繞過前面實在太容易), 需要後端同樣進行控制,在這種情況下就需要從介面層面進行驗證。

(2)、前後端傳輸、日誌列印等資訊是否加密傳輸也是需要驗證的,特別是涉及到使用者的隱私資訊,如身份證,銀行卡等。