是否值得設計一個系統，以期望測試帳戶和產品在生產中處於活動狀態，或者即使您的船員知道測試實體不會污染生產數據庫不要發送任何寄給「測試客戶」的郵箱？生產系統中的測試帳戶和產品
我已經實現了規範中具有test =「True」屬性的消息傳遞協議，並且想知道現代模式是否應該包含用於標記訂單，帳戶，交易等的元數據作爲測試實體，任何其他實體 - 但僅僅是金錢花費的點。即：它僞造了一張虛構的信用卡並僞造了一個包裹的運輸。
這不能替代完全獨立的測試，開發和質量保證數據庫，但即使對於這些，我們也一直在生產系統中使用着名的測試SKU和測試客戶。無害？
在生產中進行測試賬戶是我通常不願意看到的，因爲它會帶來潛在的安全漏洞。人們應該努力在儘可能多的生產環境中進行測試，但顯然這是不可能的。昂貴的生產硬件是一個很好的例子。我認爲，作爲一種普遍的做法，它應該是不鼓勵的，但如果你能提供一個對你有意義的理由，那麼你可能會忽視一條硬性規定。
我想象最佳實踐警方會說出「永不停止測試」的口頭禪，甚至可能會拋出「開發人員不應該獲得產品」。但是，我在一個基於大型機的系統上工作，其中生產和測試/ qa/qc之間存在巨大差異;系統越大，這種情況越可能發生。此外，在應用程序中擁有股份的團體越多，這就越有可能。
我需要兩個以上的手來計算我們只能在生產環境中複製問題的次數。然後，該選項將成爲創建測試表/用戶/數據或使用實時客戶數據。
有時候我們也會在生產表中創建測試記錄，因爲有些用戶/客戶喜歡他們可以搜索/檢索的東西總是存在的。
因此，我的建議是，如果測試帳戶/產品能夠在上線後進行故障排除，則可以投入生產。
我不會在生產系統中放置任何測試數據，也不希望作爲開發人員訪問此係統。
我正在一個非常敏感的醫療和金融信息行業工作，並且有這樣的信息會使測試系統無法區分生產和數據。
恕我直言，最好的做法是完全分開這兩個世界，並投資建立一個程序，以準備一個全面的測試環境。
在ERP系統（僅限內部可訪問）中，我們擁有測試數據，因此，當我們將測試變更從生產環境轉移到生產環境時，我們可以測試整個過程。我認爲數據是必要的惡魔，因爲系統之間細微的配置差異會導致災難性的結果，所以一旦產品發生變化，我們就會在將其「釋放」給用戶之前進行測試。
正如我所說，這些只是內部應用程序，所以安全風險有所減少 - 這是一個非常有效的問題。
永遠不要在prod中測試，即使這是所有收入產生的地方/統計數據被收集/魔術發生......？
總是有一個生產測試計劃。在產品上會出現問題，或者，如果你不走運，只有發生在產品上。如果你沒有任何東西，你第一次需要測試產品（通常是高負荷的情況下），你會在沒有槳的情況下爬上小溪。
對產品進行測試數據並不是無害的，你需要小心。
如果您的數據庫是以自動方式從腳本創建的，那麼這成爲一個無關緊要的問題。
在我的環境中，我們使用巡航控制進行連續構建。用於生成數據庫的SQL腳本與其他所有內容一起檢入CVS，並且每天都從這些腳本重建數據庫。
我們的測試數據是第二組sql腳本，它們針對測試數據庫運行，並且不運行生產數據庫。
鑑於我們的環境測試數據永遠不會觸及生產數據庫。
這個解決方案對我們來說真的很棒。
是一個崇高的目標，但並不總是我的經驗可行，因爲@tomasso指出 – cori 2008-09-23 14:42:33