JB的測試之旅-referrer標籤

前言

古話有云，長的越醜，命運越不待見，這不，jb又來了，熟悉的jb，熟悉的味道；

原本不太想寫這文章，主要以爲是雞毛的問題，不必記錄，可是想一想，雞毛雖小，但也算是一個坑，先擼一遍，加深印象吧，順便給大夥笑話笑話一下~

上集回顧

前幾天發了一篇關於seo耗時的問題，其實那個問題，是在8月份發生的，只是前幾天才搬到testerhome上；

通過了3個月，研發大大把原來是外包作的單進程版本重構成多進程版本，重構好的質量好多了，並且產品數據也愈來愈好，所以這個項目也給另外的同窗維護了，維護期間也就加一些廣告等增長轉化的需求，期間一直風平浪靜，直到上週。。。

根源

你們都知道，seo主要是利用搜索引擎的規則來提升網站在有關搜索引擎的內的排名；

然而，排名上去了，留存卻成問題，但做爲一個純資訊網站，沒啥功能吸引用戶留存的，既然如此，就提升轉化吧，爭取把進來的用戶洗到公衆號或其餘產品處，所以產品就提出了增長廣告位、運營位放二維碼的需求；

立項、開發、測試、驗收、上線，功能沒問題，這個功能運用至今；

上週某一天，產品說，商務&運營要求，廣告圖片替換下，這多簡單的，直接替換，驗證，秒級上線，結果，上線後的次日，產品就來了；

產品：今天看了下數據，感受昨天上線的版本有點問題哦，你看，UV掉到底了，並且
從昨天16點就開始掉，17點就開始後基本爲0了；
複製代碼

而後產品就給了一個圖，從圖中明顯能看出，的確有問題，並且問題很是的大；

這個圖是過後整理的，淺色表示22號，深色表示23號，數據已打碼，問題不大，能看出趨向；

從上圖明顯看出，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會加深點了解，至少之後爬小姐姐要記得帶上哦；

遇到問題不用慌，瞭解緣由，制定方案，也許不能落地，但思考了，結果就是屬於你的了；

再多說幾句

後面會項目比較忙，更新的頻率會稍微慢點；

目前關於測試在寫的文章有兩篇： 軟件測試經驗與教訓-讀後感，這本書有點意思、淺談自動化測試，不會講框架怎麼用，儘量站在不一樣的維度看自動化跟聊自動化，也請你們期待下，同時也是給本身壓力，但修行未夠，也但願你們多多提出意見；

最後，謝謝你們~