复杂业务形态回归测试思考
2021/7/2 23:21:57
本文主要是介绍复杂业务形态回归测试思考,对大家解决编程问题具有一定的参考价值,需要的程序猿们随着小编来一起学习吧!
影响凡人生活的巨大体系必有弊端
----索福克勒斯
引言
在以往的测试中,产品形态、业务形态都比较单一,无论是对于功能测试、自动化测试来讲,相对实现比较容易。显而易见,单机系统、小型微服务又或者业务未解耦的系统通常测试压力比较小,回归点比较容易梳理。
一句话来总结:业务形态比较简单
但是当业务形态比较复杂的时候,单单靠人力来完成,那就会有加不完的班,做不完的回归测试。
技术服务于业务,技术在做解耦的同时,业务也在做解耦,终极目的都是让产品多元化。
背景
近期我所在的业务线业务突然暴涨,需求源源不断,这对我们来讲是个究极考验,尤其是在回归测试方面。
以最近做的业务为例:
对接外部合作项目,产品形态非常多,有各种各样的设备、各种各样的小程序,H5
形态是一方面,重要的是对接外部合作项目比较特殊,各个渠道都会或多或少的有定制化操作,不局限页面或接口。
当然,在UI方面,个人认为回归比较难。且自身团队UI自动化实践的比较浅。
反观,如UI不可取,那么只能去回归接口。
难点便在于接口,外部合作对接上层接口一般分为2-3类,底层服务接口又有2类。且实现正式/预发回归数据清理比较复杂,会产生一定的冗余数据。
那么回归只能靠点点点了?
这个时候可能只能靠接口回归去硬着头皮上,但是日常工作便有很多需求,不能同时保证多线程工作(确实有那么多工作。。。)
回到的最原始的话题:效率 or 质量?
效率为王&质量为王?
站在高层角度上看:效率和质量,都要
实践
那么,面对问题,我们先做如下实践,是否有效果先打问号
具体如下:
·流程
·技术
·测开互动
a、流程
在流程上,应当树立起技术方案实现碰头会,开发须出技术实现方案文档,同步测试人员且与之进行评审;
技术方案具体内容是在与增加、改动的接口,以及开发自行评估的改动影响范围;
提测文件中须注明涉及影响面、梳理出详细接口字段;以及自己评估出可能影响的业务;
测试审查单测、冒烟通过率,切记不能为了通过而通过;
回归测试基线用例以及接口自动化一定保证通过。
b、技术
测试须梳理出整体业务的基线用例;
开发出具需求实现方案、涉及改动点以及影响范围;
开发完成冒烟、单测,出具相关报告;
测试根据基线用例实现接口自动化用例;
接口自动化用例覆盖单接口、场景;可集成Sonar;
codeReview循序渐进。
c、测开互动
评审需求的时候需要基于业务理解度提出影响面且罗列出来;
技术方案评审之时需要用基线用例去评估可能影响的面,与开发进行碰撞影响面的大小;
阶段性共同复盘,不局限于项目、bug等。
尾声
由于近期线上问题出现频率较为频繁,执行如上举措,尝试能否改良。
这篇关于复杂业务形态回归测试思考的文章就介绍到这儿,希望我们推荐的文章对大家有所帮助,也希望大家多多支持为之网!
- 2024-07-02springboot项目无法注册到nacos-icode9专业技术文章分享
- 2024-06-26结对编程到底难不难?答案在这里
- 2024-06-19《2023版Java工程师》课程升级公告
- 2024-06-15matplotlib作图不显示3D图,怎么办?
- 2024-06-1503-Loki 日志监控
- 2024-06-1504-让LLM理解知识 -Prompt
- 2024-06-05做软件测试需要懂代码吗?
- 2024-06-0514-ShardingSphere的分布式主键实现
- 2024-06-03为什么以及如何要进行架构设计权衡?
- 2024-05-31全网首发第二弹!软考2024年5月《软件设计师》真题+解析+答案!(11-20题)