接口/UI自動化面試題

一、UI自動化

1.1、接口和UI自動化有多少用例？

回答策略：根據接口設定用例，100個接口，自動化case在1500-2000左右。結合自身的項目，回答覆蓋的主功能流程。
示例：
- 接口自動化的測試case一般需要根據接口數量來確定，我當時將主功能流程接口實現了自動化，大概將近有80個的接口，case數量將近1000個；主要涵蓋了賬戶體系管理、合約簿記、出入金管理、流水錄入、資金清算、生成報表等核心業務流。通過數據驅動（YAML文件）實現參數化。
- UI自動化一般根據業務功能進行設計，實現近200個用例自動化，涵蓋主回歸流程測試。主要需要考慮其底層的穩定以及后續維護成本，通常是30%的自動化覆蓋率。

1.2、什么是POM模式

概述：POM全稱叫page object model，頁面對象模型。意思是把一個頁面當成一個對象，頁面的元素就是對象的屬性，頁面的操作就是對象的行為（方法）。一般情況分三層：基礎封裝層BasePage、PO頁面對象層、TestCase測試用例層。

我這里是采用PO的設計模式，大致分成了基礎驅動層用于元素的定位和瀏覽器的操控；第二層是頁面對象層，將整個頁面的元素和功能進行封裝；第三個是業務邏輯層，是通過組合不同頁面中的功能實現用例中的業務流程；第四個數據管理層管理測試數據；用例執行層，用于用例的執行、斷言、日志和報告生成等。

優點：
- 使得用例更簡單、更清晰，把很多業務操作封裝到PO頁面對象層，用例只需要調用即可。
- 如果頁面有變動，只需要修改PO頁面對象層的屬性即，增加代碼的可維護性。

1.3、如何提高UI自動化的穩定性

盡量使用相對路徑定位元素
定位元素使用封裝顯示等待，增加條件
用例和用例之間盡量避免依賴
加入用例失敗重跑機制
自動化測試的環境區分其他環境

1.4、談談印象最深的bug

1.4.1、腳本定位問題

在編寫自動化腳本時，遇到過像瀏覽器更新后，自動化測試用例會出現誤報的問題。

解決方式：1. 針對這個問題，我首先是思考影響范圍，比如其它瀏覽器是否有類似的情況存在，并對比不同瀏覽器原因是否都一致；2. 當我將一些影響因素排除之后，自己就通過網上查閱官方的文檔，學習和借鑒其他人的一些更改方法；嘗試去調整代碼的定位策略，如元素屬性和層
級關系，盡可能用相對路徑進行定位；以及更改了等待方式，通過在顯示等待中加了一些判定條件；增加用例失敗重跑機制等多種方式去規避這類問題，最終
問題得到了解決，并且我在后續會定期的去更新測試代碼，保證穩定性。

1.4.2、對比工具性能問題

在開發報表對比工具時，遇到了數據量大導致處理慢和數據格式不一致的問題。

解決方式：1. 首先，通過使用Pandas庫中的chunksize分塊讀取數據，避免內存過載，同時利用Pandas的向量化操作和分組聚合功能，提高處理能力；并行計算:
利用Dask加速計算；數據庫優化：添加索引的方式，減少查詢時間。2.  另外，針對格式問題，讀取數據后 統一設置相關列的數據格式。通過這些方法，解決了上述的問題。

1.5、遇到的挑戰

發現整體版本流程自動化覆蓋率很低，開發提測質量差，嚴重影響版本交付進度。

解決方法：1. 首先，我通過優先整理主功能流程，將回歸用例實現自動化全覆蓋，在開發腳本的過程中，我也在思考后續的用例如何便于維護，因此我通過引入PO
設計模式，并結合產品業務，大致分成了元素定位層、頁面操作層、業務邏輯層、數據管理層和用例執行層；此外，針對開發提測質量差的問題，我通過
Jenkins集成了自動化打包與用例執行自動化，在開發代碼提測后，會自動進行打包，并執行主功能用例，如果執行不通過，則代碼打回，將報錯的截圖和日志發送給開發。2.  需要將相關的依賴包批量移動和替換到指定的位置。3.  正則表達式+遞歸搜索的方式，篩選指定的路徑以及文件名稱解決了這個問題。

二、接口自動化

2.1、接口關聯是如何處理的

通過一個yaml文件獨立保存所有接口提取的變量，并且這個變量在執行用例之前清空；(truncat())

在測試用例的yaml文件里通過一個關鍵字extract提取標量：json或者正則表達式提取

在下一個接口通過{{}}或${}的（熱加載）方式進行獲取。

熱加載：代碼執行過程中，動態調用Python中的方法達到或得到動態參數的目的。

2.2、requests中的Session會話管理的作用是什么

首先，因為很多接口都需要cookie和session來記錄登錄狀態，并且必須要有這個登錄狀態才可以請求成功；
Requests中的Session會話管理的作用就是自動記錄cookie和Session的登錄狀態，不需要再手動去記錄。

2.3、接口自動化測試中的斷言是如何實現的

