oceanbase系統一直在不斷演化，需要在**不斷變化的過程中保持系統的穩定性。因此，合理的質量保證體系關乎系統的成敗。為了保證系統質量，oceanbase做了大量工作，在rd（指開發工程師）開發、qa（指測試工程師）測試、上線試執行各個階段對系統質量把關。
系統bug暴露越早修復代價越低，開發工程師是產生bug的源頭，開發階段主要通過編碼規範、**審核（code revicw）、單元測試保證**質量。另外，系統提測前rd需要主動執行快速測試（quicktest），從而避免返工。
編碼規範規定了函式、變數、型別的命名規則，保證統一的注釋和排版風格。除此之外，為了避免c/c++伺服器端程式設計常見缺陷，oceanbase編碼規範還制定了一些規則，如下所示：
1） 乙個函式只能有乙個人口和乙個出口。不允許在函式中使用goto語句，也不允許函式中途return返回。如下所示，上邊的**中途呼叫了return，在oceanbase編碼規範中是不允許的，可以修改為下邊的方式。這條規定有一定的爭議，很多優秀的開源專案都允許函式中途return。之所以這麼規定，是為了確保函式執行過程中申請的資源被釋放掉。對於分布式儲存系統，**穩定執行的重要性遠遠高於**寫得更漂亮。
alloc_memory()；
if（x > 0）
else
boolean ret = true;
alloc_memory()；
if（x > 0）
else
free_memory()；
return ret；
3）資源管理做到可控。所有的記憶體申請操作都需要經過occanbase全域性記憶體管理器，不允許直接在**中呼叫new/malloc申請記憶體。另外，系統初始化時啟動所有執行緒，執行過程中不允許動態啟動額外的執行緒。
4） 每個可能失敗的函式都必須返回錯誤碼，0表示成功，其他值表示出錯。呼叫者需要仔細、全面地處理呼叫函式返回的每個錯誤碼。
5）所有的指標使用前都必須判空，不允許使用assert語句替代錯誤檢查。這條規定是為了保證程式執行過程**現異常情況時能夠列印錯誤日誌而不是core dump。
6） 不允許使用strcpy/strca/strcpy/sprintf等字串操作函式，而改用對應的限制字元申長度函式：strncpy/strncat/strncpy/snprintf，從而防止字串操作越界。
7）嚴格要求自己，編譯時要開啟gcc所有報警開關，例如：-wall-werror
-wextra-wunused-paramcter-wformat -wconversion -wdeprecated。**提交前需要確保解決所有的報警。
oceanbase開發時要求所有**提交前至少由一人審核，對於關鍵**改動，例如，緊急修復線上bug，需要架構師和各個小組的技術負責人參與。
**審核工作主要包含兩個部分：編碼風格審核，比如是否符合編碼規範，介面設計是否合理，以及實現邏輯審核。其中，實現邏輯審核是難點，要求理解每個**實現細節，並給出建設性意見。每個剛剛加入團隊的新人都會分配乙個師兄，師兄的其中一項職責就是審核新人的**，與新人一起共同對**質量負責。
oceanbase採用開源的reviewboard( 作為**審核系統。
oceanbase 採用googletest以及google mock進行單元測試。單元測試的關鍵點在於系統介面設計時考慮可測性，並提高每個開發人員的單元測試意識。
occanbase單元測試已接入一溝網內部開發的toast平台，每天晚上會自動回歸所有的單元測試用例。toast平台說明文件見： 。
快速測試選取所有測試用例的乙個子集，這個子集中的每個用例執行都很快，從而做到快速回歸。快速測試部署成定時任務，每天自動回歸，rd提交某個功能的**之前也會主動執行快速測試，從而使得主幹**保持基本穩定。
分布式儲存引擎壓力測試工具包含兩個：syschecker 以及mixed_test。在syschecker工具中，多個客戶端併發讀寫一行或者多行資料，並對讀取到的每行資料進行校驗。對於每行資料，其中的每一列都對應乙個輔助列，二者資料之和為0。假設某列資料出錯，syschecker能夠很快檢測出來。
syschecker寫人速度很快，能夠發現分布式儲存引擎中的大部分問題，然面，syshecker只校驗單行資料，不校驗多行資料之間的關係。因此，syschecker無法發現某行資料全部丟失的情況。mixed_test正是用來解決這個問題的，它不僅對每行資料進行校驗，還校驗多行資料之間的關係，能夠檢測出某行資料全部丟失的情況。當然，mixed_test 寫入速度較慢，syschecker 和mixed_test兩個工具總是配合使用。各有優勢。
資料庫功能壓力測試工具包含兩個：sqltest以及bigquery。
oceanbase早期測試資源嚴重不足，因此，要求開發在提測前必須執行一遍壓力測試。然而，這些壓力測試工具的維護非常耗時。2023年開始，rd壓力測試工具逐步廢棄，其中的測試用例逐步融合到qa壓力測試工具中。
軟體質量保證
一 軟體質量的概念 概括的說 軟體質量就是 軟體與明確地和隱含地定義的要求相一致的程度 具體的說 軟體質量是軟體與明確地敘述的功能和效能需求 文件中明確描述的開發標準以及任何專業開發的軟體產品都應該具有的隱含特性相一致的程度。有3個要點 1 軟體需求是度量軟體質量的基礎，與需求不一致就質量不高。2 ...
軟體質量保證 軟體質量
這篇博文將較為全面深入地談談軟體質量保證中關於軟體質量的概念，內容等相關問題。關於質量的定義，不同的領域，不同的人，不同的側重點會得出截然不同的結果。因此關於其質量的基礎概念相對而言較為好理解，但是具體如何去定義實際上確是無關緊要的。不過我們在分析軟體質量的時候，不僅要考慮其面向使用者的需求覆蓋率，...
程式設計規範 質量保證
1 正確性，指程式要實現設計要求的功能。2 穩定性 安全性，指程式穩定 可靠 安全。3 可測試性，指程式要具有良好的可測試性。4 規範 可讀性，指程式書寫風格 命名規則等要符合規範。5 全域性效率，指軟體系統的整體效率。6 區域性效率，指某個模組 子模組 函式的本身效率。7 個人表達方式 個人方便性...