資料庫測試 - 快速指南

資料庫測試 – 概述

資料庫測試包括執行資料有效性、資料完整性測試、與資料庫相關的效能檢查以及資料庫中過程、觸發器和函式的測試。

示例

考慮一個捕獲使用者日常交易詳細資訊並將詳細資訊儲存在資料庫中的應用程式。從資料庫測試的角度來看，應執行以下檢查：

• 應用程式中的交易資訊應儲存在資料庫中，並應向用戶提供正確的資訊。

• 資訊載入到資料庫時不應丟失。

• 僅應儲存已完成的交易，所有未完成的操作應由應用程式中止。

• 應維護對資料庫的訪問授權。不應提供對使用者資訊的任何未經批准或未經授權的訪問。

為什麼要執行資料庫測試？

執行資料庫測試有多個原因。需要對資料庫執行資料完整性、驗證和資料一致性檢查，因為後端系統負責儲存資料並被用於多種用途。

以下是資料庫測試的一些常見原因：

• 為了簡化對資料庫後端的呼叫複雜性，開發人員增加了檢視和儲存過程的使用。

• 這些儲存過程和檢視包含關鍵任務，例如插入客戶詳細資訊（姓名、聯絡資訊等）和銷售資料。這些任務需要在多個級別進行測試。

• 對前端執行的黑盒測試很重要，但難以隔離問題。在後端系統進行測試可以提高資料的穩健性。這就是為什麼在後端系統上執行資料庫測試的原因。

• 在資料庫中，資料來自多個應用程式，並且有可能將有害或不正確的資料儲存在資料庫中。因此，需要定期檢查資料庫元件。此外，應定期檢查資料完整性和一致性。

資料庫測試與前端測試

資料庫測試不同於前端 UI 測試。下表突出顯示了主要區別：

資料庫測試 – 型別

根據資料庫的功能和結構，資料庫測試可以分為三類：

• 結構化資料庫測試 - 它處理表和列測試、模式測試、儲存過程和檢視測試、檢查觸發器等。

• 功能測試 - 它涉及從使用者角度檢查資料庫的功能。最常見的功能測試型別是白盒測試和黑盒測試。

• 非功能測試 - 它涉及資料庫中的負載測試、風險測試、壓力測試、最低系統要求，並處理資料庫的效能。

結構化資料庫測試

結構化資料庫測試涉及驗證資料庫中那些未暴露給終端使用者的元件。它涉及儲存庫的所有元件，這些元件用於儲存資料並且不會被終端使用者更改。具有良好 SQL 儲存過程和其他概念命令的資料庫管理員通常執行此測試。

討論了關於結構化測試的常見測試元件：

模式/對映測試

它涉及驗證前端應用程式的物件與資料庫物件對映。

在模式測試中：

• 有時會發生終端使用者應用程式物件未正確對映或與資料庫物件不相容的情況。因此，需要檢查與資料庫關聯的各種模式格式的驗證。

• 需要查詢資料庫中未對映的物件，例如表、檢視、列等。

市場上有各種工具可用於在模式中執行物件對映。

示例 - 在 Microsoft SQL Server 中，測試人員可以編寫簡單的查詢來檢查和驗證資料庫中的模式。

如果測試人員想要更改表結構，他/她應確保所有包含該表的儲存過程都與此更改相容。

儲存過程和檢視測試

在此測試中，測試人員確保儲存過程和檢視的手動執行生成所需的結果。

測試人員確保：

• 如果它使所需的觸發器按預期執行。

• 如果開發團隊透過向過程中的應用程式傳遞輸入涵蓋了所有迴圈和條件。

• 如果資料庫中存在任何未使用的儲存過程。

• 從資料庫中所需的表獲取資料時，是否正確應用了 TRIM 操作。

• 根據被測應用程式的要求驗證儲存過程模組的整體整合。

• 遵循異常和錯誤處理機制。

用於執行儲存過程測試的最常見工具是LINQ、SP 測試工具等。

觸發器測試

在觸發器測試中，測試人員需要確保以下事項：

• 觸發器編碼階段是否遵循編碼約定。

