敏捷开发下的测试(一)敏捷测试核心

本文是参考ThoughtWork冰玉老师(/bingyulin)讲的敏捷课程加上自己的理解写的，想听原版可以关注ThonghtWork公众号，里面有课程回顾

传统测试和敏捷测试的区别

传统测试：

独立的测试部门测试工作主要由测试人员承担详尽的测试用例文档集中的回归测试发现更多的 bug

敏捷测试：

在敏捷开发过程的所有进行质量把控的一种活动

敏捷测试不能独立存在，不是一种测试类型或方法敏捷测试不仅是测试人员的工作，是团队的活动抛开敏捷开发谈敏捷测试没有意义

敏捷测试的目标：

更快速的交付高质量软件

如何实现敏捷测试的目标

质量内建的核心就是预防缺陷大于发现缺陷缺陷发现的越晚，修复的成本就越高，所以尽可能的开发初期就尽可能的发现缺陷

测试左移

我们先看下敏捷开发的生命周期及每轮迭代生命周期

那么，由流程图可以看出，测试左移，最完美的进入方式是从初期介入，但是实际上只有很少的公司会做到测试角色参与，大多数情况下，测试角色都是从需求阶段参与

为什么测试人员要参与那么早？因为测试角色对程序/系统的了解是多维度去熟悉的，而不像开发那样是单一而深入去了解

至此

项目初期，测试角色越早参与并且给出测试角色的意见，从而可以达到预防缺陷及风险的作用需求阶段，测试角色则需要从用户、业务流程、业务风险的角度给出建议，从而达到预防缺陷和风险的

需求阶段测试角色职责

业务价值-从测试角色给出业务价值的反馈终端用户

从终端用户维度去考虑，程序/系统软件的真实使用场景 业务流程

从业务流程的维度去考虑，程序/系统软件是否真的是用户所需要的，如电商添加购物车，有很多种方式 业务风险

从业务价值的维度去考虑，我们做的特性是否需要做，业务的优先级计划又是什么 用户故事拆分-从测试角色给出业务需求拆分的用户故事是否遵循原则独立的

用户故事是独立的 可协商的

用户故事可以响应变化，是可协商的 有价值的

用户故事是有价值的，为用户所需要的 可估算的

用户故事可以估算的 足够小的

用户故事是足够小的 可测试的

用户故事是可以测试的

持续测试

测试活动贯穿用户故事生命周期，如静态测试，和动态测试通过持续集成的方式构建线上的持续自动化测试持续测试本质是在用户故事生命周期里进行的一个持续收集、快速反馈的过程 通过自动化测试方式还可以进行以下持续测试：持续安全测试

识别安全需求-安全工具集成在CI/CD中-安全测试用力-工具辅助安全测试等 持续性能测试

确定性能需求-制造性能数据-性能测试执行-持续测试，手机性能趋势数据-持续监控，掌握性能状态 持续生产环境测试

生产环境CI/CD自动化测试

生产环境问题反馈 ## 测试驱动开发单元测试驱动开发()UTDD)

设计及编码的完整性，一般由开发完成 验收测试驱动开发(ATDD)

需求实现的正确性，参与的角色有测试、开发一起完成 行为驱动开发(BDD)

促进团队协作一直理解和需求，一般由产品、开发、测试一起完成

敏捷测试宣言

如果觉得《敏捷开发流程下的测试(一)敏捷测试核心》对你有帮助，请点赞、收藏，并留下你的观点哦！