過去十年來在軟件開發領域到來的自動化一個******的變化是任務自動化。在過去,像構建一個應用的特殊版本,創建文檔,或者更新bug報告的狀態是人為的。一些團隊甚至貢獻為了 啟動一個版本而負責的"創建人"責任。像這些人為的任務(或者是緊緊地綁定給個人或機器)是消耗時間的,并且創建來為了避免瓶頸,比如創建人占據私人的一天并阻礙新版本被完成。
幸運的是,持續集成(CI)工具通過允許任務被標準化和自動化來挽救。持續集成服務重要地安排和執行任務,一個規則的臺式電腦能做的任務并且讓這些任務在目標機器上執行而不是它自己。回到創建版本的例子,取代讓鮑勃為手工在他的機器上創建版本負責,一個持續集成服務能被集成去選擇一個目標機器并且在那臺機器上執行版本。不僅使鮑勃不需要身體上在那臺版本機器出現,而且能在任意時刻發生版本創建,不管是已安排的或者是為了響應另一個動作。
舉個例子,測試者愛麗絲可能想要一個基于最新改變的應用程序版本去看一個程序錯誤是否被修復,而且她能自己發起版本創建。這個不僅使資源從做代表性任務中自由運作起來,而且給團隊在個人以外和團隊流程上給予了更多的控制。你也可以把持續集成任務綁定一起給更深的線程一些任務。學習一個持續集成如何工作是對沒有放很多編程的重點在自動化上很好的引子。
使用持續集成的一個途徑是跑端到端的測試套裝。這些測試經常需要跑數分鐘甚至數小時。我使用過持續集成去自旋向上和自旋向下測試機器并且發起在那些測試機器上的測試。相對于在你自己機器上跑這些測試這是一個很大的幫助,因為它允許一個測試開發者當測試到處跑的時候去做其他的工作。持續集成的服務器控制著所有這些任務的方方面面。
一些持續集成服務的普通例子是開源工具Jenkins,基于云的Travis CI,和專屬工具Bamboo,但是這些也是其他的一些。甚至更低技術是使用一個像克隆或者windows任務分配者的工具為了在單一機器上去使任務自動化。
CI對于開發軟件愛好之外的編程是獨立的,并且它是一個測試能確實增加價值的一個地方。
現代源碼控制
我首先需要指出我愛源碼。當編寫代碼(或者博客!)時,它是一個很有幫助而不僅是工具。對于一個編碼的測試員,它是一個無需腦力者。甚至即使一個測試不編碼,當測試軟件時以現代方法使用源碼控制可能是一個大的利益。
在現代方法中"我"的意思是什么?"我"的意思是使用源碼控制1)集成其他工具,比如CI服務器或者問題追蹤器,并且2)允許使用好的團隊流程習慣,比如基于干線的開發。好的源碼控制允許個人去分析變化和更深地挖掘軟件工程正在發生什么。
一個接近源碼歷史和一些基本學習的測試能問出像"在應用里的哪個文件有最多的開發在它們上面工作?""哪個文件有******的變化?""哪個變化的設置包含引起問題的代碼?"等待。這個信息有助于找到步調且暗示一些事件的引發。
用CI集成源代碼甚至能更加有力。在問題跟蹤者的事件能使它們的狀態在由開發引起的變化中更新。測試者能要求必要的需求在輸入的代碼被自動查找出來,比如通過自動測試或者代碼模式需求。建構和部署能被改代碼發起。當源碼控制被很好使用,在這種情況下有很多種可能,這是一個在持續傳遞后隱含的概念。
舉個例子,我在一個使用基于云集成服務的開源項目上工作為了檢查每一個由提交者提交的交付。在這個項目里,持續集成運行所有的自動化測試并且檢查所有為形式和格式增加的代碼。假如一個提交造成錯誤的測試,或者沒有滿足設置的風格向導,提交失敗了并且暗示了提交者和項目維持者去修改提交。這有助于提供項目歷史里以統一的風格每一個提交并且暗示了提交者在增加或者更新模塊中可能的微小錯誤。
這些目前在源碼控制的熱點是Git,自由和開放代碼的,在它周邊有著健壯的生態系統。這些也是一些其他的方面,比如Subversion,Mercurial和微軟團隊基金會。
遙測和監控
這是一個我并不熟悉的主題,但是它確定是測試者們感興趣的。監控是一種方法,從此掛鉤被放在一個應用程序里去發回關于軟件是如何被使用的信息給軟件創造者。這能包含正被使用的后端/服務器應用程序接口函數,并且在哪個指令,由被使用的由用戶界面組成的部分和在什么頻率上,等等。
這個目標不是為了發送特殊的用戶信息返回給開發團隊,更普通的信息是關于一個應用程序正在被用著的和如何被用的部分。這提供了終端用戶在做什么的視角,他們實際上如何使用應用程序,并且特定屬性如何被得到。安蘭培是個微軟測試,曾經簡短討論這事情的他曾做過的通過遙測和監視的一部分。
類似于最小化資源控制歷史,監視能幫助你找出答案,從簡單的問題中("上周多少人記錄?")到更特殊的和可視化的問題("當特性X被發布時用戶們如何改變他們的習慣?")。這些是幫助測試們執行更好的測試策略的種類問題,并且,總的說來,幫助團隊對用戶做更好的選擇。
更多的信息,請檢查AB測試播客頁面和布倫特詹森。一個主流產品如何使用遙測技術,看一看Mozillla如何通過火狐使用監測技術。
也使用Selenium
最后一點,但這不意味著這不重要,對于使用web應用程序以及其相似的應用程序的測試者來說,Selenium WebDriver是一個很好的工具。在這一點上,WebDriver是一個用于自動驅動瀏覽器行為的標準工具,類似于一個人類用戶如何在瀏覽器中用網站APP交互。它有一些語言綁定,和一些主流瀏覽器工作,并且是一款非常好的能被開發第一組件的可擴展性API的例子。簡言之,它是一個優秀的工作。
當被靈活地使用時,WebDriver允許測試和開發去使用戶體驗性測試得到自動化,這個可以被放在一個持續性的可傳遞流程。我寫了一個簡單的基于網頁驅動的測試,可以找到像導航到登錄頁面的鏈接的事務,而不是尋找用戶名和密碼場合(由于壞的部署),或者尋找一個不打開的對話當一個控制被點擊成想象的(一個明顯的但嚴重的問題)。這些是很快被找到的事情但是不能被單元測試覆蓋。
WebDriver也能被用在寫自動化的測試,可以被本地執行去雙重檢查那些不會以非預約的方式打斷重要特性的變化。這些甚至是WebDriver用于擴展功能測試以外的用處。
對于對學習代碼感興趣的測試來說,WebDriver能提供一個好的學習代碼的介紹。自動化測試腳本能是一個容易的方法去熟悉編程而不是深入挖掘代碼語言鴻溝。它提供足夠的架構去開始,并且仍然能夠完成一些很好的測試工作。
大腦有這些概念,加強測試自動化,不管你在軟件開發中的角色是什么。


027-87808016
武漢市光谷大道41號現代光谷世貿中心9棟1002室您現在的位置 : 首頁 > 新聞中心
新聞中心
自動化測試工具哪些經常用到?
- 上一條:RTK引領北斗高精度應用走向深入
- 下一條:常用的變形監測數據模型有哪些