QA應該更新的測試工具

沉默術士發表於2017-07-03
作為一名QA，過去一年是我的軟體質量知識體系和自動化測試知識體系收穫最豐的一年，讓我對於軟體質量和自動化測試有了一個更高層次的認識。所以我寫下了一些自己更新了的知識，以及在和其他公司的QA交談之後發現的一些他們應該更新的知識。藉此希望能對各位看官起到一些提示或者補充作用，當然我也希望各位與我進行聯絡，並共同探討未來的QA到底應該具有什麼樣的能力和知識體系。
　　Web應用程式視覺感知測試
　　視覺感知測試，對於很多QA，包括我在2013以前對於它的認知都是手動測試領域的一個成員。在這個Web系統爆炸的年代，Web UI介面佈局測試，多瀏覽器測試，CSS的refactor等都成為了Web UI測試的痛中之痛，特別是大型Web應用的功能迴歸測試量太大，從而導致很多時候根本無法完成，所以很少會有團隊去做全方位的UI介面佈局迴歸測試，特別是對於使用Agile流程開發的團隊就更加困難。
　　為了緩解這樣的困境，不斷地有人思考怎麼自動化UI測試，我以前的公司就有人嘗試在手機上做自動UI測試，但是最後也沒有什麼成效。最幾年，Web應用程式發展得如火如荼，所以在去年，就有兩個工程師，一個來自於Google，一個來自於ThoughtWorks就在嘗試解決Web應用程式測試上的這個問題。不過他們的思路和以前不一樣，不是想做一個全自動的UI測試框架，而是基於Agile的持續整合和持續部署的概念上，使用半自動的方法來減少UI迴歸測試的時間，從而減少WEB應用程式UI迴歸測試的時間。
　　來自Google的工具是Dpxdt,而來自ThoughtWorks的是Viff. 這兩個工具的基本原理都是類似的，只是使用了不同的語言開發，以及適用的範圍有點區別。
　　Dpxdt是基於Python和PhantomJS開發的一個Web Service系統，其中PhantomJS可以理解為一個沒有UI的瀏覽器。使用者使用其提供的RESTFul API可以十分方便的對比兩個頁面，而且它還提供一個功能十分強大的報表系統。 對於全部是靜態頁面的Web系統來說非常適用，不過對於需要手動導航，比如需要進行輸入，點選等之後才能進行比較的頁面，它現在的版本並不適合。它還提供了一個方式可以把他很方便的部署到GWS上，所以對於國內在GFW下的使用者可以暫時不用考慮這個功能。
　　Viff是基於NodeJS和Selenium開發的一個本地工具。通過編寫JavaScript程式碼來呼叫Selenium API, 並在真實的瀏覽器中進行截圖比較。所以它比較適合動態的Web系統，因為可以編寫程式碼模擬使用者輸入和點選操作。由於它底層使用的是Selenium作為驅動，所以他支援多種瀏覽器，比如IE，Chrome，Firefox等。在最新的Selenium中加入了對Android和iOS的支援，不過現在還不是很穩定，所以Viff還支援Android和iOS上的瀏覽器測試。如果對你來說搭建多瀏覽器環境比較困難，比如需要同時測試IE8，IE9，IE10等，可以選擇BrowserStack。
　　BrowserStack是一個商業產品，他同時通過Web介面和API介面提供多瀏覽器環境給客戶進行Web測試，Viff可以使用期API進行進行多瀏覽器截圖。對於Viff，由於編寫JavaScript程式碼也需要一定的門檻，所以對於沒有程式碼能力的使用者在測試靜態網頁的時候應該選擇Dpxdt，但是如果你有一定的程式碼能力，建議選用Viff。現在Viff正在開發Web Service功能，這樣以後就可以作為一個Service進行部署和使用。
　　不過現在這兩個工具都還不是很成熟，還存在一些Bug，其中Viff還在繼續開發新的功能中，不過基本使用還是可以的。如果在使用這兩個工具的過程中發現任何Bug，請通過Github的Issues跟蹤功能來及時反饋給作者，幫助這兩個開源系統越來越好。我在BQConf上有一個Perceptual Testing的演講,有興趣的可以聽一聽。
　　下圖為實施了視覺感知測試之後對於Web系統迴歸測試的時間示意圖：