• 檢視執行的觸發器是否滿足所需條件。

• 觸發器執行後是否正確更新了資料。

• 驗證更新/插入/刪除觸發器相對於被測應用程式的功能。

表和列測試

此測試涵蓋的關鍵領域包括：

• 驗證資料庫中的資料型別與前端應用程式中的欄位值。

• 驗證資料庫中資料欄位的長度與應用程式中資料型別的長度。

• 檢查資料庫中是否存在任何來自應用程式欄位物件的未對映表或列。

• 驗證資料庫表和列的命名約定，它們是否符合業務需求。

• 驗證資料庫中的鍵和索引，即表中的主鍵和外部索引鍵是否按要求定義。

• 檢查兩個表中主鍵及其對應外部索引鍵是否相同。

• 檢查鍵的唯一和非空特性是否得到維護。

• 鍵和索引的長度和資料型別是否按要求維護。

資料庫伺服器檢查

資料庫伺服器檢查涉及驗證：

• 資料庫伺服器是否可以處理根據業務需求預期的交易數量。

• 資料庫伺服器的配置詳細資訊是否滿足業務需求。

• 使用者授權是否按要求維護。

功能測試

功能測試是在牢記終端使用者觀點的情況下執行的；終端使用者執行的所需交易和操作是否滿足業務規範。

黑盒測試

黑盒測試涉及驗證資料庫的整合以檢查功能。測試用例很簡單，用於驗證函式的傳入資料和傳出資料。

各種技術，例如因果圖技術、等價劃分和邊界值分析，用於測試資料庫的功能。

其優點如下：

• 它相當簡單，並在開發的早期階段執行。
• 與白盒測試相比，開發測試用例的成本更低。

其缺點如下：

• 無法檢測到一些錯誤
• 不知道需要測試多少程式。

白盒測試

白盒測試處理資料庫的內部結構，並且規格細節對使用者隱藏。它涉及資料庫觸發器和邏輯檢視的測試，這些將支援資料庫重構。

它執行資料庫函式、觸發器、檢視、SQL 查詢等的模組測試。這種型別的測試驗證資料庫表、資料模型、資料庫模式等。它檢查參照完整性規則。它選擇預設表值以檢查資料庫一致性。

執行白盒測試最常用的技術包括條件覆蓋、決策覆蓋、語句覆蓋等。

白盒測試可以檢測編碼錯誤，因此可以消除資料庫中的內部錯誤。白盒測試的侷限性在於它沒有覆蓋SQL語句。

非功能測試

非功能測試包括執行負載測試、壓力測試、檢查滿足業務規範的最低系統要求、風險查詢和資料庫效能最佳化。

負載測試

負載測試的主要目標是檢查大多數正在執行的事務是否會對資料庫的效能產生影響。

在負載測試中，測試人員檢查 -

• 多個遠端使用者執行事務的響應時間。
• 資料庫獲取特定記錄所需的時間。

不同測試型別中負載測試的示例 -

• 重複執行最常用的事務以檢視資料庫系統的效能。
• 從網際網路下載一系列大型檔案。
• 在計算機或伺服器上同時執行多個應用程式。

壓力測試

壓力測試用於識別系統斷點。在此測試中，應用程式以某種方式載入，以便系統在某一點失敗。這一點稱為資料庫系統的斷點。

確定資料庫事務的狀態需要大量工作。需要進行適當的計劃以避免任何基於時間和成本的問題。

最常用的壓力測試工具是LoadRunner和WinRunner。

讓我們以示例說明壓力測試。CRM 應用程式最多可以承受 50000 個併發使用者的負載。假設您將負載增加到 51000 並進行一些事務，例如更新記錄或新增條目。執行事務後，應用程式可以與資料庫系統同步。因此，下一個測試是使用 52000 的使用者負載執行。有時，壓力測試也稱為疲勞測試。

資料庫測試 – 流程

執行資料庫測試的過程類似於其他應用程式的測試。DB 測試可以用下面給出的關鍵流程來描述。

• 設定環境
• 執行測試
• 檢查測試結果
• 根據預期結果進行驗證
• 將發現的結果報告給相關利益相關者

