隨著移動互聯網的發展,越來越多的應用基于前后端分離構建,后端提供數據接口,前端調用接口返回數據渲染到UI,這個時候保證后端接口數據正確性變的愈來愈重要,接口自動化測試逐漸成為各大公司投入產出比最高的測試技術。介入時間早,執行效率高,穩定性高的優點,讓越來越多的公司引入接口自動化測試。很多團隊,接口測試就是手動運行接口,肉眼比對接口返回的數據,這樣的操作流程效率低下,容易出錯,如何實現對接口的自動化測試,提升接口測試的效率呢?本次我們有幸邀請到一位接口自動化資深大佬,幫助大家且深入的熟練掌握接口自動化測試,讓你工作得心應手!
15年

15年以上軟件測試、開發及管理經驗
參與過美國大型收繳費系統的開發及測試工作

項目

熟悉大型應用軟件的開發和測試流程
有豐富的測試技術項目管理經驗

管理

對單元測試、系統測試的方法和管理流程有深刻認識

51Testing:商老師您好,有很多測試人員對接口測試不是很了解,您能和我們說說為什么要做接口測試?接口測試的意義是什么?編寫接口測試用例時應該考慮哪些測試點?
        當今的互聯網時代,需要越來越開放,也更需要越來越“兼容”。所謂的開放,是一些通用的平臺(比如銀聯、微信或支付寶等),開放出來可以供其他的運營平臺進行調用,同時要提供一些標準的使用規則,可以供各種不同的系統和平臺進行相互的數據傳輸及處理,這就是所謂的“兼容”。

        接口技術剛好滿足了這兩個特點要求,它不僅能夠有效的保護自身系統的安全性和完整性不受到危害的同時,可以把接口的規則和要求以及處理的結果“公諸于眾”,讓其他的產品及平臺能夠和這些通用平臺進行數據的通訊,既保證了安全性,又擴展了平臺的應用范圍。而對于公司產品內部而言,用接口進行設計實現,也可以很大程度上的提升產品實現的靈活性,適應各種不同情況的處理邏輯變更問題。所以接口測試不光是我們系統內部之間的相互調用,可能還有系統之間,平臺和平臺之間的,這些都是有可能的。所以基于以上這樣的IT產品的技術應用背景,接口測試工作勢在必行,但這方面的測試人才儲備和培養是遠遠不夠的,因為企業需求大,而且薪資待遇高,所以就成為現在最炙手可熱的測試崗位之一。

        從技術層面上而言,接口測試的意義主要是檢查接口的實現和接口測設計是否相一致。接口測試的用例設計主要是考慮到接口的請求地址、請求類型、請求參數等等。

        在具體設計接口測試用例時,先要對接口測試需求進行挖掘和分析,很多人認為接口測試用例很簡單,就是按照要求構造正常的參數,異常的參數就可以了。這些只能達到一個接口是否可用的最低測試標準。如果我們希望設計完備的接口測試用例,那就不能只是簡單的考慮參數的正確和錯誤,而應該從接口測試的整體進行全面的分析。

        接口測試包括獨立接口的測試、聯調接口的測試、接口性能測試、接口安全性測試等多個方面。最近我們正在給企業做的一個項目就是接口性能測試。

        所以不能簡單的把接口測試用例只定位在獨立接口功能測試層面上,這個是不充分的。要考慮是否存在大規模的接口并發調用問題。還有就是接口的安全性,因為現在有很多抓包工具,如果我們在發送接口請求時沒有對敏感或重要數據進行安全性處理的話,經過抓包可以獲取相關的賬號或密碼信息,那就是很恐怖了。

        而且每一個接口的設計細節還有很多的不同,比如有些接口參數是放在header中而不是body體中,有些是https協議,不是http協議,有些接口還需要有cookie或session的認證才能發送成功,有些認證參數是靜態的,有些卻是動態生成的,有些接口在執行時,需要用到其他接口的返回結果,等等。諸如各種各樣的接口設計分析問題,都是要在接口測試需求分析和用例設計工作中去解決的。
