小巧、快速、可靠。
任選三項。
任選三項。
這是 SQLite 的品質管理計畫。
品質管理文件往往會擴充成充滿難以理解的術語的活頁夾，沒有人會閱讀。本文件力求打破此慣例，力求簡潔且實用。
本文件的靈感來自 DO-178B。在品質標準中，DO-178B 似乎具有最高的實用性與文書工作比率。即便如此，完整實作 DO-178B 所需的文件數量龐大。SQLite 力求靈活且低儀式感，因此省略了許多必要的 DO-178B 文件。我們只保留那些真正能提升像 SQLite 這樣的開放原始碼軟體專案品質的部分。
此文件旨在向讀者簡要介紹 SQLite 開發團隊的日常運作方式，因為他們持續改善 SQLite 軟體並致力於提升其既有的高可靠性。如果一位有能力的開發人員在細讀此文件後能快速融入開發團隊，則此文件便達到了其目的。
品質管理計畫最初是透過檢閱 DO-178B 第 11 節（第 48 至 56 頁）中的輸出描述，並寫下那些看似與 SQLite 相關的元素而組成。後續將會修訂文字以追蹤 SQLite 品質程序的增強功能。
此部分結合了 DO-178B 中的「軟體認證方面計畫」和「軟體開發計畫」部分。
請參閱 關於 SQLite 以取得 SQLite 軟體的概觀，以及它做了什麼以及它有何不同。
SQLite 使用持續整合程序。軟體持續進行增強和改良。最新的主幹簽入經常在內部用於任務關鍵作業。
沒有預先定義的發布週期。當功能增強和/或錯誤修正達到臨界質量時，就會發布。過去的發布頻率約為每年 5 或 6 次。SQLite 的使用者會根據需要從網站取得新版本。
SQLite 常規維護版本包含功能增強、效能增強和/或對非關鍵問題的修正。主要版本的版本號碼格式為「3.N.0」，其中 N 為某個整數。有關詳細資訊，請參閱版本編號慣例文件。
即將推出的維護版本會在 sqlite-users 和 sqlite-dev 郵件清單上於預期發布前約兩週公告。在發布前約一週，主要開發人員會宣告「停止撰寫」，此後僅允許在主幹上進行錯誤修正簽入。會建立一個新的發布檢查清單，並視需要更新。檢查清單上的項目驗證後，會勾選並變為綠色。當檢查清單上的所有元素都變為綠色時，就會發布。此程序通常需要約一週的時間。
偶爾會發現嚴重的問題，必須針對常規維護版本發布一個小型「修補程式」版本。修補程式與維護版本不同，在於從前一版本變更的程式碼行數較少。我們會盡一切努力避免發布修補程式版本，方法是確保維護版本沒有錯誤。
修補程式版本可能會有或沒有發布檢查清單，視問題而定。這是專案負責人的判斷。
文件系統會自動維護過去版本的年表，以及SQLite 版本的完整清單，其中包含變更摘要。
SQLite 有長遠的願景。規劃時假設 SQLite 將至少使用和支援到 2050 年。所有程式碼都是以有一天會由尚未出生的人員閱讀和維護為前提編寫的。程式碼經過仔細註解，目的是幫助這些未來的開發人員更輕鬆地了解程式碼背後的邏輯和原理。
SQLite 是以可攜式 C 程式碼編寫的。開發工作在 Linux、Mac 和 Windows 工作站上進行。開發人員使用命令列工具，並盡可能迴避整合式開發環境 (IDE)。所有開發人員都預期能流暢使用 unix 命令列。
從正規來源編譯和測試 SQLite 的最低設定如下
Tcl 腳本語言用於協助將正規原始碼轉換成 合併，並管理測試。SQLite 本身並未直接使用 Tcl（除非編譯時選項要求）。SQLite 合併來源的最終使用者不需要 Tcl。
在建置 CLI 時，擁有以下第三方函式庫會很有幫助，但並非必要
SQLite 的完整發行版本測試需要額外的軟體，
預期 SQLite 在所有現代作業系統、所有現代電腦架構和使用所有現代 C 編譯器上都能執行相同，並使用完全相同的 磁碟格式。開發人員會持續在他們能取得的各種平台上測試 SQLite。
SQLite 的測試程序說明於 測試 文件中。測試目標包括
測試程序由發布測試檢查清單控制。檢查清單簡潔地總結了完全驗證 SQLite 所需的所有步驟，並記錄了每個驗證步驟的執行時間和執行者。
發布檢查清單的檢查項目集可能會在每次發布時更新。每個發布檢查清單的內容和完整歷史記錄都會保留以供歷史記錄。
SQLite 原始碼使用Fossil版本控制系統進行管理。Fossil 是專門為支援 SQLite 開發而編寫的。Fossil 提供分散式版本控制和問題追蹤。
所有程式碼都封存在三台獨立的機器中：https://www.sqlite.org、https://www2.sqlite.org、https://www3.sqlite.org。這些機器位於不同的城市（分別為達拉斯、紐瓦克和舊金山），並由兩家不同的託管公司管理（前兩家為Linode，第三家為Digital Ocean）。這種多樣性旨在避免單點故障。
位於達拉斯的主機https://www.sqlite.org/是主伺服器，也是大多數人使用的伺服器。其他兩台被視為備份。
除了官方儲存庫之外，開發人員通常會在個人機器上保留所有軟體的完整複製。網路上還有其他分散的複製。
SQLite 原始碼被分為多個儲存庫，每個儲存庫都在以下的獨立區段中描述。
SQLite 原始碼和 TCL 測試套件 儲存在單一儲存庫中。這個儲存庫是建置 SQLite 的唯一必要條件。原始碼儲存庫是公開的，網路上的匿名過客都可以讀取。
文件來源包含文件文字和圖片，以及建構 SQLite 網站文件的指令碼和 makefile。此文件包含在文件來源中。文件來源儲存在與原始碼不同的獨立儲存庫中。文件來源儲存庫是公開可讀取的。
用於產生文件的 makefile 和指令碼，從文件來源儲存庫中的基準文件收集文字。其他文字從 SQLite 原始碼中的註解中擷取。需求涵蓋範圍資訊從 TCL 測試套件 中的特殊註解擷取，而該測試套件是原始碼儲存庫的一部分，以及從 TH3 測試套件中的註解擷取，而該測試套件在獨立的私人儲存庫中。
SQL 邏輯測試 是一組測試案例，用於顯示 SQLite 與其他 SQL 資料庫引擎的行為相同。這些測試會在獨立的公開程式碼儲存庫中主機。
測試框架 #3 或 TH3 測試套件是一組私有的測試案例，用於測試 SQLite 到 100% MC/DC 在交付配置中。TH3 來源在與其他 SQLite 儲存庫相同的伺服器上提供，但與其他儲存庫不同的是，它們是專有的。TH3 程式碼僅供 SQLite 開發人員存取。
dbsqlfuzz 模組是一個基於 libFuzzer 的 SQLite 模糊測試器。Dbsqlfuzz 同時模糊 SQL 和資料庫檔案。Dbsqlfuzz 使用自訂的變異器。
Dbsqlfuzz 似乎比任何其他可用的模糊測試器都能更有效地找出問題。因此，它保持私有。我們不希望駭客獲得此技術的存取權。
版本測試透過 核對清單 進行。每個核對清單的目前狀態和完整的變更歷程記錄儲存在一個獨立的 SQLite 資料庫檔案中。這些檔案不受版本控制，但會在私人備份伺服器上保留獨立的副本。
執行檢查清單的軟體原始碼儲存在其位於 https://www.sqlite.org/checklistapp 的 Fossil 儲存庫中。
在 SQLite 專案中，「需求」是專案文件。文件文字中的特殊標記識別個別需求。需求編號基於正規化需求文字的加密雜湊，因此不可能在不變更需求編號的情況下變更需求文字。
文件文字（因此也是需求文字）取自上述 SQLite 文件原始碼儲存庫，以及實作中的註解。用於建置文件的 makefile 位於文件原始碼儲存庫中。
建置文件時，會識別並標示需求。文件建置程序也會掃描驗證每個需求的測試案例，並建構矩陣，顯示哪些需求已測試，並識別測試這些需求的特定測試案例。
SQLite 的客觀編碼標準最少
所有其他設計和編碼規則都是主觀的。我們的目標是讓軟體在 2050 年仍然可讀且可維護。為此，我們尋找簡潔但有用的註解（沒有樣板）、仔細選擇的變數名稱，以及仔細說明每個資料結構的意義和每個程式區塊的角色。
所有問題都迅速修正。SQLite 軟體沒有任何懸而未決的問題。
SQLite 所使用的 Fossil 版本控制系統 內建支援追蹤問題單。此內建問題單系統用於追蹤和記錄許多歷史問題。
SQLite 社群論壇 是網路上任何人都可以提問或回報 SQLite 錯誤的地方。第三方發現的錯誤通常會先在論壇上回報。論壇回報的錯誤有時會轉移到問題單，不過最近的做法是直接在論壇上處理錯誤。論壇有出色的全文搜尋功能，會鏡像到多台機器，而且和問題單系統一樣可搜尋且不易消失，因此似乎沒有必要將源自論壇的錯誤回報複製到問題單系統。論壇的公開位置為
與原始程式碼存放庫一樣，論壇也會同步到各種私人機器。請注意，由於 Fossil 的運作方式，「備份」不只是唯讀備份。它們也可以作為資料輸入。輸入的所有內容都會同步到所有存放庫，無論使用哪個存放庫進行插入。