淺談自動化測試實踐經驗和教訓

作自動化有好一段時間了，經歷了自動化從無到有，而後到框架，到如今的平臺，以及持續集成，回顧發現因爲本身以前經驗太淺，走過的彎路太多，如今也還在謹慎的前進着，以前發現早前不少懵懂的經驗，如今稍稍清晰，因而想着結合本身的歷程精簡出一些經驗吧。如今經驗仍是尚淺，若是有更深認識的朋友，互相討論，謝謝。

 

1、所謂自動化是爲了軟件發佈服務的，並不僅是爲了測試服務

　　之前一直懷疑自動化測試的用處，咱們以前花費大力氣開發了大量的基於關鍵字方式的腳本，用來提升測試的覆蓋率，每次測試耗費大量時間，可是發現的問題少之又少，雖說，自動化測試不是用來發現問題的，是用來驗證軟件沒有問題，可是有一個矛盾在於我若是不作自動化測試，問題仍是那麼少，那麼作自動化測試咱們難道只是爲了追求一個心理感覺嗎？這個機率問題怎麼平衡

後來，這個經驗是在與開發一塊兒合做冒煙測試建設，到如今的持續集成建設，開始明白，自動化測試的好處是爲了加強開發的靈活性和保證軟件開發流程的有序性

1）快速檢測新版本的不穩定變動，即冒煙測試，可以快速驗證當前build版本是否能夠繼續下一步或者提測，此處冒煙測試能夠是單元測試、集成測試和基本功能覆蓋測試，經常使用的框架和工具：Junit、TestNG和接口測試框架（soapui、httpClient等）、界面測試框架用於基本的界面測試（QTP、RFT、selenium）。

2）儘量的暴露迴歸程序的錯誤，即例行迴歸測試，測試部門在開發提測後，基於開發的測試單，手工重點測試變動內容，利用自動化有選擇性的覆蓋其餘功能。此處更多的是到了系統測試層面。

3）驗收測試，在發佈前應用自動化的各類手段進行一次基本功能驗收測試，經過率在多少以上才能夠提交發布，並且此處環節還能夠加入非功能測試。

　　因此說，咱們作自動化測試的目標一切都是爲了軟件發佈服務，也能夠理解爲部署軟件生產流水線，在這裏，推薦一本書，《持續交付-發佈可靠軟件的系統方法》

2、不要過後去計算人工替代率，而是要參考自動化測試有效性

　　以前在年末作自動化測試度量的時候，要求每一個產品線將自動化測試執行次數和時間進行統計，這樣作的目的是爲了統計自動化測試執行時間，而後要求測試人員算出每一個模塊的人工耗時，而後進行換算，獲得自動化替換人工的時間，後來算完後，發現這樣的數據實際上是沒有意義的

　　1）測試的本質是不能夠比較的，一次手工測試執行有可能比自動化測試執行也許是更有意義的。

　　2）大多數的人工耗時都是拍拍腦殼想出來的

　　3）運行只是代表自動化測試被執行，但不能證實此次執行是有效的，只有真正原本須要手工的測試被自動化執行時纔有意義。

　　因此，在度量上，必定要保持維度一致，能夠橫向比對，即不一樣模塊之間進行比對，有效性上能夠從自動化測試模塊的應用場景和執行次數、執行頻率去評估，成本上，便是自動化測試開發和維護成本

3、度量一個自動化測試的可實施性能夠從其可控制性或者可測試性上來考慮

　　有的人說單元作自動化比較好，有人說接口測試作自動化比較好，但奇怪的是也有人說他們作界面自動化比較成功，其實說接口測試和單元測試比較好的人，單元測試每每是開發來定義的，因此開發來控制可測性，接口測試的話，接口協議都是約定好的，因此可控制性和可測性有保證，而界面的話，有些產品的界面可測性控制比較好，例如都有惟一的debug id，或者界面變更性很小，那麼也是考慮能夠用界面自動化的。因此說，咱們在推廣自動化測試過程當中，不是人云亦云，而是要結合當時的環境，從可測性上去考慮自動化測試的開展。

 

