讓我們回到2014年(一個永恒的軟件版本)。那時，手工測試是我們產(chǎn)品全球化(G11n)QE團隊的標準，每年有超過60個產(chǎn)品發(fā)布。作為其中的一部分，該團隊進行了數(shù)十萬次初級和次級測試。

作為一名高級QE經(jīng)理，我一直管理著一個運行大規(guī)模功能UI測試矩陣的全球團隊，涵蓋區(qū)域設置、瀏覽器、訪問者、主機和數(shù)據(jù)庫。每年，測試需求列表(以及測試數(shù)量)都在穩(wěn)步增長。雖然手動測試確實會產(chǎn)生高價值的結(jié)果，但更大的規(guī)模和效率需要在自動化方面進行投資，尤其是考慮到三個月的發(fā)布系列和敏捷版本即將推出。

我們的G11n QE團隊相信自動化測試是一項100%必要的任務。

一旦我們選擇走向自動化，我們就會看到一個岔路口。我們很快意識到有兩種自動化測試的方法:UI(記錄回放工具)或API。該團隊的三名專家為軟件平臺提供了實用分析，并比較了每種方法的優(yōu)缺點(成本和生產(chǎn)時間)。

我們很快意識到有兩種自動化測試的方法:UI或API。

使用API自動化意味著我們將用Java來做這件事。Java有一個陡峭的學習曲線(記住，我們將它與手工測試相比較)。API在發(fā)布周期的早期趨于穩(wěn)定，這將允許我們在發(fā)布時及時編寫自動化測試腳本。因為我們在業(yè)界的成熟度，我們也對Java很滿意，大部分團隊都已經(jīng)懂這門語言了。Java的另一個優(yōu)點是，大多數(shù)內(nèi)部QE團隊使用Java作為他們的庫，所以我們可以很容易地交換工作和代碼審查。最后，用Java比用任何其他語言更容易雇傭更多的熟練工程師。

UI測試意味著我們需要使用Selenium(或者類似的記錄回放工具)進行測試。硒更容易學習和使用。但是，在任何給定的發(fā)布周期中，不斷的UI變化都會給我們帶來很大的壓力，比如我們需要在每次運行之前驗證測試的準確性(甚至使用API來做到這一點)。

當我們環(huán)顧四周，觀察其他事物時，公司在做某件事的時候，我們發(fā)現(xiàn)其他企業(yè)同事也走API路線。這是因為UI自動化通常更關注個人終端用戶軟件場景，或者作為手工回歸測試的補充。對于復雜的后端企業(yè)軟件，似乎最好使用API進行自動化測試。因此，我們決定使用API來自動化測試(在大多數(shù)情況下)。

等等，我們在做什么？！

當我們開始實現(xiàn)新的自動化測試框架時，我們提出了兩條規(guī)則:

捕捉產(chǎn)品功能中新的和倒退的故障；在產(chǎn)品回歸測試之前，使用具有已知錯誤的舊版本來觸發(fā)驗證周期中的失敗。

在多個操作系統(tǒng)語言環(huán)境下的每一次自動化測試之后，必須對單個操作系統(tǒng)語言環(huán)境進行后續(xù)的手動測試，以最大限度地減少遺漏的錯誤。

它是......

隨著咖啡因的苛刻劑量、相關培訓、大量電子郵件、大量笑聲、免費啤酒和大量口頭討論(不一定是這個順序)，測試自動化開始看起來像我們?nèi)鄙俚那髑虬簟?/p>

到2015年，所有安裝和升級測試都將實現(xiàn)自動化。

到2016年，近85%的通用UI測試將實現(xiàn)自動化。

現(xiàn)在，雖然這是一個擴展，但是兩個平行的努力正在進行，這將影響可以自動化的測試的數(shù)量。這項工作是對相關性和優(yōu)先級的測試案例審查。

充滿測試的游泳池

看看我們的很多功能測試(以及它們的結(jié)果)，你很快就會發(fā)現(xiàn)，有些測試與產(chǎn)品的變化無關。我是說，一些測試一直在進行...即使通過多次發(fā)布...多年來。我們運行的成千上萬個測試看起來是以微小的排列方式排列的，每個測試都是以同樣的方式開始的，只有很小的區(qū)別(測試一個特定的功能)。

為了解決這些不必要的測試，每個功能負責人都會檢查近三個月的優(yōu)先級和相關性的測試評估。這個練習將我們的測試池減少了30%。更少的測試池意味著我們有更少的自動化測試。

國際化測試

國際化(i18n)測試是一種不同的野獸。對于i18n關鍵路徑測試，使用產(chǎn)品的API進行高/非ASCII輸入/輸出和非默認的系統(tǒng)路徑測試絕對是最好的起點，因為它加快了我們的測試交付。在這里，通過使用API調(diào)用，我們可以在發(fā)布周期的早期開始，這將允許我們驗證每個功能是否運行在非英語系統(tǒng)區(qū)域。

使用基于API的自動化框架比從UI進行測試要快得多。團隊通過內(nèi)部培訓和高效編碼，快速提高了測試自動化的測試數(shù)量。一旦框架開始運行，我們將添加自動的分支穩(wěn)定性測試和定期的連續(xù)測試。

使用量角器和硒

其中兩個團隊決定推進Selenium的UI測試用例，如預期的那樣，覆蓋終端用戶類型的場景。一位工程師開始使用量角器進行自動化測試。量角器位于Selenium WebDriver上，為AngularJS應用程序定制。然后用Javascript編寫測試用例，在Node.js中運行，用于AngularJS應用，比如Web客戶端。量角器內(nèi)置了對角度JS頁面和動作的支持。例如，特定于角度的定位器使得查詢元素更加容易；它還會自動設置角度頁面對象。

自動鍵盤布局測試

測試鍵盤布局是一項關鍵任務，因此您應該像測試功能一樣測試鍵盤功能。我的意思是，想象一下試圖在虛擬機中輸入一個字母，但是什么也沒有(或者完全不同的東西)？！害怕！

因此，我們測試了全球所有主要語言(目前不支持雙向輸入，但計劃正在進行中)。

2015年出現(xiàn)了鍵盤測試，但是是手動的，不能擴展(注意“胖手指”輸入！)，這需要時間。幸運的是，萬強、劉明和卓振軍非常仔細地研究了鍵盤測試，發(fā)明了自動鍵盤輸入/輸出工具。這個自動化工具可以將鍵盤測試從每季度16天縮短到3天。今年的國際Unicode大會40 # 8也選擇了國際鍵盤處理的工具和測試策略！

我們現(xiàn)在結(jié)束了嗎？！

還沒有。已經(jīng)提出了用于早期UI布局掃描的自動化軟件解決方案。創(chuàng)建默認圖像來跟蹤截斷的UI文本也是如此。由于自動化測試的價值，每天都會發(fā)現(xiàn)更多的用例。

想象力、編碼技巧和時間是極限！