ATDD - 驗收測試從哪裏開始？

我想了解驗收測試，但我很困惑它從哪裏開始或涉及什麼樣的測試/ s。我是否必須使用自動化GUI測試框架，還是必須使用單元測試？驗收測試的邊界是什麼？ATDD - 驗收測試從哪裏開始？

編輯：我的問題是關於自動化驗收測試。

來源

2012-10-10 Rookian

單元測試不應與驗收測試混淆。

驗收測試基本上要求，寫作測試，這樣：

時要求得到滿足很明顯;
實際測試更容易計劃和運行。

單元測試針對小的代碼比特，用於保持對所有的小位眼睛而不需要常數（和多恨）手動檢查的自動化測試。

來源

2012-10-10 19:03:18

是的，但我需要一個GUI測試工具，如華廷或硒或有其他possibilites？我聽說很多次GUI測試工具很麻煩，維護不好和速度慢。 – Rookian

你可以沿着UI道路走下去。 Selenium或WatiR是可以用來運行基於ui的測試套件的可靠工具。如果你是Dot.Net開發者，你可以使用WatiN，但問題在於它似乎已經死了，因爲自2011年4月以來它沒有新的版本。

我確實設法有一些體面的測試套件爲我工作了一陣子，整合SpecFlow（稍後更多）和watiN，並且它工作正常。然而，隨着時間的流逝，我意識到當我在做基於UI的測試時，我所做的只是加載一個頁面，點擊一下，然後檢查數據庫中的結果。有時候，我還檢查了屏幕還顯示了預期的消息，但僅此而已。這個結論讓我失去了基於UI的測試。

我開始做的是確保用戶界面是建立在規則和成語之上的。現在的工具（asp.net mvc，剃刀模板或更好的 - knockout.js）使我們可以做到這一點，沒有太多的痛苦。當UI是有條不紊地構建的，而不是每個人都在頁面上拋出他們喜歡的任何字段時，大多數時候你需要測試的只是構建它的方法，而不是結果。 Ofcurse，如果我想測試一下（在某些情況下，你會），這是很容易，速度更快與像QUnit工具來測試它，

所以我練ATDD的路電流：

使用specflow將業務需求轉化爲測試代碼。
只測試「後面的代碼」。
對UI管道使用knockoutJS（使用大量自定義綁定）
爲返回到視圖的模型創建標準。
將UI行爲測試視爲單元測試。

這裏是specflow一個很好的起點：http://www.infoq.com/articles/Spec-Flow

來源

2012-10-10 21:03:31 motime

我使用Machine.Specifications。僅測試「後面的代碼」的問題是您可以擁有100％的代碼測試覆蓋率，但是您仍然存在缺陷。該觀點仍然有一些邏輯必須經過測試。而當javascript也涉及它變得越來越複雜。 http://lostechies.com/jimmybogard/2012/08/22/thatconference-presentation-content-posted-functional-testing-in-mvc/ – Rookian

驗收測試是整個應用程序/軟件後進行開發和集成。驗收測試主要是爲了測試應用程序是否符合用戶要求。

主要有2種驗收測試。

Alpha測試階段
Beta測試

驗收測試主要是通過客戶端（人誰問的軟件開發）和最終用戶來完成。

Alpha測試階段是由客戶端來完成。他由開發人員幫助。客戶在這裏查看軟件以確保滿足他的所有要求。 Alpha測試階段完成後

Beta測試完成。這裏的應用程序發佈給一組行爲最終用戶並使用應用程序的人。

來源

2012-11-22 16:20:40

ATDD - 驗收測試從哪裏開始？

回答

相關問題