導讀Selenium自動化測試面試題目錄1、什么是自動化測試、自動化測試的優勢是什么？2、什么樣的項目比較適合做自動化測試，什么樣的不適合做自動化測試？3、說一....Selenium自動化測試面試題

目錄

• 1、什么是自動化測試、自動化測試的優勢是什么？
• 2、什么樣的項目比較適合做自動化測試，什么樣的不適合做自動化測試？
• 3、說一下開展自動化工作的主要流程是怎樣的？
• 4、在制定自動化測試計劃的時候一般要考慮哪些點？
• 5、編寫自動化腳本時的一些規范？
• 6、你一般一天能編寫多少個自動化腳本？
• 7、做自動化測試時關注的一些指標？
• 8、自動化測試可以達到100%的覆蓋率嗎？
• 9、你們公司開展自動化測試遇到一些什么問題？
• 10、Selenium驅動瀏覽器使用的協議是什么？
• 11、Selenium工具都包含哪些組件？
• 12、Selenium中定位網頁元素的八種方式？
• 13、webdriver啟動常見的瀏覽器語句？
• 14、如何選中下拉列表中的下拉選項？
• 15、如何取消選中下拉列表中的下拉選項？
• 16、Selenium如何處理彈窗？
• 17、Selenium可以處理Windows彈窗嗎？
• 18、如何判斷一個元素在頁面上是顯示出來的？
• 19、Selenium中如何判斷元素是否存在？
• 20、driver.quit()和driver.close()的區別？
• 21、自動化測試用例從哪里來？
• 22、常見的自動化測試框架有哪些？
• 23、什么是POM？
• 24、Selenium中如何保證操作元素的成功率？也就是說如何保證我點擊的元素一定是可以點擊的？
• 25、如何提高Selenium腳本的執行速度？
• 26、你的自動化用例的執行策略是什么？
• 27、什么是持續集成？

1、什么是自動化測試、自動化測試的優勢是什么？

通過工具或腳本代替手工測試執行過程的測試都叫自動化測試。

自動化測試的優勢：

1、減少回歸測試的成本

2、減少兼容性測試成本

3、提高測試反饋速度

4、提高測試覆蓋率

5、讓測試工程師做更有意義的測試

2、什么樣的項目比較適合做自動化測試，什么樣的不適合做自動化測試？

1、適合做的項目：

a.項目周期長且相對穩定

b.需要做頻繁的冒煙測試

c.需要經常做回歸測試

d.需要進行大數據量的數據驅動測試

2、不適合做的項目：

a.項目周期短用例不會多次重復執行

b.被測項目不穩定變化太頻繁

3、說一下開展自動化工作的主要流程是怎樣的？

1、選擇合適的測試工具

2、定義自動化測試覆蓋的范圍

3、制定測試計劃

4、自動化測試環境搭建

5、腳本開發

6、測試執行

7、測試腳本維護

4、在制定自動化測試計劃的時候一般要考慮哪些點？

1、選擇適合的測試工具或分析當前的工具是否適合新項目

2、選擇合適的自動化測試框架

3、確定要做自動化測試的范圍和不做自動化測試的范圍

4、測試環境的準備與搭建

5、制定一個粗略的腳本開發的時間表

6、制定腳本執行的一些策略，如冒煙測試的頻率，回歸測試的時間點及頻率等

7、定義自動化測試的輸出，比如腳本，測試數據，發現的缺陷，測試報告等

5、編寫自動化腳本時的一些規范？

1、統一的命名約定，如用例名，方法名等

2、良好的腳本注釋

3、遵循代碼規范，使用適當的縮進

4、對異常進行處理

6、你一般一天能編寫多少個自動化腳本？

這個取決于測試用例場景的復雜度，一般一天能寫2~5個左右，復雜的話一天只能寫一個

7、做自動化測試時關注的一些指標？

1、自動化測試用例的覆蓋率=自動化測試用例數/所用用例總數，這個比例越高測試反饋越快，成本節約越多

2、節省的時間成本=手工測試所花的時間-自動化測試所花的時間

3、自動化測試的投入=開發腳本的投入 腳本維護的投入 工具價格

4、自動化測試發現的缺陷數，每次回歸測試時自動化測試發現的缺陷數及漏測數，反應了自動化用例的有效性

5、自動化測試投入產出比

ROI=（手工測試的成本-自動化測試成本）/自動化測試成本

ROI如果是負值說明自動化測試的成本未收回，ROI為正值說明自動化測試成本已回收，且值越大說明回報越好

