Web测试技术笔记之敏捷开发（一组基于迭代开发的软件开发方法）

一组工程最佳实践旨在允许快速交付高质量的软件，将客户需求和公司目标作为企业经营决策。
瀑布模型和敏捷模型比较：
瀑布模型：简单，分阶段，阶段间存在因果关系，不支持用户参与，要求预先确定需求：使用范围：需求易于完善定义且不易变更的软件系统。
敏捷模型：不要求需求预先完备定义，支持用户参与，支持需求的渐进式完善和确认，能够适应用户需求的变化。
使用范围：需求复杂、难以确定、动态变化的软件系统。
注意：在目标明确下瀑布模型最快，在目标不明确下敏捷模型可以帮助我们减少犯错所倒置的浪费。
敏捷模型可以更快的调整目标，可以消除不切实际的计划。
敏捷测试的原则
测试推进项目
测试不是一个阶段，贯穿全局。
每个人都在测试
缩短反馈循环
保持代码清洁
轻量级文档
测试驱动
敏捷测试人员角色：
给其他团队成员提供与测试有关的培训
确保在发布和迭代计划种，加入了测试任务并安排了合理的实践进度
积极地与开发人员和业务人员协作，对需求进行细化，尤其是对需求地可测试性，一致性和完整性进行细化。
积极地参加团队地回顾会议，建议并实施改进措施。
有几种敏捷方法支持敏捷开发，敏捷方法包括：
Scrum
Scrum是一种迭代地增量化过程，用于产品开发或工作管理。它是一种可以集合各种开发实践的经验化过程框架，scrum发布产品的重要性高于一切
XP
eXtreme Programing是一种近螺旋式的开发方法，它将复杂的开发过程分解为一个个相对比较简单的小周期：通过积极的交流、反馈以及其他一系列的方法，
让开发人员和客户都可以非常清楚开发速度、变化、将解决的问题和潜在的困难，并根据实际情况及时的调整开发过程。
水晶
水晶系列方法不强调软件开发流程的纪律性，所以它和其他敏捷方法相比易于使用，但生产率不如其他方法
FDD
特征驱动开发（Feature-Driven Development）强调特征驱动，快速迭代，既能保证快速开发，又能保证适当文档和质量。
DSDM
动态软件开发方法基于快速应用开发（RAD），与敏捷框架相一致。DSDM专注于产品的频繁交付，使用户积极参与并赋予团队快速判断权。
精益软件开发
重点在于消除浪费，为客户带来价值
Scrum框架：
包括3个角色、3个工件、5个事件、5个价值
3个角色
1、产品负责人：主要负责确定产品的功能和达到要求的标准，指定软件的发布日期和交付的内容，有权力接收或拒绝开发团队的工作成果（代表甲方？）
2、ScrumMaster：主要负责整个Scrum流程在项目种的顺利实施和进行，以及清除挡在客户和开发工作之间的沟通障碍（项目经理（中管））
3、开发团队：主要负责软件产品在Scrum规定流程下进行开发工作，包括功能实现、测试等团队，不同只能的团队人数控制在5-10人，相互协作最终达到Sprint的目标
3个工件
产品Backlog
SprintBacklog
产品增量
5个事件
Sprint（Spring本身就是一个事件，它包括了以下4个事件）
Sprint计划会议
每日站会
Sprint评审会议
Sprint回顾会议
5个价值：承诺、专注、开发、尊重、勇气
用户故事：
用户故事三要素：干系人的角色、要实现的业务价值、需要系统提供的功能
用户故事的6个特性（INVEST）：独立的（解耦）、可讨论的、对用户或客户有价值的、可估计的、小的、可测试的
用户故事排优先级：Must should（应该做但没时间可以不做） could（可以不做但做了更好） Wouldnot（不要做）
看板：
看板管理，是丰田生产模式种的重要概念，指为了打到及时生产Just In Time（JIT）方式控制现场生产流程的工具
看板的作用：
明确的阶段和准入准则
确定每个阶段的任务数量
确定交付周期的各个事件长度
确定待交付价值和已交付价值
信息的可视化和变化通知，让信息对等。
Devops：文化观念的改变+自动化工具=不断适应快速变化的市场。
测试左移和右移：
测试左移：

评审、技术对齐、自测赋能、多角色协作。
评审：
需求评审：提出需求不清晰、不合理、遗漏等意见，了解开发实现方式
研发设计评审：研发需求分解，协助梳理分解遗漏点，参与概要、接口设计评审，协助梳理遗漏逻辑
测试设计评审：对选用的测试方法，测试策略，测试用例进行评审
技术对齐：
在研发代码改动时，自动同步到标准模型定义，标准模型定义也可以自动生成测试模型类代码
自测赋能：
为研发约定自测规范：交叉测试，自测准入准出标准。
为研发搭建自测技术骨架
框架与抽象
指导文档
覆盖率监控
多角色协作
角色：产品经理、研发、测试运维
工具与平台：需求管理平台、自动化流水线平台
对齐各个角色之间的话术
需求-新功能代码分支-新功能测试-新功能测试环境
稳定可发布的产品-发布代码分支-回归测试-回归测试环境
左移的要点：降低成本，提升效率。
预防bug比拦截bug的成本要低  
提升测试效率，多角色对齐与约定是提高速度的关键
右移：
灰度
什么是灰度：
灰度从字面意思理解就是存在于黑与白之间的颜色。以互联网产品来讲，上线为黑，未上线为白。
非黑即白从来就不是一种普遍现象。灰度发布就是下发一部分进行测试调整，通过结果来决定是回滚还是全量上线，降低风险成本。
隔离与下发，分为服务端下发和客户端下发
服务端下发：
灰度机器下发、机房下发
灰度域名下发、服务下发
客户端下发：
所有灰度策略，都需要通过配置进行下发与撤回
比例下发：子域名、随机流量比例、随机用户
制定下发：按机型、按省份地区、按用户类型
监控
服务端监控：机器和服务实例监控：硬件指标，线程数等。
请求/流量监控：QPS，带宽，响应时间，成功率。
客户端监控上报
请求和流量纬度上报：成功率，响应时间
业务纬度上报：订单失败，业务请求异常。
反馈上报：用户报障
客户端通过对数据进行上报、聚合和运算后，输出实时数据曲线形成监控，对监控设置阈值，形成报警机制。
归因分析：
业务请求/流量染色：
每一个业务请求/流量都会被染色，通过染色分析失败的原因，染色可能会包含以下内容：
客户端属性：地区，用户机型，用户群体来源。
产品属性：版本号，功能开关等
右移的要点：
降低试错成本提升拦截率
心细：具备完善的灰度，配置下发，配置撤回，监控以及报警的能力；必要时设计fall back策略
胆大：只要能够灰度的都可以进行大胆的灰度实验。

误区
误区1：右移和内场测试冲突
内场测试一开始的收益很高，随后边界收益递减，这中间有个平衡点，某些产品无法试错，一次失败的交付可能导致客户的流失。
误区2：监控可以拦截大部分的线上问题
用户的反馈同样重要，是对监控的补充，另外如果是运行和产品策略等非技术因素导致的问题，一般不会被监控到。