點擊展開
點擊收起
51Testing:在學習接口測試的過程中,經常會提到API接口測試和普通的接口測試,兩者之間有何區別?
        API(Application Programming Interface)顧名思義,叫應用程序編程接口。它屬于接口,但是接口的概念更寬泛一些,可以說API只是接口的一種類型。比較流行的API接口有RPC(Remote Procedure Call)、RESTful、web Service、Socket。

        對于接口測試工程師而言,這些接口的具體內部實現方式以及它們的區別對于接口測試工作本身的影響并不大。

        可以借用“以不變應萬變”的工作思路,即無論是哪種接口實現技術,我們都要有能力分析出以下內容,就可以有效的開展后續的接口測試工作了。
  • 接口的請求地址或接口程序訪問地址
  • 接口所需要傳遞的參數(參數個數,參數名稱,參數的規則及要求等,注意是否存在隱性參數)
  • 接口的請求方式
  • 接口的響應結果(格式,內容,正常響應,異常響應)
點擊展開
點擊收起
51Testing:用JMeter做接口測試和用Python做接口測試有什么區別呢?
        Jmeter是一個測試工具,而Python是一個腳本語言,這是兩個范疇的概念,無法進行區別比對。簡單來說可以這樣理解,使用Jmeter可以通過人工的操作來進行接口測試的執行工作,我們暫且稱為接口手工測試。這樣的工作方式非常簡單,在接口測試工作量比較小的情況下,還是可行的,但是需要測試接口的數量非常多,一般來說超過20個以上,就不太適合再用工具進行測試了。

        建議可以在接口基本已經穩定的情況下,使用python來編寫自動化接口測試腳本來進行,可以大大提高測試工作的整體效能。
點擊展開
點擊收起
51Testing:在進行接口測試之前,一般開發會提供接口文檔,給出一些接口參數和必要熟悉,便于我們編寫接口腳本。但如果沒有提供接口開發文檔的請求下,我們該如何編寫接口測試腳本呢?在編寫測試腳本前要做哪些必要的準備呢?
        其實現在很多公司都存在文檔不完備,文檔不全,或者是有變更,沒有進行及時更新的情況,更嚴重的就是壓根沒有文檔,各種可能性都有可能存在。那么作為測試工程師,我們要學會在最惡劣的環境下生存,所謂最惡劣的環境就是文檔不規范,甚至沒有文檔的情況。如果在這種情況下都不妨礙測試工作的進行,那您可以說在接口測試需求分析方面具備了很強的理解、溝通和分析能力。

        那么在接口文檔支持不足的情況下,到底如何開展編寫接口測試腳本呢?個人建議首先要解決的不是腳本編寫的問題,必須先解決測試需求分析的問題。具體過程如下:

        1、明確接口測試范圍


        2、進行接口測試需求分析


        3、使用postman等工具進行接口的冒煙測試

        4、接口基本上測試通過或bug已經修復完成

        5、編寫自動化接口測試腳本
點擊展開
點擊收起
51Testing:接口測試數據用什么方式構造和存儲比較合理,有利于后期維護?
        接口測試數據有很多種存儲方式,如果從便于腳本的編寫和維護的角度而言,我們可以在研發接口測試腳本的時候,以不同的方式分版本來實現接口測試數據的存儲,一方面可以由簡到繁,逐步提升測試數據的覆蓋面,同時也更有利于腳本研發工作的開展和后期的維護工作。具體過程如下:

        1、V1.0版本,以一組固定的常量方式來存儲接口測試數據。這個版本所研發的腳本主要目的是調通接口的正常請求發送。

        2、V2.0版本:把常量的測試數據變成變量形式存儲,一般在python種采用字典格式。這個版本是一個過渡版本,為后續的腳本參數化打一個基礎。


        3、V3.0版本:以文件的方式進行測試數據的存儲,可以現在文件中寫入一組測試i數據進行讀取,調試通過后,再多增加兩組數據,再進行調試,直到沒有任何問題了,就可以放心大膽的構造任意的批量數據了。

        4、V4.0版本:有些接口測試數據必須從數據庫中實時讀取,那就需要寫腳本連接數據庫,通過執行SQL命令取出相應的測試數據。

        很多測試工程師都懷疑自己的編程能力,其實是因為我們缺乏循序漸進的提升方法。像以上這樣我們逐步的分版本,由簡到繁慢慢增加腳本的難點,那么不僅大家了解了各種數據存儲的方式,而且每一個版本都能實現我們預期的目標,這樣的工作也會讓我們越來越有成就感,越來越有競爭力!