8、自動化測試可以達到100%的覆蓋率嗎？

比較難，因為有些用例場景無法被自動化，一些驗證易用性友好性的用例不適合做自動化，有些邊緣的用例很少被重復執行，從投入產出比來說也不適合做自動化

9、你們公司開展自動化測試遇到一些什么問題？

1、項目流程不規范，項目變動頻繁導致自動化用例維護成本高，解決：深入理解用戶需求，規范開發流程，自動化用例先覆蓋已經穩定的功能

2、對自動化期望太高，自動化也是一個逐步完善的過程，不可能一下子完全代替手工

3、有些自動化工程師的技術能力偏弱，提升編程能力，提升自動化工具使用能力，對新人進行培訓等

10、Selenium驅動瀏覽器使用的協議是什么？

JsonWireProtocol 是通過使用 webdriver 與 remote server 進行通信的 web service 協議。通過 http 請求，完成和 remote server 的交互。

11、Selenium工具都包含哪些組件？

Selenium WebDriver

Selenium IDE

Selenium Grid

12、Selenium中定位網頁元素的八種方式？

13、webdriver啟動常見的瀏覽器語句？

#!/usr/bin/env python# -*- coding:utf-8 -*-# 公眾號：AllTests軟件測試from selenium import webdriverdriver = webdriver.Chrome()driver = webdriver.Firefox()driver = webdriver.Ie()

14、如何選中下拉列表中的下拉選項？

#!/usr/bin/env python# -*- coding:utf-8 -*-# 公眾號：AllTests軟件測試# 通過選項的順序，第一個為0select_by_index(index)# 通過value屬性select_by_value(value)# 通過選項可見文本select_by_visible_text(text)

15、如何取消選中下拉列表中的下拉選項？

#!/usr/bin/env python# -*- coding:utf-8 -*-# 公眾號：AllTests軟件測試deselect_by_index(index)deselect_by_value(value)deselect_by_visible_text(text)deselect_all()

16、Selenium如何處理彈窗？

#!/usr/bin/env python# -*- coding:utf-8 -*-# 公眾號：AllTests軟件測試# 確認driver.switch_to.alert.accept()# 取消driver.switch_to.alert.dismiss()# 在彈出框輸入內容driver.switch_to.alert.send_keys("輸入數據")

17、Selenium可以處理Windows彈窗嗎？

Selenium本身是不可以處理Windows彈窗的，但是Selenium可以借助Autolt小工具來完成對Windows彈窗的操作。

18、如何判斷一個元素在頁面上是顯示出來的？

webelement類中的is_displayed()方法

本身這個函數用于判斷某個元素是否存在頁面上（這里的存在不是肉眼看到的存在，而是html代碼的存在。某些情況元素的visibility為hidden或者display屬性為none，我們在頁面看不到但是實際是存在頁面的一些元素。）

19、Selenium中如何判斷元素是否存在？

#!/usr/bin/env python# -*- coding:utf-8 -*-# 公眾號：AllTests軟件測試from selenium.common.exceptions import NoSuchElementException# 判斷元素是否存在def isElementPresent(self, by, value):try:element =self.driver.find_element(by=by, value=value)except NoSuchElementException as e:# 發生了NoSuchElementException異常，說明頁面中未找到該元素，返回Falsereturn Falseelse:# 沒有發生異常，表示在頁面中找到了該元素，返回Truereturn True

20、driver.quit()和driver.close()的區別？

driver.close()僅關閉當前用戶正在操作的頁面

driver.quit()關閉整個瀏覽器，關閉所有的頁面

21、自動化測試用例從哪里來？

1、手工用例中抽取

2、參考自動化用例的執行策略

22、常見的自動化測試框架有哪些？

線性腳本框架、基于模塊化的框架、庫結構框架、數據驅動框架、關鍵字驅動框架、混合框架等

23、什么是POM？

POM，中文字母意思是，頁面對象模型，POM是一種最近幾年非常流行的自動化測試模型，或者思想，POM不是一個框架，是一個解決問題的思想。采用POM的目的是為了解決前端中UI變化頻繁，從而造成測試自動化腳本維護的成本越來越大。

POM主要有以下優點：

1、把web ui對象倉庫從測試腳本分離，業務代碼和測試腳本分離。

2、每一個頁面對應一個頁面類，頁面的元素寫到這個頁面類中。

3、頁面類主要包括該頁面的元素定位，和這些元素相關的業務操作代碼封裝的方法。

