軟件測試人員須要瞭解關於自動化的什麼（譯）

即便你正在使用人工測試，瞭解關於自動化測試進展如何仍然是重要的。無論你的角色是什麼，你的每日工做仍然可能經過使用這篇文章中的至少一些方法被增強。這裏，學習一些普通術語的含義和一些他們可能如何別應用在軟件開發工廠。

近日來我推特了關於軟件測試者須要瞭解自動化世界正在發生了什麼。它獲得了一個漂亮的溫暖的回覆，因此我想我應該要透露個人想法。

這些天來無論你在測試裏的角色是什麼，你的每日工做將可能經過如下方法的至少其中一些被強化。從最低程度我建議瞭解這些術語的含義和他們可能被應用在軟件開發工廠的一個例子。

持續的集成服務

過去十年來在軟件開發領域到來的自動化一個最大的變化是任務自動化。在過去，像構建一個應用的特殊版本，建立文檔，或者更新bug報告的狀態是人爲的。一些團隊甚至貢獻爲了 啓動一個版本而負責的「建立人」責任。像這些人爲的任務（或者是牢牢地綁定給我的或機器）是消耗時間的，而且建立來爲了不瓶頸，好比建立人佔據私人的一天並阻礙新版本被完成。

幸運的是，持續集成（CI）工具經過容許任務被標準化和自動化來挽救。持續集成服務重要地安排和執行任務，一個規則的臺式電腦能作的任務而且讓這些任務在目標機器上執行而不是它本身。回到建立版本的例子，取代讓鮑勃爲手工在他的機器上建立版本負責，一個持續集成服務能被集成去選擇一個目標機器而且在那臺機器上執行版本。不只使鮑勃不須要身體上在那臺版本機器出現，並且能在任意時刻發生版本建立，不論是已安排的或者是爲了響應另外一個動做。

舉個例子，測試者愛麗絲可能想要一個基於最新改變的應用程序版本去看一個程序錯誤是否被修復，並且她能本身發起版本建立。這個不只使資源從作表明性任務中自由運做起來，並且給團隊在我的之外和團隊流程上給予了更多的控制。你也能夠把持續集成任務綁定一塊兒給更深的線程一些任務。學習一個持續集成如何工做是對沒有放不少編程的重點在自動化上很好的引子。

使用持續集成的一個途徑是跑端到端的測試套裝。這些測試常常須要跑數分鐘甚至數小時。我使用過持續集成去自旋向上和自旋向下測試機器而且發起在那些測試機器上的測試。相對於在你本身機器上跑這些測試這是一個很大的幫助，由於它容許一個測試開發者當測試處處跑的時候去作其餘的工做。持續集成的服務器控制着全部這些任務的方方面面。

一些持續集成服務的普通例子是開源工具Jenkins，基於雲的Travis CI，和專屬工具Bamboo，可是這些也是其餘的一些。甚至更低技術是使用一個像克隆或者windows任務分配者的工具爲了在單一機器上去使任務自動化。

CI對於開發軟件愛好以外的編程是獨立的，而且它是一個測試能確實增長價值的一個地方。

現代源碼控制

我首先須要指出我愛源碼。當編寫代碼（或者博客！）時，它是一個頗有幫助而不只是工具。對於一個編碼的測試員，它是一個無需腦力者。甚至即便一個測試不編碼，當測試軟件時以現代方法使用源碼控制多是一個大的利益。

在現代個人意思是什麼？個人意思是使用源碼控制1）集成其餘工具，好比CI服務器或者問題追蹤器，而且2）容許使用好的團隊流程習慣，好比基於幹線的開發。好的源碼控制容許我的去分析變化和更深地挖掘軟件工程正在發生什麼。

一個接近源碼歷史和一些基本培訓的測試能問出像「在應用裏的哪一個文件有最多的開發在它們上面工做？」「哪一個文件有最大的變化？」「哪一個變化的設置包含引發問題的代碼？」等待。這個信息有助於找到步調且暗示一些事件的引起。

