作者 | 王濤，巨杉數(shù)據(jù)庫(kù)聯(lián)合創(chuàng)始人、CTO

責(zé)編 | 唐小引

封圖 | CSDN 下載自 VCG

剛剛過去的這個(gè)春節(jié)，新型冠狀病毒突如其來(lái)地橫掃大江南北。工廠停工，學(xué)校停課。為了響應(yīng)國(guó)家號(hào)召，許多軟件公司和互聯(lián)網(wǎng)公司也將在較長(zhǎng)一段時(shí)間內(nèi)建議員工采取遠(yuǎn)程辦公的方式，同時(shí)也存在骨干工程師無(wú)法及時(shí)返崗的問題，使得生產(chǎn)力大受影響。

對(duì)于軟件企業(yè)來(lái)說(shuō)，研發(fā)與測(cè)試是兩大核心命脈。研發(fā)團(tuán)隊(duì)保障著產(chǎn)品新功能新特性的及時(shí)發(fā)布，而測(cè)試團(tuán)隊(duì)則如同野馬的韁繩，確保產(chǎn)品不會(huì)由于迭代速度過快、設(shè)計(jì)考慮角度不周，而導(dǎo)致軟件缺陷的產(chǎn)生。巨杉數(shù)據(jù)庫(kù)在經(jīng)過 9 年的自研和技術(shù)創(chuàng)新歷程中，在研發(fā)體系構(gòu)建、自動(dòng)化測(cè)試、團(tuán)隊(duì)線上線下結(jié)合等方面積累了很多經(jīng)驗(yàn)。從 2011 年團(tuán)隊(duì)成立之初開始，我們的整個(gè)技術(shù)研發(fā)體系就以面向流程協(xié)作的方式進(jìn)行構(gòu)建。其核心思想是，任何員工可以在任何地點(diǎn)，只要遵循正確的流程，就可以與整個(gè)團(tuán)隊(duì)有機(jī)地銜接在一起。在這個(gè)非常時(shí)刻，為了幫助在遠(yuǎn)程辦公期間內(nèi)保質(zhì)保量完成新版本的迭代與測(cè)試工作，我們也將自己的一些經(jīng)驗(yàn)分享給大家，也是本文的內(nèi)容：如何在無(wú)人值守的環(huán)境下，完成產(chǎn)品的自動(dòng)化測(cè)試與研發(fā)協(xié)作。

基礎(chǔ)體系

1. 網(wǎng)絡(luò)基礎(chǔ)設(shè)施

我們的整個(gè)開發(fā)環(huán)境分為內(nèi)外網(wǎng)兩大網(wǎng)絡(luò)，其中外部網(wǎng)絡(luò)可以連接到廣域網(wǎng) Internet，而內(nèi)部網(wǎng)絡(luò)則沒有廣域網(wǎng)連接。外網(wǎng)包括辦公室中每個(gè)員工的臺(tái)式機(jī)，以及可供員工進(jìn)行遠(yuǎn)程連接的 VPN 服務(wù)器與防火墻。工程師們無(wú)論使用辦公室的電腦，還是通過配發(fā)的筆記本電腦從遠(yuǎn)程通過 VPN 接入，均連入公司的外網(wǎng)網(wǎng)段。

公司的外網(wǎng)網(wǎng)段與內(nèi)網(wǎng)則只能通過虛擬桌面連接，任何員工的辦公室電腦或通過 VPN 連入的筆記本電腦，均無(wú)法直接訪問內(nèi)網(wǎng)環(huán)境中的開發(fā)與測(cè)試服務(wù)器。通過使用 Remote Desktop 等遠(yuǎn)程連接軟件，我們工程師的電腦連接到虛擬桌面服務(wù)器后，所有的文檔、代碼、測(cè)試用例的編寫均在虛擬桌面服務(wù)器中完成。同時(shí)，虛擬桌面可以直接通過 SSH 連接內(nèi)網(wǎng)的開發(fā)與測(cè)試服務(wù)器，可以進(jìn)行代碼的編譯、提交、測(cè)試等所有操作。