4、代碼復用，從而減少測試腳本代碼量。

5、層次清晰，同時支持多個編寫自動化腳本開發，例如每個人寫哪幾個頁面，不影響他人。

6、建議頁面類和業務邏輯方法都給一個有意義的名稱，方便他人快速編寫腳本和維護腳本。

24、Selenium中如何保證操作元素的成功率？也就是說如何保證我點擊的元素一定是可以點擊的？

1、添加元素智能等待時間driver.implicitly_wait(30)

2、try 方式進行 id,name,class,xPath,css selector 不同方式進行定位，如果第一種失敗可以自動嘗試第二種

3、Selenium 保證元素成功率是通過元素的定位，當然它的定位方法很多，一定能有合適的。但是在自動化工程的實施過程中，高質量的自動化測試不是只有測試人員保證的，需要開發人員規范開發習慣，如給頁面元素加上唯一的 name,id 等，這樣就能大大地提高元素定位的準確性。當然如果開發人員開發不規范，我們在定位元素的時候盡量使用相對地址定位，這樣能減少元素定位受頁面變化的影響。只要我們元素定位準確，就能保證每一個操作符合預期結果。

25、如何提高Selenium腳本的執行速度？

Selenium腳本的執行速度受多方面因素的影響，如網速，操作步驟的繁瑣程度，頁面加載的速度，以及我們在腳本中設置的等待時間，運行腳本的線程數等。所以不能單方面追求運行速度的，要確保穩定性，能穩定地實現回歸測試才是關鍵。

我們可以從以下幾個方面來提高速度：

1、減少操作步驟，如經過三四步才能打開我們要測試的頁面的話，我們就可以直接通過網址來打開，減少不必要的操作。

2、中斷頁面加載，如果頁面加載的內容過多，我們可以查看一下加載慢的原因，如果加載的內容不影響我們測試，就設置超時時間，中斷頁面加載。

3、在設置等待時間的時候，可以sleep固定的時間，也可以檢測某個元素出現后中斷等待也可以提高速度。

4、配置實現多線程，在編寫測試用例的時候，一定要實現松耦合，然后在服務器允許的情況下，盡量設置多線程運行，提高執行速度。

26、你的自動化用例的執行策略是什么？

自動化測試用例的執行策略是要看自動化測試的目的，通常有如下幾種策略：

1、自動化測試用例是用來監控的，在此目的下，我們就把自動化測試用例設置成定時執行的，比如每五分鐘或是一個小時執行一次，在 Jenkins 上創建一個定時任務即可。

2、必須回歸的用例，有些測試用例在產品變動上線之前都需要回歸執行，那我們就把測試用例設置成觸發式執行，在 Jenkins 上將我們的自動化測試任務綁定到開發的build任務上，當開發人員在測試環境上部署代碼的時候，我們的自動化測試用例就會被觸發執行。

3、不需要經常執行的測試用例，像全量測試用例，我們沒有必要一直回歸執行，必竟還是有時間消耗的，有些非主要業務線也不需要時時回歸，這類測試用例我們就采用人工執行，在 Jenkins 上創建一個任務，需要執行的時候人工去構建即可。

27、什么是持續集成？

持續集成源于極限編程(XP)，是一種軟件實踐，軟件開發過程中集成步驟是一個漫長并且無法預測的過程。集成過程中可能會爆發大量的問題，因此集成過程需要盡可能小而多，實際上持續集成講的是不斷的去做軟件的集成工作。持續集成，最簡單的形式是包括一個監控版本控制（SVN、Git等）變化的工具，當變化被發覺時，這個工具可以自動的編譯并測試你的應用。

接口自動化面試題

1.請問你是如何做接口測試的？

大體來說，經歷以下過程：接口需求調研、接口測試工具選擇、接口測試用例編寫、接口測試執行、接口測試回歸、接口測試自動化持續集成。

具體來說，接口測試流程分成以下九步：

第一步：分析出測試需求，并請開發提供接口說明文檔；

第二步：從接口說明文檔中整理出接口測試用例，里面要包括詳細的入參（正常情況，異常情況包括輸入參數個數，類型，可選/必選，考慮參數有互斥或關聯的情況）和出參數據（符合接口文檔需求）以及明確的格式和檢查點；

第三步：與開發一起對接口測試用例進行評審；

第四步：結合開發庫，準備接口測試用例中的入參數據和出參數據，并整理成Excel格式的文件；

第五步：結合接口測試用例文檔和Excel格式的數據文檔，編寫接口自動化測試的業務邏輯代碼；