各種 SQL 語句用於開發測試用例。執行 DB 測試最常用的 SQL 語句是Select語句。除此之外，還可以使用各種 DDL、DML、DCL 語句。

示例 - 建立、插入、選擇、更新等。

資料庫測試階段

DB 測試不是一個繁瑣的過程，並且根據測試流程包含資料庫測試生命週期中的各個階段。

資料庫測試的關鍵階段包括 -

• 檢查初始狀態
• 測試執行
• 根據預期結果進行結果驗證
• 生成結果

DB 測試的第一階段是在開始測試過程之前檢查資料庫的初始狀態。然後測試資料庫針對已定義測試用例的行為。根據獲得的結果，自定義測試用例。

為了成功進行資料庫測試，每個測試都會執行以下給出的工作流程。

• 清理資料庫 - 如果資料庫中有可測試資料，則應將其清空。

• 設定Fixture - 這包括將資料輸入資料庫並檢查資料庫的當前狀態。

• 執行測試、驗證結果和生成結果 - 執行測試並驗證輸出。如果輸出符合預期結果，則下一步是根據需要生成結果。否則，重複測試以查詢資料庫中的錯誤。

資料庫測試 – 技術

本章解釋了執行資料庫測試最常用的技術。

資料庫模式測試

如前所述，它涉及測試模式中的每個物件。

驗證資料庫和裝置

• 驗證資料庫名稱
• 驗證資料裝置、日誌裝置和轉儲裝置
• 驗證是否為每個資料庫分配了足夠的空間
• 驗證資料庫選項設定

表、列、列型別規則檢查

驗證以下專案以找出實際設定和應用設定之間的差異。

• 資料庫中所有表的名稱

• 每個表的列名

• 每個表的列型別

• 是否檢查了NULL值

• 預設值是否繫結到正確的表列

• 規則定義以更正表名和訪問許可權

鍵和索引

驗證每個表中的鍵和索引 -

• 每個表的主鍵

• 每個表的外部鍵

• 外部鍵列和另一個表中的列之間的資料型別索引，聚簇或非聚簇唯一或不唯一

儲存過程測試

它涉及檢查儲存過程是否已定義，並將輸出結果進行比較。在儲存過程測試中，檢查以下幾點 -

• 儲存過程名稱

• 引數名稱、引數型別等。

• 輸出 - 輸出是否包含許多記錄。零行受影響或僅提取幾條記錄。

• 儲存過程的功能是什麼，儲存過程不應該做什麼？

• 傳遞示例輸入查詢以檢查儲存過程是否提取了正確的資料。

• 儲存過程引數 - 使用邊界資料和有效資料呼叫儲存過程。使每個引數一次無效並執行過程。

• 返回值 - 檢查儲存過程返回的值。如果失敗，則必須返回非零值。

• 錯誤訊息檢查 - 以使儲存過程失敗的方式進行更改，並至少生成一次每個錯誤訊息。檢查當沒有預定義錯誤訊息時發生的任何異常情況。

觸發器測試

在觸發器測試中，測試人員必須執行以下任務 -

• 確保觸發器名稱正確。
• 驗證觸發器是否為特定表列生成。
• 觸發器的更新驗證。
• 使用有效資料更新記錄。
• 使用無效資料更新記錄並覆蓋每個觸發器錯誤。
• 當其他表中的行仍引用記錄時更新記錄。
• 確保在發生故障時回滾事務。
• 找出觸發器不應該回滾事務的任何情況。

伺服器設定指令碼

應執行兩種型別的測試 -

• 從頭開始設定資料庫，以及
• 設定現有資料庫。

SQL Server 整合測試

在完成元件測試後，應執行整合測試。

• 應密集呼叫儲存過程以在不同的表中選擇、插入、更新和刪除記錄，以查詢任何衝突和不相容性。

• 模式和觸發器之間的任何衝突。

• 儲存過程和模式之間的任何衝突。

• 儲存過程和觸發器之間的任何衝突。

功能測試方法

功能測試可以透過根據功能將資料庫劃分為模組來執行。功能有以下兩種型別 -

