软件测试模型
V模型：V模型是瀑布模型的一种改进
V模型标明了测试过程中的不同阶段
需求分析：需求文档-分析客户想要什么
概要设计：系统架构、模块划分、模块与模块之间的接口-实现软件的架构，各个模块之间使用什么接口连接
详细设计：模块内部实现的逻辑和方法
编码：用代码去实现设计的内容
单元测试：测试代码中最小模块是否符合详细设计-按照最小单位去测试（类或者函数）
集成测试：测试各个模块组成到一起后是否可以正常使用-把模块组合起来的测试，主要测试接口
系统测试：测试已经集成在一起的产品是否符合需求文档中的要求-前期主要测试功能，后期测试兼容性和性能
验收测试：测试产品是否符合用户的需求-让实际用户参与进来的测试
V模型的优缺点
优点
既有底层测试又有高层测试-底层（单元测试）高层（系统测试）
将开发阶段清楚的表现出来，便于控制开发的过程。-阶段清晰，便于管理
缺点
容易让人误解为测试是在开发完成之后的一个阶段
由于它的顺序性，当编码完成之后，正式进入测试时，这时发现的一些bug可能不容i找到其根源，并且代码修改起来很困难
如果需求变更较大，导致要重复变更需求、设计、编码、测试。返工量大。
W模型
W模型明确表示出了测试与开发的并行关系
W模型中测试伴随着整个软件开发周期，并且测试的对象不仅仅是程序，需求和设计同样要测试
开发流程 用户需求-需求分析-概要设计-详细设计-编码-集成-实施-交付
对应测试流程 用户需求&验收测试设计-需求分析&确认与系统测试设计-概要设计&集成测试设计-详细设计&单元测试设计-单元测试-集成测试-系统测试-验收测试
W模型的优缺点
优点
将测试贯穿到整个软件的生命周期中，且除了代码要测试，需求、设计等都要测试。
更早的接入到软件开发中，能尽早的发现缺陷进行修复。
测试与开发独立起来，并与开发并行。
缺点
无法支持迭代的开发模型
对有些项目，开发过程中根本没有文档产生，故W模型无法使用。
对于需求和设计的测试技术要求很高，实践起来很困难。
H模型
软件开发中需求、设计、编码等活动被分阶段执行、但是实践中，他们并不是完全串行的，它们之间更多时候是交叉进行的，更多的是迭代执行
把测试活动完全独立出来，形成一个完全独立的流程，将测试准备活动和测试执行活动清晰地体现出来
H模型的优缺点
优点 软件测试完全独立，贯穿整个生命周期，且与其他流程并发进行
软件测试活动可以尽早准备、尽早执行，具有很强的灵活性
缺点 测试就绪点分析困难
对于整个项目组的人员要求非常高
软件测试工作流程
单元测试-集成测试-冒烟测试-系统测试-回归测试-验收测试
系统测试流程 需求分析-测试计划-测试设计-用例评审-测试执行-bug管理-发布维护
测试左移
左移是往测试之前的开发阶段移
测试团队在软件开发周期早期就开始介入
对代码进行测试
从发现bug到预防bug
方法 代码评审（code review）-偏人工，从测试的角度去挑问题
代码审计-偏自动化 比如安全团队使用工具审计代码问题
单元测试
自动化冒烟测试-提供给开发脚本
研发自测
测试右移
右移是往发布之后移
产品上线后进行线上监控
线上监控监控哪些内容？
闭环的线上问题反馈-检查-解决-更新流程-把线上问题做成闭环
更便捷的日志查看、回传服务-日志回传开发测试人员
丰富有效的log，便于问题的快速定位-log日志
丰富的监控指标（例如业务异常点指标）
业务监控（例如短信发送等）
关键指标每日监控（ 服务器指标）
生产数据监控（警报）