测试左移与测试右移
目录
- 1、前言
- 2、测试左移
- 2.1、左移实现步骤
- 2.2、左移过程改进
- 3、测试右移
- 3.1、右移实现步骤
- 3.2、右移过程改进
- 4、测试岗位要求
1、前言
测试左移以及测试右移，能够让测试拥有更多的主动权，有更充足的时间进行测试，同时不会像之前因为质量差风险高每次都延期上线，并且产品的线上质量也能有保证。
不管是测试左移还是测试右移，都是为产品质量服务。不要把提测认为是测试活动的开始，上线是测试活动的结束，更不要认为质量只是测试同学需要关注的。
2、测试左移
如下图所示：
大部分的问题在编码阶段引入。编码阶段引入问题的原因可能是代码问题，需求理解问题，异常处理cover不到，集成阶段，多团队合作对接过程等。
在集成阶段发现问题的修复成本是编码阶段修复成本的40倍。
从编码、单元测试、功能测试、系统测试、发布的不同阶段，修复一个bug的成本在不同阶段有着天壤差别。不仅从成本上，从修复难度，引入新问题的可能性，沟通成本，团队状态也会有很大的影响。
造成修复成本高的原因有几类：
1、出现一个线上问题，如何定位，多团队如何配合，如何确定根因？
2、线上问题，集成问题，牵扯到多个模块，如何复现？如何模拟真实环境？多线程的场景？
3、如何确定修复方案，谁来修，临时方案还是长久方案，是否是架构问题，多个模块都需要修复会增加再一次间接引入问题成本，修复会不会引入其他问题？
左移后，bug早发现早解决，修复成本下降。
视频演示：
http://mpvideo.qpic.cn/0b78tiaakaaa7aandhlhjbqvbgwdawnaabia.f10003.mp4?
http://mpvideo.qpic.cn/0bf2pqabwaaazyam5hthjbqva7gddn6aagya.f10003.mp4?
http://mpvideo.qpic.cn/0b78v4aakaaakmana7thjzqvbl6dawxqabia.f10003.mp4?
测试左移的思想，本质是越早的发现不合理的地方出问题的几率就越低。
测试左移的原则支持测试团队在软件开发周期早期和所有干系人合作。因此他们能清晰地理解需求以及设计测试用例去帮助软件“快速失败”，促使团队更早的修改所有的bug。
参与和理解会使测试人员获取产品完整的知识，彻底想清楚各种场景，根据软件行为设计实时的场景，这些都会帮助团队在编码完成之前识别出一些缺陷。
2.1、左移实现步骤
1、编写单元测试，通过单元测试提前进行测试
2、Code Review，通过代码走读发现一些基础的问题
3、参与需求评审，提出需求不清晰、不合理、遗漏等意见，了解开发的实现方式
4、参与研发需求分解，协助梳理分解遗漏点
5、参与概要、接口设计评审，协助梳理遗漏逻辑
6、提早输出测试导图，开发编码前进行评审
7、部分功能提测，提早开始测试
8、自动化测试，用于回归确保旧版本功能正确性
2.2、左移过程改进
对于测试左移，进行了相应的尝试后，也发现了测试左移实践的问题：
1、测试要求提供概要设计、接口文档
2、测试要求单元测试必须通过
3、测试干预需求设计
很多人都认为是测试在要求完成一些没必要的事情，测试在干预我的工作。
其实问题的矛盾点在于前面说过的一句话：不管是测试左移还是测试右移，都是为产品质量服务。
不要把提测认为是测试活动的开始，上线是测试活动的结束，更不要认为质量只是测试人员需要关注的。
对于测试左移的落实，最重要的就是全员质量服务意识的培养。
测试左移其实我们还有很多东西要做，就好像前面说到的都是为产品质量服务，那么在研发流程中的任何角色、人员都要为质量服务。
1、提高质量上限
（1）健康的项目流程（合理并且严格遵守的项目流程）
（2）合理的需求分析（评估需求的质量，分析需求的合理性以及完整性）
（3）出色的系统架构
（4）充分利用静态代码扫描
（5）进行研发标准的定义
2、提高质量下限
（1）健康的测试流程
（2）优秀的测试用例
（3）合理的测试计划
（4）合适的自动化
（5）适当的探索式测试
（6）开发自测（TDD、BDD，测试提供更好的用例、技术支持）
（7）尽早的测试
（8）团队质量意识的培养
对于测试左移，也需要一个重要的基础，工程习惯，SDLC成熟度，测试分层，持续集成，链路上延展发布的节奏，纵深上需要贴合业务的专精领域的深度探索，代码扫描（规范，问题，安全，异常等），CR，代码提交行为分析，test double（mock，fake，stub，dummy），UT，自动化，验收测试等。左移需要工程效率具备不亚于研发的代码能力。
因此对于测试左移，可以围绕质量服务思想展开，参与人员则不仅仅局限于测试人员。
3、测试右移
左移是往测试之前的开发阶段移，右移是往发布之后移。
也就是产品上线了之后也可以进行一些测试活动。当然在生产环境直接做测试是不推荐的，但是我们可以在生产环境做监控，监控线上性能和可用率，一旦线上发生任何问题，尽快反应，提前反应，给用户良好的体验。
技术人员要比业务方先发现问题，如果业务方已经发现业务量明显下降，说明问题已经很严重。
测试右移其实还可以理解为如果线上发生任何问题，我们有没有能力第一时间发现问题并解决问题，并保证线上数据的一致性或尽可能少的影响线上用户，以及并且实时获取用户反馈。
3.1、右移实现步骤
1、闭环的线上问题反馈-检查-解决-更新流程
2、更便捷的日志查看、回传服务
3、丰富有效的log，便于问题的快速定位
4、丰富的监控指标（例如业务异常点指标）
5、成本监控（例如短信发送等）
6、关键指标每日监控（服务器指标）
7、生产数据监控（警报）（通过sql语句实现生产数据监控，例如是否有多个订单号一样的订单出现等）
因此对于测试右移，可以围绕问题反馈、发现、定位、监控展开，参与人员则不仅仅局限于运维人员。
3.2、右移过程改进
一样的，实践起来也是存在问题，除了技术问题之外，还有例如：
1、线上监控搭建后使用率不高
2、线上问题反馈机制，业务人员不配合等等
3、监控指标不合理，反而被认为增加服务器负载
4、测试右移的落实，除了质量服务的培养，更加重要的反而可能是：完善的反馈、发现、定位，在监控-架构完善后，怎么更好的与项目工作(流程)结合，不要让其成为累赘
4、测试岗位要求
这里所列举的要求，其实是“理想型”或者是“全能型”的测试
1、会写代码，如Java、Python等
2、会用市面上常用的自动化测试工具，无论是Selenium, Appium, QTP（UFT）, Cucumber, JMeter, LoadRunnder, 统统可以上手
3、掌握运维人员使用的工具，如Jenkins、Docker、K8S等
4、会做性能测试，并可进行性能分析
5、对产品功能了如指掌
6、对测试理论，测试管理理念有深入的理解
7、细心，会沟通
8、最关键的问题是，热爱测试工作，愿意无穷尽的找bug