• 型別 1 - 在型別 1 測試中，找出專案的特性。對於每個主要特性，找出負責實現該功能的模式、觸發器和儲存過程，並將它們放入一個功能組中。然後一起測試每個組。

• 型別 2 - 在型別 2 測試中，後端功能組的邊界並不明顯。您可以檢查資料流並檢視可以在哪裡檢查資料。從前端開始。

以下流程發生 -

• 當服務有請求或儲存資料時，將呼叫一些儲存過程。

• 這些過程將更新一些表。

• 這些儲存過程將成為開始測試的地方，而這些表將成為檢查測試結果的地方。

壓力測試

壓力測試包括獲取主要資料庫功能和相應儲存過程的列表。請按照以下步驟進行壓力測試 -

• 編寫測試指令碼以嘗試這些功能，並且每個功能必須在完整週期中至少檢查一次。

• 在特定時間段內反覆執行測試指令碼。

• 驗證日誌檔案以檢查任何死鎖、記憶體不足故障、資料損壞等。

基準測試

如果您的資料庫沒有任何資料問題或錯誤，則可以檢查系統性能。可以透過檢查以下給出的引數在基準測試中發現糟糕的系統性能 -

• 系統級效能
• 識別最可能使用的功能/特性
• 計時 - 執行功能的最大時間、最小時間和平均時間
• 訪問量

透過前端測試資料庫

有時也可以透過執行前端測試來查詢後端錯誤。您可以按照以下簡單步驟透過前端測試檢測錯誤。

• 從前端編寫查詢併發出搜尋。

• 選擇現有記錄，更改某些欄位中的值，然後儲存記錄。（這涉及 UPDATE 語句或更新儲存過程和更新觸發器。）

• 在前端視窗中插入一個新的選單項。填寫資訊並儲存記錄。（這涉及 INSERT 語句或插入儲存過程和刪除觸發器。）

• 選擇現有記錄，單擊“刪除”或“移除”按鈕，然後確認刪除。（這涉及 DELETE 語句或刪除儲存過程和刪除觸發器。）

• 使用無效資料重複這些測試用例，並檢視資料庫的響應方式。

資料庫測試 – 場景

在本章中，我們將看到一些關於各種測試方法的常見資料庫測試場景。

結構化資料庫測試

關於結構化資料庫測試的常見資料庫場景如下 -

• 驗證資料庫名稱、驗證資料裝置、日誌裝置和轉儲裝置、驗證是否為每個資料庫分配了足夠的空間以及驗證資料庫選項設定。

• 資料庫中所有表的名稱、每個表的列名、每個表的列型別、是否檢查空值。驗證每個表中的鍵和索引：每個表的主鍵、每個表的外部鍵。

• 外部鍵列和另一個表中的列之間的資料型別索引，聚簇或非聚簇唯一或不唯一。

功能資料庫測試

關於功能資料庫測試的常見資料庫測試場景為 -

• 找出負責實現該功能的模式、觸發器和儲存過程，並將它們組合成一個功能組，然後可以一起測試每個組。

• 檢查資料流並檢視可以在哪裡檢查資料。從前端開始。

非功能資料庫測試

關於非功能資料庫測試的常見資料庫測試場景為 -

• 編寫測試指令碼以嘗試主要功能，並且每個功能必須在完整週期中至少檢查一次。

• 在特定時間段內反覆執行測試指令碼。

• 驗證日誌檔案以檢查任何死鎖、記憶體不足故障、資料損壞等。

• 從前端編寫查詢併發出搜尋。選擇現有記錄，更改某些欄位中的值，然後儲存記錄。（這涉及 UPDATE 語句或更新儲存過程、更新觸發器。）

• 在前端視窗中插入一個新的選單項。填寫資訊並儲存記錄。（這涉及 INSERT 語句或插入儲存過程、刪除觸發器。）

• 選擇現有記錄，單擊“刪除”或“移除”按鈕，然後確認刪除。（這涉及 DELETE 語句或刪除儲存過程、刪除觸發器。）

• 使用無效資料重複這些測試用例，並檢視資料庫的響應方式。

資料庫測試 – 物件

