我们正在转向更精益的方法，看板很多。我们开始将我们的用户故事分解为很小的用户故事，但是有很多问题正在提出，哪些故事应该有验收测试，哪些不应该。为“精益”用户故事编写验收测试
例如，我们已经分手一个故事变成2.首先创建一个实体和一些基本领域。另一个扩展在这些领域，并增加更多的功能。通常我们会在第二个故事结束时编写验收测试。但是，我们现在应该写一个小的验收测试，我们有一个较小的故事，然后在我们做第二个故事时扩展验收测试（s）？
它的论点是，所有的故事都应该是可测试的，反证的论点是它的反倾向性，因为我们正在分裂故事以让他们更快地接受测试人员，但是通过编写验收测试（在小逻辑和测试无论如何，它们都会变慢）。 Lean如何通过精益用户故事进行验收测试（或BDD测试），达成了什么共识？
从维基百科引用：
” ......一个用户故事是由在一个或多个句子的说明终端用户或系统用户的日常或商业语言，它捕捉用户做或需要做的工作功能的一部分“
在这方面，验收测试很有意义。验收测试是需要勾选以满足用户故事的“勾号框”。
你所描述的听起来很像技术性任务。验收测试在这方面没有意义，因为最终用户无法接受。单元测试和集成测试将更适合这个粒度级别。
所以，当你看一个故事，你可以识别需求的层次结构。程序将要执行的功能需求，功能所需的派生需求以及描述如何执行该功能的服务需求质量。
所有要求都是可测试的。要求的测试是组件测试的总和。只有在每个派生要求和服务质量合格的测试通过时，此测试才能通过。 Derived要求的测试可以是产生新的衍生要求和qos标准或单个测试的节点。测试服务质量通常需要收集性能指标，例如资源消耗和及时性。
例如，你可能会写的人创造你的服务的用户测试。
的功能需求是，用户能够创建一个帐户。
部分衍生要求：验证码，电子邮件验证和持久服务器。
的服务质量对于这些需求将进一步描述用户体验（验证码将有字符4和7之间等）
你可以开始看到这个结构之间的平行和Odedesigne随着需求在结构树中扩散。这个想法是，所有需求都有相应的测试代码，测试代码作为整个项目的一种文档和开发概述。
当你开始给它测试人员的测试代码的实现提供了补充报告与产品体验测试人员直接技术指标。
因为如果你在设计一个音乐流媒体服务，您可以编写一个测试，说一个用户的音乐不会跳过，从来没有超过内存使用阈值的例子。然后通过给用户提供alpha/beta产品并观察测试结果，开发人员可以看到他们的软件在真实世界中的表现如何。
希望考虑在这些方面的测试将帮助你实现的东西:)