1. 测试左移
介绍：什么是测试左移？即在提测之前介入测试，主要是借助工具或者使用一些测试手段更早地发现问题和预防问题。
测试左移的思想本质是：越早发现不合理的地方，出问题的几率就越低。
在测试左移落地前，对于测试人员的工作痛点：
-经验要求：开发变更了代码，测试要遍历哪些checklist，要求测试人员对功能模块的熟悉程度
-用例成本：每条checklist要准备用例，还要保证其数据有效性，以及定期维护用例
（一）价值：
让测试人员更早地参与开发过程
测试人员应尽早参与开发过程，以提供反馈并帮助识别缺陷。这包括与开发人员密切合作、参加每日站立会议以及参与设计和代码审查。提高代码覆盖率
使用工具来监控测试覆盖率或被测试代码的百分比，以确保正在测试所有相关代码。使用代码覆盖率工具可以帮助监控测试覆盖率，还有助于分析代码库并报告测试覆盖的代码百分比。降低错误率，提高代码质量
早期的测试有助于减少后期开发阶段的调试和错误修复成本。因为随着开发进程的推进，修复错误的成本通常会逐渐增加。
自动化测试介入
测试左移策略允许自动生成、执行和管理回归测试以及详细的覆盖率分析，这有助于确保软件的各个部分都经过充分测试，从而减少未被发现的错误。
（二）落地事项：
需求评审
需求共识和用例评审
开发设计方案评审
单元测试
要求开发组明确代码规范要求
开发自测
自动化测试
（三）具体落地方法：
在项目开始阶段就组建测试团队参与需求分析和设计评审
需求刚提出的时候，可通过借鉴竞品表现，从用户体验角度切入去分析需求设计合理性和需求价值。完善开发自测用例，并监督开发自测执行结果
测试人员需要提供接口测试最小集，接口自动化最小集，性能自动化最小集，开发自测用例必须全部执行通过。开发组明确代码规范要求，建立代码分支管理规范
代码规范：开发组应制定代码规范要求；引入代码质量检测工具（如 Sonar 代码质量检测）；开发组长对组员代码code review。
分支规范：开发人员在编码过程中，经常会因为环境不够用、或者代码被覆盖等问题而烦恼。对于敏捷开发模式的团队，需求多、分支多是常态，怎样让开发测试有序地协同工作，规范分支管理流程是必要的。
从上述维度保障开发人员编写出安全可靠的代码，减少环境干扰因素。以降低代码安全漏洞，减少代码被利用的可能性，从而提升各系统安全水平
开发提测前运行自测工具
要求开发在需求实现后，运行性能工具覆盖产品的核心性能业务场景，性能fps埋点上报，对比基线看是否通过。完善提测模板
测试人员根据以往测试经验不断完善适配公司产品的提测单模板，让开发根据提测模板发起提测申请。产品验收测试
对于产品经理，为避免产品与设计有偏离，产品稿列举的每一个点都要经过产品经理验收通过才能提测给测试人员。使用自动化测试工具进行持续集成和持续交付，确保每次代码提交都能通过测试
2. 测试右移
介绍：测试右移指产品上线了之后也可以进行一些测试活动。当然在生产环境直接做测试是不推荐的，但是我们可以在生产环境做监控，监控线上性能和可用率，一旦线上发生任何问题，尽快反应，提前反应，给用户良好的体验。
（一）价值：
验证软件在线上环境中的表现
发现潜在的性能和安全问题
收集用户反馈，优化产品体验
降低上线前的测试压力
（二）落地事项：
灰度发布：新版本线上测试
用户反馈：线上问题处理、跟踪机制
监控：合理的性能监测、数据监控和预警机制
（三）具体落地方法：
线上灰度发布
灰度发布：指在黑与白之间，能够平滑过渡的一种发布方式。即让一部分用户继续用产品特性A，一部分用户开始用产品特性B，如果用户对B没有什么反对意见，那么逐步扩大范围，把所有用户都迁移到B上面来。
用户反馈收集
创建一个合理的用户反馈渠道，例如用户支持电子邮件、在线表单、社交媒体等。确保这些渠道容易访问和使用。
提供一个明确的反馈入口，例如在软件界面中添加一个反馈按钮或联系我们的链接。
整理和分类用户反馈： 设计一个统一的反馈收集表格或数据库来记录用户反馈。
分析用户反馈： 定期审查用户反馈，确保没有漏掉任何重要问题或模式。
回应用户反馈： 及时回复用户反馈，让他们知道他们的意见和问题得到重视。
即使无法立即解决问题，也可以向用户发送一个确认信息。 如果修复了用户报告的问题，确保向他们发送更新和修复的通知。
闭环的线上问题反馈 - 检查 - 解决 - 更新流程
监控预警
一、建立性能监控平台，对异常情况的监控报警： 监控 异常js、埋点badjs、服务端接口报错、性能埋点耗时过久、帧率过低等问题
二、对关键指标每日监控（服务器指标）
3.总结：
测试左移是保证效率，右移是保证质量。 测试是干什么的？质量保证和效能提升。
所以测试是质量+效能组，围绕这两个重心不会错，测试不仅仅是点点点。