我們的團隊（QA）正面臨着以下問題：如何測試SQL腳本？ （數據完整性/遷移測試）
我們有一個只能由我們Core應用程序，它是一個WCF services應用程序訪問的數據庫。我們的客戶端應用程序正在使用Core來訪問數據庫。
在某些時候，我們提供了一個新版本的Core application和我們的Database。 Dev部門也給了我們一個sql腳本，它正在改變我們database Core data的很大一部分。 被Core Application用來描述我們系統的邏輯，所以每個數據的改變都可能影響到我們客戶端應用程序的任何功能。
我的問題是：
我要找運行遷移腳本後，數據庫的快速有效性/完整性測試。這樣可以防止我們通過應用程序對其進行測試而浪費時間。如果有效性/完整性測試成功，那麼我們可以測試這些應用程序。
從你給的描述：
我們有一個只能由我們的核心應用程序訪問數據庫... 我們提供了一個新版本的核心應用程序和 我們的數據庫...
告訴我，這是不是你的團隊的責任測試孤立的數據庫，但可以測試從客戶端的角度來看，核心服務，因此你認爲該數據庫是正確的。
將核心應用程序和數據庫視爲black box並使用單元測試進行測試。這些測試不應該要求你在數據庫中查找所有的意圖和目的，任何使用你的Core應用程序的應用程序都不知道，也不應該關心這些信息實際存儲在數據庫中。您的開發團隊可以在6個月內決定將數據存儲在雲中，在這種情況下，您的數據庫測試將被破壞。
如果做在數據庫中查詢數據看已經被正確地存儲則是因爲你把應該可以通過同一個界面檢索任何數據的核心服務的接口有問題（我只知道有人會發表評論，他們的應用程序確實存儲了無法讀回的數據，但沒有對應用程序進行更詳細的描述，因此更容易推廣）。
回到現實世界中，我假設你是QA團隊的一員，除非數據庫開發人員正在進行一些測試（他們是嗎？），你很可能不得不驗證數據庫變化。
最後，您可能有興趣閱讀我發佈在DBA Stack Exchage站點上的關於performing a data comparison between two different schemas的問題。擾流板：沒有簡單的答案。
我百分百贊同你所說的一切。然而，正如你所說，在現實世界中事情會更復雜一些。 Core應用程序的黑盒測試不會給我們帶來任何問題，因爲它的功能沒有改變。新數據將正確添加到數據庫。這些問題可能會在現有數據上發生。 – Schaliasos
在這種情況下，您有兩個單獨的問題;第一個是能夠驗證數據庫中的數據與「升級」之前的數據相同，其次是客戶端應用程序不會因這些更改而中斷。首先你必須做我在dba.stackexchange問題中描述的比較類型;第二個問題意味着，是的，你將不得不再次測試你的所有應用程序（就像你應該在*什麼時候改變）一樣。如果您的測試是自動化的，則迴歸測試不應該是一項繁重的任務。 – Tony
您對dba.stackexchange的問題確實非常有幫助，許多好的答案，以及您的問題。謝謝。 – Schaliasos
@Tim Lentine已經發布，我會推薦測試完整的應用程序。正如你所評論的，根據你的描述，你的團隊收到的新的sql腳本已經對你的數據庫開發的核心做了重要的改變，包括結構和數據本身。所以爲了確保所有東西都還在一塊，我最好做一個完整的應用測試。至於一個工具或技術，我可以推薦新的RedGate（不，我不爲他們工作）插件在名爲「SQL測試」的SSMS上。它使用單元測試open source tSQLt來達到其目的。它只有一個缺點，就是有人需要先學習如何使用tSQLt，但是這很簡單。
感謝您的回答，我會檢查您對RedGate工具的建議。至於應用程序的測試並不是我們不會測試它們，但對於從sql腳本進行更新的快速測試，然後開始測試應用程序將非常有效。如果您正在測試6-7應用程序，並且在一週後發現腳本中有錯誤，請考慮浪費時間。 – Schaliasos
謝謝，第一個鏈接真的很有幫助。 – Schaliasos
我很高興幫助你。 –
我絕對會測試應用程序。測試腳本可能會在轉換過程中顯示錯誤等。但是，它不一定會在通過服務訪問數據或客戶端應用程序使用數據的方式中顯示錯誤。 –
@Tim Lentine感謝您的回答。我只是在尋找一些能夠證實數據庫更新是正確的，而不僅僅是成功（沒有錯誤）的東西，所以我不需要完全測試應用程序。 – Schaliasos