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

責(zé)編 | 唐小引

封圖 | CSDN 下載自 VCG

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

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

基礎(chǔ)體系

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

我們的整個開發(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)包括辦公室中每個員工的臺式機(jī)，以及可供員工進(jìn)行遠(yuǎn)程連接的 VPN 服務(wù)器與防火墻。工程師們無論使用辦公室的電腦，還是通過配發(fā)的筆記本電腦從遠(yuǎn)程通過 VPN 接入，均連入公司的外網(wǎng)網(wǎng)段。

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

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

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

2. 管理集群

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

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

Jira 流程管理示意

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

GitLab 代碼管理

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

Confluence 文檔管理

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

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

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

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

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

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

Jenkins 示意

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

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

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

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

如果說網(wǎng)絡(luò)設(shè)施是保障無人值守團(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)程會議系統(tǒng)（小魚易連以及 Maxhub），以避免任何一套失效。其中小魚易連要作為 Presentation 分享以及多人會議系統(tǒng)，支持超過 20 方同時(shí)在線，對于駐扎在各個客戶現(xiàn)場的前線實(shí)施工程師與后方研發(fā)測試通訊非常有幫助。而 Maxhub 則更多作為技術(shù)討論系統(tǒng)，支持遠(yuǎn)程白板繪圖。工程師可以在電視終端上，通過觸控筆直接繪圖，而遠(yuǎn)程的團(tuán)隊(duì)則可以在他們對應(yīng)的電視終端上聽到語音，并實(shí)時(shí)看到所繪制的圖像。

遠(yuǎn)程會議和協(xié)作平臺

除了正式的視頻會議與分享之外，由于研發(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ì)組織

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

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

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

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

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

具體來說，在測試流程方面，所有測試與開發(fā)人員均需要參與的例會包括：

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

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

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

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

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

自動化測試機(jī)制

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

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

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

2. 持續(xù)集成 CI

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

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

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

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

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

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

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

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

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

我們的標(biāo)準(zhǔn)回歸測試完全運(yùn)行一次大約需要 4-5 小時(shí)?；旧显缟瞎こ處熒习嗪竽軌虻谝粫r(shí)間看到夜間編譯版本的運(yùn)行結(jié)果。

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

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

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

（4）多場景性能自動對比測試

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

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

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

（5）故障注入與可靠性測試

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

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

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

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

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

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

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

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

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

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

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

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

工具列表

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

• 代碼管理GitLab

• 流程管理Jira

• 文檔管理Confluence

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

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

• 外部通訊 IMSkype

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

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

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

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

• 測試用例管理Testlink

• 異常注入libfiu

總結(jié)

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

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

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

作者簡介：

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