自動化常識題

一.如何把自動化測試在公司中實施並推廣起來的？

1.專案組調研選擇自動化工具並開會演示demo案例，我們主要是演示selenium和robot framework兩種。

2.搭建自動化測試框架，在專案中逐步開展自動化。

3.把該專案的自動化流程、框架固化成文件。

4.推廣到公司的其它專案組應用。

二.自動化測試用例如何編寫？

不管是手工還是自動化.測試用例就是一組按部就班的指令，以驗證某些功能是否符合的需求。我們可以從以下幾個角度來思考：

1.測試環境

2.測試資料

3.測試業務

4.檢查點/測試手段

5.測試環境的清理

其中,測試業務是我們最關心的一點.可以採取轉化手工case 和 跟進需求的方式來進行編寫.一般在初級階段以基本業務流程為主（登入--完成一個業務--退出）,逐漸增加case場景。

三.自動化測試發現BUG多嗎？

不多

那麼自動化測試的價值是什麼?怎麼證明它不是偽需求?

1.比起發現bug,自動化測試更擅長保持舊有的功能沒有bug出現

2.引用自動化測試之後，能代替大量繁瑣的迴歸測試工作，把業務測試人員解放出來，既而讓業務測試人員把精力集中在複雜的業務功能模組上

3.一般來說相對穩定的功能更適合自動化

4.功能自動化儘可能用介面\驗收自動化則使用端到端

5.自動化技術是測試人員深化技能的必經之路

四.在上一家公司做自動化測試用的什麼框架?

可以說出以下自己擅長的一種：

1.pytest+requests+allure

2.python+selenium+pytest+allure

3.robotframework+Selenium2Library

五.什麼是持續整合？它有什麼用?

CI持續整合主要是在開發範圍，包括：構建>單元測試；主要針對在整合新程式碼時所引發的問題。

主要關聯git技術\程式碼管理現代應用開發的目標是讓多位開發人員同時處理同一應用的不同功能。

但是，如果企業安排在一天內將所有分支原始碼合併在一起（稱為“合併日”），最終可能造成工作繁瑣、耗時，而且需要手動完成。

這是因為當一位獨立工作的開發人員對應用進行更改時，有可能會與其他開發人員同時進行的更改發生衝突。

如果每個開發人員都自定義自己的本地整合開發環境（IDE），而不是讓團隊就一個基於雲的 IDE 達成一致，那麼就會讓問題更加雪上加霜。

持續整合（CI）可以幫助開發人員更加頻繁地（有時甚至每天）將程式碼更改合併到共享分支或“主 幹”中。

一旦開發人員對應用所做的更改被合併，系統就會通過自動構建應用並執行不同級別的自動化測試（通常是單元測試和整合測試）來驗證這些更改，確保這些更改沒有對應用造成破壞。

這意味著測試內容涵蓋了從類和函式到構成整個應用的不同模組。如果自動化測試發現新程式碼和現有程式碼之間存在衝突，CI 可以更加輕鬆地快速修復這些錯誤。

CD持續交付涉及開發、測試、運維合作,包括：構建>測試環境部署>測試（不涉及生產環境的自動化部署）。

完成 CI 中構建及單元測試和整合測試的自動化流程後，持續交付可自動將已驗證的程式碼釋出到儲存庫。

為了實現高效的持續交付流程，務必要確保 CI 已內置於開發管道。持續交付的目標是擁有一個可隨時部署到生產環境的程式碼庫。

在持續交付中，每個階段（從程式碼更改的合併，到生產就緒型構建版本的交付）都涉及測試自動化和程式碼釋出自動化。

在流程結束時，運維團隊可以快速、輕鬆地將應用部署到生產環境中。

這個階段應該關聯介面\ui的自動化測試

================================================

UI自動化

一.自動化中有哪三類等待？他們有什麼特點？

1.執行緒等待（強制等待）如time.sleep(2)：執行緒強制休眠2秒鐘，2秒過後，再執行後續的程式碼。建議少用。

2.imlicitlyWait（隱式等待）會在指定的時間範圍內不斷的查詢元素，直到找到元素或超時，特點是必須等待整個頁面載入完成。

3.WebDriverWait（顯式等待）通常是我們自定義的一個函式程式碼，這段程式碼用來等待某個元素載入完成，再繼續執行後續的程式碼

二.selenium*中的定位方式

