最近公司晋升季，听参加的小伙伴提到一些概念性的东西，其中就包括测试左移和右移。

这里就借着测试左移和右移的概念，复盘一下测试工作中的内容。

一、左移右移是什么

首先简述一下左移右移的概念。

​左移​

说白了就是尽早的进行测试。比如在正式提测之前，可以对需求、代码等进行评估或测试。

​右移​

这里是针对发布上线之后，再进行一系列的手段能够及时发现问题，降低影响范围。比如线上回归、监控等。

相比之下，右移可做的事情可能不少人都没有注意。

其实真正要做得好的话，右移或许要比左移更有挑战性。因为那是在线上，考验我们是否有能力第一时间发现问题，解决问题降低影响。

二、实际中做了什么

总体来看，目前从左到右的过程中基本都有做一些工作。下面盘点一下可做的、已做的，以及实际中的一些问题等等。

1. 需求评审

预期状态下是测试人员能够主动参与需求的设计讨论中，这个环节基本上都是做到的。

但是这里重要的是，我们参与需求会不能仅仅“听需求”，更重要的是能认真的分析需求，判断需求的合理性、上下文是哪些，以及需求覆盖的场景是否全面等。

2. 开发设计评审

这个环节也是很重要的，形式上或许不用那么严谨。

比如我们通常在大的需求、项目时候会有正式的会议讨论，但是日常大多迭代中，可能直接跟开发面对面碰一下就好了。

所以说形式不重要，但是环节必须有。

通常来说，开发人员会告诉你自己的设计，以及自己觉得会影响到的点有哪些，我们可以进行参考并进行补充。

对于开发提到的技术，我们不一定要全部都懂，但是设计思路还是需要理解的，有助于我们提高测试设计的覆盖度。

有些涉及到一些中间件交互，比如缓存、MQ等，还需要结合中间件特性引入一些针对性的测试。

3. 单元测试

这个环节我目前所参与过的项目都是没有做的，可能某些团队有一些少量的要求，但是通常业务类的系统都不会要求的，需求可能经常会变，投入回报比太低。

另外，单元测试通常开发来做比较合适，但是工期往往都是很短，根本没有时间去做单测。如果让测试人员来做，那么对测试人员的技能要求又是太高了些。

那么是不是啥都做不了呢？

也不是，个人觉得条件允许的可以尝试进行代码走读，好处如下：


  • 更加清晰开发代码的改动范围
  • 清楚具体代码逻辑
  • 倒逼自己学习

我个人目前也在尝试做，中间会遇到一些写法、封装、设计模式等问题。有问题就需要去解决，解决了就学到了。

4. 代码检查

这里可以引入一些工具来进行代码检查，目前经手的java项目会集成 SonarQube，在代码提测的时候自动进行。

5. 自动化测试

这部分就很热门了，现在也成了老生常谈的话题。

目前我的项目里是做了接口自动化集成，使用的是组内的一个平台。但是个人觉得形式不重要，重要的是能否真正的提效。

实际中其实也发现有些人是为了自动化而自动化，接口断言不严谨，基本上检查不出问题，那么这种自动化用例就没有存在的必要了。

其实除了自动化测试用例之外，某些场景下的高效造数据的脚本也是很有必要的。

6. 发布监控

首先要注意平滑发布。

另外在发布的时候，通知相关开发人员一起进行监控。通常我会看应用日志、以及对应服务器的指标状况。

关于日志，如果在测试过程中发现有些地方需要输出日志，可以提建议给开发。

7. 线上监控

发布上线后，还是需要做一些措施来监控线上服务运行状况。

目前公司是有统一的监控系统的，在里面可以方便的查看应用的各项指标，比如：


  • 请求量
  • 失败率
  • CPU
  • 内存
  • JVM
    ...

如果公司还没有一套完善的监控体系，那还是有必要建设一套的，有机会的话可以积极参与其中。

另外，必要的监控也是需要加上的。比如某个重要接口的调用量或错误率超过了设置的阈值，对应人员就可以收到警告，第一时间来关注解决问题。


--不要用肉体的勤奋，去掩盖思考的懒惰--