今天和大家来聊聊啥是测试左移，啥是测试右移？首先说这个话题之前先说下，传统的软件测试流程和目前很多公司做法是怎么样的？
一般是参与需求评审，然后根据需求文档编写测试用例，等开发提测之后进行冒烟测试，提bug，复测，回归，然后开发运维上线，之后开始下一个项目，重复上面的流程。
那么这种传统测试流程有什么弊端呢？
比如当产品文档不完善导致需求不明确，或者说开发水平比较低，交付质量差，冒烟测试主流程都没通过就提测了，那么你的测试效率就会非常低下，更严重的话还可能出现测试不完导致需求延期。
还有一种情况就是当你们的软件上线之后，一旦有一些非阻碍流程性的生产问题，由于比较隐蔽，等到被发现时，可能已经过去很久了。
这个时候，生产问题的发现者很有可能是来自客户投诉或者业务发现的，那么问题最终会上升到QA，接下来就是各种复盘会了，有多难受谁经历谁知道！
所以，为了从根本上减少此类问题的发生，这就是为什么一些大厂开始推广并实践测试左移和测试右移？接下来聊聊什么是测试左移，什么是测试右移？
首先说下测试左移，测试左移一句话来说就是在提测之前介入测试。
在需求评审时不只是了解需求，而是要去评估需求的质量，分析需求的合理性以及完整性。
在开发阶段时也要参与设计方案的设计，了解开发的实现方式。因为很多开发可能只对他负责的那一块熟悉，作为测试需要评估改动范围以及是否有遗漏的模块和系统。
测试还可以通过提供测试案例或者自动化测试脚本的方式给开发，让开发在设计时考虑地更全面，同时方便开发在coding时进行自测，有助于提高产品质量，毕竟越早发现问题，解决的成本就越低。
测试同学还需要不断地培养产品、开发同学的质量意识，同时提供必要的技术支持，协助产品、开发更好的进行测试，比如公共用例、测试工具、测试脚本。
这样，你会发现提测的质量大大提高了，原本提测后你还需要花一天的时间进行冒烟测试，现在很快就可以完成。
接下来，再说说什么是测试右移。测试右移一句话就是关注产品测试完成上线之后的状态，而不是觉得上线完成之后跟自己没什么关系了。
比如关注上线之后状态主要有下面几种方式：
通过线上监控和预警，及时发现问题并跟进解决，将影响范围降到最低。在开发设计时就要考虑预警功能，系统层（如cpu、内存问题）、应用层（如响应时间）、业务层（如注册率、交易量）等出现异常的时候通过邮件等方式发出预警，相关同学才能知道哪里出了问题。
测试同学可以监督开发需要补充监控预警功能，同时关注日常监控报警，从而在第一时间进行响应。
还有一个是关注线上业务及用户使用情况，更多地关注用户价值高、使用率高的功能，在用例中补充遗漏的场景，尽量多地覆盖这些功能。
不管是测试左移还是测试右移，都是为产品质量服务。不要把提测认为是测试活动的开始，上线是测试活动的结束，更不要认为质量只是测试同学需要关注的。
最后感谢每一个认真阅读我文章的人，礼尚往来总是要有的，虽然不是什么很值钱的东西，如果你用得到的话可以直接拿走：
这些资料，对于【软件测试】的朋友来说应该是最全面最完整的备战仓库，这个仓库也陪伴上万个测试工程师们走过最艰难的路程，希望也能帮助到你!有需要的小伙伴可以点击下方小卡片领取