【软件测试】老说左移右移?实际我们做了什么
最近公司晋升季,听参加的小伙伴提到一些概念性的东西,其中就包括测试左移和右移。
这里就借着测试左移和右移的概念,复盘一下测试工作中的内容。
一、左移右移是什么
首先简述一下左移右移的概念。
左移
说白了就是尽早的进行测试。比如在正式提测之前,可以对需求、代码等进行评估或测试。
右移
这里是针对发布上线之后,再进行一系列的手段能够及时发现问题,降低影响范围。比如线上回归、监控等。
相比之下,右移可做的事情可能不少人都没有注意。
其实真正要做得好的话,右移或许要比左移更有挑战性。因为那是在线上,考验我们是否有能力第一时间发现问题,解决问题降低影响。
二、实际中做了什么
总体来看,目前从左到右的过程中基本都有做一些工作。下面盘点一下可做的、已做的,以及实际中的一些问题等等。
1. 需求评审
预期状态下是测试人员能够主动参与需求的设计讨论中,这个环节基本上都是做到的。
但是这里重要的是,我们参与需求会不能仅仅“听需求”,更重要的是能认真的分析需求,判断需求的合理性、上下文是哪些,以及需求覆盖的场景是否全面等。
2. 开发设计评审
这个环节也是很重要的,形式上或许不用那么严谨。
比如我们通常在大的需求、项目时候会有正式的会议讨论,但是日常大多迭代中,可能直接跟开发面对面碰一下就好了。
所以说形式不重要,但是环节必须有。
通常来说,开发人员会告诉你自己的设计,以及自己觉得会影响到的点有哪些,我们可以进行参考并进行补充。
对于开发提到的技术,我们不一定要全部都懂,但是设计思路还是需要理解的,有助于我们提高测试设计的覆盖度。
有些涉及到一些中间件交互,比如缓存、MQ等,还需要结合中间件特性引入一些针对性的测试。
3. 单元测试
这个环节我目前所参与过的项目都是没有做的,可能某些团队有一些少量的要求,但是通常业务类的系统都不会要求的,需求可能经常会变,投入回报比太低。
另外,单元测试通常开发来做比较合适,但是工期往往都是很短,根本没有时间去做单测。如果让测试人员来做,那么对测试人员的技能要求又是太高了些。
那么是不是啥都做不了呢?
也不是,个人觉得条件允许的可以尝试进行代码走读,好处如下:
- 更加清晰开发代码的改动范围
- 清楚具体代码逻辑
- 倒逼自己学习
我个人目前也在尝试做,中间会遇到一些写法、封装、设计模式等问题。有问题就需要去解决,解决了就学到了。
4. 代码检查
这里可以引入一些工具来进行代码检查,目前经手的java项目会集成 SonarQube,在代码提测的时候自动进行。
5. 自动化测试
这部分就很热门了,现在也成了老生常谈的话题。
目前我的项目里是做了接口自动化集成,使用的是组内的一个平台。但是个人觉得形式不重要,重要的是能否真正的提效。
实际中其实也发现有些人是为了自动化而自动化,接口断言不严谨,基本上检查不出问题,那么这种自动化用例就没有存在的必要了。
其实除了自动化测试用例之外,某些场景下的高效造数据的脚本也是很有必要的。
6. 发布监控
首先要注意平滑发布。
另外在发布的时候,通知相关开发人员一起进行监控。通常我会看应用日志、以及对应服务器的指标状况。
关于日志,如果在测试过程中发现有些地方需要输出日志,可以提建议给开发。
7. 线上监控
发布上线后,还是需要做一些措施来监控线上服务运行状况。
目前公司是有统一的监控系统的,在里面可以方便的查看应用的各项指标,比如:
- 请求量
- 失败率
- CPU
- 内存
- JVM
...
如果公司还没有一套完善的监控体系,那还是有必要建设一套的,有机会的话可以积极参与其中。
另外,必要的监控也是需要加上的。比如某个重要接口的调用量或错误率超过了设置的阈值,对应人员就可以收到警告,第一时间来关注解决问题。