通過這種機(jī)制，任何工程師可以在任何時(shí)間地點(diǎn)，使用任何筆記本或臺(tái)式機(jī)即可接入自己的虛擬桌面，大家所有的文檔、代碼、資料均統(tǒng)一存儲(chǔ)在個(gè)人的虛擬桌面中。例如對(duì)于長(zhǎng)時(shí)間的編譯任務(wù)來(lái)說(shuō)，就算是編譯到一半需要換個(gè)工作環(huán)境，大家只需要合上筆記本電腦，回到家中打開并連上 VPN，就可以看到自己的遠(yuǎn)程桌面上編譯的結(jié)果了。

在我們的內(nèi)部網(wǎng)絡(luò)，則主要分為管理集群、開發(fā)集群、以及測(cè)試集群三大網(wǎng)段。

2. 管理集群

管理集群主要包括 Jira 流程管理、Confluence 內(nèi)容管理、GitLab 代碼管理、以及我們內(nèi)部自研的資源管理等幾大服務(wù)。

其中 Jira 流程管理作為研發(fā)與測(cè)試的主要協(xié)作流程，任何測(cè)試團(tuán)隊(duì)發(fā)現(xiàn)的潛在 bug 會(huì)在內(nèi)部 Jira 上提單，并分配給對(duì)應(yīng)模塊的開發(fā)負(fù)責(zé)人。研發(fā)工程師接收到測(cè)試提交的問題單后，會(huì)進(jìn)行問題重現(xiàn)與編碼修復(fù)。

Jira 流程管理示意

任何代碼的修改需要在研發(fā)內(nèi)部進(jìn)行 Code Review，同時(shí)當(dāng)開發(fā)人員編寫的代碼完全通過測(cè)試后，則進(jìn)行代碼 Merge 操作。不論是 Code Review 還是 Merge，我們均基于 GitLab 進(jìn)行代碼的流程管控。

GitLab 代碼管理

我們?nèi)康恼皆O(shè)計(jì)文檔均在 GitLab 中保存，而研發(fā)與測(cè)試人員自己的一些經(jīng)驗(yàn)分享則會(huì)上傳到 Confluence 內(nèi)容管理系統(tǒng)中，前線實(shí)施工程師與所有的后方研發(fā)測(cè)試人員均可以訪問 Confluence 系統(tǒng)中的文檔。

Confluence 文檔管理

當(dāng)前我們內(nèi)網(wǎng)的服務(wù)器總數(shù)，虛擬機(jī)與物理機(jī)加起來(lái)近千臺(tái)。因此如何協(xié)調(diào)管理分配這些計(jì)算和測(cè)試資源，也是非常復(fù)雜的事情。一些測(cè)試用例可能需要幾十上百臺(tái)服務(wù)器資源，如何在需要時(shí)進(jìn)行分配，在不需要時(shí)釋放這些資源，就是我們內(nèi)部自研的自動(dòng)化資源管理框架所承擔(dān)的任務(wù)。

3. 研發(fā)與測(cè)試集群

而對(duì)于研發(fā)集群來(lái)說(shuō)，主要承擔(dān)的任務(wù)就是代碼編譯與單元測(cè)試。在我們的開發(fā)環(huán)境中，每個(gè)工程師均被分配最少三臺(tái)虛擬機(jī)。每次編譯完成，在正式提交持續(xù)集成測(cè)試之前，每個(gè)工程師必須完整通過自己的單元測(cè)試以及快速標(biāo)準(zhǔn)測(cè)試。

在快速標(biāo)準(zhǔn)測(cè)試中，我們當(dāng)前包含大約 2800 個(gè)測(cè)試用例，完整運(yùn)行一遍大約需要 20 分鐘左右，所有開發(fā)人員在將代碼提交給持續(xù)集成測(cè)試框架之前，必須完成快速標(biāo)準(zhǔn)測(cè)試，已保障代碼最基本的健壯性。

而測(cè)試集群則分為三大部分：持續(xù)集成、性能測(cè)試、以及功能和混沌測(cè)試。

其中，持續(xù)集成 CI 使用 Jenkins 工具，結(jié)合我們自行開發(fā)的遠(yuǎn)程調(diào)度框架，運(yùn)行在大約 300 臺(tái)虛擬機(jī)中，24 小時(shí)不間斷地反復(fù)運(yùn)行近 2 萬(wàn)個(gè)測(cè)試用例。

