資料庫測試指南

磁石空杯發表於2023-04-18
資料庫

為什麼要測試資料庫？

資料對映

在軟體系統中，資料經常從UI（使用者介面）到後端資料庫之間來回穿梭，反之亦然。因此，這些是需要注意的一些方面：

  • 檢查使用者介面/前端表單中的欄位是否與資料庫表中的相應欄位有一致的對映。 通常情況下，這種對映資訊在需求檔案中被定義。

  • 每當在應用程式的前端執行某個動作時，相應的CRUD（建立、檢索、更新和刪除）動作會在後端被呼叫。測試人員必須檢查是否呼叫了正確的動作，以及呼叫的動作本身是否成功。

ACID屬性驗證

原子性、一致性、隔離性和永續性。DB執行的每個事務都必須遵守這四個屬性。

  • 原子性意味著一個事務要麼失敗要麼透過。這意味著，即使交易部分失敗了，也意味著整個交易都失敗了。通常情況下，這被稱為 "全有或全無 "規則。
  • 一致性： 事務將總是導致資料庫的有效狀態。
  • 隔離性： 如果有多個事務同時被執行，DB的結果/狀態應該與它們逐一執行的情況相同。
  • 永續性： 一旦事務完成並提交，任何外部因素，如斷電或崩潰，都不能改變它。

資料完整性

對於任何CRUD操作，共享資料的更新和最新的值/狀態應該出現在所有的表格和螢幕上。

  • C Create : 建立 - 當使用者 "儲存 "任何新事務時，"建立 "操作被執行。
  • R Retrieve : 檢索 - 當使用者 "搜尋 "或 "檢視 "任何已儲存的事務時，會執行 "檢索 "操作。
  • U Update : 更新 - 當使用者'編輯'或'修改'現有的記錄，DB的'更新'操作被執行。
  • D Delete : 刪除 - 當使用者從系統中'刪除'任何記錄時，將執行DB的'刪除'操作。

業務規則的符合性

資料庫中更多的複雜性意味著更復雜的元件，如關係約束、觸發器、儲存過程等。因此，測試人員必須想出適當的SQL查詢，以驗證這些複雜的物件。

資料庫測試檢查表

事務

當測試交易時，重要的是確保它們滿足ACID屬性。

這些是常用的語句：

BEGIN TRANSACTION TRANSACTION#
END TRANSACTION TRANSACTION#

ROLLBACK TRANSACTION#

SELECT * FROM TABLENAME <tables which involve the transactions>

資料庫模式

資料庫模式是對資料在資料庫中如何組織的正式定義。為了測試它：

  • 確定資料庫執行所基於的要求。樣品要求：
    • 在建立任何其他欄位之前，應先建立主鍵。
    • 外來鍵應該是完全索引的，以便於檢索和搜尋。
    • 欄位名以某些字元開始或結束。
    • 具有限制條件的欄位，即某些值可以或不可以被插入。
  • 根據相關性，使用以下方法之一：
    • SQL查詢DESC<表名>來驗證模式。
    • 用正規表示式來驗證各個欄位的名稱和它們的值
    • 像SchemaCrawler這樣的工具

觸發器

當某個事件發生在某個表上時，一段程式碼（觸發器）自動執行。

例如，新學生加入了學校。該學生正在上2門課：數學和科學。該學生被新增到 "學生表 "中。 一旦該學生被新增到學生表中，觸發器可以將他新增到相應的科目表中。

常用的測試方法是，首先獨立執行嵌入在觸發器中的SQL查詢，並記錄結果。之後再執行整個觸發器比較結果。

  • 白盒測試：

樁和驅動用於插入或更新或刪除資料，這將導致觸發器被呼叫。在與前端（UI）整合之前，只測試資料庫。

  • 黑盒測試：
    • 從前端插入/刪除/更新資料的方式來呼叫Trigger。
    • 直接載入呼叫觸發器的資料，看它是否按預期工作。

儲存過程

儲存程式或多或少類似於使用者定義的函式。這些程式可以透過呼叫程式/執行程式語句來呼叫，其輸出通常是結果集。

這些過程儲存在RDBMS中供應用。

  • 白盒測試

使用樁來呼叫儲存程式，然後根據預期值來驗證結果。

  • 黑盒測試： 從應用程式的前端（UI）執行操作，並檢查儲存過程的執行情況及其結果。

欄位約束

預設值，唯一值，和外來鍵：

資料測試活動

資料對映：

確保AUT的不同表格或螢幕與資料庫之間的對映不僅準確，而且符合設計檔案（SRS/BRS）或程式碼。基本上，你需要驗證每個前端欄位和其對應的後臺資料庫欄位之間的對映。

對於所有的CRUD操作，驗證當使用者從應用程式的GUI點選 "儲存"、"更新"、"搜尋 "或 "刪除 "時，相應的表和記錄是否被更新。

  • 表的對映，列的對映，以及資料型別的對映。
  • 查詢資料對映。
  • 在使用者介面上的每個使用者操作都呼叫了正確的CRUD操作。
  • CRUD操作是成功的。

