大家好，我是阿萨。最近几年，敏捷开发特别火，和敏捷开发对应的敏捷测试是什么呢？ 今天阿萨简单给大家聊一聊。
现代开发团队如何在开发的同时进行测试，将测试人员合并到开发团队中，并在每次产品迭代中创建持续的反馈循环，以将质量“内置”到他们的代码中。
敏捷团队一般都要求在几周内向客户发布新特性，而不是几个月或几年。质量对于敏捷方法来说是至关重要的，因为它的主要关注点是满足客户的需求。敏捷测试的最大挑战在于如何随着开发速度的提高而快速而全面地测试功能。
什么是敏捷测试?
敏捷测试在开发项目开始时开始，涉及到测试和开发之间的持续集成。传统开发模式下，测试是在编码阶段之后的独立活动;在敏捷中，测试是连续的，将测试人员置于产品所有者和开发人员之间。敏捷测试创建了一个持续的反馈循环，帮助开发人员改进他们的代码。
敏捷测试的特点:
1. 与产品负责人沟通——测试人员与产品负责人互动，以明确建立项目期望，因此他们可以帮助开发人员与产品开发里程碑以及设计图保持一致并满足客户需求。
2.与开发人员密切互动—测试与开发过程相关联。测试人员是开发团队的一部分，他们报告可能影响用户的质量问题，并建议如何改进解决方案。
3. 整个团队都参与到质量保证中——整个团队都对质量充满热情，开发人员为更好的测试过程构建单元测试用例，并提高审计的质量。开发人员还遵循测试人员对测试需求和代码改进的建议。
敏捷测试原则
指导敏捷测试的主要原则有八个:
1.持续测试——敏捷团队定期执行测试，以确保产品在不断地发展。测试与开发一起进行。
2. 持续反馈——测试人员为团队成员提供持续的反馈。成员定期收到关于质量而不是需求的反馈。
3. 全员质量负责——包括整个团队的测试人员、开发人员和业务分析人员都在测试软件。
4. 快速反馈——业务团队参与每一次迭代;持续的反馈减少了获得开发工作反馈的时间。
5. 高水平的软件质量团队——高水平的软件质量团队测试软件，以确保代码干净紧凑。通过定期的软件测试，问题和漏洞可以很容易地在开发的同一迭代中被发现和修复。
6. 可重用的清单——文档较少的团队使用可重用的清单。敏捷开发关注的是当前的客户需求，而不是全面的、文档化的需求和说明。
7. 提前评估——测试驱动的测试人员在实现时评估产品，而不是在实现之后评估产品(就像传统测试方法的情况一样)。
8. 客户满意度——客户在开发过程中接触到他们的产品。他们可以在开发过程中调整和更新需求。测试可以修改为更新的需求。
什么是敏捷测试象限?
敏捷测试可以使用由Janet Gregory和Lisa Crispin创建的象限系统进行简化。象限为测试提供了一种分类，可以帮助测试人员回答诸如“要运行哪个测试?”，“什么时候运行测试?”和“如何运行测试?”
象限1:与代码质量相关的测试，包括自动化测试，如单元测试和组件测试。
象限2:专注于产品业务相关方面的测试，通常是手动和自动功能测试。这些包括原型、功能测试和场景的测试示例。
象限3 ：这个象限为象限1和象限2中的测试提供反馈。团队、业务所有者甚至客户都以现实的方式使用产品来测试用户体验和衡量业务结果。
象限4:测试非功能性需求，包括安全性、兼容性和稳定性。象限4中使用的测试包括压力、性能和基础结构测试。
使用敏捷测试象限来定义测试策略
在计划一个新版本或冲刺时，可以使用以下流程来确定要关注哪些测试:
作为一个团队，通过每个象限，并根据冲刺计划和产品路线图确定需要哪种类型的测试。
1. 与客户讨论质量标准——在现阶段对他们来说什么是最重要的?例如，如果产品具有所需的功能，但不够稳定，则关注象限4。如果缺少关键的特性，那么就关注象限2。
2. 了解谁可以执行所需的测试。作为Scrum团队的一员，你是否具备所需的专业知识?如果不是，你是否需要从其他团队或顾问那里招募专家?例如，性能和安全测试需要特殊的专业知识。
3.是否拥有执行测试所需的工具和基础设施?例如，测试可能需要一个云上的测试环境，测试可以自动启动它。需要将构建此环境作为sprint的一部分，或者了解谁可以提供该环境。
4. 你有测试所需的数据吗?如果没有，请与产品负责人或用户一起构建一个详细的用户故事，并要求他们提供测试可以使用的实际测试数据。
敏捷测试中的7大挑战以及如何解决它们
敏捷开发过程的连续性带来了一些严重的测试挑战:
1. 需求变更
有时，管理层会在sprint期间更改需求或删除故事，即使这在敏捷/Scrum框架中是不鼓励的。这意味着已经完成一半的工作需要被丢弃或修改，这意外地改变了测试的范围。
如何解决:
测试人员应该能够根据变化的情况做出反应并修改他们的过程，因为在敏捷项目中，变化是很常见的。当需求发生变化时，测试人员应该分享尽可能多的信息，包括他们已经进行了哪些测试，以及应用程序的哪些区域还没有被测试。这可以帮助团队理解如何在不损害发布质量的情况下对sprint进行所需的更改。
2. 信息不足
负责开发用户故事的产品负责人可能对新功能有一个想法，但可能不知道具体细节。这意味着他们不能写出一套好的接受标准。如果缺少关于需求的信息，测试人员就不能构建全面的测试用例。
如何解决:
测试人员不需要深入的需求来开始测试，他们可以从提出高级场景开始，测试故事的想法，并与产品负责人确认它们。测试可以在没有关于特性的完整细节的情况下进行。可以创建高级测试场景，即使细节发生了变化。
3.连续测试
测试并不局限于开发过程的一部分，而是在开发阶段之前开始的持续活动。这就产生了一个重大的挑战，因为测试人员需要在编码开始之前，或者在编码进行时，就开始为特性构建测试。
如何解决:
为了让测试人员的工作更轻松，backlog中的用户描述应该在sprint计划期间进行扩展。测试人员、开发人员和产品负责人应该共同定义每个故事的细节，然后编写有效的验收标准。
团队应该确保每个故事都有足够的接受标准，并且在开发工作开始之前，故事的上下文被普遍理解。这使得在早期开始创建测试成为可能，这些测试可以在特性代码完成时实现。
4. 技术技能
在敏捷环境中工作的测试人员需要精通技术，用Selenium或类似的框架帮助开发人员进行API测试、集成测试和脚本UI自动化检查。具有探索性或手动测试背景的测试人员进入敏捷世界将遇到陡峭的学习曲线。
如何解决:
测试人员可以也应该学习编程或脚本语言，如Javascript和Ruby。熟悉编程但缺乏实际经验的测试人员可以向开发人员寻求帮助。测试人员还可以学习自动化测试工具，如Selenium工具和JMeter。
对于专门的测试领域，例如性能、安全性或遵从性测试，团队应该拥有具有相关专业背景的专门测试人员，或者利用在这些领域具有丰富经验的顾问。
5. 频繁的回归周期
开发人员经常不断地向产品添加功能。这可能会导致先前特性的回归。测试人员使用回归测试来识别这个问题并克服它，但是手动回归测试在快节奏的敏捷环境中是不切实际的。
另一个挑战是，现代web应用程序在不同设备或浏览器上的表现不同。这将创建一个复杂的兼容性测试场景矩阵，需要对这些场景进行测试，以确保应用程序能够正确地为所有用户运行。
如何解决:
敏捷测试人员依赖于自动化。他们使用单元测试来确保最近的更改没有破坏代码，并使用Selenium和JMeter等工具来验证基本功能中没有回归。测试人员可以使用Docker或Selenium Grid在各种浏览器和机器上并行地管理和运行他们的自动化测试。
6. 缺乏沟通
如果开发人员、测试人员和产品负责人之间缺乏沟通，敏捷测试就无法工作。
如何解决:
应该大力鼓励团队内部的直接沟通。开发人员、测试人员和产品负责人应该定期面对面交谈，以确保每个人都在同一页面上。Scrum仪式，如站立会议、冲刺计划和回顾，有助于建立对冲刺范围和目标的共同理解。
7. 没有质量度量
今天的敏捷团队没有单一的质量度量，他们可以用它来优化和计划测试工作。
有许多度量标准，如单元测试代码覆盖率、代码行数(LOC)以及代码的复杂性。但是没有一个能够提供关于在冲刺或发布中每个点的质量的“我们所处的位置”的清晰图片——产品的哪些部分工作得很好，哪些不太稳定，质量问题的风险更高。
大多数敏捷团队都在盲目飞行，只对生产失败或bug做出反应，却无法主动关注存在最大质量问题的产品领域。
了解了敏捷测试的8大原则和7大挑战之后，相信大家已经对敏捷测试有了初步的了解。也欢迎大家日常测试中迅速使用起来真敏捷的方法。
如果你觉得阿萨的文章对你有帮助，欢迎围观，点赞和在看。谢谢大家。