Jenkins 示意

而性能測(cè)試則是完全基于物理機(jī)，包括多種配置的 x86 服務(wù)器、OpenPower 服務(wù)器、以及國(guó)產(chǎn)化 ARM 服務(wù)器。我們當(dāng)前使用了十余套不同類型的性能測(cè)試框架，包括 benchmarksql、tpccrunner、sysbench 以及一系列其他的標(biāo)準(zhǔn)化測(cè)試框架。每個(gè)重要功能的合入與變更、以及所有的版本發(fā)布之前必須完成性能測(cè)試，并繪出與之前所有版本的性能對(duì)比曲線，已進(jìn)行性能回歸測(cè)試。

功能測(cè)試與混沌測(cè)試使用同一集群。一般來(lái)說(shuō)，功能測(cè)試需要一定的手工操作，主要是用來(lái)模擬一些外部匯報(bào)的問題、以及一些較難使用腳本自動(dòng)化完成的操作。另外，新功能開發(fā)后，測(cè)試團(tuán)隊(duì)在梳理出測(cè)試用例后會(huì)首先在功能測(cè)試區(qū)完成對(duì)應(yīng)測(cè)試，再將其固化為持續(xù)集成腳本進(jìn)行自動(dòng)化測(cè)試。

我們每次版本發(fā)布前會(huì)有 2 周左右的代碼凍結(jié)窗口。在代碼凍結(jié)窗口內(nèi)，除非最高優(yōu)先級(jí)的故障修復(fù)才會(huì)被允許合并入主干代碼庫(kù)。在這個(gè)期間內(nèi)，測(cè)試團(tuán)隊(duì)會(huì)用最嚴(yán)格的的手段，使用 libfiu 結(jié)合混沌測(cè)試的機(jī)制，在整個(gè)集群環(huán)境中隨意注入故障（例如網(wǎng)絡(luò)中斷、丟包、磁盤數(shù)據(jù)損壞、磁盤滿、控制器錯(cuò)誤、服務(wù)器掛起、服務(wù)器掉電、服務(wù)器時(shí)間錯(cuò)亂等），并確保數(shù)據(jù)不會(huì)產(chǎn)生錯(cuò)亂或丟失。

4. 遠(yuǎn)程協(xié)作

如果說(shuō)網(wǎng)絡(luò)設(shè)施是保障無(wú)人值守團(tuán)隊(duì)有效協(xié)作的基礎(chǔ)，遠(yuǎn)程協(xié)作工具與流程則是是否能夠高效進(jìn)行協(xié)作的核心。

我們當(dāng)前的團(tuán)隊(duì)分散在北京、上海、廣州、深圳、成都等幾大城市，團(tuán)隊(duì)之間的溝通非常頻繁，因此早在 2014 年就開始搭建了遠(yuǎn)程協(xié)作通訊機(jī)制。

當(dāng)前我們使用了兩套不同的遠(yuǎn)程會(huì)議系統(tǒng)（小魚易連以及 Maxhub），以避免任何一套失效。其中小魚易連要作為 Presentation 分享以及多人會(huì)議系統(tǒng)，支持超過 20 方同時(shí)在線，對(duì)于駐扎在各個(gè)客戶現(xiàn)場(chǎng)的前線實(shí)施工程師與后方研發(fā)測(cè)試通訊非常有幫助。而 Maxhub 則更多作為技術(shù)討論系統(tǒng)，支持遠(yuǎn)程白板繪圖。工程師可以在電視終端上，通過觸控筆直接繪圖，而遠(yuǎn)程的團(tuán)隊(duì)則可以在他們對(duì)應(yīng)的電視終端上聽到語(yǔ)音，并實(shí)時(shí)看到所繪制的圖像。

遠(yuǎn)程會(huì)議和協(xié)作平臺(tái)

