在这种情况下：作为质量检查，如果需求不断变化并且公司遵循敏捷模型，该怎么办？
#1 楼
在回答这个问题之前，我想解释一下为什么需求在任何开发周期中都在不断变化：人们出于很多原因改变了主意，并定期这样做。发生这种情况的原因是：
他们错过了一个要求：利益相关者将使用现有的系统并意识到它缺少功能。
他们发现了一个缺陷：一个bug，或更重要的是解决该bug的需求也应被视为一项要求。
他们意识到他们不了解他们的实际需求：通常向一个利益相关者展示您的工作系统，只是让他们意识到他们真正要求的不是他们毕竟想要。这就是利益相关者积极参与和短暂迭代对您的成功至关重要的原因之一。
政治：您组织内的政治格局可能是动态的（是的，我很礼貌）。当利益相关者之间的政治力量平衡发生变化并且总是如此时，他们的优先事项也是如此。这些不断变化的政治优先事项通常会促使需求发生变化。
市场发生了变化：也许竞争对手会发布一种新产品，该产品实现了您的产品所没有的功能。立法变更。也许新法规要求软件中具有新功能或对现有功能进行更改。
“您不必改变，生存不是强制性的。”
作为质量检查：如果需求在不断变化，则应优先进行测试特点;应该确保对所有通用流程都进行了尽可能多的测试。
在测试案例中设计一些灵活性。这不容易做到；最好的选择是尽量减少测试用例中的细节，或者仅设置更高级别的通用类型的测试计划。
不太关注详细的测试计划和测试用例，而更多地关注即席测试，因为这会带来额外的风险。
将最初的自动化测试重点放在最有可能保持不变的应用程序方面。
适当地对变更进行风险分析，以最大程度地减少回归测试需求。
#2 楼
根据我的经验-更快的反馈和更多的测试（理想情况下是自动测试的形式）。如果行为没有改变，但是代码经常被重构，那么系统的行为应该由自动检查覆盖。我们有单元测试，集成测试和ui测试，它们在每次提交后都运行。
如果需求和行为经常变化，则测试人员应保持循环，并始终计划和调整测试工作量（这就是为什么每天召开会议很好的原因）
花时间写严格计划的详细计划，案例和报告，而应该花时间在沟通，学习系统和自动化测试开发上
评论
这个。专注于及时了解更改，以便您的测试能够反映不断变化的预言。
–ernie
17年2月7日在18:17
同意，非常全面。
–张瑜
17年2月7日在19:28
并确保自动测试由开发人员负责。
–ne2dmar
17年12月21日在15:56
#3 楼
当您说“更改的是技术细节”时，您可能正在实施级别进行测试。如果您的测试失败是因为实现发生了变化，而不是需求发生了变化；然后确定您正在测试实施。测试驱动开发（TDD）文章和培训花费了很多时间来讨论这个问题以及如何避免它。当然，您必须能够适应不断变化的需求。避免在冲刺期间“发展见识”的一种方法可能是行为驱动开发（BDD）的应用。在这种情况下，您可以在冲刺开始时运用技术来制定需求并通过团队传播对需求的理解。在某种程度上，这可以减少sprint期间的更改，因为整个团队可以更好地理解需求。
最后，可以预期行为和需求会随sprint的变化而变化。准备随时放弃测试并重新开始。
#4 楼
当需求不断变化时，持续遵循以下几点将对敏捷测试人员有所帮助：
编写通用测试计划和测试用例，重点在于测试人员的意图。需求而不是其详细信息。
要了解更改的范围，请与产品所有者或业务分析师紧密合作。
确保团队了解更改需求所涉及的风险，尤其是在冲刺结束时。
直到功能稳定并最终确定要求之前，最好等待是否要自动化该功能。
可以通过协商或在下一次实施中将更改保持在最低限度sprint。
最佳实践是直到需求最终确定后才进行自动化过程。
评论
在哪里描述了这种最佳做法？似乎更像是一种意见。极限测试中将单元测试描述为实践，他们说所有代码都应具有单元测试。由于XP是最古老的敏捷框架，因此我应该在这里保留一些真理：extremeprogramming.org/rules/unittests.html
– Niels van Reijmersdal
17年2月8日在6:34
在敏捷环境中，我经常认为需求从未完成
–迈克尔·杜兰特（Michael Durrant）
17年2月8日在12:51
如果您等待完全冻结需求的那一天开始自动化，那一天可能永远不会到来。
– Vishal Aggarwal
17年12月21日在23:32
#5 楼
如果需求在开发过程中可能会经常变化...这是给定的，这就是敏捷的工作方式。
对于QA / QE专业人员来说，他们需要不同的思维方式，他们应该关注：
在开发过程中进行测试，而不是在功能完成之后进行测试
在开发开始之前与开发人员一起制定测试计划
将自动化用于稳定且不变的零件
在需要时准备好进行手动测试
成为测试专家不同的浏览器，设备和仿真器
确保为开发人员提升测试心态
#6 楼
当需求不断变化时，作为测试人员每个团队成员都应准备好应对项目中的变化。团队应与产品负责人紧密合作，以了解需求变化的范围和进行协商以将需求更改减至最少或在下一个Sprint中采用这些更改。
根据需求变更，测试团队可以更新测试计划和测试用例，以达到截止日期。
团队应了解需求变更中的风险并制定应急计划。
#7 楼
敏捷就是跨职能团队。作为一名测试人员和经验丰富的敏捷开发人员，我们每天召开一次Scrum会议，讨论各自冲刺所要达到的目标。
整个目标影响了测试策略和要立即测试的项目中的次要目标。
测试自动化用于重复的测试用例。
#8 楼
我们Agilist承认，不断变化的需求是确定的，因此宣言声明：持续关注技术卓越性和良好的设计可增强敏捷性。
能够连续更改软件而不破坏其他功能是敏捷性的重要组成部分。如果不是最大的部分，便能够应对变化。当前最常用的方法是使一切自动化，当然还有您的测试自动化。这意味着将所有（重复）测试自动化。所有的？是的，全部！这是重构代码并经常放心释放的唯一方法。如果确实发生任何缺陷，请进行根本原因分析，并进行更多的自动化测试。
Less框架提供了一些有关实践的漂亮页面，请在此处查看更多详细信息。
测试不再意味着测试
感到困惑吗？我们可以想象！以前测试的目的很明确-“测试是为了发现错误而执行程序的过程” [Meyers79]。当采用敏捷和精益开发时，这种情况会发生变化。从自动化开始到后来，都导致开发工作停滞。这仅在您的用户故事始终为DoneDone时才有效，其中包括测试自动化以及其他许多方面。
其他内容：
http：// www。
jamesshore.com/Agile-Book/test_driven_development.html
http://www.extremeprogramming.org/rules/unittests.html
https://www.thoughtworks.com/continuous-delivery
评论
好。您如何才能完全自动化所有测试？当开发人员问您“嘿，您可以检查X”时，您是否回答“是，让我先为X写一些测试，明天见”？
–乔治
17-2-7在19:23
我的意思是您将要重复的所有测试用例。您可能仍需要进行一些手动测试和探索以及其他工作才能找到测试用例，但最后不要重复任何手动测试，而是要使它们自动化。我建议在编码之前先从测试自动化开始。它称为测试驱动开发，在敏捷团队中很常见。编写测试是团队工作的一部分，不应推迟到功能完成后再并行进行。
– Niels van Reijmersdal
17年2月7日在19:29
我宁愿将功能更改为可以通过自动化进行测试，然后手动进行测试。本周末，在FOSDEM上，ThoughtWorks的一名员工不断向我们重复，他们每隔2秒钟部署一次应用程序，并进行2万多次测试。在持续交付的世界中，实际上不再需要进行手动测试。 :)
– Niels van Reijmersdal
17年2月7日在19:35
这与我的想法有些不同。有时您甚至不能确定实现本身是正确的，如果从假设您需要使用自动化测试覆盖X开始，那么您的测试就覆盖了错误的实现并且是无用的。如果您说在编写测试之前应该先验证实现是否正确，那么那也就是测试。无需手动测试，更像是在进入自动化之前认真思考实际开发的内容。
–乔治
17年2月7日在19:46
更不用说在敏捷中，我看不到立即跳入自动化的意义。如果在开发过程中需求发生变化，请重写不会产生任何价值的自动化测试。 （测试失败了，没什么大不了的，我们改变了X的工作方式）不是最好的时间利用方式。宁可自动运行一次功能更稳定的功能，然后添加到回归套件中，因此您无需再次测试。
–乔治
17年2月7日19:50
#9 楼
需求在冲刺期间不应经常更改（假设您正在询问Scrum），因此更改需求不会产生太大影响。主要困难在于，对于最新要求有一个真实的来源，因此您不必筛选很多票证就可以了解给定功能的当前行为。如果UI我正在经历很大的变化，因此我不会在自动化这些测试上花费很多精力。选择器在更改或删除时效果不佳。
评论
产品的问题在于，在构建产品时，市场适应性将发生变化。当您了解有效的方法和无效的方法时，通常必须更改一半的产品。建议您跳过自动测试声音，因为您不了解敏捷的基本原理。您应该构建测试（和选择器）的结构，以便能够轻松处理更改。由于手动测试的每个迭代都会减慢实验和学习的速度，因此这不是敏捷商店的选择。自动化测试是真理的源头。
– Niels van Reijmersdal
17-2-7在18:55
评论
由于敏捷没有定义测试方法，因此投票决定关闭主要基于意见。只要团队能够响应变化，每个团队都应该为自己做些什么。@NielsvanReijmersdal敏捷不是说范围是在冲刺时间内冻结的吗？该准则以某种方式定义了应该如何进行测试。
不，敏捷甚至没有Sprint。 Scrum和Scrum不等于敏捷，它只是流程管理的一部分。另外，Scrum不会冻结sprint，而只是建议您这样做。它冻结了Sprint目标，引用了Scrum指南：“没有做出会危害Sprint目标的更改；”。 Scrum或敏捷宣言（agilemanifesto.org）都未提及测试实践