什么是敏捷测试
互联网产品开发多数都是用的敏捷开发模式, 这种模式下产品发布频繁, 产品更新快, 所以传统的测试行为是跟不上产品更新的速度, 在这种变革下, 产生了敏捷测试, 同时对测试人员的要求也更高, 需要每个人都能够快速而高效的面对变化.
敏捷测试的特点
相对于传统的测试行为, 敏捷测试有如下特点:
"敏捷测试强调持续集成, 持续的质量反馈, 测试阶段划分模糊
"敏捷测试没有很强的计划性, 强调的是测试速度和对变化的适应性
"敏捷测试时刻以用户需求为中心, 关注产品本身, 将产品功能的验证和需求的确认统一起来
"敏捷测试强调团队的沟通和协作, 同敏捷开发类似, 文档性的工作很少
"敏捷测试是基于自动化的, 自动化程度高低决定敏捷测试的成败
"敏捷测试强调全民参与, 无时无刻, 随时随地的测试, 要求整个团队对质量负责
敏捷测试金字塔
相较于传统测试中的阶段划分, 比如测试V模型 (需求分析, 概要设计,详细设计, 编码,单元测试, 集成测试,系统测试, 验收测试), 敏捷测试也有自己的测试模型, 并且不同于V模型, 整个敏捷测试活动是贯穿于软件的生命周期之中的. 敏捷测试的模型就是金字塔模型:
测试职责划分
敏捷测试强调全民参与, 共同为质量负责, 所以金字塔中的每一层都由团队中不同的角色负责
"单元测试层: 这一层主要由产品开发同学负责, 比如使用Junit开发方法的单元测试用例, 通常这些用例都是静态的, 测试数据通过各种Mock技术产生
"API层测试: 这一层主要由测试同学负责, 比如在阿里内部, 我们就需要对Http, HSF, TOP/MTOP等接口进行业务上的功能测试, 验证是否符合接口定义和业务需求, 因为是基于业务测试, 所以测试数据都是真实地, 需要我们调用其他业务方提供的接口生成测试用的数据.
"手动测试层: 这一层由团队所有的角色负责, 特别要求需求方和产品经理随时随地的进行产品手动验收测试和探索性测试, 这一层也体现出敏捷测试所要求的整个团队对质量负责的理念
基于BDD的敏捷测试
BDD是行为驱动开发的简称(Behavior Driven Development), 他的Feature文档和胶水代码就像桥梁一样, 将业务需求和产品实现连接在一起, 所以BDD不仅可以作为自动化测试框架进行产品功能测试, 也可以作为业务验收工具, 在手动层进行验收测试.
BDD可以在API层和UI层上实现自动化测试, 因为Feature文档是用中文书写, 并且里面的场景是可以执行的, 所以需求方和产品经理也不会在觉得我们的自动化测试代码晦涩难懂, 结合持续集成, 他们也能够随时跟踪产品是否按照预期的业务行为进行工作的.
Feature文档中的场景描述都是基于业务行为的, 步骤清晰, 且画面感强, 同时还包含业务需求描述, 所以团队中的每个人都可以基于Feature文档进行手动验收测试和探索性测试.
BDD敏捷测试实践
在互联网业务的测试过程中, 我们采取BDD的敏捷测试方法, 大量使用自动化进行回归测试, 将业务需求进行实例化, 然后又将实例化的需求转为接口和UI的自动化测试用例, 结合持续集成框架, 不仅提高了测试效率, 同时也提高了产品的稳定性和开发团队的效率.
下面以百度搜索为例, 介绍如何实例化一个需求,同时在Jenkins中进行持续回归
1.百度搜索功能的feature文档:
2.对应的Java实现代码 (UI回归测试)
3.结合Jenkins和 cucumber-reports-plugin 插件, 我们可以每天监控各个Feature的执行情况:
具体配置信息参见cucumber-reports-plugin 主页.
测试工程师在敏捷开发团队中的职责
在敏捷实践中, 测试工程师划分为两类:
"有开发能力的测试开发工程师, 这类人偏向于API层和UI层的自动化框架开发, 同时还需要负责各种测试工具开发, 比如测试数据生成工具, 供团队进行手动测试使用, 提高整体测试效率
"熟悉业务的测试工程师, 这类人对业务更熟悉和精通, 他们适合和需求方一起进行业务场景开发, 同时负责指导整个团队的验收和探索性测试
未来
随着敏捷越来越流行, 以及全栈化, 未来单纯的测试工程师将会消失, 比如:
"熟悉技术的测试和开发的界限将越来越模糊, 在高效的敏捷团队中, 这样的测试和开发是可以互换的, 这样更容易提高团队整体研发效率和产品质量.
"熟悉业务的测试和产品经理的界限越来越模糊, 这样的测试可以从更高层次发现产品中的问题, 及早发现可用性的问题, 减少后期缺陷的修复成本, 也能够提高团队整体研发效率和产品质量
版权声明：本文出极测 linxuan，51Testing软件测试网原创出品，未经明确的书面许可，任何人或单位不得对本文进行复制、转载或镜像，否则将追究法律责任。