除了正式的視頻會(huì)議與分享之外，由于研發(fā)團(tuán)隊(duì)內(nèi)部虛擬桌面網(wǎng)絡(luò)不直接連接廣域網(wǎng)，因此 IM 工具使用的是不需要外網(wǎng)鏈接的騰訊 RTX；而如果需要與前線實(shí)施團(tuán)隊(duì)交流時(shí)則通過桌面電腦，使用 Skype 作為團(tuán)隊(duì)之間的實(shí)時(shí)溝通工具。

5. 團(tuán)隊(duì)組織

眾所周知，一個(gè)大型項(xiàng)目必須被盡可能切分成小模塊，才能夠有效保障開發(fā)周期與代碼質(zhì)量。幾十人同時(shí)進(jìn)行一個(gè)功能的開發(fā)必然會(huì)導(dǎo)致災(zāi)難性的結(jié)果。

我們的研發(fā)體系按照研發(fā) 測(cè)試進(jìn)行劃分。研發(fā)人員則一方面按各自專長(zhǎng)，以 SQL 引擎、優(yōu)化器、數(shù)據(jù)索引存儲(chǔ)、集群管理、以及事務(wù)管理等模塊，作為領(lǐng)域?qū)＜邑?fù)責(zé)對(duì)應(yīng)模塊問題的解決；同時(shí)也會(huì)根據(jù)新功能開發(fā)任務(wù)劃分為一個(gè)個(gè)虛擬團(tuán)隊(duì)（或者叫做“部落”），每個(gè)虛擬團(tuán)隊(duì)以 2-5 人為主。

一般來(lái)說(shuō)，一個(gè)典型的虛擬團(tuán)隊(duì)包括 2 位開發(fā)人員與 1 位測(cè)試工程師，極端情況下可以包含 3 位開發(fā)人員與 2 位測(cè)試工程師。如果一個(gè)功能模塊需要超過 3 個(gè)工程師完成，則意味著該模塊需要被進(jìn)一步分解為更細(xì)的子任務(wù)。

該測(cè)試人員需要在功能的設(shè)計(jì)之初階段即參與整個(gè)模塊的設(shè)計(jì)討論，并在前期對(duì)功能需求做出深入的了解。與功能設(shè)計(jì)同時(shí)，測(cè)試工程師必須盡早完成測(cè)試用例的設(shè)計(jì)，并在開發(fā)人員正式編碼前通過測(cè)試用例評(píng)審。

測(cè)試用例的開發(fā)與代碼開發(fā)幾乎同時(shí)開始進(jìn)行，理想情況下數(shù)據(jù)庫(kù)程序代碼開發(fā)完畢后測(cè)試用例代碼需要已經(jīng)準(zhǔn)備好，并可以立刻開始進(jìn)行功能性驗(yàn)證。在進(jìn)行功能性驗(yàn)證的同時(shí)，該測(cè)試用例會(huì)被作為新的測(cè)試單元合并入集成測(cè)試框架，確保之后所有新的迭代不會(huì)影響該功能的正常運(yùn)行。

具體來(lái)說(shuō)，在測(cè)試流程方面，所有測(cè)試與開發(fā)人員均需要參與的例會(huì)包括：

• Planning：確定目標(biāo)產(chǎn)品功能 scope，作出工作量預(yù)估與安排，細(xì)化任務(wù)并作出 sizing；

• Implementation：所有用例盡可能在測(cè)試開始前完成。實(shí)踐中，開發(fā)人員階段性完成開發(fā)任務(wù)，測(cè)試也可同步，盡早發(fā)現(xiàn)問題盡早在需要的情況下重新設(shè)計(jì)；

• Retrospection：團(tuán)隊(duì)分析項(xiàng)目成功經(jīng)驗(yàn)及問題和障礙。

每次功能開發(fā)完畢并合入主干后，該虛擬團(tuán)隊(duì)將會(huì)解散，所有成員則會(huì)被分配入其他的項(xiàng)目和模塊中。在緊急情況下，一些骨干工程師可能會(huì)同時(shí)參與多個(gè)虛擬團(tuán)隊(duì)的開發(fā)或測(cè)試工作。

在團(tuán)隊(duì)協(xié)作方面，我們目前已經(jīng)做到了跨地域、跨部門的協(xié)同，目前團(tuán)隊(duì)已經(jīng)在六地跨國(guó)、跨地區(qū)辦公，可以保證工作的高效。