第六步：開始執行接口自動化測試用例；第七步：執行如有bug，提交至缺陷管理平臺；第八步：開發修改完成后，回歸bug，跟蹤狀態；第九步：完成后進行自動化持續集成；

2.接口測試如何設計測試用例？

主要從四個方面來設計接口用例：功能，業務邏輯，異常，安全。

功能：是否符合需求

1）從用戶角度出發看接口能否實現業務需求，功能是否正常；

2）功能是否按照接口文檔實現；

舉例：比如博客園添加隨筆，需要登錄才能添加。也就是業務要求不支持游客添加隨筆功能，如果設計一個沒有登錄的用戶，然后去測試添加隨筆接口，結果接口能添加到隨筆，說明功能不正常，不符合需求和接口文檔描述。

業務邏輯：是否依賴業務

1）接口實現邏輯；

2）業務邏輯覆蓋（語句/條件/分支/判定/…）；

舉例：該接口調用之前，需要調用登錄接口，如果不登錄也能請求數據，不符合業務邏輯。

異常：參數異常和數據異常

1）參數異常：關鍵字參數，參數為空，多，少參數，錯誤參數；

2）數據異常：關鍵字數據，數據為空，長度不一致，錯誤數據；

舉例：不管數據異常還是參數異常，測試點差不多，一個參數有key和value，key表示參數，value表示數據。

第一，看看參數和數據能不能支持關鍵字，例如Java中的保留關鍵字等等；

第二就是參數和數據都為空，看看是否做了判斷；第三，參數多和少，例如有兩個參數的接口，需要設計一個包含三個參數的用例，一個只有一個參數的用例。

數據長度不一致，例如設計很長的字符串是否支持，因為數據庫創建表過程都設置好了每個字段的長度。輸入錯誤的參數和數據，如故意輸錯單詞等等。

安全測試用例設計：

1.cookie：有cookie才能獲取數據，如果不帶cookie還有信息返回，說明有問題；

2.header：正常接口帶header信息，刪除header看是否能夠返回數據；3.唯一識別碼：app手機識別碼，一般是唯一的；

4.文本輸入框sql注入和xss攻擊。

3.接口測試執行中需要比對數據庫嗎？

接口的返回關鍵字段和字段值是需要校驗的，不然接口測試就沒有意義了，一般有兩種方式：

1.數據庫預置數據，接口校驗返回；

2.接口調用，比對數據庫查詢結果。

4.接口測試質量評估標準是什么？

一般來說，從以下八個方面評估：

1.業務功能覆蓋是否完整；2.業務規則覆蓋是否完整；3.參數驗證是否達到要求（邊界、業務規則）；4.接口異常場景覆蓋是否完整；5.接口覆蓋率是否達到要求；6.代碼覆蓋率是否達到要求；7.性能指標是否滿足要求；8.安全指標是否滿足要求；

5.接口產生的垃圾數據如何清理

造數據和數據清理，需用Python連數據庫了，做增刪改查的操作測試用例前置操作。

1.setUp做數據準備后置操作；

2.tearDown做數據清理；

6.其他接口要先獲取接口信息，如何讓登錄的接口只在其他接口調用一次？

解決方法如下：

1.使用單例模式；

2.使用自定義緩存機制；

3.使用測試框架中的 setup 機制；

4.pytest 中 fixture 機制；

7.接口測試斷言從哪些方面去設計?

接口測試斷言可以從以下五個方面進行設計：

1.響應碼：檢查響應碼是否符合預期，用來判斷測試用例是否執行成功（針對http接口）

2.關鍵字：驗證關鍵字是否符合預期，用來判斷測試用例是否執行成功；

3.正則匹配：當一個接口返回的內容較多，并且有一定規律時，可通過正則表達式來校驗接口返回的信息來判定測試用例是否執行成功；

4.數據庫匹配核對：比如對查詢一個接口返回的數據進行驗證時，可通過編寫sql語句查詢結果，然后將sql語句執行后數據庫返回的結果與接口返回的結果進行核對，以此來判定測試用例是否執行成功；

5.通過相關接口進行輔助驗證：比如，當測試一個刪除接口時，刪除一條記錄后，想驗證這條記錄真的被刪除，可調用查詢接口，若刪除的記錄沒被查詢到，則說明刪除這條記錄成功。

8.依賴于第三方數據的接口如何進行測試？

可以利用一些Mock工具（如：JSON Server、Easy Mock）來模擬第三方的數據返回，最大限度的降低對第三方數據接口的依賴。

