如何使用Cucumber在功能級別編寫驗收測試？

Question

JBehave是基於Java的&，適用於Java應用程序。 JBehave也支持良好的HTML報告。但是，JBehave的問題是它只支持Story級別而不支持Feature級別。

這裏的任何人可以幫我一個小解釋或文件，我可以理解Cucumber如何支持功能級別？

Answer 1

功能是功能的實現（功能可能需要多個功能）。

讓我們看一個「故事」的Mike Cohn's description，因爲這是相當不錯：

用戶故事很短，一個功能的簡單描述從人的 角度來看誰想要新的能力告訴記者，平時一個 用戶或系統的客戶。他們通常遵循一個簡單的 模板：

As a <type of user>, I want <some goal> so that <some reason>. 

一個好的用戶故事遵循INVEST principles，而這正是我們開始進入場景：

• 獨立，這意味着它可以被傳遞上它自己的

一個故事可能有一個或多個上下文其中的功能將t工作。上下文的性質與其他上下文無關。

• 元，這樣你就可以把它改寫

當你通過一個故事的工作，你可能會發現其他情況下或需要考慮的結果。功能的核心功能通常與「何時」相關聯。舉例來說，如果我想成爲能夠生成報表時，「時」將是，「當我生成的報告......」

• 有價值的，所以它創造價值的利益相關者

可能有幾個利益相關者有不同的結果。例如，發送電子郵件說出租車已被預訂很重要，但是也可以向司機發送預訂確認信！通過考慮不同的利益相關者，我們想出了需要考慮的情景的結果。

• 估，這樣你就可以估算大小

如果無法估計的大小，儘量剛開一個場景中工作。這是Kent Beck的「秒殺」功能。順便提一下，你需要估算的唯一原因通常是找出是否值得去做，考慮到可以完成的其他工作，請相應地對待。

• 小，它（快速編輯，因爲我意識到我錯過了這封信）意味着你應該有一定程度的確定性。

其實我更喜歡人們知道他們有不確定性關於它的一些水平，並期待得到的反饋儘快。如果你確實確信它（例如：登錄），那麼它可以做得更大，因爲你需要的反饋較少;你知道「工作」是什麼樣子。

• 可測試，這意味着相關的描述必須包括足夠以測試它

實例成爲測試作爲該分析的一個很好的副產物。

爲什麼我們首先要做故事？爲什麼不只是提供全部功能？

事實證明，獲得某些功能所需的工作最終會變得相當龐大，特別是如果您涉及到很多利益相關方，並且我們希望將它們分割開來，以便我們可以早點獲得它們的價值，或者我們想要分割它們以便我們可以獲得反饋。

因此，一個故事可能是通過一個可以實際發貨的功能的一部分，或者它可能是爲獲得反饋而設計的。

情景是一個很好的方法！該特徵可以縮小到最有價值的環境，或者需要考慮其結果的不同利益相關者。注意不要消除交易需求（ATM上的用戶獲得資金;銀行借記賬戶）或監管需求（銀行進行重大投資;監管機構看到資本儲備變化）的利益相關者。

方案不是只有獲取功能反饋的方式。新的UI？硬編碼它沒有任何行爲，並顯示給人。新報告？製作一個模擬副本。新的飼料，沒有人曾經處理過？做一個高峯，看看你是否可以從中得到你認爲可以的信息。否則，考慮需要考慮其結果的不同情境和利益相關者，並考慮與他們的情境和結果不同的能力。功能實現了不同的需求，其行爲由您所派生的場景來說明。

由於故事是通過一個功能片，和功能實現能力，這是一個典型的層次結構：

• 利益相關者
• 目標
• 能力
• 功能
• 故事
• 場景

如果您正在努力研究如何將情景與故事和功能聯繫起來，這不是一個糟糕的方法。如果你看看Gojko Adzic's "Impact Mapping"或Matt Wynne's "Example Mapping"（我想我們都聽到Chris Matts的話），你會發現它很熟悉。

要小心，因爲在現實中這有點模糊;當你開始交付時你會發現，所以不要提前打破所有事情。我發現功能可以製作出優秀的規劃級別的工件，並且通常很容易與「Epics」相關聯。他們還帶着自己的高級測試：「我們的用戶能夠做他們需要的嗎？我們需要考慮的背景以及需要哪些利益相關者的成果？」

一個故事的技巧是隻考慮什麼是需要創造價值，直到它實際上完成了...然後一些，其餘的將是下一個件事是需要的，等

對於更多的想法，這是我的博客上capability-based planning and lightweight analysis，並在splitting up stories另一個。

黃瓜，通過能力組織，然後（如果需要）的情況下，並用標籤的故事數自己的簽到（CI大部分工具，電路板和電子版本控制系統支持此）。功能或故事可以創建更多場景。