點擊展開
點擊收起
51Testing:那中小企業的測試人員要如何從零開始搭建企業級的接口自動化框架?能否舉例說明一下呢?
        那么所謂的接口自動化框架,它有兩種不同的類型,一種類型的就是完全用現在成熟的一個框架技術,只是把我們相關的這個接口的腳本移植到框架里面能使用框架進行運行就可以了。這種方式的優點的就實現起來比較方便一些,也不需要投入額外的太多的開發去進行,只要把用例的腳本移植到框架里面,以框架的風格來編寫和運行就可以了。但靈活性是比較弱,很難應對頻繁的、大規模的不同版本的回歸測試。

        舉個例子:假如我們有一千多個腳本文件,此次回歸測試里面需要從中提取34個腳本執行.首先怎么找到這34個腳本,執行順序怎么重新調整,這些腳本對應哪些測試數據文件,又生成哪些測試報告......這些工作沒有復雜度,但是非常繁瑣,也考驗我們的記憶力!

        但如果我們有自己研發的接口自動化框架,那就不一樣了。可以通過讀取自己設計的配置文件,來確定要運行哪些腳本文件,只要把運行的狀態改一下就行,接口之間的執行順序也只需要改配置文件就可以了。修改好配置文件后,啟動框架驅動程序,一鍵就可以搞定了。如果我們自主研發的框架靈活性足夠強的話,不僅支持一個項目,任意項目都是可以支撐的,只要去維護框架的配置層文件就可以了,代碼是絲毫不用做任何的調整的,所以是非常值得我們去研究和探討的。
點擊展開
點擊收起
51Testing:有會員反映在接口測試中,經常會遇到cookie和session,二者有什么區別和聯系呢?
        cookie和session不一定是接口測試才能遇到的,這是程序在設計的時候本身存在的。它們都是為了進行頁面訪問驗證而使用的技術。簡單來說就是在打開一個頁面時,后臺服務器如何判斷你是哪個用戶,是非法的還是已登錄的合法用戶,它都要通過cookie或session來進行判斷。

        cookie和session最大區別的就是一般而言cookie會保存在用戶本地的瀏覽器端,只要不刪除或賬號信息不變更,可以一直使用,而session是服務器發給我們的一個動態驗證碼,在我們關閉瀏覽器或退出訪問或超過一定時間時,就會失效,如果想繼續訪問,就必須重新登錄后,服務器端會重新發一個session。

        比如說我們拿一個網站來說,我們登錄一次后,發現下次登錄時,界面上自動存有上次登錄的用戶名,一般來說都是采用了cookie技術,把信息保存在本地了。但是有的網站訪問時我們發現,如果有一會沒有操作頁面(比如超過了一個多小時),再進行操作時,它自動跳轉到登錄頁面,讓我們重新登錄,說明可能使用的是session技術,這時候說明session超時了,已經失效了。

        在進行接口測試時,如果遇到cookie和session,就需要進行這些參數的構造了,否則無法訪問成功。如果大家想具體了解如何進行cookie和session的驗證,可以看一下python全棧測試開發課程關于接口測試部分的內容。
點擊展開
點擊收起
51Testing:隨著手機支付的普及,越來越多的人已習慣出門不帶現金,直接用手機支付購買商品。作為測試人員要怎么調用微信和支付寶第三方接口進行測試呢?(例如:程序支持微信支付,支付寶支付,怎么對交互接口測試?)
        其實對于我們測試人員來言,我們所謂的內部接口和外部接口跟我們來說沒有什么太大關系,我們所有的測試都是要解決我剛講的就是接口的請求地址、請求方式、傳入參數,包括驗證,你要不要給我一個數字證書啊,反正我要去安裝呀?把這些問題搞清楚了,他其實接口的實現過程基本上是類似的,沒有什么太大區別,只是說一個是系統內部一個是系統外部。
