大家好，我是Kisel，我的工作是為英雄聯(lián)盟客戶端更新做測(cè)試，構(gòu)建和部署團(tuán)隊(duì)。在這里，我們要談?wù)摰氖琼?xiàng)目的自動(dòng)化測(cè)試。

如果您曾經(jīng)使用過當(dāng)前的聯(lián)盟客戶端(“AIR“客戶端)，您可能已經(jīng)遇到了一些奇怪的錯(cuò)誤。即使那些問題是罕見的，你仍然可能會(huì)想到“wtf Rito，這怎么可能存在，“你這么做是完全有道理的——因?yàn)轶w驗(yàn)不符合我們想提供給玩家的質(zhì)量。之前一篇關(guān)于在客戶端更新架構(gòu)的文章提到了我們?cè)诎l(fā)展原始客戶端時(shí)使用AIR的決定——它支持豐富的多媒體效果，但是不可能在HTML中使用。然而，遺憾的是，AIR客戶端自動(dòng)化測(cè)試覆蓋面有限。開發(fā)和發(fā)布更新是一個(gè)緩慢而危險(xiǎn)的過程，因?yàn)橐胱兏恍﹥?nèi)容就必須要手動(dòng)測(cè)試——這是一個(gè)耗時(shí)和不連貫的進(jìn)程。理想情況下，我們會(huì)讓機(jī)器測(cè)試枯燥的，重復(fù)的東西，讓人類做更有創(chuàng)意的測(cè)試工作(在吉姆最近的文章中有更多的相關(guān)內(nèi)容)。

聯(lián)盟客戶端更新的核心目標(biāo)之一是讓簡(jiǎn)單粗暴的測(cè)試自動(dòng)化，那么我們就可以給玩家提供他們應(yīng)該得到的優(yōu)質(zhì)體驗(yàn)。客戶端更新的架構(gòu)包括一個(gè)基于谷歌瀏覽器的前端和一個(gè)C++的后端，這些為進(jìn)行交流提供了REST api和websockets 。此體系結(jié)構(gòu)為我們提供了兩個(gè)方便的自動(dòng)化接口：對(duì)于前端來說，我們可以使用ChromeDriver，這是行業(yè)標(biāo)準(zhǔn)Selenium WebDriver協(xié)議的具體實(shí)施。對(duì)于后端來說，我們使用開源的HTTP請(qǐng)求和websocket庫(kù)。這些都是地球上最常見的自動(dòng)化接口，所以我們沒有必要實(shí)現(xiàn)自定義的自動(dòng)化測(cè)試驅(qū)動(dòng)程序。我們已經(jīng)實(shí)現(xiàn)了功能測(cè)試和運(yùn)行使用Cucumber.js。

這些都是具有豐富文檔的常見工具，所以，在本文中，我將關(guān)注我們的流程和渠道，而不是我們的工具。我希望這將有助于任何想要接近一個(gè)類似于自動(dòng)化挑戰(zhàn)的人。
?

聯(lián)盟客戶更新驗(yàn)證系統(tǒng)架構(gòu)

文化

成功的測(cè)試自動(dòng)化在很大程度上是一種文化和心理學(xué)。技術(shù)在其中只是起到次要的作用。

無論我們有多少技術(shù)，我們?nèi)匀恍枰膭?lì)正確的人類行為，致使自動(dòng)化測(cè)試成功。每一次測(cè)試失敗，人們必須正視它并判斷這個(gè)失敗是否是正在測(cè)試項(xiàng)目中一個(gè)真正的失敗、還是一個(gè)行為不端的編寫差的測(cè)試，或是某種其他環(huán)境或基礎(chǔ)設(shè)施問題，比如網(wǎng)絡(luò)故障。

傳統(tǒng)的自動(dòng)化測(cè)試策略是先有一個(gè)有質(zhì)量保證的團(tuán)隊(duì)為開發(fā)和運(yùn)行測(cè)試來維護(hù)負(fù)責(zé)。這種方法有一定的優(yōu)點(diǎn)，你最終會(huì)得到完全擁有測(cè)試系統(tǒng)的主題專家。它通常適合長(zhǎng)發(fā)布周期的項(xiàng)目，如果你的團(tuán)隊(duì)一周之內(nèi)對(duì)一個(gè)新的構(gòu)建只測(cè)試一次，那么即時(shí)反饋并不是那么重要。

此外，這對(duì)專業(yè)的測(cè)試工程師有好處，工程師們能花時(shí)間設(shè)計(jì)復(fù)雜的測(cè)試用例，充分鍛煉每個(gè)構(gòu)建。我讓我們的藝術(shù)家來想象這個(gè)過程:
?

