本文为《DevOps软件架构师行动指南》一书测试相关章节的学习笔记。
DevOps
DevOps是一套实践方法，在保证高质量的前提下，缩短系统变更从提交到部署至生产环境的时间。
DevOps五要素
- 敏捷
- 持续
- 协作
- 系统性
- 自动化
部署流水线
部署流水线是从开发提交代码，到代码实际部署到正式生产环境的流程。
- 开始：开发人员把代码提交至联合版本（dev、test、master）
- 在本地环境执行提交前测试
- 测试通过后，提交代码，提交操作触发集成构建，并进行集成测试
- 集成测试通过，提升到准生产环境（预发布环境），再次测试
- 测试通过后，部署到生产环境，并进行密切监控
- 经过一段时间的密切监控后，部署到正式生产环境
- 结束
- 持续集成：通过自动触发器进行集成，直到集成测试
- 持续交付：使用自动触发器，直到预发布系统
- 持续部署：直到部署到生产系统，都是自动化的
环境
不同环境用于不同的测试类型。成功完成的测试越多，对系统版本质量更有信心。
- 提交前：开发本地环境或开发服务器，有更详细的日志记录以帮助发现缺陷
- 构建与集成测试：持续集成服务器，有足够多的测试数据
- 用户验收测试/预发布/性能测试：尽可能接近生产环境。数据库应包含真实生产数据的一个子集
- 生产：正式生产环境，应有足够的资源以满足其日常需要
测试关注点
- 测试框架
软件以及配置的测试数据，通过在各种条件下运行它，并对行为和输出进行监控，来测试一个程序单元。测试框架会产生报表，并识别测试失败的测试用例。 - 负面测试
即异常测试。违背正确输入和执行顺序操作的测试。在进行异常测试时，常见期望是程序可能优雅地降级或失败。若故障不可避免，反馈有意义的错误信息，并以可控方式退出。 - 回归测试：
①在程序变更后力求发现新的缺陷
②确保已经被修复的缺陷不再被引入
部署流水线的不同测试
在部署流水线流程中，代码提交前、构建后、预发布环境、生产环境都有测试参与。
在开发和提交前测试中的测试
在开发过程中有两种类型的测试过程。测试驱动开发和单元测试。
测试驱动开发
传统开发流程：先概要设计，再详细设计，编码完成后进行测试。
测试驱动开发：先开发自动化测试，再编码开发功能，直到测试通过。单元测试
在知晓系统代码的前提下，对单独类或方法进行测试。
在执行提交前，自动地运行以上测试。提交前测试通常包含一组相关的单元测试，还有几个冒烟测试。目标是在集成测试前可以发现通过单元测试但未破坏整体系统的缺陷。一旦测试通过，就可以执行代码提交操作了。
集成测试
对系统已构建的可执行部分的测试。
功能测试
对已构建提交的整体系统的功能进行逐个测试，测试是否满足需求，功能能否正常，满足用户使用需求。
接口测试
对已提交的功能对应的接口进行测试，从接口层面底层是否满足健壮性，容错性，易用性。
自动化测试
丰富自动化测试用例，将测试过的主流测试功能转化为自动化脚本，在后期的回归测试中更加容易减少人工投入，丰富测试手段。
用户验收测试/预发布/性能测试
预发布是系统部署到生产环境前的最后一步，因此预发布环境应尽可能贴近生产环境。在这个步骤中有以下测试类型：
- 用户验收测试（UAT）
相关的用户或独立测试人员根据测试计划和结果对系统进行测试和接收。
可根据测试脚本测试，也可使用探索性测试。 - 自动化验收测试
对最重要的、需要重复执行的，且不太需要做很多维护的检查点实现自动化 - 冒烟测试
是自动化验收测试的一个自己，用于快速分析提交的代码是否影响到系统的某些核心功能 - 非功能测试
对性能、安全、容量以及可用性等方面的测试
生产环境
在系统部署到生产环境后，还会继续进行观察和测试。
早期发布
beta发布
将产品有计划地发布给特定用户，让用户大量使用来发现软件存在的问题与错误，再把信息反馈给开发者修改。金丝雀发布
若系统部署有多台服务器，先将新版本部署到其中几台服务器上，然后观察验证。确认没有异常后，后续再更新剩余的所有服务器。
若只有一台服务器，不可以使用金丝雀发布。A/B测试
beta发布与金丝雀发布是发布策略，A/B测试关注的是发布效果。
线上同时运行多个版本的服务，不同服务会有一些体验上的差异。相关人员通过分析各个版本的实际效果确定哪个版本执行得更好。
例如：推荐算法、用户界面
错误检测
即使系统通过所有测试，还是有可能存在缺陷。
对于检测非功能的错误，可以对系统信息进行监控。监控包括：用户请求的响应时间、队列长度等。当监控数据与历史数据有偏差时，会触发报警并通知给相关人员。
在检测到错误后，为了对错误进行跟踪溯源，一般要求系统日志有合适的记录。
在错误诊断并修复后，会在未来发布的版本进行回归测试。
现场测试
在系统部署后，通过特殊手段干扰正在运行的系统。例如：宕服务、宕虚拟机、模拟网络变慢等。