51Testing:現在跟多公司的接口都進行了這樣或者那樣的加密處理,以前測試人員測試的接口都是沒有加密的,現在的接口加密了,那如何去對這些加密過的接口進行測試呢?
        加密有幾種加密方式,一種是協議上的加密,比如用HTTPS那這種這時候需要可能有一個協議的證書去把他導入到我們的這個接口的代碼里面,或者說如果我們用工具進行接口測試的話,需要將其導入到我們的工具中,這是一種所謂的加密方式,和數據加密不太一樣。

        那關于接口的數據加密,那就是我們在測的時候發送出去之后我們要通過抓包工具,或者通過腳本,幫我們發送的數據的截取下來看看我們的數據有沒有進行加密的一個處理,判斷是否十分正確,比如說我們把加密后的數據取出來之后呢,在要去問開發要一個解密的一個算法,然后呢去執行這段算法之后,看你加密之后通過解密這個程序解密之后和你剛才輸入的參數是否一致就可以了,主要就這么兩個過程。
點擊展開
點擊收起
51Testing:如何在初創自動化團隊引入并推廣自動化測試?有什么注意事項嗎?自動化從零到有怎么樣才能少走彎路?
        基本上所有的自動化測試工作都需要一些共有的前提條件,和是否初創的關系并不是特別大,主要和以下幾個條件相關:

        1、這個項目或產品是要長期運營還是提交之后就沒有太多的維護工作了

        2、目前我們的需求或設計是否已經基本穩定或局部穩定

        3、團隊中是否有具備自動化測試能力的工程師

        如果這個產品或項目需要長期運營,意味著后續有越來越多的回歸測試要進行,那就非常有必要進行自動化測試了。但如果這個產品提交后,不需要太多的升級維護工作,那么可以有自動化測試,但辛苦開發的腳本使用的次數如果在10次以下,就工作的投入產出比而言就是不劃算的。

        可以給大家舉個例子,比如我們天天頓頓吃面包,那么買個面包機(加入花500元,帶原材料),比起外面買面包而言,每一個面包便宜至少5元,也就意味著如果我們吃了200個面包,節約了1000元,減去投入成本500,我們還有500的利潤,這個就是面包機創造的價值。但如果我們不是每天每頓都吃面包,非常偶爾吃一下,那么大家算算,吃夠了100個面包,才是剛剛持平,如果只吃了10個面包,就不再吃了,那就太虧本了。

        而自動化測試就像面包機一樣,雖然后續的工作成本越來越低,但是初期寫腳本的工作量比手工測試要高很多,可以說差不多1:10的關系,那么投入這么大的工作成本做出來的成果,使用次數太少,其價值就無法體現了。所以第一個條件是決定有沒有必要進行自動化測試的首要條件。

        其次為什么需要需求設計較為穩定或局部穩定呢?因為需求設計的變更很有可能會帶來腳本的變更,這都需要投入不少的工作量,也是一樣的道理,如果反復的修改腳本,其所投入的時間遠遠大于手工測試的時間,所以一般都是針對需求、設計比較穩定或者是使用頻率比較高,比較重要的內容做自動化測試,其性價比是較高的。

        最后一個條件:團隊中是否有具備自動化測試能力的工程師,不言而喻是需要具備的。如果非常有必要開展自動化但是沒有自動化人才,那么就需要創造條件去滿足了。要么招聘要么培訓,主要是這兩種方案。

        至于自動化從零到有怎么樣才能少走彎路的問題,可以有三個方面的思路來考慮:

        首先:分析自動化前提條件是否已經具備,哪一項不具備,就不要急于開展,否則得不償失;其次如果前兩個條件基本已經滿足,最后一個人的問題就是招聘和培訓來解決,先不要大面積招聘,可以先找一個技術優秀又愿意分享的人才,讓他先針對重要常用的功能實施自動化,等有了成果后,也通過了審核,確認技術是過關的沒有太大問題的時候,可以陸續再招聘1-2名較為熟練的自動化測試工程師,由這名優秀的工程師帶領,逐步推行自動化測試,等基本成熟后,可以把團隊中業務能力優秀的手工測試工程師培養轉化為自動化工程師,或招聘新的人才,這樣團隊就慢慢建立起來了。

        自動化測試的成果也不要一下子要求太高,先從獨立的測試腳本慢慢積累,在到業務場景腳本的實現,最后才是到測試框架這個維度。逐步積累經驗,不容易半途而廢,而且保證產出的成果物都能用于目前的測試工作,就基本上沒有太大的風險了。