然而，這也有明顯的缺點(diǎn)。當(dāng)開發(fā)團(tuán)隊(duì)不運(yùn)行測(cè)試，或者只關(guān)注結(jié)果時(shí)，他們就會(huì)傾向于采用“各管一攤”的心態(tài)。開發(fā)者自己失敗的代碼學(xué)習(xí)反饋循環(huán)往往是緩慢的，這并不是可接受的。聯(lián)盟客戶端更新動(dòng)作極快，從早上到晚上，賣QQ賬號(hào)基本的開發(fā)環(huán)境每15分鐘會(huì)接受一個(gè)新的構(gòu)建。以那樣的速度，即時(shí)反饋是至關(guān)重要的。即使測(cè)試本身迅速執(zhí)行，我們也不能等開發(fā)人員等待測(cè)試工程來解釋結(jié)果。團(tuán)隊(duì)效率是我們的核心目標(biāo)之一，所以傳統(tǒng)的自動(dòng)化測(cè)試就不會(huì)為我們工作。我們的方法是這樣的：

我們的信條是使測(cè)試和自動(dòng)化成為整個(gè)團(tuán)隊(duì)最關(guān)心的問題。每個(gè)開發(fā)人員都有參與其中。我們的標(biāo)準(zhǔn)項(xiàng)目新員工培訓(xùn)過程包括詳細(xì)的如何編寫文檔和運(yùn)行測(cè)試，我們會(huì)讓開發(fā)人員弄清楚，我們期望他們完全擁有自己代碼的單元測(cè)試、功能測(cè)試、性能測(cè)試和負(fù)載測(cè)試。測(cè)試、構(gòu)建和部署團(tuán)隊(duì)專注于建立和維護(hù)測(cè)試工具和基礎(chǔ)設(shè)施，但這個(gè)團(tuán)隊(duì)并不自己編寫測(cè)試——這是個(gè)別特殊團(tuán)隊(duì)的責(zé)任。

我們現(xiàn)在能達(dá)到一個(gè)高度，聯(lián)盟客戶端更新測(cè)試失敗時(shí)團(tuán)隊(duì)能快速反應(yīng)和調(diào)查。然而，很難達(dá)到這一點(diǎn)。學(xué)習(xí)如何應(yīng)對(duì)片狀測(cè)試由始至終都是難題。

原來的工作流程是這樣的：

1、注意到一個(gè)測(cè)試是偶然性失敗；

2、只是偶爾失敗，所以它可能不如其他壞掉的東西緊要，可以忽略它幾個(gè)小時(shí)或幾天；

3、最終開始調(diào)查，如果測(cè)試確實(shí)是錯(cuò)了就檢查修復(fù)。

結(jié)果就是：團(tuán)隊(duì)開始假設(shè)，任何失敗都可能只是一個(gè)片狀測(cè)試，所有的結(jié)果將被忽略。如果團(tuán)隊(duì)在測(cè)試系統(tǒng)時(shí)沒有信心，該系統(tǒng)就是一文不值的。如果你的汽車檢查引擎燈隨機(jī)打開時(shí)，你可能會(huì)開始忽略它。為了防止這種類型的習(xí)慣，我們目前的工作流程是立即調(diào)查失敗的測(cè)試，以確定該測(cè)試已經(jīng)跑偏還是我們發(fā)現(xiàn)一個(gè)合法的bug。

將被破壞的測(cè)試移動(dòng)到我們階段測(cè)試套件，是以盡可能高地保持完整測(cè)試套件的信噪比。為了測(cè)試，階段套件在正常的構(gòu)建渠道之外運(yùn)行。新的或重構(gòu)的測(cè)試被放在某一階段幾天，確保在我們將其放到全套之前它們是健康的，在那里他們可以通知開發(fā)人員失敗和block部署。

我們不斷強(qiáng)化通過面對(duì)面討論的方式、發(fā)布會(huì)議公告的方式、或團(tuán)隊(duì)間郵件的方式來保持我們的測(cè)試和構(gòu)建健康的重要性。關(guān)于bug或測(cè)試的任何討論都是一個(gè)宣傳自動(dòng)化福音的很好的機(jī)會(huì)(禮貌地)。每一個(gè)團(tuán)隊(duì)都會(huì)定期地進(jìn)入“必須停船”的心態(tài)，然后開始不重視測(cè)試的重要性，這是很自然的，有時(shí)會(huì)為測(cè)試要求感到沮喪。當(dāng)然，我們必須小心地找到?jīng)]有提醒和太多提醒之間的適當(dāng)平衡，在這兩種極端的情況下，沒有人能得到消息。當(dāng)有遠(yuǎn)程團(tuán)隊(duì)參與其中時(shí)這可能需要特別注意。

這些文化的態(tài)度并不是放之四海而皆準(zhǔn)的。他們必須仔細(xì)定制以滿足各種項(xiàng)目和涉及的人員。最重要的部分是沒什么是理所當(dāng)然的，不做任何假設(shè)。總有改進(jìn)的余地——我們時(shí)常留意系統(tǒng)是如何順利工作的，并適當(dāng)作出調(diào)整。

總結(jié)

以上是生活随笔為你收集整理的揭秘《英雄联盟》客户端更新运行自动化测试的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。