后端总说他啥也没动,我从线上调了一下测试接口,你再说一句动没动

时间:2022-11-19 11:56:38

       ◇  不知道广大前端同学有没有过这样的经历,在做新需求联调的时候,原本上一个版本已经做的好好的功能,前后端已经联调好的。这次做需求的时候,测试发现好多地方都不对了。

        ◇ 开发人员经常说的一句话就是:我啥也没动啊。这次就是,我们这个后端,一口咬死,我啥也没动,要不你问一下前端是不是动哪里了?

后端总说他啥也没动,我从线上调了一下测试接口,你再说一句动没动

        如果这个时候你再和他争吵下去就像极了这个图片一样,两个人都张大了嘴,来吧,我们互相伤害。 

        因为是在测试环境,大家都做了新需求,谁也不敢保证自己没动,所以这个时候争吵是无意义的。那么幸亏我提前准备了一招。

 

1、现在前端是怎么区分测试环境与线上环境的? 

        其实这个问题现在是一个普遍现象,之前也说过好几次了。

        △ 大家都是通过npm run build /prod来区分环境的,所以如果准备测试的时候,我们很高兴的终于做完需求了,打了一个npm run build包,开始部署。

        测试阶段完了,测试同学说,咱们往测试环境部署一下正式包吧,验证一下线上环境的接口。然后我们又npm run prod一下,然后部署上去。测试验证过后,喊一声没问题了,发报告吧。发完收到通知,然后我们就开始把刚才npm run prod那个包部署到线上去。

        但是线上那个包,貌似验证不了测试环境吧?

 

        △ 还有一种方式呢,就是前端不做处理,把HTML做到服务端进行渲染。服务端是可以区分测试环境的机器与线上环境的机器的,所以我们前端只要打一个包就可以,不用区分测试与线上环境。只要服务端识别到是测试机器,还是线上机器,就可以在HTML页面帮我们渲染一个区分变量,我们前端用以区分请求环境。

        但是一但到了线上,貌似线上的js还是没法往测试环境发请求吧?

 

2、为什么要从线上往测试环境发请求?

        这也是出于周全考虑的一种策略行为。试想,在开发新需求的时候,如果后端的接口名字没变,只是参数变了;或者后端的接口没变,参数没变,逻辑变了?再或者后端直接把接口名字给变了;每一种情况其实都会有一定的危险的,所以,能不上线就不上线。

        比如后端把接口名字变了,我们没有反应及时,或者沟通不及时,那么这个时候的上线过程必定是要出问题的。

        比如后端参数变了,那么试想,我们前端先上线,线上的接口会不会不适应的新版本的js,服务端先上线,会不会接收不到前端的新参数而不适应。就会变得像下面这张图一样,造成扭曲的情况。

后端总说他啥也没动,我从线上调了一下测试接口,你再说一句动没动

 

        虽然每次我们所做的功能都应该是向后兼容的,但多做一些测试措施总是没错的。

 

3、线上怎么向测试环境发请求?

        △   例如测试环境的请求前缀是  test.xx.com/api    而线上环境的请求前缀是 prod.xx.com/api

        △   那么我们前端一定是要有地方适配这2个前缀的。

        △  比如我们的网站访问地址为: www.ooo.com 这个时候调用的一定是prod.xx.com/api的请求域名

        △ 这个时候我们手动给url加个参数 例如 www.ooo.com?test=ok

        △ 这个时候如果没有任何操作,其实这对我们网站是没有任何意义的,但是我们可以在js的代码里做适配

function geturlparam(key){
   let url = window.location.href;
   let params = url.split('?')[1]
   let getParam = new URLSearchParams(p);
   return getParam.get(key);
}
var testOrProd = geturlparam('test'); 
let urlDomain = '';
if (testOrProd === 'ok') {
    urlDomain = 'test.aa.com/api';
} else {
    urlDomain = 'prod.aa.com/api';
}

module.exports = urlDomain;

通过这种线上环境向测试环境发请求的方式,是不是就可以做到另一个维度的测试了呢