Mock服務是指在測試過程中對于某些復雜（或者不太好構造）的對象，用一個虛擬的對象替代它。

如現在有A和B兩個接口， A需要調用接口B才能完成業務需求。這個時候B接口有如下三種情況：

1.B接口還沒有開發完成：需要等待接口的數據來進行開發，這時候完善的接口Mock服務能大大縮短開發聯調等待時間。

2.B的某些場景很難去模擬：比如超時、未知錯誤或者不穩定的第三方接口。

3.性能測試中隔離B接口(第三方接口)：在進行壓測的時候就會遇到問題。

9.API測試有哪些優勢？

API是(Application Programming Interface)，即應用程序編程接口。API是一組用于構建軟件應用程序的規程，協議和工具。

API充當軟件應用程序之間的接口，并允許兩個軟件應用程序相互通信。API是一組軟件功能，可以由其他軟件執行。API測試具備如下優勢：

1.更快及更高的測試覆蓋率。

2.API測試有助于我們降低測試成本。通過API測試，我們可以在GUI測試之前找到小錯誤。在GUI測試期間，這些小錯誤將變得更大。因此，在API測試中發現這些錯誤將對公司具有成本效益。

3.API測試與語言無關。

4.API測試在測試核心功能方面非常有用。我們可以在沒有用戶界面的情況下測試API。在GUI測試中，我們需要等到應用程序可用于測試核心功能。

5.API測試有助于我們降低風險。

10.接口調不通，如何去排查？

接口調不通的原因：

問題1.接口沒有任何響應

很多時候在做接口測試時，會發現接口沒有任何返回，比如瀏覽器一直在轉圈，或者返回一個空白頁面。用接口測試工具時，工具報錯，提示“no response”。

排查思路：

1.先檢查接口ip是否正確，可以通過在本機ping 接口的ip，檢查網絡是否通暢；

2. 檢查接口的端口號是否正確，可以通過在本機telnet接口的ip和端口號，檢查端口是否能連通；

3.檢查項目是否啟動或者部署成功，可以找研發確認，或者自己登錄到服務器上，通過ps命令檢查項目的進程是否存在，然后用tail命令查看部署日志；

4.檢查服務器防火墻是否關閉，如果因為安全或者權限問題不能關閉，需要找運維進行策略配置，開放對應的ip和端口號；

5.檢查你的客戶端（瀏覽器/測試工具），是否設置了網絡代理，網絡代理可能會造成請求失?。?/p>

6.檢查操作系統的host文件，是否綁定了一個錯誤的ip映射；

問題2：接口有響應但是返回了錯誤的狀態碼

有些時候接口會返回一些錯誤的HTTP狀態碼，需要根據不同的狀態碼來確定具體的原因。

排查思路：

400：客戶端請求錯誤，比如請求參數格式錯誤（如json字符串不合法）；

401：未授權，比如在請求header里，缺乏必要的信息頭（如token、auth等字段）；

403：禁止，常見的原因是用戶的賬號沒有對應的url權限，還有就是項目所用的中間件，不允許遠程訪問（比如Apache）；

404：資源未找到，導致這種情況的原因很多，比如：

1.url拼寫錯誤；

2.url后有空格；

3.項目沒有啟動成功；

4.請求協議不對，如http/https；

405：方法不允許，常見的原因是請求方式不正確，比如GET類型接口，使用POST方式去請求；

415：不支持的媒體類型，常見原因是請求數據的類型和服務端支持的類型不匹配，比如json接口，需要添加一個信息頭Content-type:application/json；

500：服務器內部錯誤，出現這種情況，說明服務端內部報錯了，需要登錄到服務器上，檢查錯誤日志，根據具體的提示信息再進行排查；

502/503/504（Bad Gateway/錯誤的網關、Service Unavailable/服務無法獲得、Gateway Timeout/網關超時）。從以下兩種情況分析：

1.如果單次調用接口就報該錯誤，說明是后端服務器配置有問題，或者服務不可用，掛掉了；

2.如果并發壓測時出現此錯誤，說明是后端壓力太大，出現異常，此問題一般是后端出現響應時間過長或者無響應造成。

希望本文對你有所幫助~~如果對軟件測試、接口測試、自動化測試、性能測試、面試經驗交流感興趣可以私聊我或關注公眾號“特斯汀軟件測試”。免費領取最新軟件測試大廠面試資料和Python自動化、接口、框架搭建學習資料！技術大牛解惑答疑，同行一起交流。