【巨杉數據庫SequoiaDB】巨杉數據庫無人值守智能自動化測試實踐

剛剛過去的春節，新型冠狀病毒疫情突如其來地橫掃大江南北。爲了響應國家號召，許多軟件公司和互聯網公司也將在較長一段時間內建議員工採起遠程辦公的方式，同時也存在骨幹工程師沒法及時返崗的問題，使得生產力大受影響。

對於軟件企業來講，研發與測試是兩大核心命脈。研發團隊保障着產品新功能新特性的及時發佈，而測試團隊則如同馬的繮繩，確保產品不會因爲迭代速度過快、設計考慮角度不周，而致使軟件缺陷的產生。

巨杉數據庫在9年的自研和技術創新曆程中，在研發體系構建、自動化測試、團隊線上線下結合等方面積累了不少經驗。從2011年團隊成立之初開始，巨杉數據庫的整個技術研發體系就以面向流程協做的方式進行構建。其核心思想是，任何員工能夠在任何地點，只要遵循正確的流程，就能夠與整個團隊有機地銜接在一塊兒。

在這個很是時刻，爲了幫助在遠程辦公期間內保質保量完成新版本的迭代與測試工做，咱們也將咱們本身的一些經驗分享給你們，主要介紹巨杉如何在無人值守的環境下，完成產品的自動化測試與研發協做。

基礎體系

網絡基礎設施

咱們的整個開發環境分爲內外網兩大網絡，其中外部網絡能夠鏈接到廣域網Internet，而內部網絡則沒有廣域網鏈接。外網包括辦公室中每一個員工的臺式機，以及可供員工進行遠程鏈接的***服務器與防火牆。工程師們不管使用辦公室的電腦，仍是經過配發的筆記本電腦從遠程經過***接入，均連入公司的外網網段。

公司的外網網段與內網則只能經過虛擬桌面鏈接，任何員工的辦公室電腦或經過***連入的筆記本電腦，均沒法直接訪問內網環境中的開發與測試服務器。經過使用Remote Desktop等遠程鏈接軟件，咱們工程師的電腦鏈接到虛擬桌面服務器後，全部的文檔、代碼、測試用例的編寫均在虛擬桌面服務器中完成。同時，虛擬桌面能夠直接經過SSH鏈接內網的開發與測試服務器，能夠進行代碼的編譯、提交、測試等全部操做。

 

經過這種機制，任何工程師能夠在任什麼時候間地點，使用任何筆記本或臺式機便可接入本身的虛擬桌面，你們全部的文檔、代碼、資料均統一存儲在我的的虛擬桌面中。例如對於長時間的編譯任務來講，就算是編譯到一半須要換個工做環境，你們只須要合上筆記本電腦，回到家中打開並連上***，就能夠看到本身的遠程桌面上編譯的結果了。

在巨杉的內部網絡，則主要分爲管理集羣、開發集羣、以及測試集羣三大網段。

管理集羣

管理集羣主要包括Jira流程管理、Confluence內容管理、Gitlab代碼管理、以及咱們內部自研的資源管理等幾大服務。

其中Jira流程管理做爲研發與測試的主要協做流程，任何測試團隊發現的潛在bug會在內部Jira上提單，並分配給對應模塊的開發負責人。研發工程師接收到測試提交的問題單後，會進行問題重現與編碼修復。

任何代碼的修改須要在研發內部進行code review，同時當開發人員編寫的代碼徹底經過測試後，則進行代碼merge操做。不管是code review仍是merge，咱們均基於Gitlab進行代碼的流程管控。

 

咱們所有的正式設計文檔均在Gitlab中保存，而研發與測試人員本身的一些經驗分享則會上傳到Confluence內容管理系統中，前線實施工程師與全部的後方研發測試人員都可以訪問Confluence系統中的文檔。

 

當前咱們內網的服務器總數，虛擬機與物理機加起來近千臺。所以如何協調管理分配這些計算和測試資源，也是很是複雜的事情。一些測試用例可能須要幾十上百臺服務器資源，如何在須要時進行分配，在不須要時釋放這些資源，就是咱們內部自研的自動化資源管理框架所承擔的任務。

研發與測試集羣

而對於研發集羣來講，主要承擔的任務就是代碼編譯與單元測試。在咱們的開發環境中，每一個工程師均被分配最少三臺虛擬機。每次編譯完成，在正式提交持續集成測試以前，每一個工程師必須完整經過本身的單元測試以及快速標準測試。

在巨杉的快速標準測試中，當前包含大約2800個測試用例，完整運行一遍大約須要20分鐘左右，全部開發人員在將代碼提交給持續集成測試框架以前，必須完成快速標準測試，已保障代碼最基本的健壯性。

