自動化測試的準備

什麼是自動化測？

　　首先理清自動化測試的概念，廣義上來說，自動化包括一切經過工具（程序）的方式來代替或輔助手工測試的行爲均可以看作自動化，包括性能測試工具（loadrunner、jmeter）,或本身所寫的一段程序，用於生成1到100個測試數據。狹義上來說，通工具記錄或編寫腳本的方式模擬手工測試的過程，經過回放或運行腳原本執行測試用例，從而代替人工對系統的功能進行驗證。

　　固然，咱們更廣泛的認識把「自動化測試」看作「 基於產品或項目UI層的自動化測試」。

 

 

分層的自動化測試

 

　　這個概念最近曝光度比較高，傳統的自動化測試更關注的產品UI層的自動化測試，而分層的自動化測試倡導產品的不一樣階段（層次）都須要自動化測試。

 

　　相信測試同窗對上面的金字塔並不陌生，這不就是對產品開發不一樣階段所對應的測試麼！咱們須要規範的來作單元測試一樣須要相應的單元測試框架，如Java的Junit、testNG，C#的NUnit ，Python 的unittest、pytest 等，幾乎全部的主流語言，都會有其對應的單元測試框架。

　　集成、接口測試對於很多測試新手來講不太容易理解，單元測試關注代碼的實現邏輯，例如一個if 分支或一個for循環的實現；那麼集成、接口測試關注的一是個函數、類（方法）所提供的接口是否可靠。例如，我定義一個add()函數用於計算兩個參數的結果並返回，那麼我須要調用add()並傳參，並比較返回值是否兩個參數相加。固然，接口測試也能夠是url的形式進行傳遞。例如，咱們經過get方式向服務器發送請求，那麼咱們發送的內容作爲URL的一部分傳遞到服務器端。但好比 Web service 技術對外提供的一個公共接口，須要經過soapUI 等工具對其進行測試。 

　　UI層的自動化測試，這個你們應該再熟悉不過了，大部分測試人員的大部分工做都是對UI層的功能進行測試。例如，咱們不斷重複的對一個表單提交，結果查詢等功能進行測試，咱們能夠經過相應的自動化測試工具來模擬這些操做，從而解放重複的勞動。UI層的自動化測試工具很是多，比較主流的是QTP，Robot Framework、watir、selenium 等。

　　爲何要畫成一個金字塔形，則不是長方形 或倒三角形呢？ 這是爲了表示不一樣階段所投入自動化測試的比例。若是一個產品從沒有作單元測試與接口測試，只作UI層的自動化測試是不科學的，從而很難從本質上保證產品的質量。若是你妄圖實現全面的UI層的自動化測試，那更是一個勞民傷財的舉動，投入了大量人力時間，最終得到的收益可能會遠遠低於所支付的成本。由於越往上層，其維護成本越高。尤爲是UI層的元素會時常的發生改變。因此，咱們應該把更多的自動化測試放在單元測試與接口測試階段進行。

　　既然UI層的自動化測試這麼勞民傷財，那咱們只作單元測試與接口測試好了。NO! 由於無論什麼樣的產品，最終呈現給用戶的是UI層。因此，測試人員應該更多的精力放在UI層。那麼也正是由於測試人員在UI層投入大量的精力，因此，咱們有必要經過自動化的方式幫助咱們「部分解放」重複的勞動。

　　在自動化測試中最怕的是變化，由於變化的直接結果就是致使測試用例的運行失敗，那麼就須要對自動化腳本進行維護；如何控制失敗，下降維護成本對自化的成敗相當重要。反過來說，一份永遠都運行成功的自動化測試用例是沒有價值。 

　　至於在金字塔中三種測試的比例要根據實際的項目需求來劃分。在《google 測試之道》一書，對於google產品，70%的投入爲單元測試，20%爲集成、接口測試，10% 爲UI層的自動化測試。

我爲何要作自動化測試？

 