　　最近幾年由於iOS和Android裝置越來越普及，移動應用的出現了井噴，大部分都是個人開發者或者小型公司開發的個人應用或者手遊。而且隨著iOS和Android的裝置和SDK的初步成熟，大量的大型商業公司已經或者準備開發移動應用。對於商業移動應用，穩定性非常重要。對於穩定性，測試就非常重要。由於智慧系統越來越複雜和成熟，其上面的應用程式的功能也越來越多，所以自動化測試也就越來越重要。自動iOS在2007年和Android在2008年釋出以來，基於這兩個系統的自動化測試工具就初步發展起來。一般情況下最好使用和應用程式開發使用的語言來寫功能測試，但是由於商業應用的業務需求越來越複雜，所以我傾向於使用基於BDD和SBE的測試工具來做業務測試。比如Calabash就是一個十分好用的基於Cucumber[2]的BDD移動測試工具，它同時支援Android和iOS。其Android的實現是基於robotium，而iOS的實現是基於Frank和UISpec。使用Calabash，測試人員可以使用自然語言來編寫的cucumber測試指令碼，然後通過在PC上執行cucumber指令碼來測試iOS和Android裝置上的應用程式。如果你的公司擁有大量的手動測試人員，並且希望進行移動自動化測試，ThoughtWorks針對這樣的公司開發了一套全新的移動自動化測試工具：Lever，他和Calabash一樣，同時支援Android和iOS。測試人員只需要通過開啟一個網頁，通過選擇移動應用介面上的特定元件和對其的操作來進行組成自動化測試步驟，多個測試步驟可以形成一個測試場景，最終完成各種自動化測試案例並執行。由於Lever不是開源產品，也沒有公開的詳細資料，所以如果你想了解其詳細功能和內容，可以BQConf上的Lever的專題演講。



　　敏捷開發在當今軟體行業裡面扮演著越來越重要的角色，軟體測試也隨著逐步敏捷起來。由於軟體系統，特別是伺服器系統越來越複雜，規模也越來越大。開發人數也達到幾十，甚至幾百人，而且大規模使用第三方的軟體庫，比如Spring，Rails，Hibernate，.Net等。如果使用不當，將會引起很嚴重的效能問題甚至是穩定性問題，所以效能問題在當前的軟體開發中已經越來越明顯了。常規的持續整合驗證了構建是否滿足了功能設計要求，而持續效能測試增加了另外一重驗證標準，程式是否滿足了效能要求，從而是效能問題儘早被發現。持續效能測試主要的優點就是可以在程式碼改變以後可以快速的知道效能變化，比如如果發現效能問題，可以讓提交這個Commit程式設計師去修復這個問題，因為他還能記住這個Commit。如果等到最後釋出之前才發現，那麼這個程式設計師可能已經不記得這個Commit，或者已經離開了公司，有可能導致修復這個問題的難度大大增加。如果這個是一個設計上的錯誤，那麼團隊就可以儘早修復它並避免以後的功能受其影響。


　　比如鐵道部的12306購票系統上線後的第一個春節就遇到了嚴重的效能問題，面對預料中的高訪問量，系統在春運期間經常長時間無法訪問，導致大量使用者無法購票。像這樣嚴重的效能問題是在開發的時候是可以預見的，不過還是出現在產品環境上，由此可見系統在構架上沒有對效能進行有效的設計，在測試上沒有進行有效的效能測試（由於12306產生這個效能問題的原因很複雜，我們這裡不做過多討論，比如各種組織和利益等原因，也不討論怎麼解決。）。當這個效能問題出現的時候，根本無法在短時間內修復，導致瞭如此嚴重的效能問題維持了很長一段時間。在第二年的春運裡面，系統才增加了排隊系統，有效的緩解了效能問題，不過還是會時不時出現無法訪問的情況。由於12306是中國唯一的網上火車票購票系統，就算出現這樣嚴重的效能問題，人們還是隻有繼續使用它。但是如果有多個購票網站，一旦某個出現了效能問題而導致客戶長時間無法訪問，那麼就會帶來大量的客戶流失，造成巨大的損失。因此效能測試對擁有大量使用者軟體系統十分重要，而且需要越早發現效能問題，越早修復越好，因為等到釋出前，就算測試出效能問題，也有可能因為構架問題而無法修復。


　　讓效能測試成為敏捷開發的一等公民對於更好的進行敏捷開發和高質量的持續部署越來越重要。持續效能測試不應該只是說說，特別是對於大型伺服器專案和開發人員眾多的情況下，持續效能測試將成為必不可少的組成部分。持續效能測試應該被看做持續交付的重要步驟，應該和迴歸測試一樣，可以做到更頻繁的高效能持續交付。在2013年5月釋出的ThoughtWorks技術雷達中，讓效能測試成為敏捷開發一等公民已經被列入了ADOPT。對於當今的軟體系統，特別是對於大型伺服器系統，並且它又擁有大量使用者的情況下，持續效能測試將成為一個必不可少的組成部分。讓我們一起去實踐持續效能測試，比如新一代的效能測試工具Gatling 就是一個很好的試驗田，通過它，我們可以很好的實踐對於伺服器系統的持續效能測試。




