行爲驅動開發（BDD）方案vs用戶方案還是用例差異？

Question

我是BDD的新人。所以我有一些關於場景的問題？ BDD方案和用戶方案之間的區別是什麼？與所謂的傳統「用戶場景」或「用例」有明顯區別嗎？你能解釋更多嗎？

Answer 1

既然你剛纔提到的「傳統用戶方案」，這是一個有點含糊，我假設你指的是用戶故事的描述：

作爲[作用]
我想要[目標]
因此[效果/益處]

這是用戶故事描述，它需要描述用戶應該如何與系統行爲的場景。這可以通過各種方式完成。其中之一可能是BDD。現在，BDD並沒有特別定義如何編寫他們的場景。所有它定義的是，

• 應該有開發人員，測試人員和業務之間的明確溝通
• 這種溝通應該是一個簡單的格式，它是所有
• 例子理解應該通信用於指定&明確的要求

第一點是確保在要求中沒有歧義，並且反饋能夠在三個團隊之間快速分享。第二點確保每個人都使用一種所有人都能理解的語言，並且不會給每個人留下任何含糊之處。例如，測試人員可能會寫一個場景爲：

When I drop a file to FTP location, then it's FTP information should be validated and file should be sent 

但是Business可能不熟悉FTP/FTP位置/信息驗證是什麼。更好的辦法是使領域特定語言的情景（DSL），像

When a file is dropped in send location, then validate it's credentials and send the file 

---

一種方式實現上述兩點是使用小黃瓜語言。小黃瓜是有語法如下一個DSL語言：

Given [Precondition] 
When [Action] 
Then [Result] 

擴展我們前面的例子：

Given user drops file "sample.txt"in "Send File" location 
When the credentials for file "sample.txt" are validated 
Then the "sample.txt" should be sent to "Receive File" location 

正如你所看到的，它幾乎一樣我們前面的例子，但我們有使用了一個用戶放棄文件的例子，從而大大減少了歧義;也用於非技術性的語言，但所有人都可以理解。

同樣可以寫成Verify that file FTP credentials are valid and fie is sent through FTP但是在這裏我們可能錯過了前提條件，或者最終結果可能不明確。而語言更具技術性，所以生意不會理解它。而且企業還沒有提供任何示例來解釋他們真正想要的內容，因此我們的方案可能與企業真正想要的內容無關。

爲了避免所有這些混淆，BDD建議商業，測試人員和開發人員都坐在一起並一起寫下功能和場景。這允許交叉問題，例子和快速反饋。這樣做的另一個好處是，由於企業參與制作這些場景，場景的重點將更多地放在系統的行爲上，而不是技術方面。如果一個系統使得A進入一個房間並且B離開，那麼無論房間中正在進行什麼過程，輸入和輸出或行爲都是相同的。系統不應該因爲有人將房間從正方形改爲圓形而破壞。這是流程變化，而不是行爲變化。

此外，看看這個職位here。