（轉）測試開發之路--聊聊自動化的打開方式

https://testerhome.com/topics/7271

前言

自動化好像是測試行業永恆不變的熱點話題。貌似也是測試行業爭議最大的話題。不知道如今還有多少言論說自動化沒有用的，記得前段時間的時候網上還有很多人在爭論自動化的價值和做用，但其實自動化不只僅是存在測試行業。 如今的運維行業以及最近特別火的devops概念都是深深的依賴着自動化的。 好像咱們也從沒據說人家運維圈子在爭論自動化有沒有用。往近了說咱們公司專門有運維開發來搞運維自動化， 往遠了說google也有SRE團隊大行其道。自動化是人家圈子裏根正苗紅的標配。爲何到了測試圈子裏爭議就這麼大呢？我一直以爲這是個很奇怪的現象。大道理我就不講了，理科男沒那麼多文縐縐的詞彙，我只講講我以爲有價值的自動化是怎麼個打開方式把。
注：測試圈子太大，每一個領域有各自不一樣的狀況，若有不一樣，歡迎探討。

自動化的目的

節省資源。我實在想不出來有什麼目的比這個還更重要的了。我一貫以爲不以節省資源爲目的的自動化都是耍流氓。

先說說UI自動化

誤區一: UI自動化實現很簡單

之因此有這麼一個誤區緣由也很簡單。UI自動化不管是selenium仍是rf。日常用的API確實沒多少，很好學。稍微有代碼基礎的人就能很快上手，而且以爲這真的很簡單。 可是，實則否則。寫個腳本跑起來很簡單。可是按產品業務構建起一個由數百甚至數千個腳本組成的自動化測試項目就徹底不是一回事了。腳本的穩定性，可維護性，可擴展性,業務上的拆分，執行的性能，報表的展現，日誌的展現，異常捕獲與處理，分佈式運行，與數據庫和各類底層存儲介質的通訊等等都是要考慮的。同時你還要考慮自動化最大的敵人--需求變化所帶來的影響。你要從項目之初就設計好自動化項目的架構來針對這個多變性。 這要求測試人員有起碼的代碼設計能力。只惋惜不少人用着Python，用着Java。可我看着都覺得這是在寫shell，寫c。連起碼的封裝都作很差，我實在不以爲這是在用「面向對象的語言」。

誤區二: UI自動化沒用

形成這個誤區的緣由也很簡單。技術和業務拆解能力不足就直接去搞自動化了。因此天然就沒什麼好效果。並且忙於在維護腳本中奔波。而後總結出了一個結論--UI自動化沒有什麼卵用。

正確的打開方式

1. 首先，代碼能力要好，代碼能力要好，代碼能力要好。重要的事情說三遍。好的UI自動化項目依賴於好的設計。好的代碼能力不是說你會使用各類牛逼的技術，框架。而是你能設計好一個項目，該封裝變化的封裝變化，該抽象分層的分層，設計模式該用就用。把腳本層，數據層，基礎框架層，業務層，page層等等剝離清楚。 按業務需求把各模塊分割明白。 這時候要明白，我是寫代碼的。以一個開發的標準要求本身。
2. 挑選最合適的開源框架。別裝逼本身寫，本身寫的確定沒人家開源的作得好。除非你是大神不然別本身寫。但也別一刀不動，要根據本身的需求對開源框架作二次開發。 推薦一個java系的工具鏈。UI工具用selenide，注意不是selenium。report框架allure，斷言框架assert-core和assert-db。基礎測試框架testng或junit。 UI相關的差很少就這些。別再用老舊過期的工具了，還在用原生webdriver是很痛苦的。連自旋等待機制都沒有。
3. 別迷戀關鍵字驅動，錄製回放和各式測試平臺。這些東西的發展就目前來講雖然逼格滿滿，但還沒法作好自動化，它們善於下降學習成本，讓沒有技術能力的人能迅速作到60分，而咱們這裏說的是要作到90分以上。而且腳本數量一上來就是維護噩夢。公司體量沒到必定程度的時候也別去自研測試平臺，測試平臺也不是保姆式的無腦下降學習成本，主要目的還在於標準化，自動化。
4. 要與業務綁定，讓技術人員只寫腳本無論業務測試是大忌。先不說別的，架構都是根據業務拆分設計的，你看哪一個架構師設計的時候不看業務需求直接動手的？退一步講業務不熟練你用例都寫很差。
5. 標準化，咱們並非在一我的在戰鬥。最好要有統一的技術棧，運行環境，代碼風格等等。標準化真的是好處多多。
6. 理性看待UI自動化，合理運用UI自動化。它不是神，有不少東西不適合作UI自動化的別硬去作。也別由於有些東西UI自動化作的很差就否認它。

