5分钟带你了解什么是敏捷测试？难点显而易见！(3)

既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，涵盖了95%以上软件测试知识点，真正体系化！

由于文件比较多，这里只是将部分目录截图出来，全套包含大厂面经、学习笔记、源码讲义、实战项目、大纲路线、讲解视频，并且后续会持续更新

需要这份系统化的资料的朋友，可以戳这里获取

• 灵活性高，快速应对需求变更；
• 客户对每次迭代的成果提出修改意见，开发人员进行调整和完善，大大降低了一次性交付验收被客户彻底否定的项目开发风险；
• 一个产品的交付（上线）需要进行多次迭代

至于敏捷开发模式的具体实践方法，本文就不仔细介绍了，相关文章自行百度即可。

敏捷测试

敏捷测试就是在敏捷开发方法中所需要的测试流程、方法和实践。敏捷测试就是持续测试、持续反馈，需要测试人员扮演“用户代表”角色，确保产品满足客户的需求。简单地说，敏捷测试就是持续地对软件质量问题进行及时地反馈

敏捷测试与传统的测试侧重点有所不同，主要包括以下几点：

• 减少测试计划、测试用例设计等工作的比重

在敏捷方法中，不再要求写几十页的测试计划书，而是在每个迭代周期，写出一页纸的测试计划，将测试要点（包括策略、特定方法、重点范围等）列出来就可以了。在敏捷测试中，测试用例是针对use case 或user story直接进行验证，节约出来的时间，用于开发原有功能的自动化测试脚本为回归测试服务，自动化测试脚本将代替测试用例。（在后面敏捷测试中的难点章节中会对其重点讨论）

• 测试人员需要更加关注探索性测试、组合交互性测试和用户场景测试。
• 增加与产品设计人员、开发人员的交流和协作

由于敏捷方法中迭代周期短，测试人员尽早开始测试，包括及时对需求、开发设计的评审，更重要的是能够及时、持续的对软件产品质量进行反馈。测试人员要全程参与需求、产品功能设计等讨论，而且要面对面地、充分地讨论。

• 在敏捷开发流程中增加 “产品走查（Product work-through）”环节

测试人员和产品经理、开发人员在一起，从头到尾将新功能看一遍，这样可以更加直观、快速地发现问题。

• 测试人员需要有较强的代码功底

敏捷测试中需要测试人员具备编码能力的点包括：

基础要求

原有功能的自动化测试 (回归测试)

开发测试工具提升测试效率

高要求

参与代码复审（code review），并适当辅助开发人员进行单元测试

对核心接口进行性能测试

对架构中使用的组件以及研发同学的代码安全进行扫描测试

敏捷测试中的难点

回归测试是敏捷测试中需要面对的难点。每次迭代都会增加新的功能，一个产品可能会经过十几次、甚至几十次迭代，回归测试范围在不断增大，而如果每次迭代周期不变，那么留给测试人员的验收测试时间就会变得越来越少。所以回归测试很大程度上依赖于自动化测试，我建议大家以接口自动化为主，因为通过敏捷方式开发的互联网产品，无论是功能还是页面UI都会经常变化的，UI自动化测试投资与回报会非常非常的低！备注：这里不对UI自动化测试和接口自动化测试进行展开讨论！当然也有些办法可以帮助我们提升回归测试的效率，例如：

• 通过执行code diff来了解代码变动的所有地方，再做代码关联分析，就可以明确知道要进行哪些地方的回归测试。
• 回归测试只是保证主要功能点没有问题，而忽视一些细节的问题。
• 持续测试的过程，只要有时间，就进行测试，包括开发人员、产品设计人员都参与到日常的试用和测试中来。

网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。

需要这份系统化的资料的朋友，可以戳这里获取

一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！

很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！**