敏捷测试是一种相对较新的软件测试方法。它遵循敏捷宣言中提到的敏捷软件开发原则。大约10到12年前，大多数项目都是以Waterfall方式运行的。但是，凭借缩短上市时间的基本优势，敏捷方法论如今已越来越流行。
在敏捷中，软件开发和测试是连续的，这是测试人员，开发人员，产品所有者甚至客户之间的共同努力，并且测试不是瀑布模型那样的单独阶段。
敏捷方法学的不同之处在于，测试从项目的开始就开始，甚至在开发开始之前就开始了，并为开发活动提供了持续的反馈。
同样，在思考过程中，敏捷方法论的测试也有所不同，因为质量的责任在于敏捷团队中的每个人，而不仅仅是质量保证，即团队中的每个人都负责测试。
敏捷测试方法：
1.测试驱动开发(TDD)：
- TDD一词由肯特·贝克(Kent Beck)在2002年提出
- 在这种方法中，测试是在功能之前编写的。
- 它依赖于重复非常短的开发周期
- 首先，开发人员编写一个最初失败的自动测试用例，该用例定义了所需的改进或新函数
- 其次，开发人员生成最少数量的代码以通过该测试，并且
- 最后将新代码重构为可接受的标准
测试驱动开发背后的想法是使每个更改足够小以快速进行迭代。在自动化和实现每个功能或更改时，您基本上已经在整个系统中添加了一些有价值的东西，并且准备好交付产品和产品所有者反馈。
(一种)。行为驱动测试(BDD)：
- 它是由Dan North在2009年首次描述的。
- BDD是测试驱动开发(TDD)的扩展。
- 产品负责人，程序员和测试人员(3位朋友)从一开始就参与其中。
- 从利益相关者的角度来看，通过使用给定时间表示测试的方式来帮助实现应用程序。
- BDD将词汇表从基于测试的内容转变为基于行为的内容。
- 它可以互换/宽松地称为
- 讲故事
- 功能测试
- 验收测试驱动开发(ATDD)
由于BDD涉及以一种通用语言进行思考，因此它可以帮助团队在正确的时间进行正确的对话，从而最大程度地产生有价值的代码。它也有潜力在我们真正知道要做什么之前，找出理解上的差距以及我们需要更多信息的领域。
2. BDD测试涉及的步骤：
- 首先，对系统进行即将进行的小更改，即用户故事或场景(在Cucumber上下文中也称为Example)。
- 分析新功能，通过在三个好友(BA，开发人员和测试人员)之间进行讨论来探索并达成共识，以期完成预期的细节。
- 以一种可以自动化的方式记录方案。
- 最后，实现每个文档示例描述的行为，从自动测试开始，以指导代码的开发。
下图描述了一个实际的BDD项目流程。
3. BDD，ATDD和TDD：主要区别
行为驱动开发(BDD)：
- 本质上更面向客户，并帮助开发人员在编写测试时牢记涉众所期望的行为，而不是进行测试以验证代码的实现。
- 以客户为中心并使用英语之类的语言，从而使与非技术利益相关者的协作更加轻松。
- 从开发人员和客户的角度清楚地了解系统应该做什么。
- 在BDD中，测试失败是因为尚未开发功能，
- 功能基于客户需求
验收测试驱动开发(ATDD)：
- 首先，指导开发团队确定实际需要构建哪些功能，然后测试这些功能以验证其功能。因此，ATDD侧重于高层，而TDD则侧重于低层。
- 做正确的事(业务观点)。
- 使开发人员了解系统应该做什么。
- 最近的ATDD工具正朝着使用类似BDD的“给定，何时，然后”的语言发展。
测试驱动开发(TDD)
- 告诉开发人员她/他的代码是否工作正常。
- 做正确的事(Dev观点)。
- 在TDD中，测试失败是因为尚未开发算法/函数。
- 算法基于程序员所知道的
BDD / TDD中的一般流程
4.黄瓜和嫩Cucumber：
Cucumber：
- 需要注意的重要一点是Cucumber不是测试工具。
- Cucumber是基于行为驱动开发(BDD)框架的工具，用于编写用户验收测试。
- Cucumber读取用英语编写的可执行规范，并验证该软件是否符合规范的建议。
- Cucumber的场景或规格以以下格式编写：
方案：<详细方案说明>
给出：本节描述了前提条件
时间：此子句定义触发点或操作。
然后：此子句定义事件或操作的结果。
嫩黄瓜
- Gherkin是一种商业可读的领域特定语言。
- 它很容易理解，因为它从行为测试中删除了逻辑和语法细节。
- 它使用一组关键字使测试更易于理解。最常用的关键字是：功能，给定，时间，规则，规则等等。
- 小黄瓜已被翻译成多种语言并可以使用。这有助于利益相关者与业务用户之间的轻松交流。
的优点和缺点 ：
- 用Gherkins / Cucumber编写的测试具有测试和项目文档的双重目的。
- 采用BDD方法可确保在开发过程中牢记用户体验。
- 这种方法需要3个好友的大量参与。根据项目情况，这可能是优点还是缺点。
结束语：
当您需要团队中的每个人都参与而又不涉及技术方面时，BDD方法可能是一个不错的选择。同样，这种方法对于所有项目类型也不是理想的。使用这种方法，较短的项目可能会延迟。它也可能使项目变得复杂，有时甚至使它们变慢。这也需要从传统的工作方式上进行重大的观念转变。