1、WEB自動化測試框架是如何搭建的？
我們web自動化測試使用的技術棧是： Python+Selenium+Pytest+Parametrices+Excel+Allure+Jenkins 框架使用的是基於Excel的關鍵字驅動，將維護框架和使用框架分離開來進行自動化測試時，將元素定位表達式及要執行在操作寫入excel即可，顯著降低了自動化測試的落地難度。
主要功能：
- 內置常用關鍵字，實現關鍵字驅動測試，有升級爲BDD潛力
- 自動的判斷瀏覽器類型版本，並自動下載、啓動合適的瀏覽器驅動
- 內置自動等待，避免正常情況下UI測試的出錯情況
- 通過執行js的方式，實現特殊場景交互，如強制點擊、強制輸入、拖拽上傳等
- 以字符串爲核心斷言策略，支持等於、包含、正則匹配、內容組合等多種斷言方式
- 自動生成allure的測試報告，報告內置與excel內容一一對於匹配
- 支持並行測試和分佈式測試文件架構： conf # 項目配置 data # 數據驅動測試文件 action.py # 關鍵字驅動封裝case.py # 用例管理和封裝data.py # 數據驅動封裝pages # PO 封裝 report # allure測試報告 tests # 存放 excel文件作爲測試用例框架用法：
- 1）創建execl文件，每個sheet頁看作一個TestSuite
- 2）在sheet頁中申明測試用例，填寫測試用例的名稱
- 3）在單元格中填寫步驟名、關鍵字、關鍵字參數，完成測試步驟
2、WEB自動化測試的價值在哪裏？爲什麼要做WEB自動化測試？
Web自動化測試就是模擬手工測試人員來做功能測試。用機器的自動執行代替人的操作。主要用於產品的核心功能冒煙測試、迴歸測試。從系統最核心的功能開始做，再根據情況慢慢展開。 引用自動化測試之後，能代替大量繁瑣的迴歸測試工作，把業務測試人員解放出來，既而讓業務測試人 員把精力集中在複雜的業務功能模塊上，自動化測試一般是對穩定下來的功能進行自動化，保證不會因爲產品的更新導致之前穩定下來的功能出現BUG。
3、公司如何把WEB自動化測試在項目中開展起來？
1）項目組做自動化的可行性分析，包括自動化率能夠實施到什麼程度？主要考慮：
1.項目時間是否比較長，一般需要一年以上的項目或者長期的產品
2.需求會不會頻繁變更
3.自動化腳本是否能夠持續反覆的使用。
2）項目組調研自動化工具的選擇和demo演示，主要演示selenium和robotframework兩種。如果有以往成熟的框架演示更好。
3） 逐漸在項目中實施自動化，發現問題並改善。主要包括：
1.編寫自動化測試計劃
2.提取或編寫自動化測試用例
3.由leader編寫自動化測試框架腳本
4.編寫，調試並維護自動化測試腳本（代碼規範以及根據分工編寫相應的自動化測試腳本，自測沒有問題之後提交到Git服務器）
5.Jenkins持續集成無人值守測試
6.後期維護腳本（主要是因爲版本更新添加用例）
4） 把自動化流程化，規範化，文檔化，自動化框架需要編寫使用文檔以及規範文檔。
5） 生成定製的報告。繼續完善框架。並推廣到其他的項目
4、web自動化有多少case？覆蓋率是多少？全部執行完需要多久？
1） WEB自動化用例個數根據功能測試用例數而定。自動化用例覆蓋率一般爲功能測試用例的30%左右
2） 所有WEB自動化用例執行完成大概30-60分鐘左右。
5、web自動化測試用例如何設計？
WEB自動化測試用例是從手工測試用例中提取出來的，主要是冒煙用例和迴歸測試的用例。自動化測試用例的選取更加需要注重用例的嚴謹性，選擇用例的時候遵循以下原則：
- 優先選取覆蓋產品核心業務流程的用例；
- 選取的用例是需要重複執行或繁瑣的驗證功能，比如字段驗證、提示信息驗證；
- 優先選擇正向的測試用例，反向用例一般情況複雜、數量多；
- 不要選擇流程太複雜的用例（主流程除外）；
6、如何保證(提升)自動化測試的穩定性？
自動化測試穩定性主要表現在兩個方面：一個是元素定位的穩定性，另一個是用例之間依賴穩定性： 元素定位穩定性問題：
(1) 儘量用相對路徑的xpath表達式；
(2) 定位元素使用智能等待+顯示等待的方式避免元素未加載完成問題；
(3) 腳本執行失敗後加入重試機制，提升用例的穩定性；
(4) 用例執行結束後對測試場景進行還原，避免影響其他用例的執行；
(5) 儘量保證單獨的測試環境，避免其他的測試同步進行；
用例之間依賴穩定性問題：
用例與用例之間儘量避免依賴，用例儘量可以獨立執行；讓每條用例都從一個共同的頁面開始執行，比如首頁，這就需要在測試框架中採用後置處理的方式使每條用例執行完成後都回到首頁。
7、自動化測試發現BUG多嗎？
不多，因爲WEB自動化的用例就是之前項目組已經測試過的基本功能，然後再進行自動化腳本的編寫和 執行，它主要是保證已經測試通過的功能在新版本更新後不會因爲新增的功能而導致原來的基本功能產 生錯誤。
8、什麼是PO模式？爲什麼要使用它？ PO模式，全稱爲Page Object Model ，簡稱PO，是頁面對象模式。意思是把一個頁面當做一個對象， 頁面的元素就是對象的屬性，頁面的操作就是對象的行爲（方法），PO模式一般使用三層架構，分別爲：基礎封裝層BasePage，PO頁面對象層，TestCase測試用例層。 使用PO模式可以使我們的測試用例更簡單，更清晰，很多時候我們可以在頁面對象中封裝很多業務操作方法，測試腳本只需要調用相關方法就可以。另一個就是如果有頁面元素髮生改變，我們只需要去修改這個頁面對象的元素定位和相關方法就可以 了，不需要修改其它腳本。增加代碼的可維護性。
9、對數據驅動和關鍵字驅動的理解？
數據驅動是從某個數據文件(例如Excel文件、Csv文件、YAML文件等)中讀取輸入、輸出的測試數據，然後通過數據驅動方法（ddt，parameterize等）傳入自動化測試腳本中。在整個過程中，自動化測試腳本實現數據的讀取、測試狀態的改變、結果的判斷等，從而實現數據和代碼分離，這種方式叫數據驅動。
關鍵字驅動是從面向對象的思路出發，同樣的業務邏輯會編寫成一個函數作爲關鍵字來被不同的測試腳 本所調用。當所有的業務邏輯測試都可以被寫好的函數所組合完成時，就是關鍵字驅動框架。這個時候 測試用例的開發就變成了測試數據和關鍵字的組合，並把這種組合工作簡化爲所有人都很熟悉的表格填寫任務，從而最終達到一個由數據和關鍵字驅動整個測試的效果。
10、在自動化測試過程中主要用到了哪些Python 庫？碰到過哪些異常？
web自動化測試： webdriver，WebDriverWait，By，os,xlrd，xlwt，unittest/pytest，time，logging， HTMLTestRunner等。
接口自動化測試： requests，time，logging，json，csv，jsonpath，pyyaml，re，unittest/pytest，allure 常見的異常有以下： NoSuchElementException： 沒有如此元素異常
NoSuchAttributeException ： 沒有如此屬性異常
NoSuchFrameException ： 沒有如此frame異常
ElementNotSelectableException ：元素不能選擇異常
ElementNotVisibleException ：元素不可見異常
Element not visible at this point ：在當前點元素不可見
TimeoutException ： 超時異常；
11、接口測試的過程中發現過哪些bug?多嗎？（或者說：接口測試有沒有測試出什麼問題？）
接口測試中發現的bug，大多都是接口沒按約定返回結果，參數爲空，參數長度或類型校驗、參數邊界 值、代碼邏輯、數據錯誤、或沒有返回合理的錯誤提示等方面的問題。
(1) 一般在前後端聯調階段執行接口測試發現的 bug 會很多（之前開發寫代碼的時候，所有的ajax 數據都不是後端返回的真實數據，而是我們自己通過接口mock模擬的假數據，當前端的代碼編寫完畢， 後端的接口也已經寫好之後，我們就需要把mock數據去掉，嘗試使用後端提供的數據，進行前後端聯 調，這個過程我們就把它稱之爲前後端的接口聯調。） 前後端聯調接口Bug案例： 比如1：查詢列表頁接口，前端想分頁，Mock就寫了三條測試數據，調用後端接口時分頁有問題？ 比如2：前端訪問的mock數據時沒有考慮鑑權。訪問真實的後端接口時沒有權限。
(2) 然後在接口冒煙測試、迴歸測試階段執行接口測試的時候，bug就不多。 常規接口Bug案例： 比如1：新增促銷活動接口，滿減金額爲空也能保存成功，原因是後端代碼沒有對滿減金額參數做空值判 斷。 比如2：活動列表接口，查詢出來的活動數據少了第一條，原因是SQL中limit條件傳入起始序號是1而不 是0 比如3：更新活動接口，接口提示更新成功，但是數據庫中的update_time字段沒有更新成最新時間，原 因是開發忘記更新這個字段 比如4：比如說下訂單接口，商品的價格參數是300元，那我在提交訂單時候，我把這個商品的價格改成 3元，後端並沒有做驗證，更狠點，我把錢改成-3，我的餘額還增加了？ 接口鑑權Bug案例： 比如1：比如說修改商品信息接口，只有賣家權限才能修改，我傳一個普通用戶也可以修改成功，我傳一 個其他賣家用戶也能修改成功。 比如2：之前有個退保接口，下游系統加了身份證證件有效期校驗，導致被測系統接口調用跑不通，通過 自動化發現的問題，並及時去評估到對被測系統的影響。