每一個項目面對的狀況不同，我就不說太多了。介紹下我廠如今的狀況。 6個瀏覽器併發一個小時基本跑完全部UI自動化。以前3個QA3天跑完全部case，如今是7個小時。如今的痛點仍然是運行速度問題。 但願今年能申請到更多的資源。

接口自動化

這個在業界比較火，各大廠測試圈子的寵兒。自從分層測試理念出現之後就開始嶄露頭角。成本低，速度快，效果好，運行也穩定。UI自動化中不少奇形怪狀的坑在接口測試裏是踩不到的。根據金字塔型的測試理念，測試人員大多都更關注這一層。 打開方式上其實與UI自動化並沒有太大的區別，上面說的那些該作的仍是得作。仍是那句話，得有代碼設計能力和業務能力來支撐接口自動化。只不過接口自動化不只僅是http接口自動化，還有各種底層協議通信，例如一些RPC協議的接口。 廣義上來講只要是對外提供服務的都是接口，不只侷限於須要網絡通信的。哪怕是個lib是個jar包，都是能夠作接口測試的。 咱們公司也叫模塊級測試。這時候就是語言相關的東西了，再也不是你想用什麼語言就用什麼語言，是要使用開發的語言去開發的repo裏以單側的形式編寫測試代碼。這時候偏底層的東西多，須要瞭解開發代碼和架構，須要用mock。正確的打開方式參照UI吧，理念上差的不太多。工具仍是推薦java的，rest-assured，其餘的跟UI的工具同樣

環境自動化

這部分也一直是有爭議的。糾結於究竟是QA來仍是運維來負責這部分自動化。各家公司的觀點都不同，以前面試的時候問過不少候選人環境相關的問題，其中比較多的都是說交給運維來作的，他們最多自動化部署一個前端(app,browser)或某一個模塊。不多見候選人是能獨立把整個產品部署起來的，能畫出產品架構圖的就更少了。我比較偏向於公司內部的產品環境由QA維護，我廠也確實是這麼作的。個人理由也很簡單，咱們的產品很偏底層，要測負載均衡，高可用，異常處理等等，常常要增減節點，kill掉各類底層服務。因此必需要對產品架構很瞭解。要清楚各層各模塊是怎麼通信的，都負責什麼任務。出了錯怎麼定位，去哪看日誌，找哪一個開發都要清楚，因此搭建環境的過程是十分有助於以後的測試工做的。同時QA負責環境自動化也是有一些好處的。

1. 首先，QA更瞭解本身對於測試環境的需求，直接本身定製比跨部門協做效率高。
2. 其次，QA是鏈接開發，運維，產品，售前，進場工程等職位的角色。能夠說咱們跟全部部門都緊密的合做着，咱們是比較容易獲取他們對於環境的需求。
3. 最後，我現階段傾向於QA做爲一個接口輸出方，交出去的就是直接可用沒有坑的產品以及部署方案。把運維從這些瑣碎的事情中解放出來。

到底該誰來作不爭論了，各家有各家的狀況。我來介紹一下咱們的打開方式把。

基於docker的解決方案

如今業界要麼用傳統的虛擬機加shell。要不就用當前大火的Docker。 我以前使用前者，如今熱愛後者。下面是我廠的環境部署流程圖。

 

過程說明：

1. 首先讀取用戶配置，啓動N個編譯容器併發編譯全部模塊。
2. 統一發送到彙總容器，由彙總容器打成一個符合部署規範，能夠直接發送給進場同窗的大包。並傳送到FTP服務器上。
3. 根據配置挑選部署鏡像(各版本的centos, ubantu, suse, redhat等)，從FTP上拉取部署包進行部署。若是是線上鏡像，不會部署，而是製做成一個可在線上部署的鏡像。

解釋一下