點擊展開
點擊收起
51Testing:您認為是否任何項目都適合使用自動化?如果遇到您判斷來看用不上自動化,但是領導希望做這個東西來顯示部門的含金量,這個時候有有必要據理力爭嗎?
        關于自動化的前提條件前面也已經提到過了。如果領導希望使用自動化,在條件不完全具備的情況下也是可以考慮的。首先,先要給領導說明為什么現在有些條件不具備,這樣做可能的風險是什么,要有實際的數據來進行說明。其次,領導能承擔這個風險的前提下,我們可以針對一些穩定的業務或模塊,開展部分的自動化測試試驗,這是可以的。最后,如果沒有這方面的人才,可以邀請一些外部的技術專家進行培訓指導,還有其他的方式也可以和領導探討。結合領導可接受的投入,來規劃我們的自動化測試工作。自動化測試確實是一個勢在必行的事情,但是需要多溝通,多交流,多積累,多儲備人才,可以逐步分階段進行就可以了。
點擊展開
點擊收起
51Testing:作為部門領導,在團隊初創時,您是否有遇到過人力投入安排的問題,在團隊人力進展的情況下,要如何合理安排,高效地開展測試工作呢?
        所謂的人員投入安排是一個比較大的一個問題,可以給大家一些參考。首先,要判斷一下目前團隊成員的技能水平,如果有些工程師腳本能力不太強的,可以使用工具進行手工的接口測試。腳本能力比較強的,要再細化是能寫獨立的腳本,還是說測試框架也能實現?把人員的技術分成不同的層次,可以做一個團隊成員能力分析表。

        依據每個成員的技術能力進行分工,這樣更容易完成預定的計劃。而不要簡單的只按照工作量進行平均分配,做到人盡其能,才是最有效的分工方式。

        在這個前提下,如果資源還是不足,那就必須要和項目經理或更高的管理層進行溝通了。溝通的目的就是如何能提升開發提交代碼的質量問題,也就是說如果開發提交的代碼質量能有很大程度的改善的話,那么測試資源其實就可以很大程度的減少投入了。

        如果還是不足,可以考慮臨時找一些實習的測試工程師,但是前提是我們的測試用例需要特別完備,特別詳細才可以。

        以上這些方法供大家參考使用,如果都無法做到,那就是有很大的測試風險,需要提前和管理層進行充分的溝通,讓大家了解到這個問題。
點擊展開
點擊收起
51Testing:如果遇到團隊沒有接口測試相關的技術領頭人,大家都只有邊學邊試著做,從無到有,應該按照怎樣的步驟來走?您能否提供一個系統的學習線路圖?
        如果測試團隊中沒有技術負責人,那么建議先開展接口手工測試。等到基本的測試任務都完成了,接口相關的bug也修復了,需求設計也基本穩定了,可以邊學邊試著做自動化測試。否則工作風險太高,不建議大家在正常工作沒有保障的情況下做“試驗”。

        如何進行系統的學習,基于python的全棧課程的設計思路給給大家一些建議參考:

        1、一定要依托于項目,不能單純的只是為了學習而學習

        2、學習也好,試驗也罷,必須在開展之前,明確我們要提交的測試成果物是什么,要有目的的學習和試驗,要有成果對應。一般而言,自動化接口測試的成果有:接口測試需求分析、接口自動化測試用例、接口測試腳本、接口測試中遇到的問題分析等等。

        3、完成一個任務后,要對該任務進行不斷的優化升級(比如最開始的腳本只支持一組數據的測試,如何能支持任意多組測試數據的測試覆蓋呢?原來的腳本沒有測試報告內容,無法脫離人的跟蹤檢查,那如何加入測試報告的內容呢?......)

        4、從一個單一的任務逐步過渡到復雜的、有關聯的場景測試任務,最后到自動化測試框架的設計及研發。

        按照以上這樣的思路開展學習、試驗以及工作的推演,不僅能很快的上手,而且目標也是十分清楚明確的,成果也是可見可評估的。不是簡單的技術或語法的堆砌,我們最終要解決的是工作的具體問題,這點非常重要!