模式、表、儲存過程和觸發器是資料庫的關鍵物件。我們已經分享了這些資料庫物件的資料庫測試型別和測試場景。

模式

資料庫模式以資料庫管理系統支援的格式定義資料庫系統的結構。模式指的是資料庫是如何構建的（在關係資料庫的情況下，由資料庫表組成）。

資料庫模式是一組稱為完整性約束的公式，施加在資料庫上。這些完整性約束確保模式各部分之間的相容性。

在關係資料庫中，模式由表、欄位、檢視、索引、包、過程、函式、觸發器、型別、物化檢視、同義詞、資料庫連結和其他元素組成。

模式通常儲存在資料字典中。雖然模式是在文字資料庫語言中定義的，但該術語通常用於指代資料庫結構的圖形描述。換句話說，模式是定義資料庫中物件的資料庫結構。

資料倉庫中常用的模式型別有：

• 星型模式
• 雪花模式
• 星系模式

資料庫中的表

在關係資料庫中，表用於將資訊組織成行和列。

示例 - 客戶表包含諸如客戶 ID、地址、電話號碼等資訊，作為一系列列。

每條資料都是表中的一個欄位。列包含單個欄位中的所有條目，例如所有客戶的電話號碼。欄位被組織成記錄，它們是完整的資訊集（例如關於特定客戶的資訊集），每個資訊集構成一行。

儲存過程

儲存過程是一系列儲存在資料庫中的已編譯形式的 SQL 語句，多個程式可以共享它。使用儲存過程有助於維護資料完整性、資料訪問控制和提高生產力。

觸發器

資料庫觸發器是在資料庫中特定表或檢視上發生某些事件時執行的程式碼。觸發器主要用於維護資料庫中資訊的完整性。

資料庫測試 – 資料完整性

資料完整性在資料庫中非常重要。它包括在插入、更新和刪除之前進行資料驗證。必須設定觸發器以驗證參考表記錄。

為了檢查資料完整性，您需要執行以下操作：

• 您需要檢查每個表中的主要列，並驗證是否存在任何不正確的資料。（名稱欄位中的字元、負百分比等）。

• 找出不一致的資料並將它們插入相關表中，檢視是否發生任何錯誤。

• 在插入父資料之前插入子資料。嘗試刪除仍被另一個表中的資料引用的記錄。

• 如果表中的資料已更新，請檢查其他相關資料是否也已更新。您需要確保複製的伺服器或資料庫同步幷包含一致的資訊。

資料庫測試 – 資料對映

資料庫中的資料對映是每個測試人員都需要驗證的關鍵概念之一。通常，測試人員必須驗證使用者介面前端欄位對映與相應的後端資料庫欄位。

此資訊在軟體需求規格說明書或業務需求規格說明書 SRS/BRS 文件中給出。如果未提供對映，則需要檢查編碼部分。

當您在前端應用程式中執行任何操作時，都會呼叫相應的 CRUD 操作，測試人員必須檢查每個呼叫的操作是否成功。

資料對映的關鍵方面

以下是資料對映的關鍵方面：

• 檢查 UI/前端表單中的欄位是否與相應的 DB 表一致地對映。此對映資訊在上述需求文件中定義。

• 對於在應用程式前端執行的任何操作，都會在後端啟動相應的 CRUD“建立、檢索、更新和刪除”操作。

• 測試人員必須檢查是否呼叫了正確的操作，以及呼叫的操作本身是否成功。

資料對映測試的步驟

以下是資料對映測試中遵循的步驟：

• 步驟 1 - 首先檢查每個指令碼中的語法錯誤。

• 步驟 2 - 接下來是檢查表對映、列對映和資料型別對映。

• 步驟 3 - 驗證查詢資料對映。

• 步驟 4 - 當目標表中不存在記錄時執行每個指令碼。

• 步驟 5 - 當記錄已存在於目標表中時執行每個指令碼。

資料庫測試 – 效能

響應時間更長且效能較差的應用程式會導致巨大的問題。資料庫負載測試用於在您為終端使用者部署資料庫應用程式之前查詢任何效能問題。

