“精准测试”在商家地址专项的探索 | 得物技术
在商家地址专项测试中结合现有精准测试平台,以STAR模式介绍精准测试探索与实践。
一、背景
随着公司业务的不断迭代发展,业务架构越来越复杂,测试亟需优化以下几个方面:
- 应用随业务发展在不断扩展,各个应用代码复杂度会不断增加,如何准确、全面判定代码修改影响范围会越来越重要;
- 测试过程中会发现只是自身应用代码一个修改,会导致对外暴露的接口逻辑发生很大变动,此时测试人员需要判定出这个对外暴露的接口对上层应用到底有多大影响;
- 业务快速迭代导致测试时间不断压缩,全量回归是一个很困难的事情,那么测试范围需要开发测试人员根据代码和业务熟悉程度精确把控,风险不可控。
基于上述背景,QA可以将精准测试作为应用上线质量的参考维度之一,有效辅助日常迭代测试工作,提高测试效率。
二、任务
2.1 认清精准测试
精准测试是基于源代码变更分析,结合一些分析算法,从而确定改动代码影响的范围,设计测试用例进行针对性测试,一方面可以提升测试效率,另一方面精准测试还可以将测试用例与程序代码之间的逻辑映射关系建立起来, 而这个过程则是通过工具去采集测试过程执行的代码逻辑及测试数据。这两个点也正是精准测试的核心:正向追溯和逆向追溯。
所以,要想做好精准测试,核心目标可以总结为以下两点:
- 质量的评估不再完全靠个人经验和业务熟悉度,而是通过精准的数据。在测试资源有限的前提下,将用例精简到更加有针对性,提高测试效率,有效的减少漏测风险。
- 代码覆盖率的可衡量性,提升测试质量,同时帮助开发定位缺陷对应的代码执行逻辑,提升缺陷修复效率。
2.2 了解正向追溯
所谓正向溯源,就是解决开发处理bug的盲目性、QA测试覆盖率的可衡量性。通过精准测试可以分析出哪些代码被覆盖到,哪些代码没有被覆盖,从而统计测试覆盖率,通过代码覆盖率,找出漏测的地方,可以更精准的进行验证,减少重复工作。精准测试的运用是从经验型的主观判断向精准的数据可视化转变,让质量的把控减少了一些不确定性、不可控性。
在用例执行过程中,开发也可以看到QA执行用例的代码细节。从而追溯到调用具体方法与实现类,可直接在代码级定位测试执行的代码缺陷逻辑,并提供最后运行的时序数据。也可以更快地定位缺陷对应的代码执行逻辑,帮助开发人员快速修复缺陷,可追踪难复现缺陷。
<!---->
2.3 了解逆向追溯
所谓逆向追溯,就是解决QA要测什么的问题,实现了代码变更的影响面评估,分析识别增量与变更代码。QA通过精准测试对影响的代码做准确的针对性测试,回归的范围更准确,避免了全量回归造成测试资源的浪费,既保证了质量又缩短了版本的迭代周期。
在日常的迭代回归测试中极大减少回归测试的盲目性和工作量,释放人力成本,将更多的时间和成本投入到更深更复杂的测试工作中,减少资源浪费。
三、行动
基于精准测试的两大核心目标,QA可以通过正向溯源和逆向追溯进行精准测试探索。下面就借助精准测试平台以商家地址专项这个项目进行精准测试实践。
3.1 了解精准平台架构
3.2 精准平台接入计划
迭代 | 需求 | 涉及 服务 | 接口 数量 |
---|---|---|---|
512-513迭代 | 商家地址专项-地址监控 | 商家核心服务、商家下单链路服务、商家拆分服务 | 22 |
514迭代 | 商家地址专项-接口新增 | 商家拆分服务 | 2 |
3.3 开发梳理改动接口清单
从开发梳理的改动清单中,可以看到,本次商家地址涉及的改动的接口包含三个服务:商家下单链路服务(4个)、商家核心服务(8个)、商家拆分服务(10),总的接口数量为22个。
单从开发的技术方案上梳理的涉及接口清单上看,QA无法判断是否有接口遗漏或者错误,按照以往的测试策略,QA只能针对这22个接口进行相应的测试。
但是有了精准测试平台之后,QA可以先针对这三个服务在提测分支和线上master进行对比,识别出有变动的接口数量,可以初步确认测试范围。
3.4 精准平台拉取接口清单
精准平台地址:https://ep.shizhuang-inc.com/precision/center/recommend
1、商家下单链路服务
从平台拉取的结果来看,当前提测分支feature-address-513_monitor分支跟master分支对比,涉及到4个接口的改动,其中2个接口完成自动化,2个接口没有相关自动化。
对比开发梳理的商家下单链路服务改动接口清单和平台拉取的接口清单,可以看出商家下单链路服务改动接口以及数量是完全吻合的,这无疑给了QA莫大的信心。
2、商家拆分服务
从平台拉取的结果来看,当前提测分支feature-address-513_monitor分支跟master分支对比,涉及到8个接口,4个接口完成自动化,4个接口没有相关自动化。
对比开发梳理的商家拆分服务改动接口清单和平台拉取的接口清单,可以看出商家拆分服务改动接口以及数量也是完全吻合的,只是存在部分接口没有自动化覆盖,需要后期补充对应的接口自动化进行覆盖。
3、商家核心服务
从平台拉取的结果来看,当前提测分支feature-address-513_monitor分支跟master分支对比,涉及到11个接口,且均没有相关自动化。
对比开发梳理的商家核心服务改动接口清单和平台拉取的接口清单,可以看出商家核心服务改动接口数量比开发梳理的接口多一个,并且有一个接口没在开发的方案当中,说明该服务需要进行具体分析。
3.5 具体分析发现问题
1、接口遗漏
通过精准平台确认通过商家用户id查询退货地址接口也存在对应的改动,开发少梳理了一个,并同步开发在清单中进行补充。
2、代码分支合并
商家核心服务识别出了一个非地址相关的改动,跟开发确认之后发现是因为当前提测分支没有合并当前线上最新的master分支,导致跑出了非地址相关的功能数据。告知开发进行对应代码合并之后,QA需要重新部署重新拉取接口再次确认。
3、接口重载
商家核心服务有一个重载方法精准平台没有识别出这个根据商家id查询商家地址的接口,跟开发进行确认,最终结论是根据商家id查询商家地址的V2接口是重载了以下接口:平台没有看到重载的方法名,最终确认重载方法还是原来的方法名,只是在入参上作区分,一个只有商家ID,一个需要传商家ID、订单类型、商品ID。最终在精准平台确认了对应的入参区别,平台没有作为两个接口进行识别。
4、内部调用方法也被识别
在使用精准平台进行新增接口拉取的时候,发现平台会将一些私有方法识别出来,这些方法是内部调用,没有注册,接口测试平台也看不到对应的接口信息,无法覆盖。
3.6 最终接口确认
1、商家拆分服务
本次涉及8个改动接口,并补充缺少的4个接口的自动化之后,正常识别且状态正常,说明此服务接口都正常覆盖。
2、商家核心服务
本次涉及10个接口改动,并补充缺少的接口自动化之后,对应接口都能正常识别且状态正常,说明此服务接口都正常覆盖。
3、商家下单链路服务
本次涉及4个接口改动,并补充缺少的2个接口自动化之后,对应接口都能正常识别且状态正常,说明此服务接口都正常覆盖。
四、结果
4.1 各个服务触发自动化结果
1、商家拆分服务
2、商家核心服务
3、商家下单链路服务
五、探索心得
5.1 总结
- 借助于精准测试平台,发现一个开发梳理遗漏的接口,有效避免了梳理遗漏导致的测试遗漏,一定程度上规避了风险,是QA从经验型的主观判断向精准的数据可视化转变。
- 借助精准平台识别出一些没有进行自动化覆盖的接口,让QA能针对这些清单进行接口自动化的查缺补漏,从另一层面提升了自动化用例集的完整性。
- 精准平台与自动化平台、测试用例平台、覆盖率平台打通,从正向追溯和逆向追溯两个核心进行测试,确保数据的准确性、完整性,方便QA持续跟踪,提高测试效率。
5.2 优化
在接入精准测试平台的过程中,对平台有了进一步的了解,当然在使用的过程中也发现一些问题,并给开发提了相关建议,从而不断完善精准测试平台开发,也帮助QA更好更高效得完成质量保障工作。
本文属得物技术原创,来源于:得物技术官网
得物技术文章可以任意分享和转发,但请务必注明版权和来源:得物技术官网

