作者 | 王濤，巨杉數據庫聯合創始人、CTO
封圖 | CSDN 下載自 VCG
剛剛過去的這個春節，新型冠狀病毒突如其來地橫掃大江南北。工廠停工，學校停課。為了響應國家號召，許多軟件公司和互聯網公司也將在較長一段時間內建議員工採取遠程辦公的方式，同時也存在骨幹工程師無法及時返崗的問題，使得生產力大受影響。
對於軟件企業來說，研發與測試是兩大核心命脈。研發團隊保障著產品新功能新特性的及時發佈，而測試團隊則如同野馬的韁繩，確保產品不會由於迭代速度過快、設計考慮角度不周，而導致軟件缺陷的產生。巨杉數據庫在經過 9 年的自研和技術創新曆程中，在研發體系構建、自動化測試、團隊線上線下結合等方面積累了很多經驗。從 2011 年團隊成立之初開始，我們的整個技術研發體系就以面向流程協作的方式進行構建。其核心思想是，任何員工可以在任何地點，只要遵循正確的流程，就可以與整個團隊有機地銜接在一起。 在這個非常時刻，為了幫助在遠程辦公期間內保質保量完成新版本的迭代與測試工作，我們也將自己的一些經驗分享給大家，也是本文的內容：如何在無人值守的環境下，完成產品的自動化測試與研發協作。
基礎體系
1. 網絡基礎設施
我們的整個開發環境分為內外網兩大網絡，其中外部網絡可以連接到廣域網 Internet，而內部網絡則沒有廣域網連接。外網包括辦公室中每個員工的臺式機，以及可供員工進行遠程連接的 VPN 服務器與防火牆。工程師們無論使用辦公室的電腦，還是通過配發的筆記本電腦從遠程通過 VPN 接入，均連入公司的外網網段。
公司的外網網段與內網則只能通過虛擬桌面連接，任何員工的辦公室電腦或通過 VPN 連入的筆記本電腦，均無法直接訪問內網環境中的開發與測試服務器。通過使用 Remote Desktop 等遠程連接軟件，我們工程師的電腦連接到虛擬桌面服務器後，所有的文檔、代碼、測試用例的編寫均在虛擬桌面服務器中完成。同時，虛擬桌面可以直接通過 SSH 連接內網的開發與測試服務器，可以進行代碼的編譯、提交、測試等所有操作。
通過這種機制，任何工程師可以在任何時間地點，使用任何筆記本或臺式機即可接入自己的虛擬桌面，大家所有的文檔、代碼、資料均統一存儲在個人的虛擬桌面中。例如對於長時間的編譯任務來說，就算是編譯到一半需要換個工作環境，大家只需要合上筆記本電腦，回到家中打開並連上 VPN，就可以看到自己的遠程桌面上編譯的結果了。
在我們的內部網絡，則主要分為管理集群、開發集群、以及測試集群三大網段。
2. 管理集群
管理集群主要包括 Jira 流程管理、Confluence 內容管理、Gitlab 代碼管理、以及我們內部自研的資源管理等幾大服務。
其中 Jira 流程管理作為研發與測試的主要協作流程，任何測試團隊發現的潛在 bug 會在內部 Jira 上提單，並分配給對應模塊的開發負責人。研發工程師接收到測試提交的問題單後，會進行問題重現與編碼修復。
Jira 流程管理示意
任何代碼的修改需要在研發內部進行 Code Review，同時當開發人員編寫的代碼完全通過測試後，則進行代碼 Merge 操作。不論是 Code Review 還是 Merge，我們均基於 GitLab 進行代碼的流程管控。
GitLab 代碼管理
我們全部的正式設計文檔均在 GitLab 中保存，而研發與測試人員自己的一些經驗分享則會上傳到 Confluence 內容管理系統中，前線實施工程師與所有的後方研發測試人員均可以訪問 Confluence 系統中的文檔。
Confluence 文檔管理
當前我們內網的服務器總數，虛擬機與物理機加起來近千臺。因此如何協調管理分配這些計算和測試資源，也是非常複雜的事情。一些測試用例可能需要幾十上百臺服務器資源，如何在需要時進行分配，在不需要時釋放這些資源，就是我們內部自研的自動化資源管理框架所承擔的任務。
3. 研發與測試集群
而對於研發集群來說，主要承擔的任務就是代碼編譯與單元測試。在我們的開發環境中，每個工程師均被分配最少三臺虛擬機。每次編譯完成，在正式提交持續集成測試之前，每個工程師必須完整通過自己的單元測試以及快速標準測試。
在快速標準測試中，我們當前包含大約 2800 個測試用例，完整運行一遍大約需要 20 分鐘左右，所有開發人員在將代碼提交給持續集成測試框架之前，必須完成快速標準測試，已保障代碼最基本的健壯性。
而測試集群則分為三大部分：持續集成、性能測試、以及功能和混沌測試。
其中，持續集成 CI 使用 Jenkins 工具，結合我們自行開發的遠程調度框架，運行在大約 300 臺虛擬機中，24 小時不間斷地反覆運行近 2 萬個測試用例。
Jenkins 示意
而性能測試則是完全基於物理機，包括多種配置的 x86 服務器、OpenPower 服務器、以及國產化 ARM 服務器。我們當前使用了十餘套不同類型的性能測試框架，包括 benchmarksql、tpccrunner、sysbench 以及一系列其他的標準化測試框架。每個重要功能的合入與變更、以及所有的版本發佈之前必須完成性能測試，並繪出與之前所有版本的性能對比曲線，已進行性能迴歸測試。
功能測試與混沌測試使用同一集群。一般來說，功能測試需要一定的手工操作，主要是用來模擬一些外部彙報的問題、以及一些較難使用腳本自動化完成的操作。另外，新功能開發後，測試團隊在梳理出測試用例後會首先在功能測試區完成對應測試，再將其固化為持續集成腳本進行自動化測試。
我們每次版本發佈前會有 2 周左右的代碼凍結窗口。在代碼凍結窗口內，除非最高優先級的故障修復才會被允許合併入主幹代碼庫。在這個期間內，測試團隊會用最嚴格的的手段，使用 libfiu 結合混沌測試的機制，在整個集群環境中隨意注入故障（例如網絡中斷、丟包、磁盤數據損壞、磁盤滿、控制器錯誤、服務器掛起、服務器掉電、服務器時間錯亂等），並確保數據不會產生錯亂或丟失。
4. 遠程協作
如果說網絡設施是保障無人值守團隊有效協作的基礎，遠程協作工具與流程則是是否能夠高效進行協作的核心。
我們當前的團隊分散在北京、上海、廣州、深圳、成都等幾大城市，團隊之間的溝通非常頻繁，因此早在 2014 年就開始搭建了遠程協作通訊機制。
當前我們使用了兩套不同的遠程會議系統（小魚易連以及 Maxhub），以避免任何一套失效。其中小魚易連要作為 Presentation 分享以及多人會議系統，支持超過 20 方同時在線，對於駐紮在各個客戶現場的前線實施工程師與後方研發測試通訊非常有幫助。而 Maxhub 則更多作為技術討論系統，支持遠程白板繪圖。工程師可以在電視終端上，通過觸控筆直接繪圖，而遠程的團隊則可以在他們對應的電視終端上聽到語音，並實時看到所繪製的圖像。
遠程會議和協作平臺
除了正式的視頻會議與分享之外，由於研發團隊內部虛擬桌面網絡不直接連接廣域網，因此 IM 工具使用的是不需要外網鏈接的騰訊 RTX；而如果需要與前線實施團隊交流時則通過桌面電腦，使用 Skype 作為團隊之間的實時溝通工具。
5. 團隊組織
眾所周知，一個大型項目必須被儘可能切分成小模塊，才能夠有效保障開發週期與代碼質量。幾十人同時進行一個功能的開發必然會導致災難性的結果。
我們的研發體系按照研發+測試進行劃分。研發人員則一方面按各自專長，以 SQL 引擎、優化器、數據索引存儲、集群管理、以及事務管理等模塊，作為領域專家負責對應模塊問題的解決；同時也會根據新功能開發任務劃分為一個個虛擬團隊（或者叫做“部落”），每個虛擬團隊以 2-5 人為主。
一般來說，一個典型的虛擬團隊包括 2 位開發人員與 1 位測試工程師，極端情況下可以包含 3 位開發人員與 2 位測試工程師。如果一個功能模塊需要超過 3 個工程師完成，則意味著該模塊需要被進一步分解為更細的子任務。
該測試人員需要在功能的設計之初階段即參與整個模塊的設計討論，並在前期對功能需求做出深入的瞭解。與功能設計同時，測試工程師必須儘早完成測試用例的設計，並在開發人員正式編碼前通過測試用例評審。
測試用例的開發與代碼開發幾乎同時開始進行，理想情況下數據庫程序代碼開發完畢後測試用例代碼需要已經準備好，並可以立刻開始進行功能性驗證。在進行功能性驗證的同時，該測試用例會被作為新的測試單元合併入集成測試框架，確保之後所有新的迭代不會影響該功能的正常運行。
具體來說，在測試流程方面，所有測試與開發人員均需要參與的例會包括：
Planning：確定目標產品功能 scope，作出工作量預估與安排，細化任務並作出 sizing；
Implementation：所有用例儘可能在測試開始前完成。實踐中，開發人員階段性完成開發任務，測試也可同步，儘早發現問題儘早在需要的情況下重新設計；
Retrospection：團隊分析項目成功經驗及問題和障礙。
每次功能開發完畢併合入主幹後，該虛擬團隊將會解散，所有成員則會被分配入其他的項目和模塊中。在緊急情況下，一些骨幹工程師可能會同時參與多個虛擬團隊的開發或測試工作。
在團隊協作方面，我們目前已經做到了跨地域、跨部門的協同，目前團隊已經在六地跨國、跨地區辦公，可以保證工作的高效。
自動化測試機制
1. 測試用例規劃與管理
在測試的工作中，工具畢竟都只能作為輔助，而真正對產品質量進行保障的還是測試用例的完善程度。對於數據庫這類緊耦合的基礎軟件來說，各種功能併發和順序在不同的排列組合下可以說是天文數字般的場景，完全不可能做到 100% 全覆蓋。因此，測試團隊需要做的，是在有限的測試用例和測試時間內，儘可能做到對程序代碼的全面覆蓋。
測試團隊需要針對每個功能進行 story 用例設計和實現，通過用例間的併發以及用例本身的併發，以及可靠性自動化用例構造斷電、斷網、集群中節點異常、磁盤空間滿等各種隨機故障來保障不同場景產品的質量。所有自動化用例對應的文本用例均使用 TestLink 統一管理，且用例按特性指定責任人按時維護跟蹤。
2. 持續集成 CI
隨著數據庫系統越來越複雜，我們需要覆蓋的測試場景與用例也越來越多。到目前為止，我們總共已經包含了近 2 萬個不同的測試用例，單純的自動化測試用例也已經超過了 1 萬個，完整運行所有的自動化測試用例需要 3-4 小時，而覆蓋全部自動化與手工測試用例（包括性能測試與混沌測試）則需要近 1 周的時間。
在這麼多的測試用例中，不可能每次代碼提交都要求運行一遍全部用例，這樣只會讓開發效率變得低下。因此，測試團隊使用了多級測試保障的規範，將全部測試用例分為 5 個級別：
（1）提交構建+基線測試
該級別為最低測試級別，也叫做快速標準測試程序，所有研發人員在提交代碼前必須手工運行並通過該測試，以達到最基本的穩定性需求。
該測試用例包直接坐落在程序的代碼樹中，開發人員可以在編譯完成後直接調用腳本，運行該級別的測試程序。
快速標準測試程序大約包含 2800 個左右的簡單測試用例，基本上能夠覆蓋大部分常用的數據庫基本功能。開發人員每次提交代碼後，測試框架在後臺會同樣運行一遍該快速標準測試程序，如果發現任何異常則意味著該開發人員沒有按照要求運行相關測試用例，會被記以相應的違規警告。
（2）每日構建+集成測試
該級別為標準的迴歸測試項目，由我們的持續集成框架（CI）反覆 24x7 地運行。該測試框架每天夜間 2 點自動根據當天最新提交的代碼觸發全編譯，之後在大約 300 臺虛擬機中反覆 24x7 地運行近 2 萬個測試用例。
這些測試用例遠比快速標準測試用例複雜很多，除了最基本的功能操作以外，包含了大量的併發與混合操作業務邏輯，儘可能模擬真實客戶現場的用戶操作。實際上，我們很多集成測試用例設計就是來自於客戶的真實操作環境。
我們的標準迴歸測試完全運行一次大約需要 4-5 小時。基本上早上工程師上班後能夠第一時間看到夜間編譯版本的運行結果。
（3）七天穩定性壓力測試
迴歸測試只是保障程序不出現破壞已有功能的問題，但是一般來說很難針對內存洩露、性能下降、隨機故障等問題進行檢測。我們知道，一些隨機問題並不會每次運行程序都出現，而是運行了一段時間後可能在某種特定場景和條件之下才會出現。因此，我們的第三級測試為七天穩定性壓力測試。
在該測試下，巨杉數據庫集群會在多臺服務器中同時運行包括 TPCC、sysbench 以及模擬一些已知客戶業務場景的壓力測試程序。該測試的目的是儘可能將數據庫的增刪改查打滿，同時在運行的過程中不斷檢測性能是否存在下降、進程的內存消耗是否不斷增加，最後 168 小時後會出具彙總報告。
（4）多場景性能自動對比測試
測試級別 1-3 均為基準測試，測試結果為通過或不通過。但是軟件不同版本之間畢竟代碼做過修改，如果一個不注意很可能造成整體的性能下降。因此，我們的測試級別 4 為多場景下的性能自動對比測試。
在該測試中，我們會基於測試級別 3 的穩定性壓力測試框架，使用最新版本與之前的次新版本在同樣的硬件環境下運行同樣的邏輯，運行 6 小時對比兩者的性能。
一般來說，如果發現最新版本的性能與次新版本存在下降則會作為故障提交給研發分析，如果該性能下降達到 5%以上則會成為重大故障，極端情況下會中斷版本的發佈直到問題解決。
（5）故障注入與可靠性測試
測試級別 1-4 均為正常環境的測試，也就是所有的軟件硬件環境均正確配置且不存在突發故障。但是我們知道，在真實的生產環境中，任何軟硬件的故障都有可能發生，而作為數據庫軟件必須保障在任何故障發生後數據的不錯不丟。
在該測試級別中會引入混沌測試與手工測試。測試工程師被要求以任意“有創意”的方式來“折騰”數據庫，只要發現最後的數據造成了丟失或不一致，都會被認為是產品 bug 併成為重大故障報告給研發團隊。
而混沌測試則更為極端。我們的混沌測試框架能夠在操作系統和網絡層面自動隨機注入故障，例如磁盤 I/O 直接返回一個全空的數據頁或錯誤碼，或者網絡中隨機丟包或者字節跳變，用以驗證數據庫軟件對於異常情況的處理能力。
與手工測試一樣，混沌測試中產生的數據丟失或不一致均會以重大故障報告給研發團隊，極端情況下可能造成版本發佈的推遲。
可以看到，持續集成體系覆蓋了從代碼的提交、系統集成、長時間運行、版本間升級、以及第三方軟硬件故障等場景。其中，除了測試級別 5 需要一定程度的手工運行外，其餘所有測試場景均可以做到自動運行、檢測結果、生成報告、併發出告警郵件。
3. 研發測試協作
一旦發現問題，測試團隊需要第一時間將故障報告給研發團隊對應的模塊負責人。我們所有的測試用例均用一個負責人（團隊），不管任何測試用例失敗均會向該測試用例的負責人（團隊）自動發送告警郵件，其中包括測試用例號以及對應的日誌下載路徑。同時，任何測試用例失敗後其虛擬機將會被凍結，不會繼續運行任何其他的測試用例，直到測試與研發人員在該環境重現問題並解鎖該虛擬機。
測試用例負責人看到失敗的用例或收到郵件後，會第一時間下載分析日誌。如果發現該問題並不是測試用例本身編寫錯誤導致，則會對比上一次正常運行的日誌，並結合這段時間內所提交的代碼更新進行簡單的問題定位。
當故障被限定到某個具體某塊後，測試用例負責人會通過 Jira 向研發團隊開一個 ticket，根據測試用例重要性的不同標記嚴重級別。而研發人員在接收到 ticket 後會直接登錄到被凍結的虛擬機上查看環境與日誌，必要時可以重新運行測試腳本並打斷點定位問題。
當研發人員修復問題並進行 code review 後，首先會在開發環境本地運行快速標準測試程序，完成後研發人員會針對問題所影響的測試用例單獨運行，確保該修復真正解決了測試用例報告的問題。
本地測試流程通過後，開發人員則可以使用 git 來 commit 並 push 代碼進入主幹。代碼進入主幹後會自動觸發提交構建程序，在後臺虛擬機針對該 push 進行編譯並在此運行快速標準測試程序，保障代碼的最基本穩定性。
到了每天晚上 2 點，CI 系統會自動觸發最新主幹代碼的全編譯，大約 1 小時編譯時間後會在 300 臺測試虛擬機上運行 4-5 小時，在早上 8 點前完成所有測試用例的運行併產生結果報告。
工具列表
最後，我們簡單羅列一下在進行自動化測試中所使用到的工具：
代碼管理GitLab
流程管理Jira
文檔管理Confluence
服務器資源管理自建系統
研發內部通訊 IMRTX
外部通訊 IMSkype
持續集成管理框架Jenkins
虛擬桌面Windows 虛擬機+Remote Desktop
虛擬機管理OpenStack + VMWare
性能測試LoadRunner + JMeter + 獨立測試工具
測試用例管理Testlink
異常注入libfiu
總結
本文主要分享了我們在自動化測試方面的實踐。作為自研技術公司，公司成立以來，我們在研發體系、自動化測試、多地工作協調管理以及用戶支持服務等方面，搭建了自己的完善體系，積累了豐富的經驗。因此，我們在非常時期也將會保證提供給用戶一如既往的服務和支持，保證我們的技術研發進度不受影響。
在新型冠狀病毒引發的肺炎疫情形勢嚴峻的今天，我們要求所有的員工儘可能在家辦公保護好自己，同時也由於預先建設了相對完善的遠程協作與自動化測試的機制，最大程度上減少了本次疫情對研發測試進度的影響。
文章分享的我們的研發和測試機制，希望也可以作為軟件公司的參考，最終幫助到大家解決遠程辦公協作、研發測試管理的問題。
王濤，巨杉數據庫聯合創始人、CTO，曾是北美 IBM DB2 Lab 核心研發成員，負責 DB2 核心引擎研發，還曾參與世界第一款分佈式數據庫 DPF 的研發。有著超過十五年的數據庫核心架構設計、研發和創新經驗。作為巨杉數據庫的總架構師和技術產品負責人，自 2011 年以來，在王濤的領導下，SequoiaDB 的技術團隊從零開始自研分佈式數據庫，目前在在金融行業交易業務、數據中臺等場景得到廣泛應用。
閱讀更多 CSDN 的文章
