自動化測試常見問題總結!(適合新手團隊)

狂師發表於2021-12-13

自動化測試是近幾年比較火熱的一個話題,想要在軟體測試這個行業繼續前行,就必須擁有核心競爭力,掌握自動化測試技術,是必不可少的一個技能

在《Google軟體測試之道》一書中有介紹到:在Google,70%的自動化測試工作集中於單元測試,20%集中於介面測試,剩下10%才是UI測試。

誠然,我們沒有Google那麼完善的機制和工程師文化,沒必要一切照搬Google,但Google作為網際網路2.0時代最耀眼的一個公司,它的技術發展方向,流程管理等可以說是不久的將來,我們也要到達的方向。選擇適合自己的,落地應用,是當下我們應該做的。目前國內的網際網路行業,大環境來說,還處在一個快速發展,需要流程化標準化的時期,如何跟上不斷變幻發展的節奏,除了不斷了解接觸新的東西,還需要不斷學習,提升自身,以內在的驅動力,去緊跟時代浪潮。即使做不了弄潮兒,也不能變成時代淘汰的那一批。

一、自動化測試簡介

1、為什麼要進行自動化測試?

①黑盒測試迴歸效率低;

②手動測試的偶然性和不確定性;

③迴歸的覆蓋率不足;

④交付的產品質量無法保證,全靠評估;

⑤系統越複雜,問題越多;

⑥上線時間長、構建失敗率高導致的蝴蝶效應(迭代快,加班多);

2自動化測試能解決什麼問題?

①提高出現問題後的響應速率;

②降低迴歸成本;

③提高迴歸覆蓋率;

④提高迴歸效率;

⑤提高迴歸的穩定性;

3自動化測試的不足有哪些?

①無法減少成本投入,而是為了加快測試結果反饋,提升測試質量;

②自動化適用於迴歸和冒煙,而不是發現BUG;

③錄製回放功能是雞肋,視覺化並不是一個很好的做法;

④不是所有所有系統所有功能都適合做自動化測試;

4常見的自動化測試框架?

介面自動化框架常用組合:

方案一:Java+TestNG/Junit+Maven/ANT/Gradle+Jenkins+Mysql+Testlink/Redmine
方案二:JMeter+Maven/ANT/Gradle+Jenkins+Mysql+Testlink/Redmine
方案三:Python+Unittest/Pytest+Jenkins+Testlink/Redmine
方案四:Python+Robot Framework+Jenkins+Testlink/Redmine

UI自動化測試框架常用組合:

方案一:Java+Selenium/Appium+TestNG/Junit+Maven/ANT/Gradle+Jenkins+Mysql+Testlink/Redmine
方案二:Python+Selenium/Appium+Unittest/Pytest+Jenkins+Testlink/Redmine
方案三:Python+Selenium/Appium+Robot Framework+Jenkins+Testlink/Redmine

通過上面的一些常見框架,你發現了什麼?它們都擁有共同特性:程式語言+單元測試框架+掃描編譯工具+持續整合工具+資料庫+專案管理工具

  • 程式語言:編寫測試指令碼、日誌記錄和輸出;
  • 單元測試框架:提供測試指令碼執行、異常校驗等一些列的配置;
  • 掃描編譯工具:測試檔案掃描編譯,一般配合持續整合工具使用效果更佳;
  • 持續整合工具:Jenkins,經典的持續整合工具;
  • 資料庫:測試資料管理;
  • 專案管理工具:測試結果統計管理;

自動化測試工具太多,上面只是列舉使用率較高以及一些開源工具,具體的框架選型,需要根據具體專案特點和團隊、個人技術特點來決定。

二、介面測試的意義和必要性

介面,即API,應用程式程式設計介面。以下主要說說介面測試的必要性和意義:

介面測試實施在多系統的平臺架構下,有著極為高效的成本收益比(當然,單元測試收益更高,但實施單元測試的成本投入更大,技術要求更高,所以應該選擇更適合自身的才是最好的方案)。

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

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

1、節省測試成本

根據資料模型推算,底層的一個程式BUG可能引發上層的8個左右BUG,而且底層的BUG更容易引起全網的當機;介面測試能夠提供系統複雜度上升情況下的低成本高效率的解決方案。

2、介面測試不同於單元測試

介面測試是站在使用者的角度對系統介面進行全面高效持續的檢測。

3、效益更高

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

三、開展介面測試必備的技能

開展介面測試需要的技能,基本就是以下幾點:

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

資料流:瞭解介面的I/O(input/output:輸入輸出);

協議:包括HTTP協議,TCP/IP協議族;

工具:工具可以輔助我們更好更高效的完成工作,常用的介面測試工具有:Jmeter、LoadRunner、SoapUI、Postman等;

資料庫知識:無論是從資料庫獲取知識,還是確認資料落地,抑或介面對資料執行了哪些操作,都需要確認,因此資料庫知識(其實就是增刪改查)就很有必要;

介面文件的幾個必要點:完整性、一致性、容錯性

四、介面自動化測試

1、如何開展介面測試?

  • 首先,除錯單個介面,保證單個介面的正確和通暢(類似於效能測試中的基準測試);
  • 其次,明確資料流,業務流;
  • 最後,將N個介面測試指令碼串起來,執行即可;

最重要的一點,別想太多太複雜的層面,先把最基礎最簡單的做起來,就成功一大半了,至於擴充套件性的第三方介面、https、定時任務、自動出測試報告、自動發郵件等等功能,這都是不斷累計和優化的,想太多不如行動起來,讓介面自動化測試落地,才是我們首先需要考慮的。

2、開展之前需要明確的問題?

①現在的測試物件包含幾個頁面?

②每個頁面涉及幾個介面?

③分別在哪一步呼叫?

④每個介面包含哪些欄位?

⑤各個欄位對應資料庫哪張表?

⑥每個表中各個欄位是什麼意思?

⑦各個介面對錶產生了怎樣的操作?

3、搭建自動化測試框架

什麼是框架?你可以理解為一個完整的環,也可以理解為讓介面測試指令碼執行的一整套環境,平臺,隨便什麼都可以;一般一個自動化測試框架包含以下幾點。

資料池:即測試資料的儲存管理,一般整合為一個data包,其中包括:

log(日誌檔案)、report(測試報告檔案,一般為xml格式)、case-data(單個介面的測試資料,一般為json格式)、server-data(介面業務串聯的資料,可以用excel管理)

指令碼管理中心:介面測試指令碼的統一管理、儲存、排程中心,常用的工具有maven、ant等,或者可以使用程式語言中的單元測試框架提供的功能,選擇自己適用的即可;

執行平臺****:一般是藉助工具來執行這些測試指令碼,工具可以使用上面提及到的幾種(jemter、loadrunner、soapui等),同樣,選擇合適的很重要;

持續整合工具:最常見的就是Jenkins,它的作用就是監控外部程式的呼叫執行,定時或者觸發排程任務,測試指令碼執行等功能;

通訊服務:dubbo、spring_boot、thrift等RPC、REST同步呼叫服務;

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

總而言之,介面自動化測試的意義就是:資料與指令碼分離,測試結果自動提交通知,提高測試指令碼和測試資料的維護便利等等。

相關文章