低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。
持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。
转载内容版权归作者及来源网站所有,本站原创内容转载请注明来源。
- 上一篇
走进社区客户端测试 | 得物技术
0.引言 社区 C 端 质量 体系建设思考? 询问 一下 ChatGPT 1.关于社区客户端 1.1 社区端上功能 得物首页 搜索、发布、关注流、推荐流、沉浸式单列流、活动 tab、其他二级频道 tab 动态详情页 图文、视频、专栏、点评 私域 个人/他人主页、通讯录好友、微博好友、好友推荐 创作者 创作者体系、poizon+、种草分佣、视频分佣、成长任务、创作灵感、创作学院 活动 抽奖玩法、新人池、乐高页、年终总结、allstar全明星活动、潮流教父藤原浩活动 框架及创新 话题、圈子、ar、穿搭精选、晒单有礼、数字藏品、点评 1.2 客户端技术栈移动端应用可以分为三大类:Web 应用(Web App)、原生应用(NativeApp)、混合应用(Hybrid App)。 Web 应用 这里的 web 应用指的是移动端的 web 浏览器,和 PC 端的差别就是在移动端依附的操作系统是 iOS 和 Android 系统。一般采用的技术栈就是传统的 HTML、JS、CSS 等,包括这些年流行的 H5,但本质上还是个 web 网页,所以自然支持了跨平台。在社区这边主要用的是 nextjs11。...
- 下一篇
百度APP iOS端包体积50M优化实践(二) 图片优化
一、前言 在上一篇文章,我们介绍了包体积优化的必要性、安装包组成部分和生成过程、国内外大厂APP包体积分析、百度APP包体积优化技术方案及各项收益,本文重点讲述图片优化,解压IPA包后发现,百度APP中asset和bundle里面图片共有94M,这是我们重点优化的对象。 本系列文章目录如下: 《百度APP iOS端包体积50M优化实践(一)总览》(点击标题即可跳转) 百度APP采用如下方式对不同的图片资源进行了优化: 第一、无用图片优化,解决的是随着版本迭代,一些图片已经没有了引用关系,但还在IPA包中保留,挖掘这部分图片并删除,这个优化是所有包体积优化项目中ROI最高的,影响范围局限在单个组件内,质量可控,关键是提高查找无用图片的准确度; 第二、Asset Catalog优化:使用Asset Catalog管理的图片能被App Store工具App Thinning处理,处理后用户只会下载匹配其设备分辨率的图片资源,从而降低了用户下载的包体积; 第三、HEIC图片优化:跟PNG、JPEG、WebP相比,HEIC图片编码格式体积减少最小,从解码效率角度来说,跟WebP相比,HEIC硬解...
相关文章
文章评论
共有0条评论来说两句吧...