1、Scrum
它是什么？作为最受欢迎的软件测试方法之一（58％的组织已根据VersionOne采用了敏捷方法），Scrum采用高度迭代的方法，专注于在每个sprint之前定义关键特性和目标。它旨在降低风险，同时快速提供价值。
Scrum从一个需求或用户故事开始，概述了功能应该如何执行和测试。然后，该团队通过一系列冲刺循环，以快速提供小规模的价值爆发。为了帮助团队以这种灵活的方式工作并避免改变优先级，Scrum要求从一开始就回答问题。
它和瀑布有什么不同？瀑布包括在发布产品之前的几个测试和错误修复周期，而Scrum更具协作性和迭代性。其中一个最大的区别是瀑布早期需要大量文档。这个文档使得在过程继续进行时更改功能变得更加困难，这在某些环境（例如消费级软件）中可能是负面的，而在其他环境中则是积极的（例如团队试图发射火箭的那些）没有人想要经常危险移动的要求）。也就是说，您可能会认为Scrum就像许多“迷你瀑布”一样，因为每个冲刺开始时需求都很明确，不应该在其中移动。不同之处在于，下一个冲刺的详细要求不是提前几个月设定的。
潜水更深入，Scrum要求测试人员，开发人员和BA之间进行更多定期协作，通常采用每日站立和冲刺回顾的形式，以确保正确的沟通和协调。此外，还有一位Scrum Master通过删除团队中的阻截者来确保他们最有效，从而帮助项目完成任务。 Scrum Master可以是团队中的任何人，例如开发人员或测试人员。
采用有什么意义？ Scrum为来自瀑布环境的团队提供了最简单的转换之一，因为它基于时间的冲刺和发布仍然可以提前计划。也就是说，它确实需要更快的迭代和更强的协作。
它是谁的？由于其快速迭代，Scrum最适合那些客户和利益相关者希望通过在展示会议上定期查看工作产品而积极参与的团队。此协作允许团队对即将到来的陈列柜进行更改。在采用Scrum方法时应该参与的主要团队成员包括：
· 产品拥有者
· Scrum Master
· 开发商
· 自动化工程师
· 测试者
· 利益相关者
什么是最佳做法？除了强大的沟通，协作和适应性之外，遵循Scrum方法的测试人员的其他最佳实践还包括：
1)根据销售代表或客户的通信（通常以用户故事的形式）确定验收标准（注意：此直接连接应有助于减少误传）;
2)使用验收标准开发代码并确保团队批准该代码;
3)在将其部署到生产环境之前，在类似沙箱的环境以及类似生产的环境中测试代码。
2、看板
它是什么？看板是一种非常简单的基于敏捷的方法，植根于制造业（它由丰田公司开发，旨在帮助提高工厂的生产率）。在它的核心，看板可以被认为是一个大的，优先的待办事项列表。与Scrum一样，看板中的需求由其当前阶段（待办，开发，测试，完成）跟踪。
与Scrum不同，看板不是基于时间的。相反，它完全基于优先权。当开发人员准备好完成下一个任务时，他/她将其从待办事项列表中拉出来。由于计划会议较少，这种方法意味着团队需要非常接近。在这种类型的环境中，如果开发人员的工作速度比测试人员快得多，那么就会出现瓶颈。在这些情况下，团队中的任何人都应该跳进并帮助不同的领域。当然，满足这种需求需要很大的灵活性和适应性。
它和瀑布有什么不同？看板仍然有像瀑布这样的要求，但是由于测试团队没有开始考虑测试每个要求，直到开发人员从积压的顶部选择它，因此需求可能会发生变化。相比之下，瀑布是基于时间的，在计划中有很多开销。在某些情况下，在瀑布环境中进行繁重的规划是很好的，例如在建造昂贵的东西时，但并不总是必要的。使用看板，版本仍然有计划，但团队通常不会在某些日期向任何人提供功能，除非相关项目位于待办事项的顶部。
采用有什么意义？看板为正确的团队提供简单的过渡。为了顺利过渡到看板，业务分析师，开发人员，测试人员和利益相关者应该坐在一起并定期沟通。转换到看板时，重要的是要记住这种方法提供了将代码投入生产的最快方法，但代码可能会有一些技术债务。这是因为开发时并不总是知道接下来的内容并不一定能够生成最可重用的代码。
它是谁的？看板最适合不为公众制作功能和/或承诺发布某些日期的小型团队或团队。此外，它是主要专注于维护工作的任何产品或团队的首选方法选择，因为错误并不总是直截了当，往往需要研究解决，这使得时间管理具有挑战性。根据Scrum或Waterfall方法，不能最小化问题规划量的团队可能会更好。
应参与看板环境的主要团队成员包括：
· 产品拥有者
· 专案经理
· 开发商
· 自动化工程师
· 测试者
什么是最佳做法？除了保持可见性和优先协作之外，遵循看板方法的测试人员的最佳实践还包括：
1)在业务所有者，开发人员和测试人员之间保持非常开放的沟通渠道；
2)确保团队可以灵活地承担其核心职责之外的其他角色，以帮助消除瓶颈；
3)让每个人都成为产品的所有者，以便他们完全关注结果。
3、敏捷测试方法
（1）行为驱动开发（BDD）
它是什么？很多人都听说过或使用过测试驱动开发（TDD）。例如，开发人员在编写代码之前使用TDD编写单元测试失败。 BDD基于与TDD相同的原则，但它不是单元测试，而是要求在业务级别进行更高级别的测试。 BDD不是像TDD那样从面向技术的单元测试开始，而是从基于最终用户行为的初始需求开始，并且需要“人类可读”的测试，甚至可以替换一些需求文档。此要求基于产品应展示的行为，为工程师在开发测试时使用创建气密指南。
有关更多信息，请阅读我们的文章：“为什么BDD是DevOps中的测试秘诀。”
具体来说，BDD使用Gherkin Given / When / Then语法从功能规范开始。然后，该规范指导跨功能的开发人员，测试人员和产品所有者。正如他们所做的那样，他们使用自动化测试功能来确定完整性，改进代码直到通过测试，就像TDD方法一样，除了团队级别。为了确保测试通过（并且通常需要多次尝试），开发人员应该只重构代码，而不是添加任何新功能。
总而言之，BDD需要一种“智能”自动化策略，以提高效率。该策略将BDD与其他敏捷方法区分开来。
它与标准瀑布测试有何不同？ BDD与标准的瀑布测试极为不同，因为前者要求在需求的早期编写测试用例，并要求在开发周期结束时执行这些测试。但是，在敏捷环境中使用BDD，测试不是基于需求，测试是在功能开发的情况下进行的。
此外，在Waterfall方法中，测试人员是编写测试用例的人。另一方面，BDD方法适用于编写测试的企业主。此开关可减少业务分析人员，开发人员和测试人员之间的通信（或沟通错误）。
采用有什么意义？当团队习惯于传统的测试方式时，更改为BDD方法可能具有挑战性。它需要BA或测试人员预先编写测试，并且开发人员要在代码中编写测试规范以进行匹配。这是团队内部的一种新型协调方式，但非常积极的是团队合作为一个单元，包括业务用户。
它是谁的？ BDD方法非常适合从事以功能为中心的软件和/或将用户体验放在首位的团队的团队。应参与BDD环境的主要团队成员包括：
· 产品负责人/业务分析师
· 专案经理
· 开发商
· 自动化工程师/测试员
什么是最佳做法？遵循BDD方法的测试人员的最佳实践包括：
1.简化文档以保持整个流程的精益
2.采用“三友”模式，产品所有者，开发人员和测试人员组成一个有凝聚力的团队
3.使用像Cucumber这样的测试框架来定义标准
4.以尽可能容易重用的方式构建自动化测试
5.让业务分析师学习Gherkin语法并直接编写测试用例
（2）验收测试驱动开发（ATDD）
它是什么？ ATDD就像BDD一样，它要求首先创建测试，并要求编写代码以通过这些测试。然而，与TDD中的测试通常是面向技术的单元测试不同，在ATDD中，测试通常是面向客户的验收测试。
ATDD背后的想法是用户对产品的感知与功能同样重要，因此这种感知应该推动产品性能，以帮助提高采用率。为了实现这一想法，ATDD收集客户的意见，使用该输入来制定验收标准，将该标准转换为手动或自动验收测试，然后根据这些测试开发代码。与TDD和BDD一样，ATDD是测试优先的方法，而不是需求驱动的过程。
与TDD和BDD方法一样，ATDD通过消除开发人员解释产品使用方式的需要，帮助消除潜在的误解区域。 ATDD比TDD和BDD更进一步，因为它直接进入源（也就是客户）以了解产品的使用方式。理想情况下，这种直接连接应有助于最大限度地减少在新版本中重新设计功能的需要。
它与标准瀑布测试有何不同？ ATDD与标准瀑布测试不同，因为它是测试优先方法。标准瀑布测试要求根据需求预先编写测试用例，而ATDD不是需求驱动的测试过程。
采用有什么意义？因为ATDD代表了与传统方法的背离，所以从一个到另一个并不容易让团队去做。为了处于采用ATDD方法的最佳位置，团队需要获得利益相关者的支持，这有时会证明是有挑战性的。
它是谁的？由于强调用户感知，ATDD最适合专注于用户体验的团队，具有高采用率的目标，并希望在未来版本中尽量减少功能更改的数量。应参与ATDD环境的主要团队成员包括：
· 客户/客户代言人
· 开发人员
· 产品负责人/业务分析师
· 自动化工程师/测试员
· 专案经理
什么是最佳做法？遵循ATDD敏捷方法的测试人员的最佳做法包括：
1.与客户密切互动，例如通过焦点小组，以确定期望
2.倾向于面向客户的团队成员，如销售代表，客户服务代理和客户经理，以了解客户的期望
3.根据客户期望制定验收标准
优先考虑两个问题：
如果是X，客户会使用该系统吗？
我们如何验证系统是否支持X？
本文内容不用于商业目的，如涉及知识产权问题，请权利人联系51Testing小编(021-64471599-8017)，我们将立即处理