而測試集羣則分爲三大部分：持續集成、性能測試、以及功能和混沌測試。

其中，持續集成CI使用Jenkins工具，結合咱們自行開發的遠程調度框架，運行在大約300臺虛擬機中，24小時不間斷地反覆運行近2萬個測試用例。

 

而性能測試則是徹底基於物理機，包括多種配置的x86服務器、OpenPower服務器、以及國產化ARM服務器。咱們當前使用了十餘套不一樣類型的性能測試框架，包括benchmarksql、tpccrunner、sysbench以及一系列其餘的標準化測試框架。每一個重要功能的合入與變動、以及全部的版本發佈以前必須完成性能測試，並繪出與以前全部版本的性能對比曲線，以進行性能迴歸測試。

功能測試與混沌測試使用同一集羣。通常來講，功能測試須要必定的手工操做，主要是用來模擬一些外部彙報的問題、以及一些較難使用腳本自動化完成的操做。另外，新功能開發後，測試團隊在梳理出測試用例後會首先在功能測試區完成對應測試，再將其固化爲持續集成腳本進行自動化測試。

巨杉數據庫每次版本發佈前會有2周左右的代碼凍結窗口。在代碼凍結窗口內，除非最高優先級的故障修復纔會被容許合併入主幹代碼庫。在這個期間內，測試團隊會用最嚴格的的手段，使用 libfiu 結合混沌測試的機制，在整個集羣環境中隨意注入故障（例如網絡中斷、丟包、磁盤數據損壞、磁盤滿、控制器錯誤、服務器掛起、服務器掉電、服務器時間錯亂等），並確保數據不會產生錯亂或丟失。

遠程協做

若是說網絡設施是保障無人值守團隊有效協做的基礎，遠程協做工具與流程則是是否可以高效進行協做的核心。

巨杉數據庫當前的團隊分散在北京、上海、廣州、深圳、成都等幾大城市，團隊之間的溝通很是頻繁，所以早在2014年就開始搭建了遠程協做通信機制。

當前咱們使用了兩套不一樣的遠程會議系統（小魚易連以及Maxhub），以免任何一套失效。其中小魚易連要做爲Presentation分享以及多人會議系統，支持超過20方同時在線，對於駐紮在各個客戶現場的前線實施工程師與後方研發測試通信很是有幫助。而Maxhub則更多做爲技術討論系統，支持遠程白板繪圖。工程師能夠在電視終端上，經過觸控筆直接繪圖，而遠程的團隊則能夠在他們對應的電視終端上聽到語音，並實時看到所繪製的圖像。

除了正式的視頻會議與分享以外，因爲巨杉的研發團隊內部虛擬桌面網絡不直接鏈接廣域網，所以IM工具使用的是不須要外網連接的RTX；而若是須要與前線實施團隊交流時則經過桌面電腦，使用Skype做爲團隊之間的實時溝通工具。

團隊組織

衆所周知，一個大型項目必須被儘量切分紅小模塊，纔可以有效保障開發週期與代碼質量。幾十人同時進行一個功能的開發必然會致使災難性的結果。

巨杉數據庫的研發體系按照研發+測試進行劃分。研發人員則一方面按各自專長，以SQL引擎、優化器、數據索引存儲、集羣管理、以及事務管理等模塊，做爲領域專家負責對應模塊問題的解決；同時也會根據新功能開發任務劃分爲一個個虛擬團隊（或者叫作「部落」），每一個虛擬團隊以2-5人爲主。

通常來講，一個典型的虛擬團隊包括2位開發人員與1位測試工程師，極端狀況下能夠包含3位開發人員與2位測試工程師。若是一個功能模塊須要超過3個工程師完成，則意味着該模塊須要被進一步分解爲更細的子任務。

該測試人員須要在功能的設計之初階段即參與整個模塊的設計討論，並在前期對功能需求作出深刻的瞭解。與功能設計同時，測試工程師必須儘早完成測試用例的設計，並在開發人員正式編碼前經過測試用例評審。

測試用例的開發與代碼開發幾乎同時開始進行，理想狀況下數據庫程序代碼開發完畢後測試用例代碼須要已經準備好，並能夠馬上開始進行功能性驗證。在進行功能性驗證的同時，該測試用例會被做爲新的測試單元合併入集成測試框架，確保以後全部新的迭代不會影響該功能的正常運行。

具體來講，在測試流程方面，全部測試與開發人員均須要參與的例會包括：

1）Planning：肯定目標產品功能scope，做出工做量預估與安排，細化任務並做出sizing；

