自動化測試經典問題
我們可以從以下幾個方面來提高速度:
一,減少操作步驟,如經過三四步才能開啟我們要測試的頁面的話,我們就可以直接通過網址來開啟,減少不必要的操作。
二,中斷頁面載入,如果頁面載入的內容過多,我們可以檢視一下載入慢的原因,如果載入的內容不影響我們測試,就設定超時時間,中斷頁面載入。
三,在設定等待時間的時候,可以sleep固定的時間,也可以檢測某個元素出現後中斷等待也可以提高速度。
四,配置testNG實現多執行緒。在編寫測試用例的時候,一定要實現鬆耦合,然後在伺服器允許的情況下,儘量設定多執行緒執行,提高執行速度。
5、用例在執行過程中經常會出現不穩定的情況,也就是說這次可以通過,下次就沒辦法通過了,如何去提升用例的穩定性? - time.sleep( ) - driver.implicitly_wait(30) - 多用 try 捕捉,處理異常 -此時我們要分析出不穩定的原因,然後有針對性的去解決問題。主要有以下幾個方面 :一,網速問題:有的時候網頁載入的比較慢,在程式執行的時候要操作的元素沒有顯示出來。這種情況比較常見,執行一次網速好的時候通過了,再執行一次,頁面沒有開啟,就不通過了。為了提高穩定性,我們只能犧牲執行時間了,在經常檢測失敗的元素前加上等待時間,等要操作的元素出現之後再執行下面的操作。
二,Selelnium的原因:Selenium1.0和2.0還是有區別的,有些兒函式在2.0下執行確實有時而有效,時面無效。如果mouseover()函式,就是這種情況, 我們需要避免用這類函式。
三,多執行緒的時候,測試用例間相互影響。雖然多執行緒的時候執行速度比較快,但是如果用例之間的耦合性沒有設計好,也會影響的,如果用例A先於用例B執行的時候,就會影響到用例B;反之沒有問題。這種情況,如果你的自動化測試工程打算多執行緒時,提前就要把測試用例測試的耦合度比較鬆,儘量沒有任何關係,因為多執行緒的執行順序是不受控制的。 6、你的自動化用例的執行策略是什麼? - 自動化測試用例的執行策略是要看自動化測試的目的,通常有如下幾種策略:
一,自動化測試用例是用來監控的,在此目的下,我們就把自動化測試用例設定成定時執行的,如果每五分鐘或是一個小時執行一次,在jenkins上建立一個定時任務即可。
二,必須迴歸的用例。有些兒測試用例,如BVT測試用例,我們在公司產品任何變動上線之前都需要回歸執行。那我們就把測試用例設定成觸發式執行,在jenkins上將我們的自動化測試任務繫結到開發的build任務上。當開發人員在模擬環境上部程式碼的時候,我們的自動化測試用例就會被觸發執行。
三,不需要經常執行的測試用例。像全量測試用例,我們沒有必要一直迴歸執行,必竟還是有時間消耗的,有些非主要業務線也不需要時時迴歸。這類測試用例我們就採用人工執行,在jenkins建立一個任務,需要執行的時候人工去構建即可。 7、什麼是持續整合? - 持續整合源於極限程式設計(XP),是一種軟體實踐,軟體開發過程中整合步驟是一個漫長並且無法預測的過程。整合過程中可能會爆發大量的問題,因此整合過程需要儘可能小而多,實際上持續整合講的是不斷的去做軟體的整合工作。持續整合,最簡單的形式是包括一個監控版本控制(SVN等等)變化的工具。當變化被發覺時,這個工具可以自動的編譯並測試你的應用。
通過研究selenium-webdriver的原始碼,筆者發現其實webdriver的實現原理並不高深莫測無法揣度。在這裡以webdriver ruby binding
-
當測試指令碼啟動firefox的時候,selenium-webdriver 會首先在新執行緒中啟動firefox瀏覽器。如果測試指令碼指定了firefox的profile,那麼就以該profile啟動,否則的話就新啟1個profile,並啟動firefox;
-
firefox一般是以-no-remote的方法啟動,啟動後selenium-webdriver會將firefox繫結到特定的埠,繫結完成後該firefox例項便作為webdriver的remote server存在;
-
客戶端(也就是測試指令碼)建立1個session,在該session中通過http請求向remote server傳送restful的請求,remote server解析請求,完成相應操作並返回response;
-
客戶端接受response,並分析其返回值以決定是轉到第3步還是結束指令碼;
這就是webdriver的工作流程,看起來很複雜實際上當瞭解了webdriver的實現原理後,理解上述問題應該比較簡單。
webdriver是按照server – client的經典設計模式設計的。
server端就是remote server,可以是任意的瀏覽器。當我們的指令碼啟動瀏覽器後,該瀏覽器就是remote server,它的職責就是等待client傳送請求並做出相應;
client端簡單說來就是我們的測試程式碼,我們測試程式碼中的一些行為,比如開啟瀏覽器,轉跳到特定的url等操作是以http請求的方式傳送給被 測試瀏覽器,也就是remote server;remote server接受請求,並執行相應操作,並在response中返回執行狀態、返回值等資訊;
14、webdriver的協議是什麼? -The WebDriver Wire Protocol 15、啟動瀏覽器的時候用到的是哪個webdriver協議? -http 16、什麼是page object設計模式? -http://www.cnblogs.com/tsbc/p/4080301.html 相似功能地方,程式碼基本都是一樣的,介面元素換個查詢方式,把原來的使用 xpath方式,改為使用 id 查詢,需要對每個用例指令碼都要改,雖然幾個用例看不出什麼工作量,但是重複findElement的程式碼,已經讓我們感到了程式碼的笨重。如果某些定位發生了改變,我們就得貫穿整個測試程式碼進行調整元素定位,這樣就會導致我們的指令碼在後期,難以維護。因此通過Page Object Model 我們可以建立更加健壯程式碼,並減少或者消除重複的測試程式碼,從而也能夠提高程式碼的可讀性,減少編寫指令碼的工作量。Page Object Model的實現,就是通過分離測試物件和測試指令碼的抽象來實現的。 17、什麼是page factory設計模式? - http://relevantcodes.com/pageobjects-and-pagefactory-design-patterns-in-selenium/ 18、怎樣去選擇一個下拉框中的value=xx的option? -二次定位 19、如何在定位元素後高亮元素(以除錯為目的)? -重置元素屬性,給定位的元素加背景、邊框 20、什麼是斷言? -斷言的英文是assertion,斷言檢查的英文是assertion checking。 -斷言是指定一個程式必須已經存在的狀態的一個邏輯表示式,或者一組程式變數在程式執行期間的某個點上必須滿足的條件。 21、如果你進行自動化測試方案的選型,你會選擇哪種語言,java,js,python還是ruby? -使用自己熟悉的語言 22、page object設定模式中,是否需要在page裡定位的方法中加上斷言? -不需要 23、page object設計模式中,如何實現頁面的跳轉? -get、click (可能有坑) 24、自動化測試用例從哪裡來? -手工用例中抽取 -可以參考自動化用例的執行策略 25、你覺得自動化測試最大的缺陷是什麼? -不穩定 -可靠性 -不易維護 -成本與收益 , 26、什麼是分層測試? 27、webdriver可以用來做介面測試嗎? -有難度,不推薦28、get和post 的區別?(感覺可能答案不對)
-因為使用GET請求不會產生什麼動作。不會產生動作意味著GET的HTTP請求不會在伺服器上產生任何結果。但是安全方法並不是什麼動作都不產生,這裡的安全方法僅僅指不會修改資訊。POST可能會修改伺服器上的資源的請求。比如CSDN的部落格,使用者提交一篇文章或者一個讀者提交評論是通過POST請求來實現的,因為再提交文章或者評論提交後資源(即某個頁面)不同了,或者說資源被修改了。
兩種請求方式的區別:
1、GET請求,請求的資料會附加在URL之後,以?分割URL和傳輸資料,多個引數用&連線。URL的編碼格式採用的是ASCII編碼,而不是uniclde,即是說所有的非ASCII字元都要編碼之後再傳輸。
POST請求:POST請求會把請求的資料放置在HTTP請求包的包體中。上面的item=bandsaw就是實際的傳輸資料。因此,GET請求的資料會暴露在位址列中,而POST請求則不會。
2、傳輸資料的大小
在HTTP規範中,沒有對URL的長度和傳輸的資料大小進行限制。但是在實際開發過程中,對於GET,特定的瀏覽器和伺服器對URL的長度有限制。因此,在使用GET請求時,傳輸資料會受到URL長度的限制。
對於POST,由於不是URL傳值,理論上是不會受限制的,但是實際上各個伺服器會規定對POST提交資料大小進行限制,Apache、IIS都有各自的配置。
3、安全性
POST的安全性比GET的高
29、公司內一直在使用的測試系統(B/S架構)突然不能訪問了,需要你進行排查並恢復,說出你的檢查方法
答:一、網站輸入域名直接無法訪問,網站之前還正常,突然就無法訪問