您使用什麼最佳實踐來測試數據庫查詢？

Question

我目前正在測試我們的解決方案，它具有整個「色域」層：UI，中間和無所不在的數據庫。

在我到達我目前的團隊之前，查詢測試是由測試人員手動完成查詢，理論上返回存儲過程應基於各種相關性規則返回的結果集，排序，您有什麼。

這會產生錯誤對測試人員查詢提交的副作用，而不是針對有問題的實際查詢。

我建議實際上使用一個已知的結果集，您可以推斷出它應該如何返回，因爲您控制了當前的數據 - 以前，數據是從生產，消毒，然後填充到我們的測試數據庫中。

人們仍然堅持創建自己的查詢來測試開發人員創建的內容。我懷疑還有很多。我認爲這並不理想，只是不必要地增加了我們的測試足跡。

因此，我很好奇，您使用哪種實踐來測試這樣的場景，以及在不引入混沌數據的情況下，您認爲最適合您獲得的最佳端到端覆蓋範圍的理想選擇？

我遇到的問題是哪裏是做什麼測試的最佳場所。我是否直接戳該服務，並將該數據集與我可以從存儲過程中提取的數據集進行比較？我有一個大概的想法，到目前爲止已經足夠成功，但我覺得我們仍然錯過了重要的東西，所以我期待社區看看他們是否有任何有價值的見解，可能有助於制定我的測試方法更好。

Answer 1

測試存儲過程需要每個測試人員都有一個單獨的db實例。這是一項要求。如果您共享環境，您將無法依賴測試的結果。他們將毫無價值。

您還需要確保在每次測試後將db回滾到之前的狀態，以便使結果可預測並保持穩定。由於需要在每次測試後回滾狀態，因此這些測試比標準單元測試需要更長的時間才能完成，因此它們可能會是您想要在一夜之間運行的內容。

有幾個工具可以幫助您解決這個問題。 DbUnit就是其中之一，我也相信微軟擁有一個Visual Studio for Database Professionals工具，它包含對數據庫測試的一些支持。

Answer 2

作爲我們持續集成的一部分，我們每晚都運行數據庫查詢的「構建」。這包括一系列DB調用，這些DB調用會根據代碼中的實際調用以及任何預期的臨時查詢定期更新。

這些調用定時，以確保：

1 /他們並不需要太長時間。

2 /它們與前一晚沒有很大不同（差勁）。

通過這種方式，我們可以快速捕獲錯誤的查詢或DB更改。

Answer 3

這裏有一些準則：

1. 使用單元測試一個孤立的數據庫（如沒有其他測試運行或活動）
2. 總是插入您打算在同一測試中查詢所有測試數據
3. 編寫測試以隨機創建不同的數據量，例如隨機的插入行數，例如1行和10行之間
4. 隨機化數據，例如對於布爾字段隨機插入和真或假
5. 請變量的測試計數（行如人數，trues數）
6. 對於斷言執行查詢和比較對本地測試變量
7. 使用企業服務事務回滾數據庫以前的狀態

見下面的企業服務事務技術的鏈接：

http://weblogs.asp.net/rosherove/articles/DbUnitTesting.aspx

Answer 4

查詢規劃師是你的朋友，特別是在這種情況下。檢查查看索引是否在您期望的時候使用並且查詢不需要做額外的工作總是一個很好的做法。即使您的套件中包含壓力測試，在您的應用程序開始磨合停止之前，仍然會收集昂貴的查詢。

Answer 5

我覺得測試向下發送到數據庫的SQL而不是查詢數據庫的結果很有用。

不是我不這樣做，但我發現測試的速度要比數據庫太多的提升要快得多。

Answer 6

我們爲每個開發人員和測試人員預留了空白數據庫。

當測試運行時 - 每個測試都會清除數據庫並加載它期望使用的數據。這一直給我們一個已知的狀態。

然後我們可以在同一個數據庫（一個接一個地測試）上測試幾個不同的場景，並且我們從不在另一個測試人員腳趾上戳。

這涵蓋了測試數據訪問本身。對於服務測試，我們做同樣的事情，但我們只測試服務的內部 - 我們實際上沒有創建服務，我們創建了服務處理類的實例並傳入我們需要的所有內容。這樣我們正在測試的代碼，而不是基礎設施（消息等..）

Answer 7

Django提供數據庫單元測試功能。您可以借用他們的設計理念並在其他環境中重現它。

Django人提供了Python的標準unittest的子類TestCase類，該類使用已知的fixture - 一組已知的數據行填充數據庫。

對於Django（和Python），從JSON數據提取中填充數據庫是最容易的。該燈具的其他文件格式可用於其他框架。例如，如果您在Oracle工作，您可能會發現CSV文件更易於使用。

這個TestCase子類允許編寫一個典型外觀的TestCase，它用已知的數據夾具來執行數據庫。

此外，Django測試運行器爲測試目的創建了一個臨時模式。這對於Django來說很簡單，因爲它們有一個完整的包含DDL創建的對象關係管理組件。如果你沒有這個可用的，你仍然需要DDL腳本，這樣你就可以爲單元測試創​​建和處理一個測試模式。

Answer 8

SQLServerCentral有一篇關於稱爲tsqlUnit的TSQL單元測試框架的文章here（您可能需要註冊但沒有字符串）。它是開源的，並遵循xUnit框架的傳統。

它遵循SEAT TDD模式：

設置 - 準備通過操縱的對象，表中的試驗條件，和/或數據

練習 - 調用生產代碼

斷言 - 檢查實際結果等於預期結果

拆解 - 將測試結果恢復到測試開始前的狀態。這實際上是通過回滾一個事務來完成的，這個事務保持了一切的美好和整潔。

雖然我沒有使用它，它看起來很有前途，當然我會更詳細地看待。可以下載框架here。