　　對於當前廣泛使用的Agile的開發模型，Selenium IDE的方法基本不可用，所以需要更新到Selenium WebDriver（Selenium 2.0）。Selenium WebDriver提供了一套支援各種語言的WebDriver API，比如Java，Ruby, Python等。通過這套API使用者可以啟動各種不同的瀏覽器，比如IE，Chrome，Firefox等，並且通過API可以讓瀏覽器訪問不同的網頁，模擬點選和輸入等，獲取網頁中的內容等。使用WebDriver API比老的Selenium IDE帶來了更多的好處，更為適合Agile開發，測試流程更為靈活，維護更為方便，測試流程更為清晰易讀，斷言也更為多樣化等。但是對於測試人員也有一個麻煩，就是至少需要學習一門語言來開發測試案例。驅動Selenium WebDriver的測試可以使用xUnit或者各種BDD框架。



　　由於Web Service的流行以及使用者UI的需求越來越複雜，Web開發已經由MVC的模型發展到MVP和MVVM模型。由此一來前端的邏輯複雜程度和程式碼量（如Javascript等）就會大大增加，由此帶來的問題就是測試量也會大大增加。對於如此大量的Javascript程式碼邏輯層的測試，並不適合使用做UI層功能測試的Selenium。所以我們應該在Javascript層做自動化測試。基於Javascript的自動測試框架很多，由於我傾向於Agile和BDD，所以我傾向於Jasmine，Mocha和Karma。其中Jasmine是一個支援BDD的自動化測試框架，而Macha是新的基於NodeJS開發的支援BDD的自動化測試框架。而Karma是一個自動化測試執行環境，它也是基於NodeJS開發的，Jasmine和Macha都可以在其上面執行。Karma支援多種browser，比如Firefox，Chrome， IE等，而且它使用也比較簡單。



　　雖然Web從上個世紀90年代開始崛起，到現在的空前盛世，但是任然有很多公司仍在開發和維護Windows應用程式。並且Windows應用程式的開發也從C++和MFC時代進入了.Net 和Silverlight時代。但是Windows應用程式的測試一直都是一個不大不小的問題，雖然有很多商用且成熟的自動測試系統，比如Test Complete和QTP等，不過大部分是基於錄製或者Action模型來建立測試，更沒有提供現代流行的指令碼支援，比如QTP使用的是VBScript，更不用說BDD的支援。在Agile的時代，測試工具API化才是一個正確的選擇，如果能支援DSL那就更好了。使用API後，可以獲得良好的可維護性，並且可以更為容易實現CI和CD。幸好有一幫志士開發了一套針對Windows應用程式的免費自動化測試框架White，以及.Net的BDD框架SpecFlow。White封裝了Microsoft`s UIAutomation Library，並提供了一套簡單易用的API。它支援Win32, WinForms, WPF, Silverlight and SWT (Java) platforms的應用程式，並且通過MicroSoft Windows SDK裡面的Inspect工具可以非常容易的找到應用程式中UI控制元件的ID來進行自動化測試。



　　安全，一個即神祕又興奮還憂心的話題。其中安全世界裡面的東西太多太多了，比如伺服器安全，移動安全，網路安全，防毒軟體，入侵檢測等等，不過今天我只想說說Web的安全。Web，在前面我已經用了各種的詞彙來描述它的現狀。正是由於它當前這種現狀，我們不得不特別關注它。所以有一批黑客發起了一個關注Web安全的公益性專案OWASP(Open Web Application Security Project)。在這個專案裡面，有各種關於Web安全的資料，比如文件有《OWASP安全編碼規範快速參考指南》，《OWASP測試指南》 和 《OWASP安全風險Top 10 》2013年版等, 以及各種安全測試和培訓工具，比如ZAP和WebGoat等。其中ZAP是一款簡單易用並且免費的Web安全掃描工具，使用在針對網站滲透測試過程中的檢測網站步驟中，並且很容易的和maven以及CI進行整合。由於它是由java開發的，所以也支援多種作業系統，比如Windows和MacOS等。而WebGoat是一個漏洞百出的J2EE Web應用程式，這些漏洞是故意設計用來演示Web應用程式安全課程的。這個應用程式提供了一個讓使用者可以真實去實踐和學習的平臺，讓使用者可以真實看到漏洞以及嘗試去修復這個漏洞。





最新內容請見作者的GitHub頁：http://qaseven.github.io/


相關文章