UI自動化測試工作開展：
   適合做UI自動化的場景
     1）回歸驗證
     2）巡檢
     3）移動端的埋點測試
         最典型的就是移動端的埋點測試，傳統(tǒng)的測試方法，就是在手機上操作，
         觸發(fā)埋點上報，然后通過手機抓包，獲取埋點數(shù)據(jù)，然后再依據(jù)埋點文檔，去對每個字段進行一一人工校驗。
     
一、UI自動化測試流程
前提條件：框架已經(jīng)部署ok

 編寫用例
 1.需求分析（業(yè)務(wù)流程）
     二次的需求分析 
         進行自動化測試前，肯定是手工測試已經(jīng)進行了測試，并且功能穩(wěn)定沒有bug
 2.用例設(shè)計：提供什么參數(shù)以及數(shù)據(jù)，測試步驟
         手工測試用例編寫
         自動化測試用例代碼編寫（用例設(shè)計點）
 3.用例評審，組內(nèi)評審
 4.編寫代碼
     4.1根據(jù)編寫的測試用例，進行代碼編寫，如登錄功能
         步驟：
         輸入登錄url：https://v4.ketangpai.com/Home/User/login.html
         輸入用戶名：aaa  name="account"
         輸入密碼:123  name="pass"
         點擊登錄按鈕：class="btn-btn" （雖然找到兩個相同元素，但fide_element只取第一個，正好我們需要的是第一個）
         進行斷言
     4.2優(yōu)化代碼
         優(yōu)化方向：
         更好用
         更易懂
         維護代碼方便
         更通用
         擴展性
        優(yōu)化點：
         隔離測試數(shù)據(jù)，當需要添加或修改數(shù)據(jù)時，可以在單獨的模塊中進行修改
         瀏覽器管理可以重復使用，所以可以進行單獨封裝
         需要把驅(qū)動進行隔離管理：1.可以存儲多個瀏覽器驅(qū)動，2.想用哪個用哪個
         base url域名ip
         登錄操作可以重復使用（項目通用）
         登錄操作：已經(jīng)登錄過了，不需要重新再登錄，記住用戶登錄狀態(tài)
         
        PO模式
         發(fā)現(xiàn)更多的新缺陷應(yīng)該是手工測試的主要目的，不能期望自動化測試去發(fā)現(xiàn)更多新缺陷。
         事實上，自動化測試主要用于發(fā)現(xiàn)原來的缺陷。自動化測試用于回歸測試，而大量的新業(yè)務(wù)測試更多地還是依賴手工測試。
         如果沒有建立一個正確的軟件測試自動化的觀念，認為測試自動化可以完全代替手工測試，
         或者認為測試自動化可以發(fā)現(xiàn)大量新缺陷，或者不愿在初期投入比較大的開支等，則自動化測試一定會讓我們大失所望。

