您的位置:  首页 > 技术杂谈 > 正文

DevOps模式下测试左移和测试右移

2022-12-27 15:00 https://my.oschina.net/u/6148787/blog/5671764 小编-DevOps中国 次阅读 条评论

一、什么是DevOps模式
可以参看我的上一篇文章:什么是DevOps模式,本文主要介绍DevOps模式下测试左移和测试右移可以做的事项有哪些~

二、测试左移内容


2.1 PRD评审
这一点相信很多测试同学都有参与过,需求的PRD评审,但是很多时候可能只是局限于听需求,而缺少了分析or测试需求的部分。测试一方面是熟悉需求的内容,另一方面也是找出需求的问题,确认需求的合理性,判断需求是否全面、正确,上下文具备不二性。

2.2 研发设计评审
这一点当我们测试在做测试方案、用例设计的时候,研发也在做研发设计,做好了之后通常会有研发设计的评审。测试在这个阶段是非常有必要参与研发设计的评审的。

有的同学可能会觉得,研发设计评审说的都是研发如何实现整个需求,自己去听也听不太懂,浪费时间。其实不然,虽然不一定我们能全部听懂所有的研发技术,但是至少我们能听到研发去开发整个需求的整体设计思路,听完对于我们熟悉整个需求的架构图非常有帮助,也就能帮助测试更好的去设计对应的测试用例,提高测试用例的覆盖率。

避免纯粹从黑盒的角度去设计测试用例,导致有一些个别情况下的缺失测试用例覆盖的情况。当然,如果测试具备走读研发代码的能力,参与研发的设计评审,对于提升测试用例覆盖率,会更加的事半功倍!

2.3 单元测试
这一点现在应该只有一些大厂会执行得好一些,很多中小公司都没有严格要求研发必须做单元测试。一方面是中小公司流程上要求普遍不会那么严格,另一方面也是需求开发时间越来越短,导致研发们普遍都没有很多的时间去执行单元测试的工作,为保障按时交货,都直接开发完成就扔给测试去做相应的测试。

在这一点上我依然坚持研发为主、测试为辅的思路。测试辅助研发更好的完成单元测试。为什么不是测试直接去做单元测试呢?因为这一方面需要测试具备白盒测试的能力,另一方面需要测试花费大量的时间去解读研发的代码,事倍功半。
而纯粹靠研发来做这件事,很多时候研发同学就只是大概的跑几个主case,粒度上就很粗。所以需要测试在听完研发设计评审后,去辅助研发设计更合理的单元测试用例,帮助研发提高单元测试的质量。


2.4 模块集成联调测试
这一点我们测试可以做一个mock平台或者mock服务提供给研发,帮助研发可以快速mock接口内容,提高联调测试的效率。


2.5 代码规范检查
这一点也是提高研发提测质量的手段,可以通过各类代码检查工具来规范提高研发的代码质量。比如Java系比较流行的SonarQube, 可以结合进CICD的流程,作为代码提测的必查项。


2.6 代码复杂度检查
这一点也一样,只是很多公司目前不太在意这一点。其实越复杂的代码,也就意味着其存在bug的可能性越高。同样代码越复杂,也意味着编码质量可能不高或者后期代码维护成本的升高。SonarQube目前也能扫描代码的复杂度,编译器Idea的也有类似的插件提供该项检查,因此这一点也可以列为流程中的必查项。


2.7 自动化测试
这一点就是测试最熟悉的了,自动化测试,目前主要包括UI自动化和接口自动化,实现的方式也是多种多样,编写脚本的方式、录制回放的方式,用平台、不用平台都OK。重点在于选择适合自身组织的方式,以及如何自动化是否真的提升了测试的效率,避免为了自动化而自动化。


三、测试右移内容


3.1 灰度发布
又称为“金丝雀发布”,本质就是另外构造一套环境,先把代码发布到这套环境中,只放少量指定的流量进来试用一段时间,通常为试用一周或两周,达到以实际的线上流量检测代码是否存在问题的目的,减少上线后大量流量运行下出问题的概率。引入这样的一个过程,那么测试就会先在灰度环境上做验证,也是目前大厂都必有的一个环节。


3.2 线上监控
项目上线后仍然需要关注服务的运行情况,以便在出现系统问题时能够快速做出反应。这一点主要是测试可以右移参与线上环境监控工具的部署,让整个线上的监控体系更加完善。
即使部署的工作都是运维在做,监控体系已经非常完善,测试也可以接入告警,当业务接口出错或者调用量超过阈值时,测试可以接收到对应的告警信息,和研发一起定位解决问题。


3.3 用户反馈
测试参与到线上用户反馈的问题中去,帮助复现和定位各类线上用户反馈的问题,既可以解决问题,也可以更多的了解用户实际使用过程中的问题和需求,帮助后续更好的做好需求评审和测试覆盖工作。

3.4 混沌工程
类似于“故障演练”,通过构造各类异常,验证系统在碰到这些异常时是否有做好对应的监控告警、预案处理,针对性地进行加固,防范,从而避免故障发生时所带来的严重后果。通过对各类异常提前做好监控告警和预案处理,增强系统的健壮性,增强分布式系统的信心。目前已经成为各大厂测试右移必做项目,常用工具:chaosblade

详情可以参看我之前的文章:混沌测试工具chaosblade介绍及常用命令汇总

3.5 A/B测试
ABTest 实验,其实本质上就是把平台的流量均匀分为几个组,每个组添加不同的策略,然后根据这几个组的用户数据指标,例如:留存、人均观看时长、基础互动率等等核心指标,最终选择一个最好的组上线。常用于验证不同的方案设计、算法设计的效果。

———————————————————————————————————————————————————
版权声明:本文为CSDN博主「程序员杨叔」的原创文章,遵循CC 4.0 BY-SA版权协议,转载请附上原文出处链接及本声明。
原文链接:https://blog.csdn.net/baidu_28340727/article/details/122666150

展开阅读全文
  • 0
    感动
  • 0
    路过
  • 0
    高兴
  • 0
    难过
  • 0
    搞笑
  • 0
    无聊
  • 0
    愤怒
  • 0
    同情
热度排行
友情链接