用CI集成源代碼甚至能更加有力。在問題跟蹤者的事件能使它們的狀態在由開發引發的變化中更新。測試者能要求必要的需求在輸入的代碼被自動查找出來，好比經過自動測試或者代碼模式需求。建構和部署能被改代碼發起。當源碼控制被很好使用，在這種狀況下有不少種可能，這是一個在持續傳遞後隱含的概念。

舉個例子，我在一個使用基於雲集成服務的開源項目上工做爲了檢查每個由提交者提交的交付。在這個項目裏，持續集成運行全部的自動化測試而且檢查全部爲形式和格式增長的代碼。假如一個提交形成錯誤的測試，或者沒有知足設置的風格嚮導，提交失敗了而且暗示了提交者和項目維持者去修改提交。這有助於提供項目歷史裏以統一的風格每個提交而且暗示了提交者在增長或者更新模塊中可能的微小錯誤。

這些目前在源碼控制的熱點是Git，自由和開放代碼的，在它周邊有着健壯的生態系統。這些也是一些其餘的方面，好比Subversion，Mercurial和微軟團隊基金會。

遙測和監控

這是一個我並不熟悉的主題，可是它肯定是測試者們感興趣的。監控是一種方法，今後掛鉤被放在一個應用程序裏去發回關於軟件是如何被使用的信息給軟件創造者。這能包含正被使用的後端/服務器應用程序接口函數，而且在哪一個指令，由被使用的由用戶界面組成的部分和在什麼頻率上，等等。

這個目標不是爲了發送特殊的用戶信息返回給開發團隊，更普通的信息是關於一個應用程序正在被用着的和如何被用的部分。這提供了終端用戶在作什麼的視角，他們實際上如何使用應用程序，而且特定屬性如何被獲得。安蘭培是個微軟測試，曾經簡短討論這酷斃事情的他曾作過的經過遙測和監視的一部分。

相似於最小化資源控制歷史，監視能幫助你找出答案，從簡單的問題中（」上週多少人記錄？」）到更特殊的和可視化的問題（「當特性X被髮布時用戶們如何改變他們的習慣？」）。這些是幫助測試們執行更好的測試策略的種類問題，而且，總的說來，幫助團隊對用戶作更好的選擇。

更多的信息，請檢查AB測試播客頁面和布倫特詹森。一個主流產品如何使用遙測技術，看一看Mozillla如何經過火狐使用監測技術。

也使用Selenium

最後可是固然不是最少，Selenium WebDriver是一個任一工做在網頁應用的測試須要至關熟悉的工具。在這一點上，WebDriver是一個用於自動驅動瀏覽器行爲的標準工具，相似於一我的類用戶如何在瀏覽器中用網站app交互。它有一些語言綁定，和一些主流瀏覽器工做，而且是一款很是好的能被開發第一組件的可擴展性API的例子。簡言之，它是一個優秀的工做。

當被靈活地使用時，WebDriver容許測試和開發去使用戶體驗性測試獲得自動化，這個能夠被放在一個持續性的可傳遞流程。我寫了一個簡單的基於網頁驅動的測試，能夠找到像導航到登陸頁面的連接的事務，而不是尋找用戶名和密碼場合（因爲壞的部署），或者尋找一個不打開的對話當一個控制被點擊成想象的（一個明顯的但嚴重的問題）。這些是很快被找到的事情可是不能被單元測試覆蓋。

WebDriver也能被用在寫自動化的測試，能夠被本地執行去雙重檢查那些不會以非預定的方式打斷重要特性的變化。這些甚至是WebDriver用於擴展功能測試之外的用處。

對於對學習代碼感興趣的測試來講，WebDriver能提供一個好的學習代碼的介紹。自動化測試腳本能是一個容易的方法去熟悉編程而不是深刻挖掘代碼語言鴻溝。它提供足夠的架構去開始而且仍然使得好的測試工做被完成。

大腦有這些概念，增強測試自動化，不敢你在軟件開發中的角色是什麼。