2014-06-10 48 views
1

如何編寫和運行自動化測試來檢查我的數據庫事務策略是否消除競爭條件?目前我所做的只是在開發中通過在代碼中放置一個斷點併發送兩個請求來進行測試,然後我可以用慢鏡頭看到會發生什麼。這不是我可以自動化的東西,它甚至不是真正的測試,只是開發的一部分。測試數據庫事務

回答

1

您的測試可以產生線程並運行兩個或多個線程,使相同的請求被事務隔離。

+0

但在這種情況下,如何強制第一個線程花費更長時間,以便第二個線程在事務過程中嘗試更新? – shmish111

+1

在第一個請求中發送足夠的數據以確保更新需要更長的時間。第二個請求應該只有一小部分數據。 –

+0

我喜歡這種提供有效載荷的想法,我們知道需要更長的時間。不幸的是,我不這麼認爲。 – shmish111

1

用真實的工作負載進行負載測試。不幸的是,這並不容易。在任何平臺上很難發現種族條件。我知道沒有系統的方法來找到這樣的錯誤。

有時您可以排除構建不一致的可能性。例如:

  • SERIALIZABLE下運行的事務表現得好像它是系統中唯一的事務。因此,從來沒有數據競賽。
  • SNAPSHOT下的只讀事務的行爲方式相同。總體數據一致性。
  • A UNIQUE INDEX永遠不會違反其完整性保證。

正如你可以看到你有時會令你的代碼安全施工,以便有最小的必要測試。

+0

我的意思是我嘗試這樣做,但是如果有人出於某種原因剝離了我的事務管理或以某種方式繞過/破壞了它,那麼直到產品崩潰纔會被發現。這是我想測試但看起來不能,我想唯一的解決方案是負載測試。 – shmish111

+0

對。這個答案描述了我所做的事情(而且我*必須處理系統中的併發)。您可以像「SELECT @@ TRANCOUNT,ISOLATION_LEVEL」一樣向您的代碼添加斷言,並在運行時聲明您在正確的設置下被調用。我使用這種技術來查找不可重現的產品bug。原來99%的代碼路徑很好,但是在1%的事務錯誤配置的情況下。 – usr

+0

我非常喜歡「正確的構造」代碼模式。例如,所有隻讀trans我做SNAPSHOT。所有低容量的反編譯我都可以序列化。只讀插入在READ COMMITTED中總是安全的。現在我可能已經用很少的努力和高信心使得90%的代碼安全。 – usr