自動(dòng)化測(cè)試機(jī)制

1. 測(cè)試用例規(guī)劃與管理

在測(cè)試的工作中，工具畢竟都只能作為輔助，而真正對(duì)產(chǎn)品質(zhì)量進(jìn)行保障的還是測(cè)試用例的完善程度。對(duì)于數(shù)據(jù)庫(kù)這類緊耦合的基礎(chǔ)軟件來(lái)說(shuō)，各種功能并發(fā)和順序在不同的排列組合下可以說(shuō)是天文數(shù)字般的場(chǎng)景，完全不可能做到 100% 全覆蓋。因此，測(cè)試團(tuán)隊(duì)需要做的，是在有限的測(cè)試用例和測(cè)試時(shí)間內(nèi)，盡可能做到對(duì)程序代碼的全面覆蓋。

測(cè)試團(tuán)隊(duì)需要針對(duì)每個(gè)功能進(jìn)行 story 用例設(shè)計(jì)和實(shí)現(xiàn)，通過用例間的并發(fā)以及用例本身的并發(fā)，以及可靠性自動(dòng)化用例構(gòu)造斷電、斷網(wǎng)、集群中節(jié)點(diǎn)異常、磁盤空間滿等各種隨機(jī)故障來(lái)保障不同場(chǎng)景產(chǎn)品的質(zhì)量。所有自動(dòng)化用例對(duì)應(yīng)的文本用例均使用 TestLink 統(tǒng)一管理，且用例按特性指定責(zé)任人按時(shí)維護(hù)跟蹤。

2. 持續(xù)集成 CI

隨著數(shù)據(jù)庫(kù)系統(tǒng)越來(lái)越復(fù)雜，我們需要覆蓋的測(cè)試場(chǎng)景與用例也越來(lái)越多。到目前為止，我們總共已經(jīng)包含了近 2 萬(wàn)個(gè)不同的測(cè)試用例，單純的自動(dòng)化測(cè)試用例也已經(jīng)超過了 1 萬(wàn)個(gè)，完整運(yùn)行所有的自動(dòng)化測(cè)試用例需要 3-4 小時(shí)，而覆蓋全部自動(dòng)化與手工測(cè)試用例（包括性能測(cè)試與混沌測(cè)試）則需要近 1 周的時(shí)間。

在這么多的測(cè)試用例中，不可能每次代碼提交都要求運(yùn)行一遍全部用例，這樣只會(huì)讓開發(fā)效率變得低下。因此，測(cè)試團(tuán)隊(duì)使用了多級(jí)測(cè)試保障的規(guī)范，將全部測(cè)試用例分為 5 個(gè)級(jí)別：

（1）提交構(gòu)建 基線測(cè)試

該級(jí)別為最低測(cè)試級(jí)別，也叫做快速標(biāo)準(zhǔn)測(cè)試程序，所有研發(fā)人員在提交代碼前必須手工運(yùn)行并通過該測(cè)試，以達(dá)到最基本的穩(wěn)定性需求。

該測(cè)試用例包直接坐落在程序的代碼樹中，開發(fā)人員可以在編譯完成后直接調(diào)用腳本，運(yùn)行該級(jí)別的測(cè)試程序。

快速標(biāo)準(zhǔn)測(cè)試程序大約包含 2800 個(gè)左右的簡(jiǎn)單測(cè)試用例，基本上能夠覆蓋大部分常用的數(shù)據(jù)庫(kù)基本功能。開發(fā)人員每次提交代碼后，測(cè)試框架在后臺(tái)會(huì)同樣運(yùn)行一遍該快速標(biāo)準(zhǔn)測(cè)試程序，如果發(fā)現(xiàn)任何異常則意味著該開發(fā)人員沒有按照要求運(yùn)行相關(guān)測(cè)試用例，會(huì)被記以相應(yīng)的違規(guī)警告。

（2）每日構(gòu)建 集成測(cè)試

