你不可不知的敏捷测试-定义，原则，方法和生命周期

随着软件开发过程复杂性的不断增加，客户希望得到新软件的期望周期也越来越短，所以软件测试方法需要不断的发展快速适应新的开发模式，敏捷测试的呼声越来越高，以下是CC先生对敏捷测试的一些思考。

敏捷测试的定义

在CC先生初次遇到敏捷的时候，认为敏捷只是有关于流程和工具，学习了一系列有关于敏捷的流程和自动化测试的工具，随着对敏捷理解的深入，越发能体会到敏捷不仅仅是关于流程和工具，它是关于人和文化的！ 受到这种认识的启发，CC先生开始深入了解敏捷的历史 - 事实证明，人和文化一直是敏捷的核心。敏捷测试也是如此，它不仅是流程和工具的更改，它更倾向于一种新的测试模式，高投入产出比的同时也提供高质量的产品。如果把这些年听到的关于敏捷测试的种类做一个归类的话，它更符合以下3M的说法（参照Matt对敏捷的理解，CC先生对敏捷测试的理解）：

Agile Testing As Methodology	Agile Testing As Mideset	Agile Testing As Movement
工程实践比思维更重要	思维比工程实践更重要	思维和工程实践有着密不可分的连接
敏捷测试的实践和方法都已经被他人所定义	敏捷测试的价值和原则已经被他人所定义	测试人员可以自发积极地定义组织内敏捷测试的原则和工程实践
测试人员需要按照既定的流程和工具和其它人进行交流	测试人员可以自行讨论出组织内的敏捷测试思维	测试人员需要和研发团队中的其它人一起为了共同的目标而不断的挖掘快速反馈测试价值的方式

不管我们定义为哪一种理解，在敏捷时代，测试人员和开发人员都需要在测试活动中进行更密切的协作。 测试人员必须在开发周期中向开发团队提供正确性反馈，这是测试和开发方法之间持续集成的时代。敏捷测试同时是从项目启动开始就持续的一项活动，和以往瀑布开发模式不同的是，它并不是一个顺序阶段性活动，它和开发联系得如此紧密，因为敏捷开发和测试的共同目标都是在合理的时间范围内为客户尽量提供高质量的服务。

敏捷测试的原则：

• 持续测试：敏捷团队持续的进行测试，因为它是确保产品不断进步的唯一方法。

• 持续反馈 - 敏捷测试持续提供反馈，这就是您的产品满足业务需求的方式。

• 全员测试：在传统的软件开发生命周期中，只有测试团队负责测试，但在敏捷测试中，开发人员和业务分析人员也会测试应用程序。

• 测试驱动：在敏捷方法中，测试在代码实现时执行，而在传统过程中，测试在代码实现后执行。

• 业务参与：业务团队参与敏捷测试和持续反馈的每次迭代，缩短反馈响应的时间。

• 简约代码：敏捷团队提出的所有缺陷都在同一次迭代中得到修复，有助于保持代码的清洁和简化。

• 简化文档：敏捷团队使用可重复使用的核对表，团队专注于测试而不是附带的细节。

敏捷测试方法：

有各种敏捷测试方法如下：

• 行为驱动开发（BDD）

• 验收测试驱动开发（ATDD）

• 探索式测试

• 行为驱动开发（BDD）

行为驱动开发（BDD）改善了项目利益相关者之间的沟通，以便所有成员在开发过程开始之前正确理解每个功能。开发人员，测试人员和业务分析师之间存在基于示例的持续沟通。这些示例称为场景，以称为Gherkin Given / When / Then语法的特殊格式编写。这些方案包含有关给定特征在具有不同输入参数的不同情况下应如何表现的信息。这些被称为“可执行规范”，因为它包括自动测试的规范和输入。

在实际执行过程中，BDD也可说是一种沟通方式，不要单一的看成是自动化测试的手段。

典型的BDD框架示例如下：

*** Keywords ***

Login with Valid Credentials

[Arguments] ${username} ${password}

GIVEN Open Browser To Login Page

WHEN Input Username And Password ${username} ${password}

THEN Login Success

验收测试驱动开发（ATDD）

ATDD专注于让具有不同观点的团队成员参与进来，例如客户，开发人员和测试人员。召开[Three Amigos会议]（http://www.edgetesting.co.uk/news-events/blog/three-amigos-in-the-world-of-agile），制定验收测试，包括业务分析师，开发和测试的观点。业务分析师关注的是要解决的问题，开发的重点是如何解决问题，而测试则关注可能出现的问题。验收测试是用户观点的表示，它描述了系统如何运作。它还有助于验证系统是否按预期运行。在某些情况下，验收测试是自动化的。

自动化的ATDD也可利用robotframework+seleniumLibrary来实现，还是需要再次说明，在实际执行过程中，ATDD更多的是一种和业务确定需求的沟通方式，不要单一的看成是自动化测试的手段。

典型的ATDD框架示例如下：

*** Settings ***

Documentation Test google search with specific word

Resource ../keywords/common_resources.txt

*** Variables ***

${search_text} amazon

${result_text} amazon.in - Amazon - India's Largest Online Store

*** Test Case ***

Scenario: Search specific word in google search engine

Given www.google.co.in has been launched in firefox browser

When I entered ${search_text} as search text

Then I can see the search results containing the entered word ${result_text}

Then I close the browser window

探索式测试

在这种类型的测试中，测试设计和测试执行阶段齐头并进。探索式测试强调工作软件而非综合文档。个人和互动比过程和工具更重要。客户协作比合同谈判具有更大的价值。探索式测试更适应变化。在此类测试中，测试人员通过真正的不断挖掘用户的需求来制定测试案例和执行测试计划。

敏捷测试的优点

它节省了时间和金钱

敏捷测试可减少文档

它灵活，适应变化

它提供了一种从最终用户接收定期反馈的方法

通过日常会议更好地确定问题

敏捷测试的生命周期

敏捷测试的生命周期可以划分为以下5个阶段：

敏捷测试计划

每日站会

敏捷回顾会议

发版准备

影响范围评估

影响范围评估.png

敏捷测试的计划

敏捷测试的计划（严格意义上来说，敏捷测试计划和以往的测试计划没有太大的不同），同样主要包括：

• 测试范围

• 待测试的新功能

• 测试类型/测试级别

• 性能和负载测试

• 风险计划

• 资源规划

• 可交付成果和里程碑

结论

敏捷测试是随着敏捷大潮而兴起对测试模式的一种思考，它是一个方法，还是一种思维，甚至是一个运动，全取决于组织对于快速抢占客户市场的决心和竞争的意识。“职责清晰，边界模糊”的职场规则会越来越盛行于以快求稳的组织和团队。