UAT數據應該是生產的鏡像嗎？如果是這樣，怎麼樣？

我們一直在嘗試使用近實時數據（例如最大一週的舊數據）來測試UAT。我堅信開發和質量保證環境應該控制他們自己的數據，但是UAT（生產前的最後一層）代表了一點灰色地帶。所以我的問題是：UAT數據應該是生產的鏡像嗎？如果是這樣，怎麼樣？

a）這是一個好主意嗎？我認爲是這樣，但有些嘮叨疑惑。 b）如果是這樣，過去人們使用的一些已證實的技術是什麼？

2012-03-01 mwjackson

（假設OP預期持續，實時模式和數據同步）

答案很簡單：

理由

通過「鏡像」我假設你並不意味着實時直接鏡像或複製的（UAT測試通常需要艱苦的數據測試用例進行設置，其將獲得覆蓋）。

下面是我們如何做到這一點在企業環境中，FWIW

在定義的時間間隔，通常在大約最後的督促數據庫備份恢復在QA環境1周月的時間

（UAT刷新）
環境「轉換」腳本在恢復後刷新的每個數據庫上運行（例如，指向配置或混淆敏感的財務，客戶或用戶數據等）
所有UAT腳本然後在PROD中對數據庫進行運行（您需要對腳本管理變更控制進行良好的紀律處理，以便輕鬆跟蹤這一點 - 但我們仍然無法始終保持正確）。刷新後，我們做而不是直接比較UAT和QA，並簡單地將更改回滾到UAT。
這是一個很好的煙霧測試/調試，因爲這些相同的vNext腳本需要在Production發佈時針對Production進行運行。
現代系統可能不需要顯式/外部版本遷移腳本（例如，實體框架代碼優先遷移將嘗試在第一次運行時升級數據庫模式），但在將這些數據應用到傳統數據庫或共享數據庫時執行此操作可能會有風險。

一些其他方面的考慮

剛上「腳本」循環記同步模式 - 在我們的環境中：

DEV是免費提供給所有 - 任何開發鉛可以使DDL或數據變化。
QA和UAT被鎖定 - 需要生成腳本（通常由SQLCompare），然後發送給DBA執行（在QA中）以及批准和執行（UAT）。（我們正在尋找自動化部署到QA的方式，但我們確實需要保留每個腳本SCM）則
這些腳本「每個環境」簽入源代碼控制和跟蹤

2012-03-01 08:49:10 StuartLC

真的沒有測試用例的要求，我們的UAT更多的是分期/最終標誌的關閉從客戶。功能測試用例在流程的早期處理。 – mwjackson 2012-03-01 11:02:22

我想我的問題是，你只是每個月使用一次數據庫備份，然後向前滾動遷移？ – mwjackson 2012-03-01 11:05:21

是的 - 通常有多個系統和團隊受到UAT DB刷新的影響（例如核心系統，倉庫飼料，報告系統等），所以每月一次的時間表在所有適用的利益相關者，測試用戶等方面變得「根深蒂固」。任何搞砸UAT環境的人都會被關在熱水中。 – StuartLC 2012-03-01 11:09:20

這裏是東西我們爲我工作的最後一家公司做過。我們有許多州政府的項目和合同。以下是我們在某些項目中使用的環境級別的示例。在下面的例子中，質量保證是爲我們服務的，UAT是爲客戶服務的，Pre-Prod是我們有時創建的另一種環境，但並非總是如此;只取決於項目。

DEV ==> QA ==> UAT ==> PRE-PROD ==> PROD

一旦所有的數據進行了驗證，我們從PROD向下複製到剛纔的一切的UAT和QA，包括任何DB有關。

我們還有一個爲某些方面編寫的工具，而不必總是使用SQL。我們有一個基於網絡的程序，我不記得它寫了什麼。我們稱之爲CTM - 控制表管理。在那裏，我們可以對錶格中的某些更改進行更新，更正，下拉菜單，拼寫和語法錯誤，以及任何其他問題。任何東西。有單選按鈕來提交更改和框來檢查您想要更改的環境。

希望這是對任何人的幫助或給人一些想法。 :-)

感謝，

約翰

2016-08-09 19:09:39

回答