該級(jí)別為標(biāo)準(zhǔn)的回歸測(cè)試項(xiàng)目，由我們的持續(xù)集成框架（CI）反復(fù) 24×7 地運(yùn)行。該測(cè)試框架每天夜間 2 點(diǎn)自動(dòng)根據(jù)當(dāng)天最新提交的代碼觸發(fā)全編譯，之后在大約 300 臺(tái)虛擬機(jī)中反復(fù) 24×7 地運(yùn)行近 2 萬(wàn)個(gè)測(cè)試用例。

這些測(cè)試用例遠(yuǎn)比快速標(biāo)準(zhǔn)測(cè)試用例復(fù)雜很多，除了最基本的功能操作以外，包含了大量的并發(fā)與混合操作業(yè)務(wù)邏輯，盡可能模擬真實(shí)客戶現(xiàn)場(chǎng)的用戶操作。實(shí)際上，我們很多集成測(cè)試用例設(shè)計(jì)就是來(lái)自于客戶的真實(shí)操作環(huán)境。

我們的標(biāo)準(zhǔn)回歸測(cè)試完全運(yùn)行一次大約需要 4-5 小時(shí)。基本上早上工程師上班后能夠第一時(shí)間看到夜間編譯版本的運(yùn)行結(jié)果。

（3）七天穩(wěn)定性壓力測(cè)試

回歸測(cè)試只是保障程序不出現(xiàn)破壞已有功能的問題，但是一般來(lái)說(shuō)很難針對(duì)內(nèi)存泄露、性能下降、隨機(jī)故障等問題進(jìn)行檢測(cè)。我們知道，一些隨機(jī)問題并不會(huì)每次運(yùn)行程序都出現(xiàn)，而是運(yùn)行了一段時(shí)間后可能在某種特定場(chǎng)景和條件之下才會(huì)出現(xiàn)。因此，我們的第三級(jí)測(cè)試為七天穩(wěn)定性壓力測(cè)試。

在該測(cè)試下，巨杉數(shù)據(jù)庫(kù)集群會(huì)在多臺(tái)服務(wù)器中同時(shí)運(yùn)行包括 TPCC、sysbench 以及模擬一些已知客戶業(yè)務(wù)場(chǎng)景的壓力測(cè)試程序。該測(cè)試的目的是盡可能將數(shù)據(jù)庫(kù)的增刪改查打滿，同時(shí)在運(yùn)行的過程中不斷檢測(cè)性能是否存在下降、進(jìn)程的內(nèi)存消耗是否不斷增加，最后 168 小時(shí)后會(huì)出具匯總報(bào)告。

（4）多場(chǎng)景性能自動(dòng)對(duì)比測(cè)試

測(cè)試級(jí)別 1-3 均為基準(zhǔn)測(cè)試，測(cè)試結(jié)果為通過或不通過。但是軟件不同版本之間畢竟代碼做過修改，如果一個(gè)不注意很可能造成整體的性能下降。因此，我們的測(cè)試級(jí)別 4 為多場(chǎng)景下的性能自動(dòng)對(duì)比測(cè)試。

在該測(cè)試中，我們會(huì)基于測(cè)試級(jí)別 3 的穩(wěn)定性壓力測(cè)試框架，使用最新版本與之前的次新版本在同樣的硬件環(huán)境下運(yùn)行同樣的邏輯，運(yùn)行 6 小時(shí)對(duì)比兩者的性能。

一般來(lái)說(shuō)，如果發(fā)現(xiàn)最新版本的性能與次新版本存在下降則會(huì)作為故障提交給研發(fā)分析，如果該性能下降達(dá)到 5%以上則會(huì)成為重大故障，極端情況下會(huì)中斷版本的發(fā)布直到問題解決。

（5）故障注入與可靠性測(cè)試

測(cè)試級(jí)別 1-4 均為正常環(huán)境的測(cè)試，也就是所有的軟件硬件環(huán)境均正確配置且不存在突發(fā)故障。但是我們知道，在真實(shí)的生產(chǎn)環(huán)境中，任何軟硬件的故障都有可能發(fā)生，而作為數(shù)據(jù)庫(kù)軟件必須保障在任何故障發(fā)生后數(shù)據(jù)的不錯(cuò)不丟。

