开启掘金成长之旅！这是我参与「掘金日新计划 · 12 月更文挑战」的第10天，点击查看活动详情
敏捷开发的最大特点是高度迭代,有周期性,并且能够及时、持续地响应客户的频繁反馈。敏捷测试即是不断修正质量 指标,正确建立测试策略,确认客户的有效需求能得以圆圆满实现和确保整个生产的过程安全的、及时的发布最终产品。
敏捷测试计划包括在该迭代中完成的测试类型,例如测试教据需求,基础架构,测试环境和测试结 果。与瀑布模型不同,在敏捷模型中,针对每个发行版编写并更新测试计划。敏捷中的典型测试计划 包括
1.测试范围
2.正在测试的新功能
3.基于功能复杂性的测试级别或类型
4.负载和性能测试
5.基础设施注意事项
6.缓解或风险计划
7.资源配置
8.可交付成果和里程碑
敏捷的测试核心
敏捷测试的核心是质量内建。
敏捷测试的目标不是发现更多的Bug,而是帮助开发人员理解需求(提前预防缺陷,而不是等开发完成了才发 现很多问题),尽快地交付高质量的软件,这就是质量内建重。
现实中,不少敏捷团队还保留提测这样的环节,开发写好代码,在某一天达到了某一个标准就提交给测试团队 测试团队开始全面测试,这其实还是传统测试,不是敏捷测试,相当于第一讲所描述的那样,开发测试被分为两个 阶段,还没有真正跨入敏捷测试,的确有不少敏捷团队只是交付的节奏快了,但执行的流程还是传统的,即我们通 常说的"小瀑布,伪敏捷"。
持续测试没有"提测"环节,持续测试也不等于持续集成,持待续集成里只包含了BVT,持续测试也不等于自动化测 试,虽然会向自动化测试借力。
持续测试就是从产品发布计划开始,直到交付、运维,测i试融于其中,并与开发形影不离,随时暴露出产品的 质量风险,随时了解产品质量状态,从而满足持续交付对测试、质量管理所提出的新要求。可以类比赛车,在比赛 过程中需要加油,或者在比赛时,车出现了故障,都是在现场处理,处理结束了再继续比赛。
目前我们也开始关注测试右移,而做更多的在线监控,在线测试
敏捷测试无处不在、无时不在。在传统测试里也提倡尽早测试,包括需求和设计的评 审;在传统测试里也提倡全过程测试。但在传统测试里阶段性特征相对突出一些,例如,需 求评审,意味着先让产品人员去写需求,但需求文档写好之后,测试人员再参加评审。而在 敏捷测试里,团队每一天都在一起工作,一起讨论需求、一起评审需求。在敏捷测试中,这 种持续性更为显著一些。