點擊展開
點擊收起
51Testing:隨著互聯網市場競爭愈發激烈,在企業招聘軟件測試中高級崗位時,很多女性會因為已婚未孕、生育問題,收到用人單位的各種刁難!同時在女性帶領團隊的時候,往往不知所措,作為一個成功的女領導,您之前是否有遇到這樣的問題?您是如何解決的?
        自己也是一個女性,不敢稱為成功。和大家就是交流分享,希望能對大家有幫助就好!關于女性做測試崗位其實有很多的優勢,而面臨婚育問題,其實大家不用過于恐懼。因為無論是什么崗位的女性,都會面臨這個階段。只是有幾點需要注意的地方,大家提前規劃好就沒有問題了。

        首先,重中之重是不要把生育和換工作甚至是技術提升這三件事放在一個時間點上去完成。也就是說不要到了快生育或打算生育的時候同時又要換工作,還想提升崗位或薪資。這是非常糟糕的規劃。

        合理的規劃應該是,在一家公司任職超過2年以上(至少一年以上),各方面的工作做的還比較不錯,領導也比較認可,這時候就可以考慮生育問題。因為我們為公司已經創造了工作價值,生育的問題公司領導是可以接納和認可的。但是如果我們在婚育年齡(結婚問題倒不大,主要是考慮生孩子的風險),這時我們又想換個工作,甚至想換個更好的工作,那基本上就比較糾結了。除非您能力特別強,或者公司愿意承擔您生育對工作進度影響的風險,或者您本人承諾幾年之內不生孩子......總之,這時很難成為公司的首選人才,只能是備選項了。

        如果大家沒有完全規劃好,剛好已經準備生育但同時也面臨找工作,那么就只能退而求其次了,但是仍然可以改善。策略一:找一個不是特別繁忙的工作,薪水不要要求太高,那就一邊工作一邊安心待產。策略二:辭職在家生產。但這兩個策略大家都要注意,在這一段不算短的時間內,大家一定不能松懈,不要認為只生寶寶就行,對未來而言仍然有很大的風險。因為我們生產后再去找工作,公司仍然會擔心我們的工作強度能否勝任,所以沒有過硬的技術,可能在一段時間內,還是沒有太多的競爭優勢。

        所以大家一定要利用好每一段較為閑暇的時間,一定要不提升自己的技能。我們網校的python全棧測試大家可以參與進來,是以項目的形式帶領大家一步步完成自動化的測試任務,有了項目和技術的成果,那么等可以上班或者再找更好的工作,我們才有了過硬的砝碼。千萬不能懈怠,否則生完寶寶再找工作,我們技術上沒有什么優勢,又有一段時間可能沒有參與工作,仍然是難以繼續發展的。即使要做全職的媽媽,也需要不斷的學習如何教育孩子,所以任何時候,我們都不能忘記學習和提升自己。

        其實講到最后,女性也好,生寶寶也好,其實都不是問題,只要我們規劃好,有了過硬的技術實力,永遠都是公司炙手可熱的測試人才,并不會因為這些正常的事情而影響到我們的提升和發展!

        特別喜歡老師(索達吉堪布上師)說過的一句話:終身學習、終身修行、終身利他。也把這句話送給大家,祝愿我們每一個人都能通過自己的不斷努力,給自己的未來插上騰飛的翅膀!!
點擊展開
點擊收起
日本av