2011-08-23 90 views
3

使用Specflow,我正在編寫一套場景模擬月薪,驗證每月計算的付款以及最終的年終數字。Specflow - 「場景」之間的狀態

每個月的結果都是累積的,因此每個後續情景都取決於上個月的增加和減少。支付計算通過第三方工具寫入數據庫,因此在各種情況之間創建和銷燬測試數據非常昂貴。

根據我的測試經驗,我知道並不總是可以確保測試的執行順序。我可以用一些場景命名約定來控制執行順序,但不能保證遠程測試運行器將按字母順序運行測試。

選項,我認爲:

  • 通過一個單一的情況下,包括大量的給定的時候,那麼斷言運行整整一年。這會導致一個難以閱讀的巨大場景。
  • 爲每個場景創建一個「給定」級聯。 「鑑於:所有到X月的付款都已完成」。這會創建大量的數據庫流量,因爲每個場景都需要創建和銷燬測試數據。

是否有更好的方法來在場景之間存儲狀態並確保場景按照所需的順序執行?

+0

您也可能會發現這個答案有幫助,如果您將它映射到您的問題上,並且您想要執行的測試類型選擇較高級別的抽象: http://stackoverflow.com/a/23375756/936469 – realtime

回答

4

依靠場景的執行順序是一種反模式,應該避免。出於同樣的原因,測試運動員通常不會提供任何控制執行順序的機制。這也會違反可執行規範的概念:該方案應該可以自行理解(並且可執行)。

在你的情況下,給定的部分應該爲有問題的計算準備數據,當應該計算,然後應該檢查單個計算的結果。

爲了縮短執行時間,您可以嘗試選擇「重要」場景,以便測試不同方面。可能沒有必要每個月1-11測試一次。你可以爲第一個月的工資單進行一次測試,一個爲第二個月,一個爲結束一整年,一個爲開始新的一年等。

這也是一種常見的技術,給定不一定是與「真正的應用程序」(從頭開始)完全相同。有時你可以在測試中做快捷鍵,以更快更簡單的方式確保先決條件。例如。你可以指定上個月的總和,如果這是你所有的場景需要計算下個月(而不是讓應用程序從頭開始計算所有東西)。當然,你必須知道你在做什麼,你必須考慮僞造應用程序某些方面的風險。

+0

感謝您的反饋。我已經欺騙了「整個一年」的情景。提供以前的每月付款計算不是成立的,計算太難以模擬。 – Cr1spy

+1

「計算」太難以模擬了嗎?當然,前一個月的結果可能是靜態數據 - 事實上,您正試圖在步驟之間存儲的數據恰好是? – perfectionist