id：根據id來獲取元素，返回單個元素，id值一般是唯一的；

name：根據元素的name屬性定位；

tagName：根據元素的標籤名定位；

className：根據元素的樣式class值定位；

linkText：根據超連結的文字值定位；

partialLinkText：根據超連結的部分文字值定位；

cssSelector：css選擇器定位；

xpath：通過元素的路徑來定位；

優先順序最高：ID

優先順序其次：name

優先順序再次：CSS selector

優先順序再次：Xpath

三.xpath和css定位都比較強大,那他們之間有什麼區別?

①、CSS locator比XPath locator速度快,因為css是配合html來工作，它實現的原理是匹配物件的原理，

而xpath是配合xml工作的，它實現的原理是遍歷的原理，所以兩者在設計上，css效能更優秀；

②、對於class屬性Css能直接匹配部分，而Xpath對於class跟普通屬性一致；

③、xpath可匹配祖先元素,css不可以；

④、查詢兄弟元素， Css只能查詢元素後面(弟弟妹妹)的元素，不能向前找(哥哥姐姐)；

四.你寫的測試指令碼能在不同瀏覽器上執行嗎？

當然可以，我寫的用例可以在在IE，火狐和谷歌這三種瀏覽器上執行。實現的思路是封裝一個方法，分

別傳入一個瀏覽器的字串，如果傳入IE就使用IE，如果傳入FireFox就使用FireFox，如果傳入Chrome

就使用Chrome瀏覽器，並且使用什麼瀏覽器可以在總的ini配置檔案中進行配置。需要注意的是每個瀏

覽器使用的驅動不一樣。

5.在你做自動化過程中，遇到了什麼問題嗎？舉例下

這個問題，不管是自動化還是任何工作，都會被問到。主要想知道你是如何解決問題的，從而推斷你問

題分析和解決的能力。 當然有遇到問題和挑戰，主要有以下幾點： 頻繁地變更UI，經常要修改頁面物件

裡面程式碼 執行用例報錯和處理，例如元素不可見，元素找不到這樣異常 測試指令碼複用，儘可能多程式碼復

用 一些新框架產生的頁面元素定位問題，例如ck編輯器，動態表格等

6.什麼是PO模式，為什麼要使用它

PO是Page Object 模式的簡稱，它是一種設計思想，意思是，把一個頁面，當做一個物件，頁面的元素和元素之間操作方法就是頁面物件的屬性和行為；

PO模式一般使用三層架構，分別為：基礎封裝層，BasePage，PO頁面物件層，TestCase測試用例層。

對於簡單的Selenium自動化測試，我們要做的不過是找到頁面元素，並且值傳遞給這些元素。

但是假如有10個指令碼同時呼叫了一個相同的頁面元素，當這個元素髮生改變，我們需要修改10個指令碼。

隨著指令碼數的增加，時間工作複雜度也飛速增長。這個時候我們就可以考慮設計一個類，專門用來頁面元素的查詢、傳遞值和修正。

這樣，當一個頁面元素髮生改變的時候，只用修改一個類，而不用同時修改10個指令碼。

Page Object是一種程式設計模式，將面向過程轉變為面向物件(頁面物件)，將測試物件（按鈕、輸入框、標題等）及單個的測試步驟封裝在每個Page物件中，以page為單位進行理。

這樣，在Selenium測試頁面中可以通過呼叫頁面類來獲取頁面元素，從而巧妙的避免了當頁面元素id或者位置變化時，需要改測試頁面程式碼的情況。

當頁面元素id變化時，只需要更改測試頁Class中頁面的屬性即可。可以使程式碼複用，降低維護成本，提高程式可讀性和編寫效率。

POM解決的問題：

以頁面為單位，集中管理元素物件和方法。當頁面元素或流程變動時只需要修改相關頁面方法即可，不需要修改相應指令碼

編寫指令碼簡單，順著業務邏輯寫指令碼。page object模式以業務邏輯上的每一步操作作為區分點，

頁面方法代表了此頁面的一個業務操作並嚴格控制此操作的後續流程後期維護方便.

在編寫PO前，建議先掌握以下幾個知識點：

selenium庫的基礎運用

xpath語法

pytest 或者 unittest

面向物件中的類 和 繼承

說在前邊：

PO模式是一種設計思想，在實際編碼的時候可以有若干種實現方式。

