在传统的开发中，测试只是在开发周期的末尾执行。导致风险和成本全部聚焦临近发布，此时如遇到高严重的问题，会带来超级昂贵的成本，甚至阻塞发布。成本风险曲线如下：

需要在更早的、更广泛的介入测试，这样成本的损失才会减少，

于是便有了测试左移和测试右移两种说法

左移 & 右移

上图中明显左移占比要大一些，实际在操作中也是如此

对比下左移和右移的成本

左移

预防规避问题，注重风险控制和效率

• 降低了开发和测试的成本

• 早期的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以内

测试边界模糊化

比左移 + 右移还不够，应该是更彻底的 全面、持续的改善过程

正确的质量价值观：

• 不能存在鄙视链，列如：开发同学绝对不能认为自己会写几行代码，就瞧不起测试同学

• 不再是线性的上下游戏关系

• 质量是测试同学的职责，更是开发同学的职责

• 谁交付、谁负责

• 质量是每个人都应该牢记和时时践行的准则

• 测试要进入到每一个角落，无孔不入；测试要有能力进入到每一个角落

• 产品、设计、开发、测试、运维、运营等等都要严格践行，允许大家对质量的定义会稍稍有所差异

代码化(标准化)

能标准化的必须代码化、不能标准化的灵活化。

通过左移和右移，标准化无数细节的场景，进而积累大量的工具、系统、脚本、代码，接入构建部署流程自动化的发现和规避问题

关键六词

持续、改善、标准化、自动化、规模化

从产研管理的角度思考业务管理

以上的核心六词在解决了复杂的软件工程，那在生活和工作的许多地方实则都是完全适用的

把较为复杂和高风险的问题打散，分散到各种环节，通过灵敏的尝试、验证、监控、调整把每个环节持续的推进至化、尽而达到自动化

标准化和自动化是规模化的基础，规模化后边际成本就会急剧下降，收益会指数级增长，这个套路可以应用在生活和工作的许多地方， 队伍建设、业务发展等等是一样道理

以标准化为例，如果用在业务上就可以是：

能标准化的必须标准化、不能标准化的温度化。

让用户在遇到非标问题时可以享受到更人性的服务， 标准化是体现企业专业、温度化是体现企业文化。

灵敏、持续、改善、标准化、自动化、规模化 关键六词。