UI自動化測試:面試題

 1.如何把自動化測試在公司中實施起來的？
     1.選擇長期的有穩(wěn)定模塊的項目
     2.項目組調(diào)研選擇自動化工具并開會演示demo案例
     3.輸出自動化的方案，跟項目負責人確認
 2.自動化測試用例如何編寫？
     自動化測試主要用于回歸測試，因此自動化用例來源于我們編寫的功能用例，不管是接口的還是業(yè)務(wù)測試的用例；
     所以我們會從原有用例中進行篩選，篩選出需要實現(xiàn)自動化測試的，但是這個實現(xiàn)過程并不是按部就班；
     需要根據(jù)原有用例進行自動化用例設(shè)計，比如修改名稱這樣的功能，自動化用例中需要實現(xiàn)每次修改都和上一次不一樣，否則無法驗證修改是否正確。
     增加了這樣的設(shè)計之后再按照使用腳本來實現(xiàn)自動操作的過程，并實現(xiàn)結(jié)果判斷，也就是斷言
 3.自動化測試發(fā)現(xiàn)BUG多嗎？不多
    那么自動化測試的價值是什么 ? 怎么證明它不是偽需求 ?
     1.比起發(fā)現(xiàn)bug,自動化測試更擅長保持舊有的功能沒有bug出現(xiàn)
     2.引用自動化測試之后，能代替大量繁瑣的回歸測試工作，把業(yè)務(wù)測試人員解放出來，既而讓業(yè)務(wù)測試人員把精力集中在復雜的業(yè)務(wù)功能模塊上
     3.一般來說相對穩(wěn)定的功能更適合自動化
     4.功能自動化盡可能用接口\驗收自動化則使用端到端
     5.回歸測試效率和頻次的提升
 4.自動化中有哪三類等待？他們有什么特點？
     1.線程等待（強制等待）如：time.sleep(2)：線程強制休眠2秒鐘，2秒過后，再執(zhí)行后續(xù)的代碼。建議少用。
     2.imlicitlyWait（隱式等待）會在指定的時間范圍內(nèi)不斷的查找元素，
         直到找到元素或超時，是一種全局性設(shè)置，可以隨時更改，并且只針對查找元素生效
     3.WebDriverWait（顯式等待）通常是我們自定義的一個函數(shù)代碼，這段代碼用來等待某個元素加載完成，
         再繼續(xù)執(zhí)行后續(xù)的代碼，可以針對js彈框、iframe、新窗口等進行實施
 5.selenium*中的定位方式
     1.id：根據(jù)id來獲取元素，返回單個元素，id值一般是唯一的；
     2.name：根據(jù)元素的name屬性定位；
     3.tagName：根據(jù)元素的標簽名定位；
     4.className：根據(jù)元素的樣式class值定位；
     5.linkText：  根據(jù)超鏈接的文本值定位；
     6.partialLinkText：根據(jù)超鏈接的部分文本值定位；
     7.cssSelector：css選擇器定位；
     8.xpath：通過元素的路徑來定位；
    優(yōu)先級最高：ID
    優(yōu)先級其次：name
    優(yōu)先級再次：CSS selector
    優(yōu)先級再次：Xpath
 6.xpath和css定位都比較強大,那他們之間有什么區(qū)別?
      1.CSS 比XPath 速度快,因為css是配合html來工作，它實現(xiàn)的原理是匹配對象的原理，而
         xpath是配合xml工作的，它實現(xiàn)的原理是遍歷的原理，所以兩者在設(shè)計上，css性能更優(yōu)秀
      2.Xpath對于class跟普通屬性一致
      3.xpath可匹配祖先元素,css不可以
      4.查找兄弟元素， Css只能查找元素后面(弟弟妹妹)的元素，不能向前找(哥哥姐姐)
 7.寫的測試腳本能在不同瀏覽器上運行嗎？
     當然可以，我寫的用例可以在在IE，火狐和谷歌這三種瀏覽器上運行，
    實現(xiàn)的思路是封裝一個方法，分別傳入一個瀏覽器的字符串，如果傳入IE就使用IE，如果傳入FireFox就使用FireFox，如果傳入Chrome就使用Chrome瀏覽器；
    并且使用什么瀏覽器可以在總的ini配置文件中進行配置。需要注意的是每個瀏覽器使用的驅(qū)動不一樣。
    
 8.什么是PO模式，為什么要使用它
     說在前邊：PO模式是一種設(shè)計思想，在實際編碼的時候可以有若干種實現(xiàn)方式。實際上，也建議
     大家根據(jù)自己項目的情況來動態(tài)的編碼。具體來說，常見的PO模式有：
         1）三層：對象庫層+case層+page層
         2）四層：對象庫層+case層+page層+公共類
    簡單的說下PO模式的設(shè)計思想？
        所謂的PO吧，就是Page Object頁面對象,利用面向?qū)ο蟮乃季S來封裝我們的UI自動化測試用例。
     PO模式就是把我們測試過程中每個頁面都當做對象,在我們的UI自動化測試框架中,每個頁面都有一個獨立的封裝py文件,
     分為三層來管理:
         第一層是對象庫層，將測試用例在該頁面所有用到的元素對象統(tǒng)一找到并進行管理,
         第二層操作層:基于每個元素定義好其對應(yīng)的操作方法,
         第三層:業(yè)務(wù)層,組裝多個操作方法即可形成完整的業(yè)務(wù)操作。
    例如:
     登錄頁面:
         對象庫層找到用戶名、密碼等元素，
         操作層封裝用戶名輸入、密碼輸入等方法，
         業(yè)務(wù)層連續(xù)調(diào)用操作層方法，那調(diào)用業(yè)務(wù)層的登錄方法傳遞輸入?yún)?shù)即可完成登錄。
        這樣無論哪個測試用例需要進行登錄，都只需要調(diào)用該頁面py文件業(yè)務(wù)層的登錄方法，即可完成登錄。
        這樣整個UI自動化測試代碼中,對應(yīng)的元素定位代碼只會存在一份了，方便了維護，也減少了代碼的冗余。
 9. Jmeter工具如何做接口之間的關(guān)聯(lián)，簡述？
      接口關(guān)聯(lián)指的就是一個接口要使用另一個接口的返回值作為參數(shù)，這種我們在jmeter中叫做關(guān)聯(lián)。
    關(guān)聯(lián)的實現(xiàn)方式有多種：
         1.使用正則表達式提取器獲取上一個請求的響應(yīng)結(jié)果中的某個值，儲存在某個變量中，然后下一個接口使用變量進行引用
         2.使用json提取器獲取上一個請求的響應(yīng)結(jié)果中的某個值，儲存在某個變量中，然后下一個接口使用變量進行引用
         3.使用beanshell后置處理器，解析響應(yīng)結(jié)果存儲在變量中，然后下一個接口使用變量進行引用
           跨線程組關(guān)聯(lián)則需要將關(guān)聯(lián)字段設(shè)置為全局屬性
 10.cookie 和 session 的區(qū)別？
     會話（Session）跟蹤是Web程序中常用的技術(shù)，用來跟蹤用戶的整個會話
     Cookie通過在客戶端記錄信息確定用戶身份，Session通過在服務(wù)器端記錄信息確定用戶身份
    區(qū)別：
         1.數(shù)據(jù)存放位置不同：
             cookie數(shù)據(jù)存放在客戶的瀏覽器上，session數(shù)據(jù)放在服務(wù)器上
         2.安全程度不同：
             cookie不是很安全，別人可以分析存放在本地的COOKIE并進行COOKIE欺騙,考慮到安全應(yīng)當使用session
         3.性能使用程度不同：
             session會在一定時間內(nèi)保存在服務(wù)器上。當訪問增多，會比較占用你服務(wù)器的性能,考慮到減輕服務(wù)器性能方面，應(yīng)當使用cookie
         4.數(shù)據(jù)存儲大小不同：
             單個cookie保存的數(shù)據(jù)不能超過4K，很多瀏覽器都限制一個站點最多保存20個cookie，而session則存儲與服務(wù)端，瀏覽器對其沒有限制
 11.自動化測試中用例依賴的數(shù)據(jù)如何構(gòu)造
        不管是接口自動化還是ui自動化都會存在自動化case依賴數(shù)據(jù)如何構(gòu)造的問題，可以從三個方面去考慮，
          第一個是在測試前采用接口去構(gòu)造需要的數(shù)據(jù)；
          第二個是使用初始化sql去初始化數(shù)據(jù)，但是如果說表結(jié)構(gòu)復雜的話，sql編碼同學寫也是比較大的工作量；
        第三個方式是提前準備好一套數(shù)據(jù)（拿測試環(huán)境的數(shù)據(jù)），并且將該數(shù)據(jù)對應(yīng)的數(shù)據(jù)庫進行備份，在之后每次執(zhí)行測試前先備份當前數(shù)據(jù)庫數(shù)據(jù)，
          再導入之前的測試數(shù)據(jù)，再執(zhí)行測試，測試執(zhí)行完后再恢復原有的數(shù)據(jù)
 12.如何提高Selenium腳本的執(zhí)行速度？
         1.在設(shè)置等待時間的時候，可以sleep固定的時間，也可以檢測某個元素出現(xiàn)后中斷等待也可以提高速度
         2.配置實現(xiàn)多線程，在編寫測試用例的時候，一定要實現(xiàn)松耦合，然后在服務(wù)器允許的情況下，盡量設(shè)置多線程運行，提高執(zhí)行速度
         3.中斷頁面加載，如果頁面加載的內(nèi)容過多，我們可以查看一下加載慢的原因，如果加載的內(nèi)容不影響我們 測試，就設(shè)置超時時間
         4.優(yōu)化等待時間：使用 WebDriverWait 智能等待來代替線程等待 sleep 和 隱式等待 implicityWait
 13.一個元素明明定位到了，點擊無效（也沒報錯），如何解決？
         使用js點擊，selenium有時候點擊元素是會失效
 14.你會封裝自動化測試框架嗎？
         當然可以，自動化框架主要的核心框架就是分層+PO模式：
         分別為：基礎(chǔ)封裝層BasePage，PO頁面對象層，TestCase測試用例層；
         然后再加上日志處理模塊，ini配置文件讀取模塊，unittest+ddt數(shù)據(jù)驅(qū)動模塊，jenkins持續(xù)集成模式組成；
 15.關(guān)閉瀏覽器中quit和close的區(qū)別
         簡單來說，兩個都可以實現(xiàn)退出瀏覽器session功能，
         close是關(guān)閉你當前聚焦的tab頁面；而quit是關(guān)閉全部瀏覽器tab頁面，并退出瀏覽器session。
         知道這兩個區(qū)別，我們就知道quit一般用在結(jié)束測試之前的操作，close用在執(zhí)行用例過程中關(guān)閉某一個頁面的操作。