3.0 测试阶段
到了测试阶段，这里向大家推荐一本书《google软件测试之道》
测试应该是伴随着开发的全部过程的，每写一段代码之后就要想办法测试这段代码 有的人可能以为测试人员 负责保证代码的质量，但是这是一个很常见的误区 质量不是测出来的 BUG也不是因为没有测试 产生的（Bug是自己写的），希望大家在以后的工作中，能够为自己的代码负责
左边这个图是传统的测试金字塔模型，他的意思是： 越底层的测试粒度越细，就需要越多的数量去覆盖所有场景，越顶层的测试越能用少量的case覆盖大多数场景 但是有一个软件开发中的常识：越早发现的缺陷解决成本越低 因为85%的缺陷是在开发阶段引入的，而如果要在上线之后修复他们，花费的成本可能是一开始就解决他们的数百倍 所以我们还是要尽可能早的发现bug，进行充分的单元测试
3.1环境
我们日常开发的应用，可以简化成图中的模型 由客户端发送请求到网关，网关请求到后端服务器 比如我们抖音的测试同学，可能每人手里会有好几个手机，分别用来测试不同的功能 对于后端的服务，也可能有不同的版本，因此在测试中会有一个虚拟的环境概念 我们用特定的设备可以通过某些设置，让他请求到对应的后端服务器，从而达到测试对应的后端服务的目的 这样一个从客户端到服务端的一整套体系，称为一个环境
在实际的工作中，我们一般至少需要三套环境： 功能环境是用于 开发和测试新开发的功能的 集成环境是为了 把不同的功能合并在一起测试 回归环境是为了 验证新的功能对老功能没有影响 具体要根据你开发的应用采用的架构，这里只是一个最简化的模型
4.0 发布阶段
所以飞行员起飞前的检查项，很多是有血淋淋的教训的 在互联网公司， 我们会制定很多的发布规范，这些规范的背后，往往也会有一些严重的线上事故 这里推荐大家看一部纪录片《空中浩劫》 里面从一片空难飞机残骸中调查原因的过程，就很像我们平时分析线上事故的过程
4.1 各种发布模式
举个简单的例子，假如发布过程中页面突然打不开了 我们可以使用chrome的开发者者工具， 发现有一个接口连接失败 这个过程就很像我们通过黑匣子寻找事故的原因
一个请求就像一个链条，我们可以顺着链条一节一节的去推理和定位问题
实际上在发布过程中，除了出问题要快速定位，根据角色的不同，还需要做一些常规的检查
比如： 发布负责人要负责通知各个相关人员，观察各个服务的发布状态 变更服务的相关RD要按照规范检查日志，监控，响应线上的告警 值班同学要关注用户的反馈等等 就像起飞前飞行员要进行的检查一样，每完成一项就打一个勾
4.1.1 蛮力发布
4.1.2 金丝雀发布
先发一台机器 没问题 再全面发布
4.1.3 滚动发布
4.1.4 蓝绿发布
4.1.5 红黑发布
4.1.6 发布模式 对比
其实发布的模式还不止这几种 实际工作中， 我们的发布使用的是滚动发布，发布的负责人需要关注滚动的粒度和时间，以及具体执行的进度
因为这种方式对用户的体验最平滑，同时公司也有强大的流量控制能力，能够平滑的切换流量能够支持滚动 但是仍然有一些场景需要使用蓝绿发布 可能有些公司因为发布需要在用户低峰期进行，所以在那些公司发布的时候，往往都是在夜深人静的时候，这也就是程序员经常要晚上加班的很大一个原因
5.0 运维阶段
当故障发生之后，我们是有几个关键的动作的：
首先是止损，尽快去让服务恢复功能 其次是要让服务的上下游感知到出了问题 当上面两个动作做了之后大家才需要去定位和修复问题 所以大家不要反过来，线上页面都打不开了，第一时间打开IDE开始看代码 这个其实是有问题的
5.0总结一下：
经过需求阶段我们讨论该做什么不该做什么 开发阶段我们按照规范去实现产品 测试阶段我们去验证产品，修改缺陷 发布阶段我们按照流程规范上线 运维阶段我们观察线上监控和日志
一个完整的软件开发周期就走完了 互动思考题： 如果每个过程都要一步步去执行，生活会美好吗？如何优化这个流程？