ACID

DB事務的ACID屬性是指 "原子性"、"一致性"、"隔離性 "和 "永續性"。在資料庫測試活動中必須對這四個屬性進行適當的測試。你需要驗證每一個交易是否滿足資料庫的ACID屬性。

CREATE TABLE acidtest (A INTEGER, B INTEGER, CHECK (A + B = 100));

隔離測試將確保如果兩個事務同時發生並試圖修改ACID測試表的資料，那麼這些事務是在隔離的情況下執行的。

永續性測試將確保一旦該表上的事務被提交，它將保持不變，即使是在斷電、崩潰或錯誤的情況下。

如果你的應用程式使用的是分散式資料庫，這個領域需要更嚴格、更徹底、更敏銳的測試。

資料的完整性

  • 檢查所有的觸發器是否已經到位，以更新參考表記錄。
  • 檢查每個表的主要列中是否存在任何不正確/無效的資料。
  • 嘗試在表中插入錯誤的資料，觀察是否有任何故障發生。
  • 檢查如果你試圖在插入子表之前插入其父表會發生什麼（嘗試玩弄主鍵和外來鍵）。
  • 測試如果你刪除一條仍然被其他表中的資料引用的記錄，是否會發生故障。
  • 檢查複製伺服器和資料庫是否處於同步狀態。

確保實施的業務規則的準確性：

今天，資料庫不僅僅是為了儲存記錄。事實上，資料庫已經發展成為非常強大的工具，為開發人員提供充分的支援，在資料庫層面上實現業務邏輯。

使用這些和許多其他由資料庫提供的功能，開發人員在資料庫層面實現業務邏輯。測試人員必須確保實現的業務邏輯是正確的，並能準確地工作。

如何測試資料庫

  • 準備好環境
  • 執行測試
  • 檢查測試結果
  • 根據預期結果進行驗證
  • 報告結果

通常情況下，使用SQL查詢來開發測試。最常用的命令是 "選擇"。

Select * from <tablename> where <condition>

除了Select之外，SQL還有3種重要的命令型別：

  • DDL: 資料定義語言
  • DML： 資料操作語言
  • DCL：資料控制語言

讓我們看看最常用的語句的語法。

資料定義語言 使用CREATE, ALTER, RENAME, DROP和TRUNCATE來處理表（和索引）。

資料操作語言 包括新增、更新和刪除記錄的語句。

資料控制語言： 處理給使用者操作和訪問資料的授權問題。Grant和Revoke是使用的兩個語句。

Grant 語法：

Grant select/update
On <table name>
To <user id1, user id2…useridn>;

Revoke語法：

Revokeselect/update
on <table name>
from<user id1, user id2…useridn>;

實用技巧

  • 自己寫查詢：

為了準確地測試資料庫，測試人員應該有非常好的SQL和DML（資料操作語言）語句的知識。測試人員還應該知道AUT的內部資料庫結構。

你可以結合GUI和各自表中的資料驗證，以獲得更好的覆蓋率。如果你使用的是SQL伺服器，那麼你可以利用SQL查詢分析器來編寫查詢，執行它們並檢索結果。

當應用程式的複雜程度較低或中等時，這是測試資料庫的最佳和強大的方法。

如果應用程式非常複雜，那麼測試人員可能很難或不可能編寫所有需要的SQL查詢。對於複雜的查詢，你可以從開發人員那裡得到幫助。我一直推薦這種方法，因為它能給你測試的信心，也能提高你的SQL技能。

  • 觀察每個表中的資料：

你可以使用CRUD操作的結果進行資料驗證。當你知道資料庫整合時，這可以透過使用應用程式UI手動完成。但是，當不同的資料庫表中有大量的資料時，這可能是一項繁瑣的工作。

對於手動資料測試，資料庫測試人員必須擁有良好的資料庫表結構知識。

  • 從開發人員那裡獲得查詢

這是最簡單的測試資料庫的方法。從GUI中執行任何CRUD操作，並透過執行從開發人員那裡獲得的相應SQL查詢來驗證其影響。它既不需要很好的SQL知識，也不需要對應用程式的資料庫結構有很好的瞭解。

但這種方法需要謹慎使用。如果開發人員給出的查詢在語義上是錯誤的，或者不能正確地滿足使用者的要求，怎麼辦？這個過程將直接導致資料驗證失敗。

  • 利用資料庫自動化測試工具：

有幾種工具可用於資料測試過程。你應該根據你的需要選擇正確的工具，並對其進行最佳利用。

總結

有了所有這些在資料庫上測試的功能、因素和過程，對測試人員精通關鍵資料庫概念的技術要求越來越高。儘管有些人認為測試資料庫會產生新的瓶頸，並且是大量的額外支出，但這是一個吸引大量關注和需求的測試領域。

相關文章