什么叫左移？
顾名思义，测试左移在测试的左边，也就是测试开始之前进行测试的过程。涉及的阶段有需求移交阶段、设计评审阶段
为什么要左移？
1、越早发现，成本越低
我们知道尽早发现缺陷的修复成本也会相应降低，一句话：良好的开始是成功的一半
2、化被动为主动
当需求质量、开发质量差的时候，你只能被动接受，结果就是你会进行漫长痛苦的测试过程以及因为质量差导致上线延期
左移考虑的点有哪些？
需求阶段
1、需求：需求的必要性（没有这个需求会怎样），成本（开发投入成本和需求产出比是否合理）
2、功能上：需求是否考虑全面，是否有遗漏
3、兼容性：是否兼容历史逻辑
4、成本上：涉及钱的模块，是否节约成本
5、体验性：用户体验，交互是否太复杂不够直观
6、安全性：是否有权限控制、是否合规
开发设计阶段：
1、业务：业务之间是否解藕，是否有降级逻辑
是否建立可拓展的业务模型，兼容后续业务发展
2、接口：老接口的改动是否兼容历史逻辑；是否幂等
3、数据库：字段大小是否合理，设计是否存在功能缺陷
4、job：job 执行时间是否合理，job 间隔时间是否合理
5、日志：日志输出是否合理，日志是否太多、是否易于排查问题
.........
还有补充的吗？
架构设计是否合理（一般适用于新项目），帮开发写单测（？有待讨论），代码扫描，参与 CodeReview，质量门禁与质量卡点，每次交付给测试进行系统测试之前，用自动化跑一遍作为冒烟（如果有自动化的话），能做的事挺多的
小狄子
回复
这些都是开发比较关注的内容，是不是可以理解为开发的测试左移，我们单测都是开发自己写，代码扫描开发自己看，codereview 是开发组内 review,质量门禁和自动化对开发提测时没有明确卡点，但是测试上线门禁必须达到 85%，自动化必须全部通过
大葱
回复
开发->测试->运维 以测试角度来说，左移我觉得就可以是向开发靠近，关注开发关注的内容，以测试人员的视角提出独特的观点，举例来说：开发实现了一段前端代码，开发人员做 review 的时候也觉得没什么问题，但测试同事可能更关注代码的可测试性，会提出一些意见（举个不一定恰当的例子：UI 自动化的元素定位有多种方式，开发如果给元素加了 id，后期测试写自动化会更容易一些，直接 findById，也会比较稳定，开发的这个 id 可能完全没有什么业务作用，纯粹是为了给 UI 自动化定位用的，这就是可测试性的一个例子）。
测试左移，可以以测试人员的视角有独特的关注点
测试左移还可以包含提前关注下测试排期，其思路可以参考文章：https://testerhome.com/topics/34111
大葱
回复
为什么不能测试也参与代码评审呢？从底层逻辑来看，需求实现来自于代码的修改，你针对开发修改的代码做评审，可以从测试角度思考代码实现，提前发现问题（或者一些小的修改点验证，你能更好的知道验证范围）。当然会对测试代码要求高一些（此处只考虑测试左移的考虑点，不对测试技术讨论）。还有一点代码扫描的规则，可以的话最开始的规则约定，测试最好也参与一下。还有质量门禁思考为什么？对于开发提交的代码交给工具审核，也是对于开发的一种约束。（个人经验，不要太相信开发交付的东西，不仅限于代码，参数中心配置，数据库表创建，脚本等修改）