2）Implementation：全部用例儘量在測試開始前完成。實踐中，開發人員階段性完成開發任務，測試也可同步，儘早發現問題儘早在須要的狀況下從新設計；

3）Retrospection：團隊分析項目成功經驗及問題和障礙。

每次功能開發完畢併合入主幹後，該虛擬團隊將會解散，全部成員則會被分配入其餘的項目和模塊中。在緊急狀況下，一些骨幹工程師可能會同時參與多個虛擬團隊的開發或測試工做。

在團隊協做方面，咱們目前已經作到了跨地域、跨部門的協同，目前團隊已經在六地跨國、跨地區辦公，能夠保證工做的高效。

自動化測試用例

測試用例

規劃與管理

在測試的工做中，工具畢竟都只能做爲輔助，而真正對產品質量進行保障的仍是測試用例的完善程度。對於數據庫這類緊耦合的基礎軟件來講，各類功能併發和順序在不一樣的排列組合下能夠說是天文數字般的場景，徹底不可能作到100%全覆蓋。所以，測試團隊須要作的，是在有限的測試用例和測試時間內，儘量作到對程序代碼的全面覆蓋。

測試團隊須要針對每一個功能進行story用例設計和實現，經過用例間的併發以及用例自己的併發，以及可靠性自動化用例構造斷電、斷網、集羣中節點異常、磁盤空間滿等各類隨機故障來保障不一樣場景產品的質量。全部自動化用例對應的文本用例均使用testlink統一管理，且用例按特性指定責任人按時維護跟蹤。

持續集成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須要必定程度的手工運行外，其他全部測試場景都可以作到自動運行、檢測結果、生成報告、併發出告警郵件。

研發測試協做

一旦發現問題，測試團隊須要第一時間將故障報告給研發團隊對應的模塊負責人。咱們全部的測試用例均用一個負責人（團隊），無論任何測試用例失敗均會向該測試用例的負責人（團隊）自動發送告警郵件，其中包括測試用例號以及對應的日誌下載路徑。同時，任何測試用例失敗後其虛擬機將會被凍結，不會繼續運行任何其餘的測試用例，直到測試與研發人員在該環境重現問題並解鎖該虛擬機。

測試用例負責人看到失敗的用例或收到郵件後，會第一時間下載分析日誌。若是發現該問題並非測試用例自己編寫錯誤致使，則會對比上一次正常運行的日誌，並結合這段時間內所提交的代碼更新進行簡單的問題定位。

當故障被限定到某個具體某塊後，測試用例負責人會經過Jira向研發團隊開一個ticket，根據測試用例重要性的不一樣標記嚴重級別。而研發人員在接收到ticket後會直接登陸到被凍結的虛擬機上查看環境與日誌，必要時能夠從新運行測試腳本並打斷點定位問題。

當研發人員修復問題並進行code review後，首先會在開發環境本地運行快速標準測試程序，完成後研發人員會針對問題所影響的測試用例單獨運行，確保該修復真正解決了測試用例報告的問題。

本地測試流程經過後，開發人員則可使用git來commit並push代碼進入主幹。代碼進入主幹後會自動觸發提交構建程序，在後臺虛擬機針對該push進行編譯並在此運行快速標準測試程序，保障代碼的最基本穩定性。

到了天天晚上2點，CI系統會自動觸發最新主幹代碼的全編譯，大約1小時編譯時間後會在300臺測試虛擬機上運行4-5小時，在早上8點前完成全部測試用例的運行併產生結果報告。

工具列表

最後，咱們簡單羅列一下巨杉在進行自動化測試中所使用到的工具：

本文主要分享了巨杉數據庫在自動化測試方面的實踐。做爲自研技術公司，公司成立以來，巨杉在研發體系、自動化測試、多地工做協調管理以及用戶支持服務等方面，搭建了本身的完善體系，積累了豐富的經驗。所以，咱們在很是時期也將會保證提供給用戶一如既往的服務和支持，保證咱們的技術研發進度不受影響。

在新型冠狀病毒引起的肺炎疫情形勢嚴峻的今天，咱們要求全部的員工儘量在家辦公保護好本身，同時也因爲預先建設了相對完善的遠程協做與自動化測試的機制，最大程度上減小了本次疫情對研發測試進度的影響。

文章分享的咱們的研發和測試機制，但願也能夠做爲軟件公司的參考，最終幫助到你們解決遠程辦公協做、研發測試管理的問題。

巨杉數據庫與全體員工，也衷心但願本次疫情獲得快速解決，每一個人和每一個家庭在新的一年幸福安康，平安順利！