4、試點推動自動化測試

　　自動化思路重要，可是作自動化自己也是具備必定機遇性的，其環境相關性很大，因此在開展自動化測試前，必定不要過分自信，鋪天蓋地的推廣，而是要找好試點項目。以前作過一個接口錄製工具給測試人員推廣使用，因爲不是試點分析，每一個組的測試人員拿着這個工具開發了一堆一堆的線性腳本，致使存積了大量的接口線性腳本，而後後來因爲腳本的維護性和不穩定，慢慢的流於形式，甚是惋惜。若是採用試點分析的方式，先在小範圍進行使用，而且跟蹤效果。

　　業內有一個分層測試的理念很好，能夠基於IP和地域選擇性的發佈新產品，根據使用效果，而後再根據狀況逐步推向全國。若是對軟件測試、接口測試、自動化測試、面試經驗交流。感興趣能夠加軟件測試交流：1085991341，還會有同行一塊兒技術交流。

5、自動化測試框架的重要做用之一是爲了職責分層

　　所謂軟件框架功能，我以爲很重要的一點是可以將每一層次的責任細分出來，數據驅動框架就是將數據單獨抽離，讓測試人員能更有效的管理數據，例如：能夠構造重複的、組合的、隨機的或者大量的數據包；關鍵字測試框架就是將對象封裝、任務封裝、業務組裝分層，這樣，可讓代碼能力稍強的人員面對對象和任務封裝，讓業務能力稍強的測試人員面對業務組裝，這樣能夠經過框架將各我的員的職責細分，作本身所擅長的事。

　　關鍵字框架推薦robot framework，利用其可視化界面ride，其中還有一些拓展包，例如selenium2Lib能夠應用在web測試。

6、能夠的話，讓開發一塊兒參與自動化測試

　　曾幾什麼時候，我基於RFT和QTP都試點推行了公司的界面自動化，可是效果不佳，究其緣由仍是界面的變化太大，加上一些自定義控件或者一些自定義圖片展現的動態搜索沒法查找，只能用存儲對象的方式，後來大力發展接口自動化，將界面自動化先擱置了一段時間，後來開發本身作了一部分自動化，說是效果甚佳，去學習才發現，他們有一些圖形和事件是基於xml配置定義文件描述的，這樣利用JDOM技術，解析出文件，而後根據QTP的腳本編寫規範，生成QTP腳本，而測試動做基本上涵蓋增刪改查。這種狀況是咱們測試以前沒法知道的，由於開發流程緣由，咱們沒法知道開發所採用的開發技術，因此說，我以爲能夠和開發一塊兒來評估自動化測試。

7、自動化測試是能夠成爲一種習慣的，儘早自動化

　　以前，和幾位華爲的開發朋友聊天，問他們一個問題：大家自動化怎麼樣，我原來覺得開發是不太瞭解自動化的，沒想到他們給個人答案是，什麼怎麼樣，這是必須作的工做呀。原來他們華爲的持續集成過程，開發本身寫測試腳本作冒煙測試，之前這是華爲的規定，如今是他們開發人員的一種習慣。

　　因此，我以爲，推廣自動化不必定一開始就要大張旗鼓的，也不是所謂的等到一切時機成熟，自動化測試是一種輔助測試的方法，不一樣的狀況能夠採用不一樣的方式，幾行腳本，一個bat部署文件，一個數據統計，也是自動化的一種應用。用另一種說法：無論黑貓、白貓，能抓到耗子的就是好貓。

8、自動化應該當即見效，見效後應該慎重評估

 

