# 帶有示例測試案例的數據庫（數據）測試教程 > 原文： [https://www.guru99.com/data-testing.html](https://www.guru99.com/data-testing.html) ## 什么是數據庫測試？ **數據庫測試**是一種軟件測試，用于檢查被測數據庫的架構，表，觸發器等。 它還檢查數據的完整性和一致性。 它可能涉及創建復雜的查詢以對數據庫進行負載/壓力測試并檢查其響應能力。 ## 為什么要進行數據庫測試？ 測試和開發團隊成員通常最重視 GUI，因為圖形用戶界面恰好是應用程序中最可見的部分。 但是，同樣重要的是驗證作為應用程序（即數據庫）核心的信息。 讓我們考慮一個用戶進行交易的銀行應用程序。 現在，從數據庫測試的角度來看，以下幾點很重要： 1. 該應用程序將交易信息存儲在應用程序數據庫中，并將其正確顯示給用戶。 2. 在此過程中，不會丟失任何信息。 3. 應用程序不會保存部分執行或中止的操作信息。 4. 未經授權的個人不得訪問用戶信息。 為了確保上述所有目標，我們需要使用數據驗證或數據測試。 在本教程中，我們將研究 * [GUI 和數據庫測試之間的區別](#1) * [數據庫測試的類型](#2) * [模式測試](#3) * [數據庫表，列測試](#4) * [存儲過程測試](#5) * [觸發測試](#6) * [數據庫服務器驗證](#7) * [功能數據庫測試](#71) * [登錄名和用戶安全性](#8) * [負載測試](#88) * [壓力測試](#9) * [與數據庫測試有關的誤解或誤解](#10) * [最佳做法](#11) ## 用戶界面和數據測試之間的根本差異  | **用戶界面測試** | **數據庫或數據測試** | | 這種測試也稱為圖形用戶界面測試或前端測試。 | 這種測試也稱為后端測試或數據測試。 | | 這種類型的測試主要處理所有可供用戶查看和交互的可測試項目，例如表單，演示文稿，圖形，菜單和報表等。（通過 VB，VB.net，VC ++，Delphi-前端工具創建） ） | 這種類型的測試主要處理通常向用戶隱藏以供收看的所有可測試項目。 這些包括內部過程和存儲（如程序集），DBMS（如 Oracle）， [SQL](/sql.html) Server，MYSQL 等。 | | 這種類型的測試包括驗證 文本框， 選擇下拉列表， 日歷和按鈕， 從一頁導航到另一頁， ] 圖像顯示以及 整個應用程序的外觀。 | 這種測試涉及驗證 模式， 數據庫表， 列， 鍵和索引， 存儲過程 ， 觸發器， 數據庫服務器驗證， 驗證數據重復， | | 測試人員必須對業務需求以及開發工具的使用以及自動化框架和工具的使用有全面的了解。 | 為了能夠執行后端測試，測試人員必須在數據庫服務器和結構化查詢語言概念方面具有深厚的背景。 | ## **數據庫測試的類型**  數據庫測試的 3 種類型是 1. 結構測試 2. 功能測試 3. 非功能測試 讓我們逐一研究每種類型及其子類型。 ## 結構數據庫測試 結構化數據測試涉及驗證數據存儲庫中的所有那些元素，這些元素主要用于存儲數據，并且不允許最終用戶直接操作。 在這些類型的測試中，數據庫服務器的驗證也是一個非常重要的考慮因素。 測試人員成功完成此階段需要精通 SQL 查詢。 ## 模式測試 模式測試的主要方面是確保前端和后端之間的模式映射相似。 因此，我們也可以將模式測試稱為**映射測試。** 讓我們討論用于模式測試的最重要的檢查點。 1. 驗證與數據庫關聯的各種模式格式。 很多時候，表的映射格式可能與應用程序的用戶界面級別中存在的映射格式不兼容。 2. 對于未映射的表/視圖/列，需要進行驗證。 3. 還需要驗證環境中的異構數據庫是否與整個應用程序映射一致。 讓我們也看看一些驗證數據庫模式的有趣工具。 * 與 Ant 集成的 DBUnit 非常適合映射測試。 * SQL Server 允許測試人員通過編寫簡單查詢而不是通過代碼來檢查和查詢數據庫的架構。 例如，如果開發人員想要更改表結構或將其刪除，則測試人員將要確保使用該表的所有存儲過程和視圖都與特定更改兼容。 另一個例子可能是，如果測試人員想要檢查 2 個數據庫之間的架構更改，則可以使用簡單的查詢來完成。 ## 數據庫表，列測試 讓我們研究一下數據庫和列測試的各種檢查。 1. 后端中數據庫字段和列的映射是否與前端中的那些映射兼容。 2. 驗證需求指定的數據庫字段和列的長度和命名約定。 3. 驗證是否有未使用/未映射的數據庫表/列。 4. 驗證的兼容性 * 數據類型 * 場長 后端數據庫列與應用程序前端中存在的列。 5. 數據庫字段是否允許用戶根據業務需求規范文檔的要求提供所需的用戶輸入。 鍵和索引測試 重要檢查鍵和索引- 1. 檢查是否需要 * 首要的關鍵 * 外鍵 在所需表上創建了約束。 2. 檢查外鍵引用是否有效。 3. 檢查兩個表中主鍵和對應的外鍵的數據類型是否相同。 4. 檢查所有鍵和索引是否都遵循必需的命名約定。 5. 檢查必填字段和索引的大小和長度。 6. 是否要求 * 聚集索引 * 非聚集索引 已在業務需求指定的必需表上創建。 ## 存儲過程測試 將為存儲過程驗證的最重要的事物的列表。 1. 開發團隊是否采用了要求的 * 編碼標準約定 * 異常和錯誤處理 測試中應用程序所有模塊的所有存儲過程。 2. 開發團隊是否通過將所需的輸入數據應用于被測應用程序來覆蓋所有條件/循環。 3. 每當從數據庫中的所需表中獲取數據時，開發團隊是否正確地應用了 TRIM 操作。 4. 手動執行存儲過程是否可以為最終用戶提供所需的結果 5. 手動執行存儲過程是否可以確保表字段按照被測試應用程序的要求進行更新。 6. 執行存儲過程是否啟用所需觸發器的隱式調用。 7. 驗證是否有未使用的存儲過程。 8. 可以在數據庫級別完成的 Allow Null 條件驗證。 9. 當被測數據庫為空白時，驗證所有存儲過程和函數均已成功執行的事實。 10. 根據被測應用程序的要求驗證存儲過程模塊的整體集成。 LINQ 和 SP 測試工具等是一些用于測試存儲過程的有趣工具。 ## 觸發測試 1. 在觸發器的編碼階段是否遵循了要求的編碼約定。 2. 檢查為各個 DML 事務執行的觸發器是否滿足要求的條件。 3. 觸發器在執行后是否正確更新數據。 4. 驗證所需的更新/插入/刪除觸發了被測應用程序領域的功能。 ## 數據庫服務器驗證  1. 檢查業務需求指定的數據庫服務器配置。 2. 檢查所需用戶的授權以僅執行應用程序所需的那些級別的操作。 3. 檢查數據庫服務器是否能夠滿足業務需求規范所指定的最大允許用戶事務數量的需求。 ## 功能數據庫測試 需求規范中指定的功能數據庫測試需要確保最終用戶執行的大多數事務和操作與需求規范相一致。 以下是數據庫驗證需要遵守的基本條件。 * 在允許該字段上的 NULL 值的同時，該字段是否為必需字段。 * 每個字段的長度是否足夠大？ * 所有相似的字段在表之間是否具有相同的名稱？ * 數據庫中是否存在任何計算字段？ 從終端用戶的角度來看，此特定過程是對字段映射的驗證。 在這種特定情況下，測試人員將在數據庫級別執行操作，然后將導航到相關的用戶界面項，以觀察和驗證是否已經執行了正確的字段驗證。 反之亦然，首先由測試人員在用戶界面上進行操作，然后從后端進行驗證的操作也被認為是有效的選擇。 ## 檢查數據完整性和一致性 后續檢查很重要 1. 數據在邏輯上是否井井有條 2. 表中存儲的數據是否正確以及是否符合業務要求。 3. 被測應用程序中是否存在不必要的數據。 4. 對于從用戶界面更新的數據，是否按照要求存儲了數據。 5. 在將數據插入被測數據庫之前，是否對數據執行了 TRIM 操作。 6. 是否已根據業務需求規范執行了交易以及結果是否正確。 7. 如果已根據業務需求成功執行了事務，則是否已正確提交數據。 8. 如果最終用戶未成功執行事務，則是否已成功回滾數據。 9. 在事務尚未成功執行且事務中涉及多個異構數據庫的情況下，是否已完全回滾數據。 10. 是否已使用系統業務需求指定的必需設計過程執行了所有事務。 ## 登錄和用戶安全 登錄名和用戶安全憑證的驗證需要考慮以下事項。 1. 如果出現以下情況，該應用程序是否阻止用戶繼續進行該應用程序 * 用戶名無效，但密碼有效 * 用戶名有效，但密碼無效。 * 用戶名和密碼無效。 * 有效的用戶名和有效的密碼。 2. 是否允許用戶僅執行業務需求指定的那些特定操作。 3. 是否防止未經授權訪問數據 4. 是否創建了具有不同權限的不同用戶角色 5. 是否所有用戶都具有業務規范所要求的對指定數據庫的訪問級別。 6. 檢查諸如密碼，信用卡號之類的敏感數據是否已加密并且沒有以純文本格式存儲在數據庫中。 確保所有帳戶都應使用復雜且不容易猜到的密碼，這是一個好習慣。 **非功能測試** 根據業務需求，可以將數據庫測試環境中的非功能測試分為各種類別。 這些可以是負載測試，[壓力測試](/stress-testing-tutorial.html)，[安全測試](/what-is-security-testing.html)，[可用性測試](/usability-testing-tutorial.html)和[兼容性測試](/compatibility-testing.html)等。 可以在[性能測試](/performance-testing.html)范圍內進行分組的負載測試和壓力測試在達到非功能測試的作用時有兩個特定的目的。 **風險量化**-風險量化實際上可幫助涉眾確定所需負載水平下各種系統響應時間的要求。 這是任何質量保證任務的初衷。 我們需要注意的是，負載測試并不能直接減輕風險，而是通過風險識別和風險量化過程提供糾正機會，并提供了可以減輕風險的補救措施。 **最低系統設備要求**-我們通過正式測試所觀察到的理解，即最小的系統配置，它將使系統滿足涉眾的正式陳述的性能期望。 這樣就可以最小化無關的硬件，軟件和相關的擁有成本。 可以將此特定要求歸類為總體業務優化要求。 ## **負載測試** 任何負載測試的目的都應該清楚地理解和記錄。 以下類型的配置是負載測試所必需的。 1. 如果其他用戶事務效率不高，則它們可能會影響所有其他事務的性能。 2. 最終測試套件中至少應包含一個非編輯用戶事務，以便可以將此類事務的性能與其他更復雜的事務區分開。 3. 應該包括有助于系統核心目標的更重要的事務，因為根據定義，這些事務在負載下的失敗具有最大的影響。 4. 應該包括至少一個可編輯的事務，以便可以將此類事務的性能與其他事務區分開。 5. 在滿足所有預期需求的情況下，在大量虛擬用戶的情況下觀察最佳響應時間。 6. 對獲取各種記錄的有效時間的觀察。 重要的負載測試工具是負載運行程序，獲勝運行程序和 JMeter。 ## 壓力測試 壓力測試有時也稱為彎曲測試，因為它在巨大的工作量下給被測應用程序施加壓力，從而導致系統出現故障。這有助于確定系統的故障點。 重要的壓力測試工具是負載運行程序，獲勝運行程序和 JMeter。 數據庫測試期間最常見的問題 1. 為了確定數據庫事務的狀態，可能會涉及大量開銷。 2. 解決方案：應該組織整個過程的計劃和時間安排，以免出現基于時間和成本的問題。 3. 在清除舊測試數據之后，必須設計新的測試數據。 4. 解決方案：應該準備用于測試數據生成的事先計劃和方法。 5. 需要 SQL 生成器來轉換 SQL 驗證器，以確保 SQL 查詢易于處理所需的數據庫測試用例。 6. 解決方案：維護 SQL 查詢及其連續更新是整個測試過程的重要組成部分，應作為整個測試策略的一部分。 7. 上述先決條件確保了數據庫測試過程的設置可能既昂貴又耗時。 8. 解決方案：質量和總體項目進度持續時間之間應該保持良好的平衡。 [ ](/images/truth.png) **與數據庫測試有關的神話或誤解。** 1. 數據庫測試需要大量的專業知識，這是一項非常繁瑣的工作 * 現實：有效的數據庫測試為整個應用程序提供了長期的功能穩定性，因此有必要在其后面進行艱苦的工作。 2. 數據庫測試增加了額外的工作瓶頸 * 現實：相反，數據庫測試通過發現隱藏問題來為整體工作增加更多價值，從而主動幫助改進整體應用程序。 3. 數據庫測試減慢了整個開發過程 * 現實：大量的數據庫測試有助于整體提高數據庫應用程序的質量。 4. 數據庫測試可能會過于昂貴 * 現實：數據庫測試上的任何支出都是一項長期投資，這會導致應用程序長期穩定和健壯。 因此，用于數據庫測試的支出是必要的。 ## 最佳實踐 * 包括元數據和功能數據在內的所有數據都需要根據需求規范文檔的映射進行驗證。 * 由/與開發團隊協商創建的測試數據的驗證需要進行驗證。 * 通過使用手動和自動化程序來驗證輸出數據。 * 部署各種技術（例如因果圖技術，等效劃分技術和邊界值分析技術）以生成所需的測試數據條件。 * 所需數據庫表的參照完整性的驗證規則也需要進行驗證。 * 選擇默認表值以驗證數據庫一致性是一個非常重要的概念，是否已為所有必需的登錄事件成功將日志事件添加到數據庫中 * 計劃的作業是否及時執行？ * 及時備份數據庫。 結帳-[數據庫測試面試問題&答案](/database-testing-interview-questions.html) * [下一個](/software-testing.html)