我一直是4人Scrum团队中唯一的质量检查人员，用jQuery开发新的Web客户端。我发现我花了很多时间在每次冲刺过程中在新的故事和错误修复上创建和运行手动测试脚本。质量检查方面的自动化测试。
循环测试适合进行循环测试还是足以运行单元测试和自动化测试？
#1 楼
理想情况下，在项目结束之前应该有一个回归或“强化”冲刺，而在梦想世界中，每隔几个周期就要进行一次强化冲刺。我建议随着sprint的进行，对sprint的钢线进行自动测试，并且任何错误修复也应进行自动测试。这样，您可以在开发过程中建立自动回归，而与为每个新的sprint手动重新运行每个手动测试脚本相比，痛苦要小得多。这也有助于处理不发生回归/硬化冲刺的常见现实情况。
通过将自动化重点放在钢螺纹和已知断裂的结合上，您很可能会有效地使整个开发过程中最常用和最脆弱的区域退步，并且可以利用任何“发现的”时间来进行开发为您认为可能存在风险的任何其他领域添加自动化。
我还发现，它可以根据可能的使用频率和影响来对潜在的损坏进行优先级排序-这很可能会普遍发生，并且如果损坏会导致应用程序崩溃，应该进行回归测试以确保
简而言之，作为自动化和单元测试的一部分，应该在整个周期中进行回归，并逐步扩展以涵盖出现的任何新问题以及新的钢制螺纹。故事。
评论
这是一些很好的建议，您应该尽可能地自动化。如果您需要冲刺的结尾并且必须手动测试新功能，则应该在板上的某个地方添加便签纸，以便在构建手动回归套件时可以看到，这将有助于指示何时需要一个强化冲刺来减少您对先前冲刺所获得的手动测试负担。另外，在冲刺结束之前让整个团队进行一些探索性测试，这将捕获边缘情况和可用性问题。
–stuartf
2011年5月17日在22:06
如果您必须在发送之前进行额外的冲刺，我认为您对DONE的定义有问题。在scrum中，您应该能够在冲刺结束时发货（如果对企业有意义）。恕我直言，这是错误的答案，因为您开始退而求老的瀑布式习惯，即“最终进行质量测试”，而不是确保在完成每个项目后就已经真正完成了，不必思考再说一遍。
– Chuck van der Linden
2011年5月20日19:10
自动化本身应该是看板/ Scrum中的任务。可能会到达sprint的末尾，而没有完成sprint上的所有任务，但是据推测，当您运行sprint时，您要对事情进行优先级排序，以使针对任何一个用户故事的工作不会完成一半。这使您可以运送一些。剩下的任何内容都会积压到下一个sprint中，包括自动化。我遇到的问题是，尽管积压了自动化，但再也没有将其再优先作为“头等大事”，因此也就永远无法完成。在这种情况下，这是一个项目管理问题。
– TristaanOgre
2011年5月20日20:12
#2 楼
我也曾在一个小型敏捷团队中担任过独立测试人员，我发现对回归测试最有帮助的两件事是自动化和基于风险的测试优先级。覆盖范围绝对是非常有帮助的。但是，我不建议完全依靠自动化测试来进行回归，因为有些类型的bug并不是自动测试特别擅长检测的。是根据系统的风险分析来选择手动测试的子集。考虑一下最有可能受冲刺更改影响的系统区域，并仅通过手动测试确定目标区域。为了获得最佳结果，我通常将手动测试用例用于那些高风险区域作为我的探索性测试的指南。
我发现这种方法可以缩短每次冲刺结束时的回归测试时间，并且足以满足我们项目的质量要求。但是，由于低风险区域完全依赖于自动测试来检测错误，因此在低风险区域中确实留有较小的漏洞供小到普通的漏洞溜走。对于某些项目标准，这可能是不可接受的，因此请注意这种风险。
#3 楼
我作弊，并打破了一些“敏捷”开发的规则。此数字基于经验，并在手动测试和编写自动化之间取得平衡。这也迫使预算准人分配适当的资源。为什么80％？在我试图达到80％的目标的第一个项目中，我们必须努力工作才能实现这一目标。回报是，随着项目的发展，我们不需要手动进行过多的回归测试，并且每天可以运行整个测试套件的80％。在我的上一个项目中，我们的命中率达到了100％。因此，是的，80％只是一个固定的目标，但这似乎对我们有用。 :-)
我们什么时候才真正开始自动化工作？好吧，通常我们使用迭代的前几天来赶上并自动执行上次迭代结束时提供的功能的测试。 br />
更改游戏规则（过程）和
构建工具以帮助尽快加快工作。
#4 楼
根据我的观点，“ Scrum是最好的敏捷方法。在Scrum中，每个sprint都会产生一个增量，这是一个潜在的可释放产品。在这里，每个增量都必须满足所有接受标准并通过不同类别的测试。回归测试是一种繁琐的活动，尤其是在敏捷过程中，以不间断的更改和频繁的交付为特征。如果项目的“成本”影响了项目，那么我们可以手动执行回归；如果不是，则最好使用自动化来进行回归。是团队可以用来自动化回归测试的工具的示例。“
#5 楼
我们的团队通过为每个用户故事编写一个手动测试任务来处理此问题，因此它与所有其他任务一起被预算和估算。但是，目标是尽可能地自动化，以减少手动测试的负载（可能为零，例如，您可能能够使您可以想到的API自动化）。在决定手动进行自动化或运行测试时，始终应考虑因未能自动进行自动化而产生的技术债务。我个人总是希望为大多数用户故事进行探索性测试的预算，即使我认为我可以自动化100％的测试，以防万一我在sprint的后期提出了一些创意。#6 楼
理想情况下，您应该将测试自动化（单元测试和验收测试（包括后者成为您的回归套件的一部分））作为完成某项产品所需的一部分。这可能意味着您必须从队友那里获得一些帮助才能完成自动化，然后才能接受项目，因为根据我的经验，比例为4：1 “测试器”上的负载。如果您稍后尝试尝试“在有时间的时候”进行测试，则您可能会越来越落后，因为通常没有太多时间。您的CI系统设置，以便定期运行回归测试（我建议每晚进行一次）
顺便说一句：DONE的一个很好的定义，我前几天听说是“不必再考虑这个故事了” />请参阅肯·施瓦伯（Ken Schwaber）的精彩演讲（分为三个部分），其中涵盖了很多内容，并提出了一些非常重要的观点。
#7 楼
对于长期项目（已经完成2至3年），并且如果有100多个旧测试用例，我们将对“主”回归和迭代回归进行以下操作主回归-将是一大组测试文件夹，每个功能下都有合并的测试用例，新功能或更改的功能将更新现有测试用例
迭代回归-每次迭代结束后，我们将对故事/测试进行手动回归下一次迭代的案例。我们测试了先前迭代的所有功能。在即将到来的迭代中，我们进行迭代+ 1测试。
我知道每次迭代都需要更多的精力，但是，对于每2个月左右发布一次的项目，如果只有3个迭代用于开发/测试，那么我会发现这种方法建议使用。
此外，我们将第四次迭代用作回归之一。
#8 楼
凯特（Kate）在这里有一些很好的建议，尽管很难获得可以在回顾期间提出的强化冲刺。我还建议尝试安排一些时间对每个sprint进行一些回归测试，以保持工作进度。尝试从以前的冲刺中进行一些验收测试，看看可以做什么，这样一来，您将始终对事情的进展情况有更好的感觉。#9 楼
仅在某些基准测试可行产品推出后（通常在2个冲刺中的一个冲刺结束后），自动化才是Scrum或敏捷开发中的好选择，因为在那之前需求非常脆弱，尝试自动化不是一个好的选择，直到手动测试/接受在基于支持TDD的行为驱动或用例驱动/模型驱动的方法学基础上的单元级别，集成级别的测试，确实提供了适当的测试覆盖范围和缺陷识别。测试用例，他们认为是自动化的理想且有效的候选者，我们可以根据它们定义产品所有者定义的优先级，然后开始进一步构建回归套件。随着功能的增强和后续冲刺的建立，我们得到了即将出现更强大的自动化回归周期，总体而言，测试工作的有效性和效率成倍增加。
#10 楼
我一直在思考这是一个很好的问题。我想在这里添加一些东西。以及sprint中的其他任务。但这太现实了。在现实世界中，id完全取决于。将有两个因素起作用，例如测试/自动化资源可用性和自动化ROI。
如果您在Scrum团队中拥有专门的测试人员，或者如果不是每个人都可以编写测试自动化，则意味着自动化有时会成为sprint中的关键路径。如果团队依靠编写的自动化程序为当前的sprint进行回归，那么在为自动化开发分配开发资源时将需要很好的灵活性。这并不是每个Scrum团队在现实世界中都能做到的。最终可能会导致一些自动化工作被积压，并成为技术债，必须在以后的sprint中处理。不稳定。将会多次引入重大更改，因此立即自动化此类区域是不明智的。手动测试或探索性测试将更有效地运输产品。而且以后进行自动化可以节省大量的自动化维护工作。如果团队确定会发生这种情况，那么尽早进行自动化可能不是一个好主意。这就是自动化开发的本质。
评论
好问题。我将仔细地观察答案，以获取提示：)我在一个小型的AGILE开发团队中，没有自动化测试。我们使用Scrumwise来跟上开发的步伐-上面的答案在项目结束时通过自动化测试和强化测试解决了这个问题。我经过短距离冲刺就沉迷于回归测试。我应该在每个冲刺结束时进行回归测试吗？谢谢/.jp