测试左移和测试右移

一、软件的生命周期：

软件的生命周期主要可以分这几个阶段：需求分析 -> 软件设计 -> 程序编码 -> 软件测试 -> 验收上线 -> 运行维护。这流程看起来没毛病，但是却有些缺点：

1、测试过程是在一定时间间隔内发生的，测试人员必须等待产品完全构建才能找到错误和故障；测试会非常被动：当需求质量、开发质量差的时候，你只能被动接受，结果就是你会经历漫长痛苦的测试过程以及因为质量差而导致上线延期。

2、Bug的成本在后期是非常高的，需要花费很多精力和时间去修复。甚至严重的情况是产品都不能按时发布，造成很大的损失。

3、有可能一个线上问题裸奔了几个月，最后是业务方先发现才排查到是Bug导致，由于影响时间过长给公司造成的损失巨大，还被质疑为什么这么明显简单的问题上线之后没人发现。

二、左移与右移：

左移和右移是相对软件生命周期的几个阶段而言；左移是往测试之前的分析、设计、开发阶段移，右移是往发布、上线之后移。

测试左移：左移的思想本质是越早的发现不合理的地方，出问题的几率就越低。测试左移的原则支持测试团队在软件开发周期早期和所有干系人合作。因此他们能清晰地理解需求以及设计测试用例去帮助软件“快速失败”，促使团队更早的修改所有的bug。参与和理解会使测试人员获取产品完整的知识，彻底想清楚各种场景，根据软件行为设计实时的场景，这些都会帮助团队在编码完成之前识别出一些缺陷。

测试右移：右移是往发布之后移。也就是产品上线了之后也可以进行一些测试活动。当然在生产环境直接做测试是不推荐的，但我们可以在生产环境做监控，监控线上性能和可用率，一旦线上发生任何问题，尽快反应，提前反应，给用户良好的体验。技术人员要比业务方先发现问题，如果业务方已经发现业务量明显下降，说明问题已经很严重。

三、测试左移怎么做？

了解和评估需求，发掘需求的不合理之处，提供针对性的建议，提高需求的质量。

了解和评估产品设计方案，发现设计的漏洞，并及时反馈给产品人员，避免问题到了测试阶段才暴露出来，影响产品按时发布。

了解产品的技术实现，通过查看开发文档，接口文档等，执行静态测试发掘问题，检查代码问题。

参与需求评审，提出需求不清晰、不合理、遗漏等意见，了解开发的实现方式；

参与研发需求分解，协助梳理分解遗漏点；

参与概要、接口设计评审，协助梳理遗漏逻辑；

编写单元测试，通过单元测试提前进行测试；

Code Review，通过代码走读发现一些基础的问题；

提早输出测试导图，开发编码前进行评审；

部分功能提测，提早开始测试；

自动化测试，用于回归确保旧版本功能正确性；

对于测试左移，进行了相应的尝试后，也发现了测试左移实践的问题：

测试要求提供概要设计、接口文档；

测试要求单元测试必须通过；

测试干预需求设计；

提高质量上限：

健康的项目流程（合理并且严格遵守的项目流程）；

合理的需求分析（评估需求的质量，分析需求的合理性以及完整性）；

出色的系统架构；

充分利用静态代码扫描；

进行研发标准的定义；

提高质量下限：

健康的测试流程；

优秀的测试用例；

合理的测试计划；

合适的自动化；

适当的探索式测试；

开发自测（TDD、BDD，测试提供更好的用例、技术支持）；

尽早的测试；

团队质量意识的培养；

四、测试右移怎么做？

对于测试右移，线上监控可以是突破点；如：

闭环的线上问题反馈-检查-解决-更新流程

更便捷的日志查看、回传服务

丰富有效的log，便于问题的快速定位

丰富的监控指标（例如业务异常点指标）

成本监控（例如短信发送等）

关键指标每日监控（服务器指标）

生产数据监控（警报）（通过sql语句实现生产数据监控，例如是否有多个订单号一样的订单出现等）

因此对于测试右移，我认为可以围绕问题反馈、发现、定位、监控展开，参与人员则不仅仅局限于运维人员；测试右移的落实，除了质量服务的培养，更加重要的反而可能是：完善的反馈、发现、定位，在监控架构完善后，怎么更好的与项目流程结合，不要让其成为累赘

最后感谢每一个认真阅读我文章的人，礼尚往来总是要有的，虽然不是什么很值钱的东西，如果你用得到的话可以直接拿走：

  这些资料，对于【软件测试】的朋友来说应该是最全面最完整的备战仓库，这个仓库也陪伴上万个测试工程师们走过最艰难的路程，希望也能帮助到你!有需要的小伙伴可以点击下方小卡片领取