在我们的组织中，我们正在实施敏捷。现在，我们在收到故事后就立即开始测试，从不去测试案例。我们根据接受标准测试故事。我的问题是：我们是否在真正的敏捷过程中编写测试用例？如果是，何时？

评论

当然，您需要测试用例来保证行为的安全，但是要自动化测试用例：less.works/less/technical-excellence/test-automation.html

#1 楼

也许你会做，也许你不会。首先确定要完成的任务，然后确定要执行的操作。这实际上取决于项目，人员，公司和期望。

我的观点是，如果测试用例在实际测试中有所帮助，那么可以编写它们。如果将它们写成“只是因为”，那不是敏捷。

评论

您的答案对思考过程很有帮助。但是他显然在问他是否需要在敏捷中编写测试用例？您对这个Q @George的回答是什么？

– NarendraC
16年11月30日在5:59
没有大量有关项目的信息，就无法说他是否需要用敏捷编写测试用例。我认为有很多论点，很多人反对编写各种类型的测试用例，计划和文档，或者关于什么是测试用例，或者您想用它们完成什么的争论。

–乔治
16年11月30日在16:05

#2 楼

是的，在敏捷中，我们确实需要测试用例。基于故事，我们创建测试场景，并且基于测试场景，我们创建测试案例。因为在冲刺结束时，我们必须执行测试关闭活动，我们要在其中显示我们的测试工件（测试用例和测试方案）。
所以答案是肯定的，它应该在您尽快开始了解故事。

评论

您是说只是因为必须显示测试用例而编写测试用例？那我不明白它的价值。

–乔治
16年11月29日在11:31
@George，其价值是帮助证明工作已成功完成。

–汤姆·鲍恩（Tom Bowen）
16年11月29日在16:36
但通常，您可以通过执行测试而不生成文档（编写测试用例）来证明工作（项目）已成功完成。我并不是说测试用例当然不能帮助进行测试。

–乔治
16-11-30在16:34


-1，完全不同意这个答案

– FDM
17年5月30日在16:55


#3 楼

我们需要敏捷中的测试用例吗？是

我们需要在Waterfall中使用测试用例吗？是的

有什么区别？

关键的区别在于，在敏捷中，您需要最简单的测试用例。这通常被称为示例而不是规范。然后，您可以使用该示例来开发该功能，将其投入生产，获得真实用户的反馈，然后将下一个简单的小示例功能组合在一起并重复该过程。在这里您可以尝试预先开发完整而完整的规范。然后，实际的实现只是编写反映和实现该功能的软件和测试，

#4 楼


敏捷：




理解，敏捷是定义软件开发所要进行的方式和活动的方法论。
它并没有消除核心开发和测试过程的步骤
肯定会通过减少传统过程中的障碍和每个步骤与其他步骤的相互联系而增加生产率，
由于相互联系，一个将起作用并且需要依赖的人来等待其他步骤的完成


我们是否在敏捷中使用/需要测试用例？



肯定是的，我们也在敏捷中也需要测试用例
敏捷以团队和任务之间的并行实现和执行而闻名


何时用敏捷编写测试用例？



一旦完成针对特定变更/功能的规范，开发团队开始编写代码以实施。这是您需要开始编写测试用例并进行头脑风暴以记录和确定最终使用方案的时候
，在开发团队共享构建以进行测试之前，您应该准备好所有测试用例


评论

我不能满足于我的书呆子自我：敏捷是一个模型，方法，技术，人工制品等的应用才是构成方法论的基础。

– Mark C
16年11月29日在15:01

#5 楼

是的，您需要在敏捷开发环境中使用测试用例。问题是“什么是测试用例？”。如果您正在考虑逐行的说明性案例，那么我非常怀疑。如果您的意思更像是启发式方法和行为的关键示例，那么我非常希望如此。

可能会结合起来。有些情况可能是说明性的，以解决法律/财务审核要求和“证明”测试的发生，而另一些情况则更像是准则，为低风险领域提供了可遵循的示例并确保测试覆盖范围，而另一些情况可能仅仅是针对探索性测试会议。希望将有更多自动化（测试脚本）以针对CI版本执行。

无论您使用的是什么测试用例，都应该可以帮助您交付高质量的软件，帮助提供构建和交付软件所需的清晰度/理解/定义水平。如果不是这样，而您正在使它们变得不习惯，则您可能会陷入一种更加笨拙的方法，而不是敏捷的方法。

#6 楼

听起来您有测试用例，但您称它们为接受标准。除非出现问题，否则没人真正关心测试用例，然后人们会想确切地知道测试了什么。在构建要测试的版本之后，您可能会想到其他测试。

#7 楼

我同意这取决于项目，但是在大多数情况下，由于以下原因，答案是“是”：


您需要了解如何准确地检查验收标准
在创建测试用例时，您将考虑用例并提出可能有助于发现文档缺陷并节省开发和测试时间的问题，尤其是当您准备好故事编写后立即开始编写用例时。
在sprint结束时，具有一组处于“通过”状态的测试用例将减少团队对发布质量的忧虑。
发布后一切如常，测试用例将帮助您了解应该在哪些领域进行测试涵盖得更好（并在发布后的责备游戏中为您提供一些保护）
如果缺少文档，您的测试用例可能会成为X之前开发的功能的参考，这应该是X之前6冲刺应该真正起作用的
您将需要一些有关回归测试的参考，无论是手动还是（最好是）自动完成。

但是，我想我理解您问题背后的原因。通常，在敏捷团队中，创建详细的测试用例的时间少于您想要的时间，因此，似乎可以用一些捷径来节省一些时间并节省编写时间。我的经验告诉我，您最终将至少重新编写某种形式的测试用例，因此最好早些开始。如果发布时间紧迫，则可以创建清单，其中包含您或熟悉项目的其他人测试故事所需的最低限度数据。 >检查用例X
如果是Y怎么办？
不要忘记Z的可能性


#8 楼

测试用例与单一类型的项目管理都没有关联，手动或自动用例也没有。这是通过使用测试用例来实现的。易于随时间适应。您将要测试的软件/网站/应用很可能会更改，并且您的测试也将随着时间的推移而发展。并且您将要编写测试以验证是否满足AC。

#9 楼

测试用例在敏捷中被认为非常有用，以至于许多方法都将其视为流程的基本部分。


https://en.wikipedia.org/wiki/Specification_by_example

https://en.wikipedia.org/wiki/行为驱动的发展

#10 楼

是的，测试人员必须为用户案例编写测试用例。

完成针对用户故事的冲刺计划和任务分解后，开发人员将开始编写代码，测试人员将开始编写测试用例，以帮助测试人员验证是否满足接受标准。

#11 楼

在敏捷或任何其他方法中，测试人员必须进行测试，因此测试人员需要编写测试用例。
要在下一个sprint中进行回归，则必须具有用例。

现在，当Tester编写测试用例时。

在需求分析/设计之后，将开始执行/编码。对于测试或任何成员，敏捷团队可以开始编写案例。

#12 楼

编写测试用例有其好处，但是您可能没有时间编写真正冗长的测试计划。有时我只是将场景放在testname中，然后使用它来完成。
如果您离开项目的中途，书面的测试用例将帮助新成员填充您的鞋子，而他对整个项目进行回归。