面試自動化測試架構時必須知道的事兒,看完你會發現拿offer太簡單了!
當面試的時候,面試官要問你對自動化測試架構的理解時,該如何回答呢?
其實這是一個很“大”的問題,面試者需要對如下內容進行闡述,主要包括:什麼是架構、什麼是架構設計思想、自動化架構設計帶來的好處、有哪些核心類庫以及他們的作用、結合你的實際工作談談遇到的架構使用問題。在這裡我概述一下對於這幾個問題的核心回答思路。
1.什麼是架構
軟體架構(software architecture)是一系列相關的抽象模式,用於指導大型軟體系統各個方面的設計。軟體架構是一個系統的草圖。軟體架構描述的物件是直接構成系統的抽象元件。各個元件之間的連線則明確和相對細緻地描述元件之間的通訊。在實現階段,這些抽象元件被細化為實際的元件,比如具體某個類或者物件。在面向物件領域中,元件之間的連線通常用介面來實現。
2.架構設計思想
用一套通用的自動化測試框架,解決不同產品線的基礎服務構建工作(包括:提供日誌模組,提供郵件模組,提供外部檔案讀寫處理模組以及日誌解析模組等等),通過引入框架方便公司對不同的產品線自動化實施進行整合,便於日後管理和維護。該設計方案使得不同產品的自動化業務編寫人員只需專注於用例業務的實現,無需理會API中內部技術細節的實現。而架構設計人員無需對業務線的具體業務知識進行系統學習,只專注於技術細節的實現,當業務編寫人員遇到技術問題時提供必要的技術支援。正所謂術業有專攻,通過對不同角色的職責劃分,從整體上提升自動化測試的工作效率。
具體包括:
編碼選擇(用java還是python)
提供編碼規範(類、方法、變數的統一命名規範)
提供用例設計規範
程式碼管理方案(svn還是git)
3.為什麼使用架構
核心:解決錄製指令碼的常見問題,使得自動化測試穩定
1.把架構編寫人員(精通程式碼設計),用例編寫人員(瞭解程式碼),以及用例執行人員(不懂程式碼)分開
2.把UI物件通過自定義變數的方式賦值,增強了指令碼的易讀性
3.通過封裝Webdriver的API,使其更加健壯
4.把常用的業務場景封裝成業務方法,便於常用業務的複用
5.把經常需要修改的內容(例如:登陸使用者名稱和密碼)儲存在外部檔案中,避免了指令碼執行人員對測試指令碼程式碼的修改
6.生成Debug級別的log,使自動化指令碼除錯人員方便除錯程式
7.生成迴歸級別的測試報告,便於不懂指令碼的人員檢視測試結果
8.引用Suite執行多個指令碼,進行執行指令碼的管理
4.具體類庫是如何設計的
配置檔案
把經常需要修改的資訊(例如:使用者名稱,密碼,環境)保留在配置檔案中,好處如下:
便於執行用例的測試人員修改;
避免對程式碼的修改而引起的錯誤
日誌
測試報告:向專案經理、產品經理和老闆彙報
除錯日誌:便於自動化指令碼編寫人員除錯程式碼
ObjectStore
儲存頁面中的元素,當UI變化時修改對應變數即可,將可讀性差的UI元素按照統一規則命名
CommonLib
1.提供與Webdriver無關,但與自動化測試相關的API
包括:從外部檔案讀取資訊,啟動多種瀏覽器,獲得當前系統時間,啟動和終止某個應用程式,獲得隨機數等等
2.包括的方法有,從外部檔案讀取資料,生成隨機函式,獲得當前日期等等
Corelib
1.封裝webdriver的api,使其更加健壯,形成自動化專案的api
2.提供斷言的相關方法
3.自動化api提供詳細的輸出訊息,便於除錯
4.自動化api提供向測試報告中寫入訊息的方法
BusinessLib
業務方法的封裝,根據Corelib中的提供的API,把常用的業務場景封裝成方法便於複用
DataStore
儲存輸入的資料資訊,作為架構與外部檔案的介面
5.使用架構時遇到的問題
前面的問題回答的再好,只能證明你在理論方面對架構的理解是OK的,那麼你究竟使用過架構嗎?必須結合實際專案來說!主要注意以下幾點
正常流程
1.你是如何利用架構裡面的api設計用例的,舉一個具體的場景(非常重要)
解決問題
2.當遇到UI元素變化時,你是如何更新ui變數的?核心點是更新objectstore
3.當遇到指令碼執行fail時,你是如何判斷是架構的api問題還是程式本身的bug的?核心點是手工復現問題,檢視架構日誌
4.當架構提供的api不能滿足你的專案需求時,你是如何擴充套件api的?核心點是直接重寫架構的api或者新增api;寫一個新類繼承架構中的Corelib,在這個 新類中完善api
5.當架構需要新增新功能時需要如何接入?核心點是寫若干個類完成所需功能,然後提供呼叫介面在架構中使用
原創不易,如果文章幫到了你,歡迎轉發點贊,讓更多的朋友受益!
需要軟體測試面試資料,點選連結加入群聊【Python自動化測試交流群】領取全套資料!