在該測(cè)試級(jí)別中會(huì)引入混沌測(cè)試與手工測(cè)試。測(cè)試工程師被要求以任意“有創(chuàng)意”的方式來(lái)“折騰”數(shù)據(jù)庫(kù)，只要發(fā)現(xiàn)最后的數(shù)據(jù)造成了丟失或不一致，都會(huì)被認(rèn)為是產(chǎn)品 bug 并成為重大故障報(bào)告給研發(fā)團(tuán)隊(duì)。

而混沌測(cè)試則更為極端。我們的混沌測(cè)試框架能夠在操作系統(tǒng)和網(wǎng)絡(luò)層面自動(dòng)隨機(jī)注入故障，例如磁盤 I/O 直接返回一個(gè)全空的數(shù)據(jù)頁(yè)或錯(cuò)誤碼，或者網(wǎng)絡(luò)中隨機(jī)丟包或者字節(jié)跳變，用以驗(yàn)證數(shù)據(jù)庫(kù)軟件對(duì)于異常情況的處理能力。

與手工測(cè)試一樣，混沌測(cè)試中產(chǎn)生的數(shù)據(jù)丟失或不一致均會(huì)以重大故障報(bào)告給研發(fā)團(tuán)隊(duì)，極端情況下可能造成版本發(fā)布的推遲。

可以看到，持續(xù)集成體系覆蓋了從代碼的提交、系統(tǒng)集成、長(zhǎng)時(shí)間運(yùn)行、版本間升級(jí)、以及第三方軟硬件故障等場(chǎng)景。其中，除了測(cè)試級(jí)別 5 需要一定程度的手工運(yùn)行外，其余所有測(cè)試場(chǎng)景均可以做到自動(dòng)運(yùn)行、檢測(cè)結(jié)果、生成報(bào)告、并發(fā)出告警郵件。

3. 研發(fā)測(cè)試協(xié)作

一旦發(fā)現(xiàn)問題，測(cè)試團(tuán)隊(duì)需要第一時(shí)間將故障報(bào)告給研發(fā)團(tuán)隊(duì)對(duì)應(yīng)的模塊負(fù)責(zé)人。我們所有的測(cè)試用例均用一個(gè)負(fù)責(zé)人（團(tuán)隊(duì)），不管任何測(cè)試用例失敗均會(huì)向該測(cè)試用例的負(fù)責(zé)人（團(tuán)隊(duì)）自動(dòng)發(fā)送告警郵件，其中包括測(cè)試用例號(hào)以及對(duì)應(yīng)的日志下載路徑。同時(shí)，任何測(cè)試用例失敗后其虛擬機(jī)將會(huì)被凍結(jié)，不會(huì)繼續(xù)運(yùn)行任何其他的測(cè)試用例，直到測(cè)試與研發(fā)人員在該環(huán)境重現(xiàn)問題并解鎖該虛擬機(jī)。

測(cè)試用例負(fù)責(zé)人看到失敗的用例或收到郵件后，會(huì)第一時(shí)間下載分析日志。如果發(fā)現(xiàn)該問題并不是測(cè)試用例本身編寫錯(cuò)誤導(dǎo)致，則會(huì)對(duì)比上一次正常運(yùn)行的日志，并結(jié)合這段時(shí)間內(nèi)所提交的代碼更新進(jìn)行簡(jiǎn)單的問題定位。

當(dāng)故障被限定到某個(gè)具體某塊后，測(cè)試用例負(fù)責(zé)人會(huì)通過 Jira 向研發(fā)團(tuán)隊(duì)開一個(gè) ticket，根據(jù)測(cè)試用例重要性的不同標(biāo)記嚴(yán)重級(jí)別。而研發(fā)人員在接收到 ticket 后會(huì)直接登錄到被凍結(jié)的虛擬機(jī)上查看環(huán)境與日志，必要時(shí)可以重新運(yùn)行測(cè)試腳本并打斷點(diǎn)定位問題。

當(dāng)研發(fā)人員修復(fù)問題并進(jìn)行 code review 后，首先會(huì)在開發(fā)環(huán)境本地運(yùn)行快速標(biāo)準(zhǔn)測(cè)試程序，完成后研發(fā)人員會(huì)針對(duì)問題所影響的測(cè)試用例單獨(dú)運(yùn)行，確保該修復(fù)真正解決了測(cè)試用例報(bào)告的問題。

