为实现新功能而实施的单元测试都是绿色的（自动构建和CI确保了这一点）。
接受/故事测试已编写并通过。（它们在BDD工具中）
回归测试是绿色的，具有已知的失败。（自动）
已经进行了足够的探索性测试，以确保新功能的正确性并确定它可以按预期工作。
DTS或积压订单中存在未解决的缺陷。
代码覆盖率超过x％。新的实现方式并未对代码Covergae造成任何退步或影响（即自上次冲刺以来，代码Covergae最好有所改善或保持静态）。 ？如果是的话；还有什么其他东西可以帮助我作为测试人员来决定何时停止测试特定的用户故事并选择另一个故事。测试人员的直觉或直觉之类的东西。
#1 楼
理想情况下，每个用户故事的DoD应该意味着该用户故事的所有测试均已通过，并且所有自动化均已完成，作为整体自动化的一部分（而不是在一个人的机器上）运行，并且没有错误。 />现实世界通常意味着妥协，因为几乎没有足够的时间或资源来涵盖任何给定用户故事的所有潜在隐患。
与国防部一起考虑的因素是：
时间表-您是否有一个“艰苦”的期限，还是可以抽出所需的时间？ （或介于两者之间）。期限越艰巨，国防部就越倾向于钢线。在这种情况下，测试不是钢铁威胁的任何东西都将成为项目的一部分，有时还会成为开发积压工作的一部分。
外部依存关系-您的工作越依赖第三方的绩效或来自第三方的信息，您就需要在国防部中留出更多的空间来弥补外部供应商沟通或绩效上的失败。有时您需要明确声明，如果没有供应商Y的X项，就无法实现DoD。但您尚未打破以前的工作方式）-我认为这可能是唯一未明确列出的项目。
#2 楼
房间里的大象：维护。我们如何维护此新功能：
需要配置什么？
我们可以轻松地进行配置吗？推出（什么是推出？）？
我们需要哪些支持工具来快速解决生产中的问题？
我担心有一天全人类将在维护代码我们的祖先...
想到孩子们！
评论
+1用于引入新点，这些点通常由于疏忽而被忽略。
–拉杰涅什（Rajneesh）
11年7月18日在11:27
如果您使用适当的工程实践（在通过迭代构建东西时成功必不可少），那么整个代码往往更易于维护。 （“下一次迭代”中完成的工作在很多方面都与上一次迭代中生成的代码的“维护”完全相同。如果需要支持等工具，客户应将其指定为他们希望在构建过程中构建的一些故事该项目，以及诸如可配置/定制功能之类的东西。在任何情况下，请相信我，您宁愿维护敏捷团队而不是BDUF团队生成的代码。
– Chuck van der Linden
2011年7月21日在23:29
#3 楼
有几种有用的试探法可以停止测试。我能想到的一些事情'没有更多的时间'-即我们由于企业规定的截止日期而停下来。
您来了解一下您打算了解的内容吗？该功能（您确实为测试会话设定了特定的目标吗？）一篇不错的博客文章，列出了这些（以及一些其他内容）比我能说的要雄辩得多。
#4 楼
我对完成的定义通常是“我们不必担心（例如触摸，测试，做任何事情）该功能就可以发布代码。在上面看到的是Ken Schwaber去年在加拿大一家名为Pyxis的公司的演示文稿，它在U型管上分为三个部分，第一部分在这里#5 楼
在以前的生活中，我们使用看板和任务以及每个任务的时间估计来定义要完成的工作以及用户故事中剩余的时间。对于我们来说，国防部就是将特定用户故事的所有任务都移到看板的“已验证”列中。唯一的问题是，确定哪些任务不准确需要做的。我们确实在冲刺前的计划会议上花费了很多时间，以散列所有任务和时间估计，因此，真诚地，我们希望完成用户故事所需的一切都已完成。有可能我们没有为应该进行的单元测试指定任务，或者没有涵盖特定的数据配置，但是，假设我们预先进行了所有尽职调查，则可以作为国防部使用。 >实际上，通常最终会发生的事情是艰苦的最后期限悄悄地出现在我们身上，我们不得不牺牲国防部作为高优先级任务。这意味着诸如代码审查，自动回归测试和其他任务之类的东西被扔到了待办事项列表上，再也看不到了。
#6 楼
我真的没有时间发表自己的意见，但这是迈克尔·博尔顿（Michael Bolton）的观点，我很珍惜并信任他。它可以帮助您下定决心...
评论
你能在他的帖子中总结他的意见吗？ StackExchange礼节不赞成答案，而不仅仅是链接。
–卡扎尔克
13年2月21日在21:21
#7 楼
首先，您的问题是非常主观的，并且完全取决于您的上下文，因此没有一个适用于每种情况的答案。也就是说，在尝试确定是否已经足够测试用户故事时，您需要考虑很多事情并评估其相关性。哪些测试维度是与您的产品和以下特定用户故事相关或构成风险：性能，可靠性，本地化，可支持性，可测试性，安全性，文档，可维护性和兼容性（除功能以外，此列表并不详尽）。其中一些可能包含在您的BDD测试中，但是值得仔细阅读这些类型的列表，以确保您没有忘记关注重要的内容。您应该知道哪些区域对您的产品更感兴趣或对您的产品构成更高的风险，以及这些区域是否被充分覆盖。通常，只专注于一个测试领域会很快发现错误，然后错误率会降低，这时值得散焦并关注另一种类型的测试/领域。进行一系列的聚焦和散焦可以帮助您到达一个明显可以作为一个很好的起点的地方。这是James Bach的RST的概念。您说“已经完成了足够的探索性测试”，您如何知道已经完成了足够的工作？使用“聚焦”和“散焦启发式”，您可以开始对此进行评估。当然答案是您不知道的，但您可以显示如何明智地决定停止。
其他值得考虑的概念：
仅测试用户故事而不是整体测试应用程序是一个错误，您很容易陷入使用敏捷的困境。为您的国防部完成所有用户案例后，项目是否已完成？答案可能是肯定的，但值得思考。
尝试做某事时，忽略测试和风险的财务影响。请记住，一家公司（通常）正在尝试从一款软件中获利，因此在进行测试时要兼顾这一点，以保持这种想法。可能是在您的特定上下文中，测试资源（时间和技能）有限，有些用户案例根本不值得进行测试，而另一些用户案例则需要更多的资源。
列表中无用的内容：
代码覆盖率百分比目标。这些没有帮助，因为您可以100％没有断言并且不进行任何测试。已实现目标，但未进行实际测试。在开发测试以查看未涵盖的内容并质疑未覆盖区域是否应该进行测试时，覆盖范围非常有用，当然，风险，时间和环境将决定是否向未覆盖区域添加测试。这并不意味着涵盖的所有内容都经过100％测试，并且可以在所有情况下正常运行。不要用它作为温暖的毯子来说明您的产品/用户故事已经完成。
评论
什么是钢线？我不明白第一点。
– Aruna
2011年6月13日在18:39
嗨阿鲁娜钢线或快乐之路是完成功能必须绝对要实现的项目。这些是无论如何您都无法削减的东西。
–凯特·保罗（Kate Paulk）
2011年6月13日19:15
从未听说过“钢丝”一词，但我喜欢它。 +1
– MichaelF
2011年6月13日19:32
“钢线”背后的想法是，在任何一个用户故事中都涵盖了一个单一的，重点突出的功能/路径。例如，用户故事可以说“用户将单击按钮X以便验证数据记录Y”。除了确保按钮X验证数据记录Y以外，其他任何操作都不是钢丝。因此，提供了一个用于反转验证的选项，它不是钢制螺纹，应转而使用其他用户故事。
– TristaanOgre
2011年6月13日19:40
那么，在钢丝上发现的臭虫是否称为臭虫？
– dodgy_coder
2011年10月21日在7:24