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

随着敏捷开发模式的普及，越来越多的测试同仁也开始了敏捷测试。那么究竟什么是敏捷测试？敏捷测试与传统测试的主要区别是什么？敏捷测试的难点又是什么？本文会对这三个问题进行讲解。注意：本文只是讲解敏捷测试概念相关的核心内容，并未涉及技术细节以及实际工作中的实施案例。

敏捷开发

简单地说，敏捷开发是一种以用户需求进化为核心、迭代、循序渐进的开发方法。首先把用户最关注的软件原型做出来，交付或上线，在实际场景中去快速修改弥补需求中的不足，再次发布版本。通过敏捷实践，细化story ，提供更小的迭代。如此循环，直到用户（客户）满意。适用于需求不明确、创新性或者需要抢占市场的项目。我们手机中众多的互联网应用就是最典型的在敏捷开发模式下的孕育的产物！敏捷开发主要有如下几个优点：

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

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

现在我也找了很多测试的朋友，做了一个分享技术的交流群，共享了很多我们收集的技术文档和视频教程。
如果你不想再体验自学时找不到资源，没人解答问题，坚持几天便放弃的感受
可以加入我们一起交流。而且还有很多在自动化，性能，安全，测试开发等等方面有一定建树的技术大牛
分享他们的经验，还会分享很多直播讲座和技术沙龙
可以免费学习！划重点！开源的！！！
qq群号：110685036

敏捷测试

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

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

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

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

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

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

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

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

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

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

基础要求

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

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

高要求

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

对核心接口进行性能测试

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

敏捷测试中的难点

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

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

如果有写的不好的地方，请大家多多指教。如果有其他想法，也欢迎在评论区和我交流。