网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。
一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！
首先，可以明确的是，敏捷测试既不是一种方法（如黑盒方法、白盒方法等），也不是一种方式（如探索式测试）。因为在敏捷测试中可以采用已有的各种方法，包括白盒方法、黑盒方法；在敏捷中也可以采用探索式测试，也可以采用基于脚本的测试。敏捷测试应该是一套解决方案、一类测试操作与管理的框架、一组实践或由一定顺序的测试活动构成的特定的测试流程。简单地说，敏捷测试就是顺应敏捷开发方法、力求达到质量和效率平衡的一系列的测试实践。
敏捷测试强调从客户的角度，即是从使用系统的用户的角度，来测试系统。重点关注持续迭代的测试新开发的功能，而不再强调传统测试过程中严格的测试阶段。建议尽早开始测试，一旦系统某个层面可测，比如提供了模块功能，就要开始模块层面的单元测试，同时随着测试深入，持续进行回归测试保证之前测试过内容的正确性。
2.敏捷测试的意义是什么？
敏捷测试发现问题较快，而且修复起来也较快；在项目开发中即开展，可以降低bug修复成本，缩短项目的周期；
3.敏捷测试与普通测试的区别？
项目相当于开发与测试并行，项目整体时间较快。
模块提交较快，测试时较有压迫感。
工作任务划分清晰，工作效率较高。
项目规划要合理，不然测试时会出现复测的现象，加大工作量。
发现问题需跟紧，项目中人员都比较忙，问题很容易被遗忘。
耗时、或较难解决对项目影响不大的问题一般会遗留到下个阶段解决。
发现bug能够很快的解决，对相关的模块的测试影响比较小。
版本更换比较勤，影响到测试的速度。
要多与开发沟通。
要注意版本的更新情况。
测试人员几乎要参加整个项目组的所有会议
4.关注点整理
1）提供持续反馈：既然是测试驱动敏捷项目，那么很显然反馈在敏捷团队中占据重要的地位。测试人员的传统角色就是“信息提供者”，这使得她天生就对敏捷团队很有价值。敏捷测试人员的最大贡献之一是帮助产品负责人或者客户采用实例和测试的形式描述清楚每一个用户故事的需求。然后，测试人员与团队同事将这些需求转化为可执行的测试。测试人员、开发人员和其他团队成员尽快运行这些测试，并不断接收有意义的反馈。
既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，涵盖了95%以上软件测试知识点，真正体系化！
由于文件比较多，这里只是将部分目录截图出来，全套包含大厂面经、学习笔记、源码讲义、实战项目、大纲路线、讲解视频，并且后续会持续更新
系统化的资料的朋友，可以戳这里获取](https://bbs.csdn.net/forums/4f45ff00ff254613a03fab5e56a57acb)**
1万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
