持续交付
1. 导论
定义：从代码编写交付到测试
持续集成
内容涵盖：改动频繁的汇聚、频繁的质量验证
目的：减少冲突总量、越早发现越容易修复、对进度的感知、尽早发布
实现：版本控制、质量内建、自动化、过程可视化、加速
持续交付
内容涵盖：在测试环境中频繁测试；适度频繁地发布上线
目的：越早发现越容易修复、对进度的感知、尽早发布
如何实现：版本控制、质量内建、自动化、过程可视化、加速；测试环境管理；分阶段流水线；部署自动化延伸至发布上线、流水线延伸至发布上线、环境管理延伸至生产环境。
持续部署
完全自动化的测试
通过测试后自动部署上线
不同定义：集成、交付、部署、发布
特性及其隔离
特性：用户故事的实现；线上功能的修复；非功能的改进
特性隔离：完成后提交、特性开关、后端先行、特性分支
发布的最小概念
部署单元
可部署运营的最小单元
有时又称为应用、服务
通常对应一个代码库
dev<=代码库<=>部署单元=>ops
如何实现服务编排？
软件交付的目标
优先级排序：
- 在满足好（适当的质量）的前提下
- 不断深挖快（更快的响应速度）的潜力
- 同时适当关注多（更高的产能）和省（合理的成本）
2. 软件交付过程
准备——>代码开发到开发提交——>特性开发到特性提交——>集成到发布
前传
工作项管理
工作项：需求、缺陷、任务
工作项管理工具
特性要对应到工作项
一般最佳实践：在特性分支命名中包含feature对应的任务ID。在MR的时候自动建立MR和对应feature工作项的关联。工作项与代码的关联
工作项与代码改动的关联
- 在提交说明中说明工作项ID
- 在特性分支名称中包含工作项ID
- 通过合入请求关联
工作项与版本的关联
- 提测版本
- 发布版本
- 工作项与测试活动的关联
- 特性 <=> 测试用例
- 测试发现的缺陷 <=> 测试版本、测试用例、特性
- 测试报告 <=> 测试版本、特性、测试发现的缺陷
代码开发到代码提交
内容涵盖：本地提交 VS 提交到代码托管系统
代码提交颗粒度：适当频繁提交、不要僵化执行
构建并代码级测试：单元测试、代码扫描、制品分析
部署并在环境中测试：测试环境支持端到端的测试、调试能力、针对当前改动的自动测试
特性开发到特性提交
特性颗粒度：适当小、不要僵化要求
代码提交触发的测试：有一定价值，没有在集成分支上做价值大
随时进行测试：
在特性分支上测试做的越多越好，尽量将测试从集成测试前移到特性分支
需要降低测试的成本
主要挑战：测试环境的供给和回归测试的自动化
特性提交时进行的测试和提交门禁
典型方法：
合入请求：人工代码评审、自动构建&代码级测试
特性摘除，对应特性隔离
特性的完整性：
- 特性涉及多个代码库的开发时
- 特性分支上一起测试
- 特性分支一起测试
- 集成分支上一起测试
集成到发布
发布的颗粒度：包含尽量少的特性
理想情况：每个特性单独发布
测试的颗粒度：多阶段测试、门禁
制品尽量复用，通过晋级机制保证可重复性。
发布审批
- 一级或多级人工审批的代价是等待
- 改进
- 没有明确价值的：移除
- 有明确价值的：自动判断
- 一时难以消除的：流程电子化
管理角度上，尽量不需要特性团队之外的人审批
灰度发布
目的：避免故障、发现缺陷、用户需求
方法：按版本灰度 <=> 不同部署实例；按特性灰度 <=> 特性开发
发布窗口
代价：等待和影响团队幸福感
改进：自动化和自助化、其他降低风险的手段、零停机部署（可优先考虑）
发布问题
发布回滚：操作便捷、执行迅速、更新相关记录
紧急发布：便捷流程、避免版本覆盖
排期变成版本问题进行修复
交叠
尽量避免长期、多版本的交叠
通知功能
精准推动到直接处理人
一般不必设置固定协调人
渠道：电子邮件、即时通讯工具
相关信息查看
- 流程实例及其中各个步骤的详情
- 代码改动汇总信息
- 帮助流程改进的统计信息
对多部署单元的支持
一起测试、一起发布
测试及其自动化
互联网下，移动端和服务端要单独分开。用户体验的重要性提升。
维度：功能（70%）、性能（10%）、安全性（较弱）、兼容性（20）
测试是手段，质量是目标。
质量是一种可度量的状态，是相对恒定的。
互联网模式下的测试一定是多元化的，devops下的测试就是尽最大可能通过技术手段提高软件验证的效率和效果。
质量目前不是第一位的，互联网公司追求的是效率。
更多依赖技术变革搞定，而不是依赖人去提升。
软件质量都是设计出来的，测试只是为了验证是否可以工作。
测试一定要结合流水线。
测试过程
测试定位从纯粹的测试变化为质量把控人员。
需求——>测试用例
测试工程师共同识别出具体的需求涉及的端，考虑兼容性变化，选择测试策略。
用例设计：用例评审；开发自测用例选择；自测集初始化；接口测试脚本化。
开发提测：提测前自测，进行局部单元测试，CR。
尽量让每个人都在唯一的轨道上运行
CI流水线：代码静态扫描，自动单元测试，构建FVT环境，FVT环境健康扫描，运行猫眼测试集，模块级接口层持续测试
需求级测试（UAT）：移动端测试；PC端测试；特定数据层测试；特定埋点测试；服务端性能测试；
CD流水线：应用分支合并至主干，自动构建SIT环境，自动化回归测试集，主干向其他应用分支合并，移动端稳定性测试
回归测试：局部回归测试，探索性测试，移动端性能测试；移动端安全测试；服务端安全测试；兼容性测试。
CD流水线：代码安全扫描，自动构建上线包，自动生成部署清单，灰度上线，正式上线。
上线验证：灰度包回归测试，自动包回归测试，渠道包验证，接口监控集配置。
生产监控与反馈：移动端监控；服务端监控；生产事件管理；用户反馈管理。
互联网测试过程下的质量门禁
高级：CR记录、冒烟测试结果、开发自测用例结果；功能测试通过情况、安全性情况、关联BUG解决情况。
中级：代码规范性扫描、单元测试覆盖率；专项测试通过情况、移动端性能情况、服务端性能情况、兼容性情况
经典的测试方法论在互联网下依然有用，但效果有限。重要的还是测试人员的思维能力。互联网场景下对测试效率的极致追求，迫使精准性测试的出现。
测试覆盖率——>需求覆盖率+代码覆盖率。测试的覆盖率一定要使用工具作为依托。
从纯技术的角度追求覆盖率，会极大消耗人力和成本。没有太大的必要。核心代码可以考虑
代码级软件测试的意义和必要性
- 以最小成本保证局部代码的质量
- 最严格的软件测试手段
- 尽可能在早期发现问题
- 自动化回归带来的高收益
- 测试的同时改善设计
- 提供函数使用示例
质量团队的高管，更注重在团队建设，将开发、测试拧成一股力量。
单元测试可面向敏感类、关键业务，底层逻辑的适度性覆盖，避免形象工程
自动化测试
前提
- 不能取代手工测试
- 自动化测试本身的脆弱性
- 开发工作量远大于手工执行脚本
- 发现的缺陷远远少于手工测试
- 不稳定的自动化测试笔没有实现自动化更糟糕
- 自动化代码也要不断重构
- 业务测试和自动化测试是完全不同的两种技能
适用场景
- 需求稳定，不会频繁变更
- 研发和维护周期长，需要频繁执行回归测试
- 需要在多种平台上重复运行相同测试的场景
- 某些测试项目通过手工测试无法实现，或者手工成本太高
- 被测软件的开发较为规范，能够保证系统的可测试性
- 测试人员已经具备一定的编程能力
- 以技术的维度来看，很大程度上取决于软件架构设计
互联网自动化测试领域
测试报告绝大多数应该是自动生成的，测试报告中可包含效率型结果。
接口层自动化测试要点
- 充分性
- 对接口的基本验证可实现脚本全自动生成，并执行
- 对接口的测试逻辑需透明展示，可采用代码形态和界面形态混合式
- 根据生产监控回溯接口测试充分性
- 常态性
- 接口测试是互联网全栈测试下最普遍的模式，必须持续性测试
- 基于持续交付流水线封装冒烟级、全量回归级，以便持续集成
- 接口的功能与性能可兼顾，且纳入常态化压测流水线
- 接口性能作为质量交付门槛
- 监控性
- 需把生产环境下的接口机监控纳入到正常的测试工作范畴，但需考虑不让测试人员重复工作，达到一次编写多处可用
- 通过监控推动测试右移工作模式，减少用户投诉。
度量点：
- 模块级接口测试覆盖率
- 接口平均测试密度
- 接口性能测试曲线