之因此弄成這樣要解釋一下，這個跟咱們的業務形態耦合的很重。 因爲咱們是TO B的業務，並且大部分狀況是進入到客戶場地部署的。客戶場地會出現各類限制。 例如沒有網絡，沒有root權限，五花八門的操做系統等等。因此就衍生出了部署測試，咱們也稱後端兼容性測試。因此上圖的右邊咱們的部署鏡像有不少個系統版本的。這些是咱們跟運維和進場工程師共同協定的標準鏡像----基本就是一個官方的OS鏡像加少許的工具。同時使用一個普通的沒有任何額外權限的用戶。目的就是測試產品對各類狀況的兼容性。因此才造就了咱們的部署包很大，由於依賴都打在了部署包裏。 咱們部署環境的時候能夠選擇一個鏡像進行部署。

正確的打開方式

1. 標準化，docker很適合作標準化。全部環境都是同樣的，不會出現什麼bug在這個地方能重現，那個地方復現不了的。也能讓開發人員儘早發現部署上的bug，例如本身開發的時候不當心用了root權限，這樣會很快發現這個bug，由於全部環境裏都是沒有root權限的。
2. 並行化，我能夠一我的起N個容器併發編譯全部模塊增長編譯速度，也能夠N我的同時起更多的容器併發的部署不一樣的環境。不會像之前的虛擬機同樣一我的編譯的時候另外一我的就得等着。
3. 定製化，標準化以外咱們還能夠定製化。爲不一樣的角色定製化他們須要的環境。例如產品人員需求穩定可用的環境，咱們給他們作藍綠部署，服務高可用。運維人員需求一個標準鏡像直接在線上部署，咱們就給他作一個鏡像。進場人員需求一個部署包，咱們就在部署環境的過程當中自動的打成一個大包(上圖的彙總容器)放到FTP上，他下載直接帶走。開發人員除了平常部署還須要能隨時搭建一個老版本的產品(TO B業務的特性)來重現並修復一個bug，咱們就對環境部署項目也作多分支策略，保留每一個版本的鏡像。總之咱們能夠針對不一樣的崗位爲他們定製化不一樣的功能。
4. 環境編排，當你的環境到達必定數量之後必然就會面臨一個問題，一臺服務器沒法抗住這麼多容器運行的壓力。因此就會慢慢的變成2臺，3臺甚至更多。 這時候須要考慮不少東西，例如資源分配怎麼搞，怎麼肯定哪些容器部署再哪一個節點上。例如若是一臺節點掛了怎麼辦？難道在它恢復正常以前這個節點上的服務就一直不可用麼，是否是要加入recovery機制等等。因此這時候須要引入環境編排機制。通常無非就是在swarm，mesos，k8s，rancher上選了，通常公司沒那個精力自研。只是用在測試環境上推薦docker 1.12內置的swarm mode， 以前還分別研究了mesos和k8s， 對於QA來講它們都過於複雜了，須要至關大的學習成本。以mesos來講須要各類其餘插件才能正常服務，光是一個服務發現就須要安裝一個mesos dns，高可用得維護ZK等等，就算你什麼都沒要求也得裝個marathon，各類配置文件確實也讓我這個非運維感受比較棘手，想搞好它真的須要投入大量精力。而swarm mode全部的東西都已然內置，使用起來很簡單方便，至於swarm mode的那些使人詬病的缺點，咱們能夠忽略了，這又不是生產環境。 固然了，勸告各位QA同僚。。。能不搞集羣就別搞集羣，能一臺機器扛着就一臺機器扛着。一但涉及到環境編排，那坑就多了。。。。。。 對swarm mode有興趣的同窗請看我以前發的swarm mode的科普貼

持續集成

以上介紹的全部自動化類型都是要加入到持續集成裏的。 我以前寫過一篇文章介紹過持續集成，在那裏我就說過持續集成是個比較難的東西。它是對團隊工程文化的一種考驗。是細節的堆砌。你要把上面所說的全部自動化類型都作好，而後開發人員要寫好單元測試，團隊要設計好的分支模型。具體細節能夠翻我以前的帖子，我就不重複的逼逼叨了。

總結

好了，這就是小弟作過的能拿的出手的自動化了，其餘各種牛逼的東西不提也罷，我都不專業。