　　根據51testing的《中國軟件測試從業人員調查報告》，手工測試佔到的89% ，相對開發來講，測試的門檻底，薪資廣泛較底，所要求的知識面雖然有必定廣度，但缺少深度。這是測試的廣泛現狀。

　　正由於手功測試人門檻不高，使大量的畢業生，甚至是非專業人員涌入這個行業。從而增長了這個行業的激烈競爭。對於工做幾年扔處於手工測試的人員來講都會有強列的危機感。因爲工做的技術含量不高，薪資的漲幅遇到瓶頸，另外一方面受到新進入者的威脅，一樣的工做公司花5K招來的人就能夠作，那麼就不會花8K 的招。

　　好吧，這個問題不該該出現討論技術的話題中，但他的確是大多測試人員不得不面對的一個問題。因此，從測試人員自身的發展來講，我其實很是須要經過自動化技術來增長本身有競爭力。固然，作到必定年限測試人員會選擇轉管理或其它崗位，這又是另外一個話題了。

　　從測試行業的發展來講，國內產品因爲產品特色，世界級的產品很少，技術含量相對不高，質量要求相對要求不高，外包國外項目，測試人力成本低廉，因此須要大量的手工測試人員。

　　因此，在不遠的將來，我認爲純的工手測試人員的需求是遞減，公司更須要更高技術能力的測試。質量須要測試，測試行爲永遠不會消失，但純的手工測試人員是否消失是有可能的。

　　好吧，你能夠說測試多朝陽的行業，我純屬在危言聳聽。無論將來如何，咱們都須要提高自身的技能對吧！

 

 

 

什麼項目適合作自動化測試？

 

　　假如你已經決定要學習自動化測試了，如何學習是要面臨的下一個問題？這個問題以被測試產品爲出發點進行分析，假如你所學的技術不能獲得應用（驗證），將會使你的學習過程步履維艱。

　　首先考考慮產品是否適合作自動化測試。這方法比較廣泛的共識是從三個方面進行權衡。

 

　　軟件需求變更不頻繁

　　測試腳本的穩定性決定了自動化測試的維護成本。若是軟件需求變更過於頻繁，測試人員須要根據變更的需求來更新測試用例以及相關的測試腳本，而腳本的維護自己就是一個代碼開發的過程，須要修改、調試，必要的時候還要修改自動化測試的框架，若是所花費的成本不低於利用其節省的測試成本，那麼自動化測試即是失敗的。

　　項目中的某些模塊相對穩定，而某些模塊需求變更性很大。咱們即可對相對穩定的模塊進行自動化測試，而變更較大的還是用手工測試。

 

　　項目週期較長

因爲自動化測試需求的肯定、自動化測試框架的設計、測試腳本的編寫與調試均須要至關長的時間來完成。這樣的過程自己就是一個測試軟件的開發過程，須要較長的時間來完成。若是項目的週期比較短，沒有足夠的時間去支持這樣一個過程，那麼自動化測試便成爲笑談。

 

　　自動化測試腳本可重複使用

　　自動化測試腳本的重複使用要從三個方面來考量，一方面所測試的項目之間是否很大的差別性（如C/S系統和B/S系統的差別）；所選擇的測試工具是否適應這種差別；最後，測試人員是否有能力開發出適應這種差別的自動化測試框架。

選擇什麼工具進行自動化測試

 

　　假如你已經確認了XX 項目適合作自動化測試，那麼接下來你要作的就是選測試工具了。

　　首先要先確認你所測試的產品是桌面程序（C/S）仍是web應用（B/S）。

　　桌面程序的工具備：QTP、 AutoRunner

　　web應用的工具備：QTP、AutoRunner、Robot Framework、watir、selenium

　　因爲B/S架構的諸多優點，早幾年前大量C/S架構的應用轉爲B/S結構。從而也推進了web開發與測試技術的發展。假如，被測試有產品是C/S架構的，那麼推薦QTP ，QTP在UI自動化測試領域佔到了一半的試用率。因此，足以說明QTP在自動化領域強大，易用性等。學習主流的工具也可使你得到更多的機會。市面上關於QTP的書籍也很是豐富。固然，要想學好QTP ，你必需要掌握VBS腳本語言。

