摘要：敏捷测试是一种在敏捷开发方法中使用的测试方法，旨在支持敏捷开发团队快速交付高质量软件。在传统的测试执行过程中，阶段性比较强，各个里程碑都有严格的进出标准，更强调规范、过程的严格监控，缺陷的报告和跟踪。敏捷测试则强调持续测试、持续的质量反馈，更强调测试的速度和适

敏捷测试是一种在敏捷开发方法中使用的测试方法，旨在支持敏捷开发团队快速交付高质量软件。在传统的测试执行过程中，阶段性比较强，各个里程碑都有严格的进出标准，更强调规范、过程的严格监控，缺陷的报告和跟踪。敏捷测试则强调持续测试、持续的质量反馈，更强调测试的速度和适应性，强调和开发密切沟通、协作等。

敏捷测试属于一种新的测试实践，那么到底它有什么的特点呢?我认为有如下四个方面：

轻量级测试文档：敏捷开发人员和测试人员工作得更加紧密，喜欢更直接的沟通方式而不是通过邮件文档这种一来一回反反复复的沟通模式;因此测试人员可以专注于测试的本质，而不是偶然的细节。这减少了对文档的需求。

更短的周期：需求验证或测试的时间不再是按月来计算，而是按天甚至按小时计算。用户验收测试在每个sprint的结尾都会进行;

更灵活的计划：敏捷测试也需要拥抱变化，测试计划不再是一成不变的文档，而会根据业务价值交付的顺序进行灵活的调整;

更高效的自动化：相比传统测试，自动化在敏捷测试中扮演了极其重要的角色。它是实现快速交付确保质量的一种非常有效的手段敏捷测试欢迎持续反馈，帮助开发人员做出更改并快速解决性能问题。

其他好处包括：

更快地捕获错误并节省时间和金钱：敏捷方法有助于减少错误数量并在最短时间内解决它们，从而避免耗时且昂贵的修复。

高产品质量：在这里，开发和测试齐头并进。这使测试人员能够实施预防和纠正措施以提高软件质量。

敏捷开发强调快速交付价值，因此需要快速获取用户需求。可以通过用户访谈、问卷调查、原型测试等方式获取用户需求，了解用户的需求和期望。

作为敏捷测试人员，除通过产品需求评审获取测试需求外，还可以采用下列启发式测试准则来帮助自己对问题的判断。

● 产品愿景(Vision)：该项新开发的功能特性（以下简称“该项功能”?）是否和产品愿景一致？

● 业务(Business)：从操作逻辑、业务流程来分析，是否合 理？有没有冲突？

● 用户期望(User Expectation)：根据对客户业务的理解或通过对用户行为的分析、扮演用户的角色等，判断该项功能是否和用户期望一致？

● 声明(Claim)：该项功能是否和公司（如管理层、市场部、产品经理等）曾就该产品所做的各种声明？

● 竞品比较(Comparable Product)：和竞争性产品进行比较来判断产品的合理性。

● 历史性：该项功能是否和上一个版本各项功能保持连贯性、一致性？

● 合规性：该项功能是否符合相关法律、条例和规范等？

敏捷测试也需要考虑非功能性需求，如性能、可扩展性、可靠性等。在敏捷开发中，可以根据用户反馈和业务场景来评估非功能性需求，并在早期就考虑这些需求对项目的影响。这样可以确保项目能够满足用户的需求和期望。

在敏捷环境中的测试规划，是一个既高效又灵活的过程，它要求测试团队能够迅速响应需求变化，同时确保软件质量。

早期测试介入：在敏捷开发的早期阶段就需要开始测试规划，与产品团队和开发团队紧密合作，确保测试计划与项目需求同步。

每日站会：也就是每天早晨15分钟到30分钟的会议时间，最多不超过45分钟，会议形式是项目组中的成员占到白板前逐个介绍昨天完成的事项，遇到的问题，或好的方法分享，今天计划完成的工作内容等。

迭代测试计划：在每个迭代周期开始前，采用简洁明了的测试计划文档，将测试要点、策略、特定方法和重点范围等关键信息列出来，便于团队成员快速理解，随着项目进展和需更，测试计划应灵活调整。

团队合作：组建跨职能的测试团队，包括测试人员、开发人员、产品经理等，共同负责软件质量。通过紧密合作，确保测试工作与软件测试保持同步。

协作工具：利用协作工具，如禅道、TAPD、Teambition等，促进团队成员之间的日常交流和协作。通过共享信息和资源，提高团队工作效率和质量。

只要有版本构建，不管是每日还是提交时，都需要对软件版本进行自动验证，只有高成功率的持续集成才有意义。这里的 BVT 不但包含传统的冒烟测试，即对当前软件版本实现的基本功能进行测试，而且包含对代码进行扫描，检查代码的规范性、安全性等，即通常所说的静态代码分析。

传统的测试方法是“先设计、再测试”。也就是说，先分析出测试点，然后针对测试点设计好测试用例，最后执行测试。这种方法在测试目标明确的情况下是可行的。然而在实际的项目中，我们面临的测试活动要复杂的多。

与传统的测试方法相比，探索性测试主张学习，强调同时展开测试设计、执行、并从结果中获得反馈，从而持续优化测试。这是一种主张即兴发挥、快速试验、快速学习和动态调整的测试思维方式。这也是个迭代的过程，刚开始并不需要考虑地绝对充分，快速设计一些场景，然后从结果中获得反馈，再进一步优化测试，从而使测试更加丰富。

在敏捷测试流程（如Scrum）中也有验收测试，和传统的验收测试概念也不一样，简单地理解为用户故事的验收，或根据任务完成的定义(DoD)对一个开发任务的验收。也可以看做是针对要交付的版本进行全面的回归测试，因为之前是持续测试，一方面主要是单元测试和集成测试，侧重各个功能特性（或用户故事）的测试，对整个系统或业务层面测试不够；另一方面，持续测试比较零碎，版本不断更新，完成一点测试一点，需要系统性的回归测试。

将所有用户故事串起来进行相对全面的测试。从业务流程出发，完成端到端（End-to-End，E2E）的测试。相当于许多团队在 Beta 环境、准生产环境中进行一轮完整的测试或试用一段时间。

灰度发布是指在发布新版本或功能时，先选择一个较小的用户群体进行测试。如果这个用户群体中的反馈良好，那么再逐步扩大发布范围，直到所有用户都能使用新功能为止。这种策略可以帮助开发团队及时发现问题并修复，从而保证新功能的稳定运行。

测试交付还包括质量分析，并要回顾、审核整个测试过程，找到测试不佳的地方，从而在下一个迭代中改进。

测试人员是敏捷团队非常重要的一环，测试人员的成长对敏捷团队非常重要。从传统测试工作转入敏捷测试工作必然会遇到很多不适，但是只要坚持对敏捷的学习和各种新工具的开发使用，一切都能够适应下来。

谁都知道，变化，才是永远不变的，敏捷则是我们应对变化的武器。

来源：博雅教育