本地測(cè)試流程通過后，開發(fā)人員則可以使用 git 來(lái) commit 并 push 代碼進(jìn)入主干。代碼進(jìn)入主干后會(huì)自動(dòng)觸發(fā)提交構(gòu)建程序，在后臺(tái)虛擬機(jī)針對(duì)該 push 進(jìn)行編譯并在此運(yùn)行快速標(biāo)準(zhǔn)測(cè)試程序，保障代碼的最基本穩(wěn)定性。

到了每天晚上 2 點(diǎn)，CI 系統(tǒng)會(huì)自動(dòng)觸發(fā)最新主干代碼的全編譯，大約 1 小時(shí)編譯時(shí)間后會(huì)在 300 臺(tái)測(cè)試虛擬機(jī)上運(yùn)行 4-5 小時(shí)，在早上 8 點(diǎn)前完成所有測(cè)試用例的運(yùn)行并產(chǎn)生結(jié)果報(bào)告。

工具列表

最后，我們簡(jiǎn)單羅列一下在進(jìn)行自動(dòng)化測(cè)試中所使用到的工具：

• 代碼管理GitLab

• 流程管理Jira

• 文檔管理Confluence

• 服務(wù)器資源管理自建系統(tǒng)

• 研發(fā)內(nèi)部通訊 IMRTX

• 外部通訊 IMSkype

• 持續(xù)集成管理框架Jenkins

• 虛擬桌面Windows 虛擬機(jī) Remote Desktop

• 虛擬機(jī)管理OpenStack VMWare

• 性能測(cè)試LoadRunner JMeter 獨(dú)立測(cè)試工具

• 測(cè)試用例管理Testlink

• 異常注入libfiu

總結(jié)

本文主要分享了我們?cè)谧詣?dòng)化測(cè)試方面的實(shí)踐。作為自研技術(shù)公司，公司成立以來(lái)，我們?cè)谘邪l(fā)體系、自動(dòng)化測(cè)試、多地工作協(xié)調(diào)管理以及用戶支持服務(wù)等方面，搭建了自己的完善體系，積累了豐富的經(jīng)驗(yàn)。因此，我們?cè)诜浅r(shí)期也將會(huì)保證提供給用戶一如既往的服務(wù)和支持，保證我們的技術(shù)研發(fā)進(jìn)度不受影響。

在新型冠狀病毒引發(fā)的肺炎疫情形勢(shì)嚴(yán)峻的今天，我們要求所有的員工盡可能在家辦公保護(hù)好自己，同時(shí)也由于預(yù)先建設(shè)了相對(duì)完善的遠(yuǎn)程協(xié)作與自動(dòng)化測(cè)試的機(jī)制，最大程度上減少了本次疫情對(duì)研發(fā)測(cè)試進(jìn)度的影響。

文章分享的我們的研發(fā)和測(cè)試機(jī)制，希望也可以作為軟件公司的參考，最終幫助到大家解決遠(yuǎn)程辦公協(xié)作、研發(fā)測(cè)試管理的問題。

作者簡(jiǎn)介：

王濤，巨杉數(shù)據(jù)庫(kù)聯(lián)合創(chuàng)始人、CTO，曾是北美 IBM DB2 Lab 核心研發(fā)成員，負(fù)責(zé) DB2 核心引擎研發(fā)，還曾參與世界第一款分布式數(shù)據(jù)庫(kù) DPF 的研發(fā)。有著超過十五年的數(shù)據(jù)庫(kù)核心架構(gòu)設(shè)計(jì)、研發(fā)和創(chuàng)新經(jīng)驗(yàn)。作為巨杉數(shù)據(jù)庫(kù)的總架構(gòu)師和技術(shù)產(chǎn)品負(fù)責(zé)人，自 2011 年以來(lái)，在王濤的領(lǐng)導(dǎo)下，SequoiaDB 的技術(shù)團(tuán)隊(duì)從零開始自研分布式數(shù)據(jù)庫(kù)，目前在在金融行業(yè)交易業(yè)務(wù)、數(shù)據(jù)中臺(tái)等場(chǎng)景得到廣泛應(yīng)用。