資料庫負載測試可幫助您設計具有效能、可靠性和可擴充套件性的資料庫應用程式。資料庫應用程式的負載測試涉及使用不同的使用者負載測試資料庫應用程式的效能和可擴充套件性。

資料庫負載測試涉及模擬目標資料庫應用程式的真實使用者負載。它可以幫助您確定當多個使用者同時訪問資料庫應用程式時，它的行為。

負載測試

負載測試的主要目標是檢查大多數正在執行的事務是否對資料庫有效能影響。在負載測試中，您需要檢查以下方面：

• 應檢查多個遠端使用者執行事務的響應時間。

• 對於正常事務，您應該包含一個可編輯的事務以檢查資料庫對這些型別事務的效能。

• 對於正常事務，您應該包含一個非編輯事務以檢查資料庫對這些型別事務的效能。

• 應檢查資料庫獲取特定記錄所需的時間。

壓力測試

壓力測試用於識別系統斷點。在此，應用程式以使系統在某一點失敗的方式載入。此點稱為資料庫系統的斷點。壓力測試也稱為疲勞測試。

確定資料庫事務的狀態需要大量工作。需要進行適當的計劃以避免任何基於時間和成本的問題。

最常見的壓力測試工具是LoadRunner 和WinRunner。

資料庫測試 – 工具

供應商提供了各種工具，可用於生成測試資料、管理測試資料並執行資料庫測試（如負載測試和迴歸測試）。

下面列出了一些常用的工具。

資料庫測試 – 備份

組織發展最重要的部分是其資料。在系統故障的情況下，需要恢復資料。備份是資料庫的精確副本，它可以幫助您在發生任何資料丟失時恢復資料。

考慮一家金融公司，它擁有與其客戶相關的資料，例如賬戶號碼、客戶姓名、貸記和借記、持續時間等。如果發生資料故障，這樣的組織將如何應對丟失此類重要資訊的壓力？

這就是您備份資料的原因，以便在磁碟、磁碟控制器等發生任何故障時，您可以依靠備份將其恢復到資料庫中。

資料備份型別

可以使用兩種型別的備份：

• 物理備份 - 物理備份包括使用第三方備份工具（如 Veritas Net Back、IBM Tivoli Manager）或使用作業系統實用程式的使用者管理器備份進行備份。

• 邏輯備份 - 資料庫的邏輯備份包括備份邏輯物件（如表、索引、過程等）。

示例 - 用於備份資料的常用工具之一是Oracle 恢復管理器 (RMAN)，它是 Oracle 用於備份資料庫的實用程式。

RMAN 包含兩個元件：

• 需要備份的目標資料庫。

• RMAN 客戶端用於執行執行資料備份的命令。

BACKUP VALIDATE 用於測試您是否能夠建立資料庫檔案的有效備份。它確保：

• 是否為資料庫的物理或邏輯物件設定了備份。
• 是否為寶貴資料設定了定期備份。
• 備份工具是否滿足組織的備份要求。

資料庫測試 – 恢復

資料庫恢復測試用於確保資料庫已恢復。恢復測試允許您找出應用程式是否正常執行，並檢查檢索本應丟失的寶貴資料（如果您的恢復方法設定不正確）。

您還可以檢查幾個關鍵流程是否執行順利，以確保資料恢復能夠順利透過測試階段。

您可以對資料庫恢復執行以下檢查：

• 備份軟體中的任何錯誤或錯誤，您需要在早期階段解決這些問題。

• 您需要進行恢復測試，以便在緊急情況下知道該怎麼做。

• 您需要檢查恢復測試需求，以便您可以計劃有效的恢復策略。

• 您還應該知道如何恢復文件。

您需要在專案的早期階段執行恢復測試。這使您可以消除並丟棄系統中的所有型別的錯誤。以下是一些在測試時應考慮的重要事項列表：

• 資料庫系統發生更改或修改的時間跨度。

• 您希望恢復計劃執行的期限。

• 資料庫系統中資料的敏感性。資料越關鍵，您就越需要定期測試軟體。

資料庫備份和恢復測試的常見步驟