實際上，也建議大家根據自己專案的情況來動態的編碼。具體來說，常見的PO模式有：

1）三層：物件庫層+case層+page層

2）四層：物件庫層+case層+page層+公共類

====================================================

介面自動化

1.你是怎麼測試介面的

考點：

①. 是否具備介面測試實際經驗

②. 是否熟悉介面測試的流程

③. 是否熟悉介面測試的具體步驟

④. 是否熟悉介面測試用例設計

參考答案：

先了解介面的業務功能、入參出參以及介面對應的資料儲存，再依據介面測試用例設計方法完成介面測

試的設計，用例設計先業務場景再引數判斷，比如引數的邊界值、格式、組合等等，最後依據測試用例

2.沒有介面文件如何做介面測試

考點：

對介面測試的熟悉程度

測試軟技能

1.沒有介面文件，那就需要先跟開發溝通，然後整理介面文件（本來是開發寫的，沒辦法，為了唬住面試官，先說自己整理了）

2.沒有介面文件，可以抓包看介面請求引數，然後不懂的跟開發溝通

3.介面測試用例的編寫要點有哪些？

考點:

介面測試用例設計

參考答案:

1）必填欄位：請求引數必填項、可選項

2）合法性：輸入輸出合法、非法引數

3）邊界：請求引數邊界值等

4）容錯能力：大容量資料、頻繁請求、重複請求（如：訂單）、異常網路等的處理

5）響應資料校驗：斷言、資料提取傳遞到下一級介面…

6）邏輯校驗：如兩個請求的介面有嚴格的先後順序，需要測試調轉順序的情況

7）效能：對介面模擬併發測試，逐步加壓，分析瓶頸點

8）安全性：構造惡意的字元請求，如：SQL注入、XSS、敏感資訊、業務邏輯（如：跳過某些關鍵步驟；未經驗證操縱敏感資料）

4.介面測試中的加密引數如何處理

考點：

①. 是否熟悉加解密方式

②. 是否具備處理加密引數的能力

③. 是否實際應用過

參考答案：

首先了解引數的加解密方式，常見的有md5、aes、rsa等等，如果是aes的需要找開發要私鑰，如果是rsa需要找開發要公鑰和私鑰，

然後在介面測試工具中引用加解密的程式碼實現引數的加解密過程，實現引數加解密的處理；

如果公司有自定義的加密演算法則需要找開發要加解密的程式碼實現，然後在測試工具中使用。

5.介面應用題

問題1：設計介面測試⽤用例例時，涉及的是電商系統，其中包括很多修改，如商品、商家、店鋪等等，

針對這些資料的修改，會涉及到很多引數。如商品的名稱，商品的尺碼，商品的顏色等等。

那在設計實現“修改”介面時，如何確定要傳哪些引數,是隻需要傳我要修改的引數，還是全部引數都要傳。

5.同步和非同步區別

考點：

①. 考察對企業中介面通訊機制的認識

②. 考察同步通訊和非同步通訊的原理

參考答案：

同步和非同步是一種通訊方式

同步：執行一個操作時，需要等待其處理完成，然後再進行下一個操作

非同步：執行一個操作時，不需要等待返回，就進行下一個操作，一般需要使用訊息中介軟體

舉例：

下單介面中，需要呼叫庫存介面做庫存判斷，所以必須等待庫存介面返回資料才能進行下一步操作，這是同步；

下單介面中，下單成功後需要呼叫郵件通知介面，不用等待介面返回成功，就可以直接進行下一步操作，這是非同步；

6.pytest裡如何進行case的組裝

考點：

考察使用pytest組織case的能力

參考答案：

1.預設使用檢查以test_ .py 或**test.py命名的檔名，在檔案內部查詢以test打頭的方法或函式，並執行

2.可以使用自定義marker（標籤），比如pytest執行的時就只執行帶有該marker的測試用例，比如下面的@pytest.mark.P0

3.在命令列使用 指定檔案

4.引數：-k args 模糊匹配case（關鍵字args：可以是py檔名，也可以是函式名）

7.說說pytest裡的鉤子函式

考點：

pytest基礎知識

參考答案：

幾個常用的鉤子：

pytest_configure(config):新增自定義的標籤等

pytest_collection_modifyitems(items)：在case收集後呼叫，可以對專案順序或其他功能進行自定義

pytest_addoption(parser):為命令列新增自定義引數

=============================================================