　　若是，被測產品是B/S 結構，那麼推薦selenium ，爲何不是QTP 或其它工具？由於selenium 對B/S應用支持很好，更重要的一點，它支持多語言的開發，真正的試用selenium ，你所要掌握的不只僅是一個工具而已，你還須要學習一門語言。我爲何要選擇selenium？還要學一門語言，這無疑增長了個人學習成本。增長成本的同時，也增長的你的競爭力，並且，在這個過程當中你不僅僅只是學會了一個自動化工具而已，你徹底可使用所學的語言去作更多的事情。

　　好吧！假如你決定試用selenium 了以後，你又面臨了一個新的問題，選擇一門語言。selenium 是支持java、python、ruby、PHP、C#、JavaScript 。

　　從語言易學性來說，首選ruby ，python

　　從語言應用廣度來說，首選java、C#、php、

　　從語言相關測試技術成度（及 資料）來說：ruby ,python ,java

　　或者你能夠考慮整個技術團隊主流用什麼語言，而後選擇相應的語言。

 

 

 

selenium 用前須知

 

　　OK！通過上的過程，我相信你必定作出的相應的選擇，若是你選擇的是selenium 工具，那麼接着往下閱讀。

首選你在開始selenium以前，須要花一到兩個月時間去學一門語言，這裏是根據沒有語言基礎的同窗而定的。我推薦ruby ,python ,java 任意一門語言來進行學習。

　　固然，已經若是有很好的語言基礎略過這個環節，或者你的豐富的java編程能力，那麼學習python 可能只須要幾天時間或更短。

　　假如，你已經搞定了一門語言的基礎，接下來你須要先了解selenium ，selenium 並非單純的一個工具，他是一組工具的集合，並且，他還有1.0與2.0之分，固然3.0也已經到來。

　　selenium 也不是簡單一個工具，而是由幾個工具組成，每一個工具都有其特色和應用場景。

 

selenium IDE

　　selenium IDE 是嵌入到Firefox瀏覽器中的一個插件，實現簡單的瀏覽器操做的錄製與回放功能。那麼什麼狀況下用到它呢？

　　快速的建立bug重現腳本，在測試人員的測試過程當中，發現了bug以後能夠經過IDE將重現的步驟錄製下來，以幫助開發人員更容易的重現bug。

　　IDE錄製的腳本能夠能夠轉換成多種語言，從而幫助咱們快速的開發腳本，關於這個功能後而用到時再詳細介紹。

 

selenium Grid

　　Selenium Grid是一種自動化的測試輔助工具，Grid經過利用現有的計算機基礎設施，能加快Web-app的功能測試。利用Grid，能夠很方便地同時在多臺機器上和異構環境中並行運行多個測試事例。其特色爲：

· 並行執行

· 經過一個主機統一控制用例在不一樣環境、不一樣瀏覽器下運行。

· 靈活添加變更測試機

 

selenium RC

　　selenium RC 是selenium 家族的核心工具，selenium RC 支持多種不一樣的語言編寫自動化測試腳本，經過selenium RC 的服務器做爲代理服務器去訪問應用從而達到測試的目的。

　　selenium RC 使用分Client Libraries和selenium Server，Client Libraries庫主要主要用於編寫測試腳本，用來控制selenium Server的庫。

　　Selenium Server負責控制瀏覽器行爲，總的來講，Selenium Server主要包括3個部分：Launcher、Http Proxy、Core。其中Selenium Core是被Selenium Server嵌入到瀏覽器頁面中的。其實Selenium Core就是一堆JS函數的集合，就是經過這些JS函數，咱們才能夠實現用程序對瀏覽器進行操做。Launcher用於啓動瀏覽器，把selnium Core加載到瀏覽器頁面當中，並把瀏覽器的代理設置爲Selenium Server 的Http Proxy。

 

