2010-10-23 23 views
7

我在看SpecFlow的例子,它的MVC樣品中含有用於測試一些備選方案:基於驗證由控制器產生的結果如何在SpecFlow,Cucumber或其他BDD驗收測試框架中選擇不同的測試類型?

  • 驗收試驗
  • 使用MvcIntegrationTestFramework進行集成測試;
  • 使用硒的自動驗收測試;
  • 當提示測試人員手動驗證結果時,手動驗收測試。

我必須說我對SpecFlow示例的寫法(以及我在下載後幾分鐘內運行它們,只需配置數據庫並安裝Selenium遠程控制服務器)印象深刻。看看測試的替代方案,我可以看到它們大多數是相輔相成的,而不是替代方案。我能想到這些測試以下組合:

  • 控制器在TDD風格的測試,而不是使用SpecFlow(我相信鑑於/時/然後測試類型,應在更高的應用,終端到終端的水平;他們應該對各個部件提供良好的代碼覆蓋;在開發會話中運行的集成測試時
  • MvcIntegrationTestFramework是有用的,這些測試還將每天的一部分建立;
  • 雖然基於硒測試自動化,它們是緩慢的,並主要是在QA會議期間啓動,以快速驗證頁面和網站工作流程中沒有違反邏輯;
  • 提示測試人員確認結果有效性時的手動驗收測試主要是驗證頁面的外觀和感覺。

如果您在Web開發中使用SpecFlow,Cucumber或其他BDD驗收測試框架,請分享您在不同測試類型之間進行選擇的實踐。

在此先感謝。

回答

6

這都是行爲。

給定一個特定的上下文,當一個事件發生時(在一個特定的範圍內),那麼應該發生一些結果。

範圍可以是整個應用程序,系統的一部分或單個類。即使是一個函數也是如此,輸入作爲上下文,輸出作爲結果(也可以將BDD用於函數式語言!)

我傾向於在類或集成級別使用單元框架(NUnit,JUnit,RSpec等),因爲受衆是技術性的。有時我會在評論中記錄Given/When/Then。

在場景級別,我試圖找出誰真正想幫助讀取或寫入場景。即使商業利益相關者也可以閱讀包含幾個點和括號的文本,因此擁有像MSpec或JBehave這樣的自然語言框架的主要原因是,如果他們想自己寫場景,或者將它們展示給真正被點擊的人和括號。然後,我看看框架將如何與構建系統一起工作,以及我們如何賦予相關利益相關者適當的讀寫能力。

Here's an example I wrote顯示您可以使用簡單的DSLs場景做的事情。這只是寫在NUnit。

Here's an example in the same codebase顯示給定,何時,然後在類級別的示例註釋。

我抽象背後的步驟,然後我把屏幕或頁面放在那些背後,然後在屏幕和頁面中調用我使用的任何自動化框架 - 可以是Selenium,W​​atir,WebRat,Microsoft UI Automation等。

我提供的示例本身就是一個自動化工具,所以這些場景通過演示假gui的行爲來演示自動化工具的行爲,以防萬一發生混淆。無論如何希望它有幫助!

+0

謝謝你一個很好的答案,並且這些例子非常好。我會仔細看看你的WipFlash。雖然我沒有在我的curreny項目中使用WFP,但WipFlash可能會提供關於自動化和測試UI的一些想法。 – 2010-11-01 06:25:56

2

由於驗收測試是一種功能測試,總體目標是測試您的應用程序與他們端到端。另一方面,您可能需要考慮測試自動化的效率(實現測試自動化需要多少努力),可維護性,性能和可靠性。測試自動化很容易適應開發過程,這也很重要,因此它支持一種「測試優先」方法(以支持外部開發)。

所以這是一種折衷,對於每種情況都可能不同(這就是爲什麼我們提供了替代方案)。

我敢肯定,今天最廣泛的選擇是在控制器層進行測試。 (也許隨着UI和UI自動化框架的發展,這將會發生變化。)

相關問題