　　有時候若是咱們對目的不夠清晰，不能抓好本質問題解決，就很容易走極端，有人說錄製很差，咱們就反對錄製，有時候咱們抓到一個錄製工具就覺得遇到了神器，孰知後面是一個一個的大坑；而我以爲，錄製不是很差，而是如何將它用在合適的地方，錄製的好處是無需編程技能便可快速上，可是他的缺點是相對脆弱，一旦UI或者接口變化測試就會受到影響，分散的腳本不可重用且難以維護，並且系統在測試前必須可用（也就意味着沒法使用A-TDD方法）。所以這種方法並不適合大型自動化測試。而關鍵字驅動，將數據與關鍵字結合來描述如何使用數據執行測試，這種方法是具有數據驅動的優點，同時非編程人員也能創建新類型測試。全部測試由同一個框架來執行，無需不一樣的驅動腳本。然而初始成本很大，可是可使用開源方案，所以很是適合大型項目。因此，咱們剛開始的時候，選擇合適的項目，能夠採用腳本錄製這種方式，讓自動化測試當即見效，小範圍推進項目進度，而後，就嚴格控制，開始設計框架，把握可測性。

9、不要期望用自動化測試平臺一會兒解決全部的問題

　　當年在作自動化測試過程當中，遇到瓶頸，就想固然的認爲要開發業內所說的自動化測試平臺，即先弄出一個線，而後再想辦法去線上發展每一個點，後來歷時幾個月，加班加點的，總算基於STAF開發出了一套分佈式的自動化測試平臺，可是後來用着用着就不了了之了，分析出緣由是問題自己和目的都沒有明確，單純的開發出了一個架子，而後再去找衣服強塞進去是不可行的，架子自己是爲放衣服服務的，因此平臺自己是爲讓自動化更有序的進行而服務的，以後咱們大力發展點，而平臺是等點都知足需求後，開始將點串起來，天然而然的造成了一條線，而後再加以修飾，就成爲了平臺。因此說，不要捨本求末，追求花哨，而要踏踏實實的作好每個點，以需求爲導向，天然而然的才能把架子搭好。

　　在這裏也推薦幾個用來搭建平臺的較好的工具和框架：STAF， Jenkins，selenium grid能夠用來作分佈式測試執行和測試節點管理，sonar能夠用來作質量管理平臺，更多的是面向白盒測試分析。Toast也是一款不錯的自動化測試平臺，我以爲它的理念更多的像項目管理+jenkins。

10、將全部的測試資源都版本控制起來

　　這個很重要，在咱們的自動化建設過程當中，由於咱們是多產品線的，每一個產品線的有些功能模塊是共用的，咱們的方法是將每一個模塊的功能抽象成關鍵字接口，全部產品線共用接口，只是實現上不同，而這種方式前期的問題是版本管理的問題，由於一個產品線開發出一個模塊後，各個產品線開始互相遷移，致使遷移混亂，還有一個問題是產品功能模塊也在不斷的更新，不一樣的產品版本要對應不一樣的測試腳本，因此後來，加入版本管理，而最終的測試腳本版本用V1.0.0進行跟蹤，第一位表示接口版本、第二位表示產品特性，第三位表示當前產品線的腳本維護。

　　版本控制中重要的兩個概念就是分支與合併，隨着開發的版本控制的不斷深刻，測試的版本管理也須要跟上，經常使用的版本控制工具是svn、cvs以及分佈式版本控制git，和基於流的版本控制系統Clearcase，我的以爲，前期能夠用手工的方式定義好版本，等到開發協做強大到必定程度後，能夠採用這些版本控制系統。

11、時刻檢討自動化測試過程

　　自動化測試是一個長期的過程，咱們即要低頭走路，也要不時擡頭看路，也須要不時的休息一下，回顧本身走過的路程，整理以後纔可繼續向前，因此須要咱們每隔一個階段，就要好好檢討自動化測試的開展和推廣過程，你們的時間都是很寶貴的，珍惜本身的時間，更要珍惜你們的時間。

　　總結；由於時間倉促和水平有限，有些經驗和教訓不必定很全面，或者還有朋友在推廣或者平時觀察到有更好的自動化測試實踐經驗和教訓，但願能夠一塊兒總結，總之，我的以爲，學習過程最有效的方式是理論和實踐相結合，知行合一，在實踐中發現問題，而後去推敲理論，解決問題，最終總結從而變成本身的東西。以上內容但願對你有幫助，有被幫助到的朋友歡迎點贊，評論。