前言
古话有云,长的越丑,命运越不待见,这不,jb又来了,熟悉的jb,熟悉的味道;
本来不太想写这文章,主要觉得是鸡毛的问题,没必要记录,但是想想,鸡毛虽小,但也算是一个坑,先撸一遍,加深印象吧,顺便给大伙笑话笑话一下~
上集回顾
前几天发了一篇关于seo耗时的问题,其实那个问题,是在8月份发生的,只是前几天才搬到testerhome上;
经过了3个月,研发大大把原来是外包做的单进程版本重构成多进程版本,重构好的质量好多了,而且产品数据也越来越好,因此这个项目也给另外的同学维护了,维护期间也就加一些广告等增加转化的需求,期间一直风平浪静,直到上周。。。
根源
大家都知道,seo主要是利用搜索引擎的规则来提高网站在有关搜索引擎的内的排名;
然而,排名上去了,留存却成问题,但作为一个纯资讯网站,没啥功能吸引用户留存的,既然如此,就提高转化吧,争取把进来的用户洗到公众号或其他产品处,因此产品就提出了增加广告位、运营位放二维码的需求;
立项、开发、测试、验收、上线,功能没问题,这个功能运用至今;
上周某一天,产品说,商务&运营要求,广告图片替换下,这多简单的,直接替换,验证,秒级上线,结果,上线后的第二天,产品就来了;
产品:今天看了下数据,感觉昨天上线的版本有点问题哦,你看,UV掉到底了,而且
从昨天16点就开始掉,17点就开始后基本为0了;
复制代码
然后产品就给了一个图,从图中明显能看出,的确有问题,而且问题非常的大;
从上图明显看出,22号约17点后,UV出现跳楼式直线入地的情况;
二话不说,赶紧把研发拉过来讨论,讨论后,研发一脸懵逼,表情就好像这样,哈?
然后过了几秒钟,研发就说,不应该啊,就换个运营图片而已,这个是之前的代码了,之前都没问题,现在肯定没问题的啦;
这时候从测试的角度来看,的确如研发兄弟说的,换个图片而已,不至于这样吧,但是冥冥之中总觉得哪里不对,就说,兄弟,现在数据确凿,我们都逃不掉,要不回头检查下,会不会提交了不该提交的东西?
一直扯皮是没意义的,研发就老实回去看代码,几分钟后,研发胆战心惊的来到我的怀里;
研发:emmmmm,我大致知道问题了,上周跟研发B联调的时候,不小心把一行测试代码push到
分支上了,从提交记录看,就只有两次提交,一次是修改图片,一次就是这玩意了。。
也许,可能,就是这个导致的。。吧。。
复制代码
当时听完后,就是这样的;
然后就表面淡定的说,兄弟,稳住,先把这段代码干掉,一起再观察下吧;
然后就是重新发布上线,观察数据,就出现上图的趋势: 23号9点多后,数据呈上涨趋势,数据终于恢复了,不然,jb再多也不够。。
故事到这里就结束了,产品说数据回来就好,就算回不来也没关系,反正转化那么低,大佬们只关注转化率(这心态是要炸了);
研发一脸内疚,此时肯定要安慰下研发兄弟; 兄弟,别放心上,下次注意点就好了(毕竟,背锅的不是你)
而测试,只能自己安慰自己,幸好没出大事,幸好没出大事,幸好没出大事。。。
隐患
这个事情,有3个隐患:
- 数据是上线后就马上掉,但是直到上线后第二天,产品才反馈,如果产品那天刚好休息没人看数据,后果就不可想象;(缺乏预警功能)
- 研发push代码随意;(push规范)
- 测试不知情;(信息缺乏)
想解决这问题,在小公司挺难的,只能说,提高出错门槛,增加预防手段,套路也很简单;
- 增加预警功能,这个数据是某度提供的,某度也提供预警功能,注册下手机号码,自己设置下就好了,如果要自己弄,也不难,就写个爬虫,定时爬数据,对比上次数据,出现多少占比后就预警,预警到微信、钉钉、短信、邮件,任君选择(反正代码自己写);
- push随意,这个只能找研发大佬沟通了,毕竟公司没有强制review的流程,也没可能因为这个事加这个流程,只能给研发大佬反馈,让研发注意下,当然也可以提一下增加review流程这事,做不做看大佬;
- 测试不知情,那就想办法让测试知情,之前jb写过另外一篇文章,不重复,贴链接,因公司用的是gitlab,利用gitlab ci,获取最新分支,每次push后钉钉通知,效果如何,有没有作用,看具体的测试同学,有了这个工具,以后研发push相关,一清二楚;
- 把这问题列入核心用例及自动化检查,确保后续不会再因该问题影响产品数据;
(说明下,上面贴的文章没在testerhome发布,所以贴的是自己原稿写的地址,算系列文章,要对git、gitlab ci、.gitlab-ci.yml有点了解才行,之前写的文章,懒得重新发布了,太多了,懒,而且都是学习的文章,只想在这贴有点用的)
上面的是jb的看法及做法,不一定对,欢迎大家一起讨论学习,毕竟不同角度看的问题也不一样;
到这里,好像故事要完了;
是的,没错,你再看回标题,跟Meta referrer标签有毛线关系?标题党?
回到标题
是否有人跟jb一样,好奇那段导致问题的代码是什么吗?
问了下开发,其实就是在head加了这玩意:
<meta name="referrer" content="never">
复制代码
看到后,第一反应,这不是用于做防盗链吗? 然后就想起了之前偷偷爬小姐姐,第二天却发现满满是防盗链的悲伤故事;
但是,为啥这玩意会导致那么大问题?问了下开发,开发也懵逼,直接说不太清楚;
既然如此,那就翻翻资料吧,尝试总结下;
什么是referrer
其实,只要是学过py,并用来爬过小姐姐的朋友,都会知道referrer的重要性,这是防爬的第一道门槛,没有是不行的,但可以伪造哦;
那referrer到底是干嘛的?
通俗的说法就是,是一个来源,比如,去qq.com,然后点击网页上任一的链接,跳转过去,决定就看到referer:https://www.qq.com/
这样的信息;
当然,专业的说法就是这样: Referer
是HTTP请求header 的一部分,当浏览器(或者模拟浏览器行为)向web 服务器发送请求的时候,头信息里有包含Referer
。
所以,这玩意就是一个来源;
那有啥作用?
作用
1)防盗链<b 上面说到了,这玩意很大一部分作用就是防盗链? 什么?怎么做到防盗链的作用?
很简单,referrer是代表一个来源,如果我只允许自己的网站访问自己的图片服务器,那我的域名是jb.com,那图片服务器每次取referrer时判断下是否是jb.com的域名,如果是则继续访问,不是就拦截,这不就是防盗链的效果了?很简单吧?
想破解也炒鸡简单,hardcode head就好了;
2)防止恶意请求
这个其实跟上面是一样的,也是判断下referrer,避免有人恶意搞事;
3)统计
没错就是用来统计;
参数
回到这行代码:
<meta name="referrer" content="never">
复制代码
可以看到,referrer可以设置content属性,nerve代表什么意思?还有其他属性吗?
属性值 | 结果 |
---|---|
never | 删除http head中的referrer |
always | 不改变http header中的referer的 |
origin | 只发送origin部分 |
default | 如果当前页面使用的是https协议,而正要加载资源使用的是普通的http协议,则将http header中额referer置为空 |
这里面,origin想说下,搞过爬虫的同学都知道,request header可能会同时存在这3个参数:host、referrer、origin,这3个玩意有什么区别?上面的只发送origin部分的原因是什么?
- host 描述请求将被发送的目的地,包括,且仅仅包括域名和端口号。 在任何类型请求中,request都会包含此header信息。
- origin 用来说明请求从哪里发起的,包括,且仅仅包括协议和域名。 这个参数一般只存在于CORS跨域请求中,可以看到response有对应的header:Access-Control-Allow-Origin。
- referrer 告知服务器请求的原始资源的URI,其用于所有类型的请求,并且包括:协议+域名+查询参数。 因为原始的URI中的查询参数可能包含ID或密码等敏感信息,如果写入referrer,则可能导致信息泄露。
所以有些网站考虑到安全性,会考虑用origin,而不是referrer;
关系
上面说了一大堆,还是没看到referrer为什么会导致seo的数据有影响啊;
其实,非也,已经讲到了,referrer是代表来源,referrer never是删除head的referrer,没有referrer,那怎么统计?
所以这也就是为什么,把这行代码删除了,数据就马上恢复了,一开始很担心数据恢复缓慢,以为某度爬虫那边会有缓存策略(之前踩过的坑,开发删除了robots.txt,爬虫没这玩意,就不知道怎么遍历你的网站,所以发现没有就不访问了,而且会存在缓存,就算马上恢复,需要等待某度更新或缓存失效时才再来)
小插曲
有同学会疑问,为啥文中有referrer
和referer
,是打错了吗?
非也,referer
的正确英语拼法是referrer
。 由于早期HTTP规范的拼写错误,为了保持向后兼容就将错就错了。其它网络技术的规范企图修正此问题,使用正确拼法,所以目前拼法不统一。还有它第一个字母是大写。 (网上看到就copy了,留意下)
小结
其实这个事是很小的一件事,很多同学可能觉得没问题就完事了,但是站在质量角度,这里面有很多问题,责任是各端都有,只是测试处于项目下游,永远都是受害者;
阅读完后,会referrer会加深点了解,至少以后爬小姐姐要记得带上哦;
遇到问题不用慌,了解原因,制定方案,也许不能落地,但思考了,结果就是属于你的了;
再多说几句
后面会项目比较忙,更新的频率会稍微慢点;
目前关于测试在写的文章有两篇: 软件测试经验与教训-读后感,这本书有点意思、浅谈自动化测试,不会讲框架怎么用,尽可能站在不同的维度看自动化跟聊自动化,也请大家期待下,同时也是给自己压力,但修行未够,也希望大家多多提出意见;
最后,谢谢大家~