测试左移与测试右移
测试左移以及测试右移，能够让测试拥有更多的主动权，有更充足的时间进行测试进行探索性测试，同时不会像传统瀑布式开发流程那样因为质量差风险高每次都延期上线，并且产品的线上质量也能有保证。不管是测试左移还是测试右移，都是为产品质量服务。不要把提测认为是测试活动的开始，上线是测试活动的结束，更不要认为质量只是测试同学需要关注的。
测试左移
测试左移的思想，本质是越早的发现不合理的地方出问题的几率就越低。
测试左移的原则支持测试团队在软件开发周期早期和所有项目人员合作。因此他们能清晰地理解需求以及设计测试用例去帮助软件“快速失败”，促使团队更早的修改所有的bug。
测试左移思想下的测试人员需加大需求分析、评审的测试投入，及早的介入测试，发现功能需求、产品设计上的缺陷，以及通过测试技术等方式帮助研发进行质量内建。
总结就是测试左移的目的为了更早的澄清和确定需求，确保团队清晰一致的理解需求的业务价值，从而做正确的事情。
测试左移包含2个方面
- 拔高质量上限
- 拉高质量下限
测试左移，其实就是通过一系列的活动，能拔高质量的上限，缩短测试的周期，提拉质量的下限，这样子，我们就可以在不断拉高下限的过程中，始终将质量稳定在一个水平线上，而和团队一起追求更高的目标了。
从不重视代码质量的第一天开始，就埋下了问题修复，定位的成本和修复问题(发现的越晚解决问题成本越高)再次引入问题的成本。
当测试在周期的早期开始时，团队会更专注于质量，并且“让我们在第一时间获得正确的编码”前景。这有助于节省大量时间，并减少软件开发团队必须为特定代码执行的迭代次数。
测试左移的实现步骤
在团队的devops开发下，对于测试左移进行的操作：
- 编写单元测试，通过单元测试提前进行测试(根据项目实际情况选择吧)
- Code Review，通过代码走读发现一些基础的问题
- 提早输出测试方案、测试用例，开发编码前进行评审
- 部分功能提测，提早开始测试(引入新的测试方式解耦前后端测试)
- 自动化测试，用于回归确保旧版本功能正确性
- 参与需求评审，提出需求不清晰、不合理、遗漏等意见
- 参与研发需求分解，协助梳理分解遗漏点(不太常见)
- 参与概要、接口设计评审，协助梳理遗漏逻辑(不太常见)
对于测试左移，进行了相应的尝试后，也发现了测试左移实践的问题：
- 基础能力、基础设施达到测试左移要求
- 需求评审、技术评审测试人员要敢于表达自己的想法(不要当喷子)
- 持之以恒不要半途而废
- 敢于直面问题，解决问题，坚持自己的原则
很多人都认为是测试在要求完成一些没必要的事情，测试在干预我的工作。
其实问题的矛盾点在于前面说过的一句话：不管是测试左移还是测试右移，都是为产品质量服务。不要把提测认为是测试活动的开始，上线是测试活动的结束，更不要认为质量只是测试人员需要关注的。
对于测试左移的落实，最重要的就是全员质量服务意识的培养
测试左移，还需改进的实践
对于测试左移其实我们还有很多东西要做，就好像前面说到的都是为产品质量服务，那么在研发流程中的任何角色、人员都要为质量服务。
拔高质量上限
- 健康的项目流程（合理并且严格遵守的项目流程）
- 合理的需求分析（评估需求的质量，分析需求的合理性以及完整性）
- 出色的系统架构
- 充分利用静态代码扫描
- 进行研发标准的定义
拉高质量下限
- 健康的测试流程
- 优秀的测试用例
- 合理的测试计划
- 合适的自动化
- 适当的探索式测试
- 开发自测（TDD、BDD，DDD测试提供更好的用例、技术支持）
- 尽早的测试
- 团队质量意识的培养
对于测试左移，也需要一个重要的基础，工程习惯，SDLC(软件开发生命周期)成熟度，测试分层，持续集成，链路上延展发布的节奏，纵深上需要贴合业务的专精领域的深度探索，代码扫描（规范，问题，安全，异常等），CR(Code Review)， 代码提交行为分析，test double（mock ， fake， stub，dummy）测试替代， UT， 自动化，验收测试等。左移需要工程效率具备不亚于研发的代码能力。因此对于测试左移，可以围绕质量服务思想展开，参与人员则不仅仅局限于测试人员
测试右移
左移是往测试之前的开发阶段移，右移是往发布之后移。
也就是产品上线了之后也可以进行一些测试活动。当然在生产环境直接做测试是不推荐的，但是我们可以在生产环境做监控，监控线上性能和可用率，一旦线上发生任何问题，尽快反应，提前反应，给用户良好的体验。
技术人员要比业务方先发现问题，如果业务方已经发现业务量明显下降，说明问题已经很严重了。
测试右移其实还可以理解为如果线上发生任何问题，我们有没有能力第一时间发现问题并解决问题，并保证线上数据的一致性或尽可能少的影响线上用户，以及并且实时获取用户反馈。
测试右移的实践步骤对于测试右移，线上监控可以是突破点，：
- 闭环的线上问题反馈-检查-解决-更新流程
- 更便捷的日志查看、回传服务
- 丰富有效的log，便于问题的快速定位
- 丰富的监控指标（例如业务异常点指标）
- 成本监控（例如短信发送等）
- 关键指标每日监控（服务器指标）
- 生产数据监控（警报）（通过sql语句实现生产数据监控，例如是否有多个订单号一样的订单出现等）
因此对于测试右移，可以围绕问题反馈、发现、定位、监控展开，参与人员则不仅仅局限于运维人员测试右移还需改进的实践一样的，实践起来也是存在问题，除了技术问题之外，还有例如：
- 线上监控搭建后使用率不高
- 线上问题反馈机制，业务人员不配合等等
- 监控指标不合理，反而被认为增加服务器负载
- 测试右移的落实，除了质量服务的培养，更加重要的反而可能是：完善的反馈、发现、定位，在监控- 架构完善后，怎么更好的与项目工作(流程)结合，不要让其成为累赘
“测试右移”的价值应当体现在，评估新功能是否有价值或者是否达到预期价值，这并不是从功能性、性能角度评估，而是需要从用户真实反馈或者价值转化的角度评估，从而进一步推进产品的持续优化。或者验证功能发布后，线上是否是可靠的，即线上的质量运营。“测试右移”的直接体现是，将测试生命周期的终点从产品交付发布，延长至发布后的产品质量运营。
Comments | NOTHING