首先，把斷言封裝成一個方法，這個方法會讀取yaml文件里的validate字段，包括斷言的方式和數據；
然后，在后臺實現了斷言，并體現在報告中，不需要再寫任何的Python代碼。

2.4、數據驅動和關鍵字驅動的理解

數據驅動概念：從數據文件（Excel、CSV、數據庫）讀取輸入、輸出數據，然后通過變量傳入自動化用例中，測試數據都是在數據文件中，通過修改數據達到自動化用例執行的方式叫做數據驅動；
關鍵字驅動：是從面向對像的思維出發，將同樣的業務邏輯封裝成一個函數，不同關鍵字實現不同的業務邏輯，這樣業務邏輯就可以通過調用關鍵字來實現業務功能。

2.5、接口測試過程中遇到過哪些bug

常規Bug：接口沒有實現、沒有按照接口文檔返回結果、接口報錯。

如：我在測試資金賬戶接口時，其中當前名義本金參數，我改成了負值也能創建成功。

2.6、怎么校驗結果是否正確

狀態碼校驗：驗證返回的狀態碼為200。
業務校驗：
- 錯誤碼為0。
- 當接口響應報文比較短，比較固定情況下，校驗完全一致。
- 響應報文比較長，校驗核心最核心的業務信息。
- 響應報文比較復雜，多層級XML或JSON格式，通過Xpath、正則表達式的匹配方式獲取關鍵字的業務節點進行校驗。
- 查詢數據庫校驗或者通過其它接口進行校驗。

2.7、碰見過哪些異常，用到了哪些Python庫

異常
- NoSuchElementException 沒有該元素
- NoSuchAttributeException 沒有該屬性
- NoSuchElementException 沒有如此框架
- ElementNotVisibleException 元素不可見異常
- ElementNotSelectException 元素不可選
python庫
- webdriver、os、time、json、request、pytest、pymysql

2.8、報表對比工具實現邏輯

數據接入：
1. 通過使用pandas解析報表（Excel/CSV）內容；
2. 通過pyodbc連接數據庫，并查詢相關的數據庫表字段；
校驗規則設計：
1. 靜態校驗：字段是否為空、數據類型（浮點、保留位數）；
2. 業務邏輯校驗：將報表的字段與數據庫查詢的字段根據業務邏輯進行比較校驗
結果通知：
1. 通過發送郵件的方式告知相關的執行結果。
遇到的問題：性能處理
1. 分塊處理：chunksize讀取報表數據，避免內存溢出
2. 并行計算：利用Dask加速計算
3. 數據庫優化：添加索引的方式，減少查詢時間

2.9、如何開展接口自動化測試（思維）

目的：為什么要做接口測試？
1. 提效。人工、持續集成、交付
首先，我需要自動化的可行性分析，自動化率可以實現到什么樣的程度。
其次就是需要選擇合適的測試工具，做一個小的demo進行演示。
第三就是制定詳細的測試計劃，包含測試環境、測試范圍、測試用例設計，相對應的時間節點等；
第四就是用例的設計，我需要從新建波形到最后生成可執行文件，詳細測試相關的文件是否符合標準規范。
第五根據業務對自動化框架進行分層便于后續的腳本更新和維護。
1. 我這里是采用PO的設計模式，大致分成了基礎驅動層用于元素的定位和瀏覽器的操控；
2. 第二層是頁面對象層，將整個頁面的元素和功能進行封裝；
3. 第三個是業務邏輯層，是通過組合不同頁面中的功能實現用例中的業務流程；
4. 第四個數據管理層管理測試數據；
5. 用例執行層，用于用例的執行、斷言、日志和報告生成等。
再考慮引入Jenkins的方式持續集成和定時運行。
將自動化流程化，出具相關的使用說明文檔和規范文檔。
后續持續不斷完善框架功能。
比如在軍工通信項目中，我對波形建模流程測試時，首先是確保頁面元素沒有問題，通過使用邊界值、因果圖法的測試方法測試輸入值是否有異常；其次再對實際的接口進行調用測試，確保后臺功能接口能夠正常傳參返參；之后再根據需求，設復雜的測試業務場景，通過mysql后臺查詢相關數據，確保實際結果與預期結果統一；
如果出現問題時，通過截圖的方式，將報錯頁面以及后臺報錯日志通過加上時間戳的方式保存在本地，當時我也通過jenkins將截圖和日志歸檔在構建完的產物中，便于后續的歷史回溯。

2.10、對于加密接口、簽名接口如何進行測試

加密接口：在調用接口時，需要清楚接口的方式是什么。如：
- 對稱式的加密方式（私鑰加密）：Base64。
- 非對稱的加密方式（雙鑰加密）：RSA加密方式。
- 只加密不解密：MD5、SHA1。
- 自定義加密規則：混合加密方式。
清楚加密規則后，在請求接口之前，先對參數做對應的加密之后再發送請求。單一加密方式，postman和Jmeter有些支持。Poatman使用JavaScript腳本實現，Jmeter使用beanshell中的java代碼實現。

2.11、依賴于第三方數據的接口如何進行測試

可以通過Postman搭建Mock服務，但是Postman的Mock服務由訪問次數限制，一天只能訪問1000次。