在資料庫恢復測試中，您需要在實際環境中執行測試，以檢查系統或資料在發生任何災難和業務環境中任何其他不可預見事件時是否可以實際恢復。

以下是資料庫恢復測試中執行的常見操作：

• 資料庫系統的測試
• SQL 檔案的測試
• 部分檔案的測試
• 資料備份的測試
• 備份工具的測試
• 日誌備份的測試

資料庫測試 – 安全性

資料庫安全測試是為了查詢安全機制中的漏洞，以及發現數據庫系統的漏洞或弱點。

資料庫安全測試的主要目標是找出系統中的漏洞，並確定其資料和資源是否受到潛在入侵者的保護。安全測試定義了一種有效識別潛在漏洞的方法，如果定期執行，則可以有效識別潛在漏洞。

以下是執行資料庫安全測試的主要目標：

• 身份驗證
• 授權
• 機密性
• 可用性
• 完整性
• 彈性

資料庫系統中的威脅型別

SQL注入

這是資料庫系統中最常見的攻擊型別，其中惡意SQL語句被插入到資料庫系統中並被執行，以從資料庫系統中獲取關鍵資訊。這種攻擊利用了使用者應用程式實現中的漏洞。為了防止這種情況，應仔細處理使用者輸入欄位。

資料庫許可權提升

在這種攻擊中，使用者已經在資料庫系統中具有一定的訪問許可權，並且他只是試圖將此訪問許可權提升到更高的級別，以便他/她可以在資料庫系統中執行一些未經授權的活動。

拒絕服務

在這種型別的攻擊中，攻擊者使資料庫系統或應用程式資源對合法使用者不可用。應用程式也可能受到攻擊，從而導致應用程式，有時甚至是整個機器無法使用。

未經授權的資料訪問

另一種攻擊型別是未經授權訪問應用程式或資料庫系統中的資料。未經授權的訪問包括：

• 透過基於使用者的應用程式未經授權訪問資料
• 透過監控其他人的訪問許可權進行未經授權的訪問
• 未經授權訪問可重用的客戶端身份驗證資訊

身份欺騙

在身份欺騙中，駭客使用使用者或裝置的憑據對網路主機發起攻擊，竊取資料或繞過對資料庫系統的訪問控制。防止這種攻擊需要IT基礎設施和網路級緩解措施。

資料操縱

在資料操縱攻擊中，駭客更改資料以獲得一些優勢或損害資料庫所有者的形象。

資料庫安全測試技術

滲透測試

滲透測試是對計算機系統進行攻擊，目的是查詢安全漏洞，潛在地訪問它、它的功能和資料。

風險查詢

風險查詢是評估和確定與損失型別和漏洞發生可能性相關的風險的過程。這由組織透過各種訪談、討論和分析來確定。

SQL注入測試

它涉及檢查應用程式欄位中的使用者輸入。例如，在使用者應用程式的任何文字框中輸入“，”或“;”等特殊字元都不允許。當發生資料庫錯誤時，這意味著使用者輸入被插入到某些查詢中，然後由應用程式執行。在這種情況下，應用程式容易受到SQL注入的攻擊。

這些攻擊對資料構成了巨大威脅，因為攻擊者可以訪問伺服器資料庫中的重要資訊。要檢查SQL注入進入Web應用程式的入口點，請從程式碼庫中查詢直接在資料庫上執行MySQL查詢的程式碼，方法是接受一些使用者輸入。

可以針對括號、逗號和引號執行SQL注入測試。

密碼破解

這是執行資料庫系統測試時最重要的檢查。為了訪問關鍵資訊，駭客可以使用密碼破解工具或猜測常見的使用者名稱/密碼。這些常見密碼很容易在網際網路上獲得，並且密碼破解工具也免費存在。

因此，有必要在測試時檢查系統中是否維護了密碼策略。對於任何銀行和金融應用程式，都需要在所有關鍵資訊資料庫系統上設定嚴格的密碼策略。

資料庫系統安全審計

安全審計是一個定期評估公司安全策略的過程，以確定是否遵循必要的標準。可以根據業務需求遵循各種安全標準來定義安全策略，然後可以針對這些標準評估設定的策略。