selenium 2.0

　　搞清了selenium 1.0 的家族關係，selenium 2.0 是把WebDriver 加入到了這個家族中；簡單用公式表示爲：

　　selenium 2.0 = selenium 1.0 + WebDriver 

　　須要強調的是，在selenium 2.0 中主推的是WebDriver ，WebDriver 是selenium RC 的替代品，由於 selenium 爲了向下兼容性，因此selenium RC 並無完全拋棄，若是你使用selenium開發一個新自動化測試項目，強列推薦使用WebDriver 。那麼selenium RC 與webdriver 主要有什麼區別呢？

　　selenium RC 在瀏覽器中運行JavaScript應用，使用瀏覽器內置的JavaScript 翻譯器來翻譯和執行selenese命令（selenese 是selenium命令集合）。

　　WebDriver經過原生瀏覽器支持或者瀏覽器擴展直接控制瀏覽器。WebDriver針對各個瀏覽器而開發，取代了嵌入到被測Web應用中的JavaScript。與瀏覽器的緊密集成支持建立更高級的測試，避免了JavaScript安全模型致使的限制。除了來自瀏覽器廠商的支持，WebDriver還利用操做系統級的調用模擬用戶輸入。

　　若是是新項目直接學習webdriver 就OK了，RC是過期技術。

 

 

selenium學習路線

 

　　配置你的測試環境，真對你所學習語言，來配置你相應的selenium 測試環境。selenium 比如定義的語義---「問好」，假如你使用的是中文，爲了表術問好，你的寫法是「你好」，假如你使用的是英語，你的寫法是「hello」。 因此，一樣有語義在不一樣的語言下會有不一樣的寫法（語法）。

 　　接着你須要熟悉webdriver API ，API就是selenium 所定義一方法，用於定位，操做頁面上的各類元素。

　　先學習元素的定位，selenium 提供了id、name、class name、 tag name、link text、partial link text、 xpath、css、等定位方法。xpath和css 功能強大語法稍微複雜，在這其間你可能還須要瞭解更多的前端知識。xml ,javascript 等。

　　定位元素的目的是爲了操做元素，接就要學習各類元素有操做，輸入框，下拉框，按鈕點擊，文件上傳、下載，分頁，對話框，警告框...等等。

　　通過一段時間的學習，你能夠遊刃有餘的模擬手工測試來操做頁面上的各類元素了。接着你須要作的就是把這些「用例」組織起來，統一來跑。

　　那麼你須要作的就是學習並使用單元測試框架，單元測試框架自己就解決了用例的組織與運行。

　　當你寫了一些「測試用例」 以後，你會發現用例中有大量重複的操做，能不能寫到一個單獨的文件中，須要的時候調用這些操做？固然能夠，運用你的編程能力來實現這一點將很是簡單。而後，你又發現每一個用例中都有一些數據，這些數據也是同樣的，但若是變化了修改起來很是麻煩，你也能夠把他寫到一個單獨的文件中進行讀取。

　　接着你又遇到了新的疑問，我寫的腳本（用例）都是流水式的，我怎麼知道用例運行失敗仍是成功。那麼就須要在腳本中加一些驗證與斷言。

　　接着你又有了更多的想法，單元測試框架的log太簡陋了，能不能生成一張漂亮的測試報告出來。我能不能定時的來跑這個腳本。能不能把每一次跑腳本的測試結果直接發到個人郵箱。能不能......

　　爲解決這些問題，你不得不學習更多的編程技術，而後你的「測試結構」會功能愈來愈強大，愈來愈靈活。產生了必定的通用性和移植性。一個有模有樣的自動化測試框架誕生了。

 　　假如，有一天你再也不作UI的自動化測試了，你會發現你去作單元測試 或接口測試基本沒什麼難度。開發個測試工具之類的也不在話下，感謝selenium 吧！

 

 

 

 

 

 

 

 

 以爲不錯的可關注微信公衆號在手機上觀看，讓你用手機邊玩邊看