在使用BDD Gherkin语言时，不直接由人类驱动的特性使用哪种样式？
如果它们的书写方式与人类工作流程相同，那么第一个人“我已经进入了.”风格语言等等？用户实际上是一个没有性别的"AI“吗？
回答 2
Software Engineering用户
发布于 2015-07-28 13:55:09
所有的软件最终都是按照某个人类用户的要求服务的，而用户故事就是满足这一要求的。因此，用户故事中对机器或其他技术项目的任何引用通常都是实现细节。
看看这个商业例子：
Story: Returns go to stock
In order to keep track of stock
As a store owner
I want to add items back to stock when they're returned
Scenario 1: Refunded items should be returned to stock
Given a customer previously bought a black sweater from me
And I currently have three black sweaters left in stock
When he returns the sweater for a refund
Then I should have four black sweaters in stock
Scenario 2: Replaced items should be returned to stock
Given that a customer buys a blue garment
And I have two blue garments in stock
And three black garments in stock.
When he returns the garment for a replacement in black,
Then I should have three blue garments in stock
And two black garments in stock请注意，尽管用户故事非常详细，并且在库存过程中可能涉及到一些“库存机器”，但是用户故事中没有提到该机器。
现在看看这个用户故事：
As a Creator, I want to upload a video so that any users can view it.没有提到任何技术。但是，如果您开始将用户故事分解为更详细的内容：
As a Creator, I want to upload a video from my local machine so that any users can view it.
- The “Upload” button will be a persistent item on every page of the site.
- Videos must not be larger than 100MB, or more than 10 minutes long.
- File formats can include .flv, .mov, .mp4, .avi, and .mpg.
- Upload progress will be shown in real time.现在您已经有了需求的开始。
当然，没有什么能阻止你把机器当作演员看待。如果你想这样做，只需给机器一个描述它的角色的通用名称，就像你想让一个人：
As a host machine, I want to collect statistical data to track [some resource] usage.进一步阅读
用Gherkin来写有意义的用户故事
如何编写有意义的用户故事
Software Engineering用户
发布于 2015-07-29 17:13:37
BDD实际上是从一个单元级别开始，其中类的用户是其他类！因此，让一个技术元素作为另一个技术元素的用户是非常合适的。不管是“类”、“模块”、“库”还是“服务”，概念都是一样的。
这两种不同类型场景之间的一些差异是：
- 方案的重点是系统功能，而不是用户功能。
- 交互是通过API而不是UI进行的。
- 场景的最终目标可能是针对另一个系统而不是用户(尽管在某些情况下(例如，当该值被立即消耗时)，用用户值来表述这些场景可能是值得的)。
有些事情确实是一样的；特别是，与拥有必要的专业知识并能告诉您需要做什么的人讨论场景。你的谈话可能是这样的：
“因此，当数据引擎获得新交易时，它必须要求风险计算器重新计算风险，然后相应地调整国家、组织和货币的交易对手限额。”“你能举个例子吗？”“当然。假设我们与一家大宗商品交易商的比利时子公司进行了一笔价值300万美元的铁矿石交易，而我们对该交易商的风险敞口已经很大，接近交易对手的上限……”
丹·诺斯( Dan )首先提出了BDD，他喜欢在场景中使用第一人称，因为他说这能帮助他想象那个人、类、系统等必须做的事情。
我喜欢使用第三人称，因为它帮助我找出是否有缺少的利益相关者，他们的结果也很重要。
这两种方法都是编写方案的有效方法。在上面的一篇文章中，演讲者自动使用“我们”来表示组织。在这种情况下，“我们”实际上代表了两种系统:交易预订系统和持有交易对手限制的系统。
一个交易预订系统通常有它自己的UI，但是您不会从那个级别进行编码；您将通过数据引擎的API，因为这是您感兴趣的系统。
此外，该方案的最终结果仍然是，交易对手的限制被更新。在生成相关报告之前，任何用户都不会看到这一点，或者他们接近到触发警报的极限。
“你能给我举个例子吗？”仍然是一个非常容易的方法，使这些例子，以及他们表达他们的要求的自然语言.无论这些要求是在哪个层次上表述的。
https://softwareengineering.stackexchange.com/questions/291069
复制相似问题
腾讯云开发者