最常見安全標準的示例包括ISO 27001、BS15999等。

資料庫安全測試工具

市場上有多種系統測試工具可用，可用於測試作業系統和應用程式檢查。下面討論一些最常見的工具。

Zed Attack Proxy

它是一個用於查詢Web應用程式漏洞的滲透測試工具。它旨在供具有廣泛安全經驗的人員使用，因此非常適合剛接觸滲透測試的開發人員和功能測試人員。它通常用於Windows、Linux、Mac OS。

Paros

可以使用這些掃描程式攔截和修改伺服器和客戶端之間所有HTTP和HTTPS資料，包括cookie和表單欄位。它用於跨平臺、Java JRE/JDK 1.4.2或更高版本。

社會工程工具包

它是一個開源工具，攻擊的是人的因素而不是系統元素。它使您能夠傳送包含攻擊程式碼的電子郵件、Java小程式等。它首選用於Linux、Apple Mac OS X和Microsoft Windows。

Skipfish

此工具用於掃描其網站以查詢漏洞。該工具生成的報告旨在作為專業Web應用程式安全評估的基礎。它首選用於Linux、FreeBSD、MacOS X和Windows。

Vega

它是一個開源的多平臺Web安全工具，用於查詢Web應用程式中SQL注入、跨站點指令碼（XSS）和其他漏洞的例項。它首選用於Java、Linux和Windows。

Wapiti

Wapiti是一個開源的基於Web的工具，它掃描Web應用程式的網頁並檢查指令碼和表單，它可以在其中注入資料。它使用Python構建，可以檢測檔案處理錯誤、資料庫、XSS、LDAP和CRLF注入、命令執行檢測。

Web Scarab

它使用Java編寫，用於分析透過HTTP/HTTPS協議通訊的應用程式。此工具主要設計用於可以自己編寫程式碼的開發人員。此工具不依賴於作業系統。

資料庫測試 – 挑戰

為了成功執行資料庫測試，測試人員應從所有來源收集需求，例如技術和功能需求。一些需求可能處於高級別，因此需要將這些需求分解成小部分。測試資料庫是一項複雜的任務，測試人員在執行此測試時會面臨許多挑戰。最常見的資料庫測試挑戰包括：

測試範圍過大

測試人員需要識別資料庫測試中的測試項，否則他可能無法清楚地瞭解要測試什麼以及不測試什麼。因此，如果您對需求很清楚，則可能會浪費大量時間來測試資料庫中不重要的物件。

當您有一組要測試的物件時，接下來是估計為每個測試項設計測試和執行測試所需的精力。根據其設計和資料大小，一些資料庫測試可能需要很長時間才能執行。

由於資料庫規模過大，因此查詢必須測試的物件以及哪些物件需要排除變得非常具有挑戰性。

縮減的測試資料庫

通常，測試人員會獲得開發資料庫的副本進行測試。該資料庫僅包含少量資料，足以執行應用程式。因此，需要測試開發、暫存以及生產資料庫系統。

資料庫結構的更改

這是資料庫測試中常見的挑戰之一。有時，您設計或執行測試時，資料庫結構會發生更改。有必要確保您瞭解測試期間對資料庫進行的更改。

一旦資料庫結構發生更改，您應該分析更改的影響並修改測試。此外，如果多個使用者使用測試資料庫，您將無法確定測試結果，因此您應確保測試資料庫僅用於測試目的。

資料庫測試中的另一個挑戰是您同時執行多個測試。您應該至少對效能測試一次執行一個測試。您不希望資料庫執行多個任務並低估效能。

複雜的測試計劃

資料庫結構通常很複雜，並且資料量巨大，因此您可能正在重複執行不完整或相同的測試。因此，需要建立一個測試計劃並相應地進行，並定期檢查進度。

良好的SQL理解

要測試資料庫，您應該具備良好的SQL查詢知識和所需的資料庫管理工具。

資料庫測試 - 面試問題

db_connect(query1 DRIVER {drivername};SERVER server_name;UID uidname;
   PWD password;DBQ database_name );

db_excecute_query (write the required query that is to execute); Specify the appropriate condition

db_disconnect(query);