在传统的开发中，测试只是在开发周期的末尾执行。导致风险和成本全部集中临近发布，此时如遇到高严重的问题，会带来非常昂贵的成本，甚至阻塞发布。成本风险曲线如下：
需要在更早的、更广泛的介入测试，这样成本的损失才会减少，
于是便有了测试左移和测试右移两种说法
左移 & 右移
对比下左移和右移的成本
左移
预防规避问题，注重风险控制和效率
降低了开发和测试的成本
早期的Bug检测可以确保更好的代码和产品质量
有效解决bug
提高测试覆盖率
有效利用时间和资源
Improved design 改进设计
使自动化优先 Make automation priority
改善测试人员和每个开发人员、产品人员、运营人员之间的关系
最佳实践
确定并计划测试生命周期
Keep track of everything 记录一切
建立一个系统来显示你的结果
获得正确的连续测试工具
将开发和项目管理过程与测试相结合
定义各阶段的质量标准和控制
定义持续反馈机制
引导开发人员在编写代码时牢记可测试性
右移
是传统质量模型的自然演进，向下游演进是符合常理的事情，解决既有问题，在线上生产环境发现和解决问题
更全面、更深入、更及时
灰度发布
监控
用户反馈
神奇数字 7
如果评价自动化测试做的怎么样？
运行率(r) = 实际执行次数(m) / 本应该执行的次数(n)
0 < r < 0.7 糟糕
0.7 <= r < 1 及格
1 <= r 优秀
比如：每日构建自动化就应该是: 实际执行次数/365
单元测试、接口测试、压力测试等等都可以参考此模型
这里并不考虑测试代码自身出错的情况，如果因为测试代码不够健壮常常无法正常运行，正常情况下团队内也不会一直运行出错的测试代码
为何会有大于1的情况？如果做的好，开发的同学自己会找上门来说，我调整了一点东西，你帮我跑一下，看看有没有问题？
开发 VS 测试 技术实习差距 0.7以内
测试 VS 开发 综合能力 0.7以内
测试边界模糊化
比左移 + 右移还不够，应该是更彻底的 全面、持续的改进过程
正确的质量价值观：
不能存在鄙视链，比如：开发同学绝对不能认为自己会写几行代码，就瞧不起测试同学
不再是线性的上下游戏关系
质量是测试同学的职责，更是开发同学的职责
谁交付、谁负责
质量是每个人都应该牢记和时时践行的准则
测试要进入到每一个角落，无孔不入；测试要有能力进入到每一个角落
产品、设计、开发、测试、运维、运营等等都要严格践行，允许大家对质量的定义会稍稍有所差异
代码化(标准化)
能标准化的必须代码化、不能标准化的灵活化。
通过左移和右移，标准化无数细节的场景，进而积累大量的工具、系统、脚本、代码，接入构建部署流程自动化的发现和规避问题
关键六词
持续、改进、标准化、自动化、规模化
从产研管理的角度思考业务管理
以上的核心六词在解决了复杂的软件工程，那在生活和工作的很多地方其实都是完全适用的
把较为复杂和高风险的问题打散，分散到各种环节，通过敏捷的尝试、验证、监控、调整把每个环节持续的推进至化、尽而达到自动化
标准化和自动化是规模化的基础，规模化后边际成本就会急剧下降，收益会指数级增长，这个套路可以应用在生活和工作的很多地方， 队伍建设、业务发展等等是一样道理
以标准化为例，如果用在业务上就可以是：
能标准化的必须标准化、不能标准化的温度化。
让用户在遇到非标问题时可以享受到更人性的服务， 标准化是体现企业专业、温度化是体现企业文化。
敏捷、持续、改进、标准化、自动化、规模化 关键六词。
