做了這么多年測試，還是分不清什么是cookie，什么是session？很正常，很多軟件測試工程師可能
到現在都搞不清什么是session，cookie相對來說會簡單很多。 下面這篇文章希望能夠幫助大家分清楚這兩個技術的區別和他們對應的使用場景。 一）.cookie的特點： cookie是一門客戶端緩存技術 cookie數據由服務器生成，發送給瀏覽器保存 cookie數據的格式：鍵值對 cookie數據過期機制：設置expire值 cookie是一門客戶端技術，一般是由服務器生成返回給瀏覽器客戶端來保存的，並且cookie是以鍵值對的
形式保存在瀏覽器客戶端的，每一個cookie都會有名稱，值，過期時間...。 cookie有很多使用場景，在項目中比較常見的有： 1.登錄記住用戶名 2.記錄用戶瀏覽記錄 ... 上面應用中大家最熟悉的應該就是記住用戶名這個場景了，以京東網站的登錄功能為例，當我們登錄了一次京東，
后面再去登錄頁面登錄的時候，會發現它會幫你回填之前的用戶名，這個場景就是通過cookie技術實現的。 1.打開火狐瀏覽器，訪問京東登錄頁面輸入登錄賬號，密碼完成登錄：
2.在首頁點擊退出登錄
3.登錄頁面再次登錄發現用戶名輸入框已經回填了之前的手機號：
4.F12打開火狐瀏覽器找到保存手機號的這個cookie："mp"，值就是我們填寫的用戶名信息：
總結：此實現過程：登錄成功，將手機號寫入到cookie---》回到登錄頁面再次登錄時，根據mp這個cookie的名稱取出手機號的值回填到用戶名輸入框（根據鍵取出值）
拓展：cookie是有過期機制的，可以通過設置cookie的過期時間來控制cookie什么時候過期
這個mp的過期時間為一個月，因此這一個月內只要不清除瀏覽器端的cookie數據，那么使用火狐瀏覽器來訪問京東的登錄頁面都可以看到手機號回填的效果。
二）session
session的特點：
session是一門服務端會話緩存技術。
session由服務器端的web容器創建，保存在服務器端。
session保存數據：鍵值對形式
session過期：默認30分鍾
session是服務端的會話技術，當用戶登錄了系統，服務器端的web容器就會創建一個會話，此會話中可以保存登錄用戶
的信息，並且也是以鍵值對的形式去保存的，現在大部分系統都是使用的session技術來做的鑒權（權限鑒定），即：當用
戶登錄完了才可以訪問系統中的一些頁面和數據。
三）session+cookie接口鑒權實戰項目講解【重點】 1.首先直接訪問系統cms的首頁index.do無法訪問成功，會被重定向到登錄頁面login.do，因為這個系統有做用戶鑒權，沒有
登錄的用戶無法訪問系統里面的數據。
2.現在登錄cms系統：
打開F12可以看到，loginJump接口的請求頭里有一個“cookie”的頭信息，里面就有
“JSESSIONID=8C01446270E498C1D879EF6983CC27E7”這個信息，
瀏覽器看到這個數據就知道要把這個數據寫到cookie當中，cookie名稱為：“JSESSIONID”，
值為：“8C01446270E498C1D879EF6983CC27E7”。這
個session會話編號就是服務器返回的。服務器端的這個session會話保存了登錄用戶的信息。
作為cookie緩存后，在瀏覽器的cookie中就能看到這個數據，如下圖：
登錄完成后再訪問系統中的任何頁面都是有沒有問題的，因為后面每次請求都會帶上瀏覽器里cookie里
面的這個"JSESSIONID"的值過去，如下圖，
訪問"用戶管理" 這個菜單的時候，請求這個頁面以及頁面的任何一個接口請求都會在請求頭里面帶上這個會
話JSESSIONID=8C01446270E498C1D879EF6983CC27E7然后再提交到服務器，如下圖的這個請求：
當服務器收到這個請求的“Cookie”請求頭里的會話id去服務器匹配，判斷是同一個session會話，會
話中有登錄用戶的信息，從而判斷這個請求是一個登錄
用戶發出的，從而放行這個請求。
上面這個過程可以用下面的這張圖來表示：
四）拓展1：session過期處理。
當服務器端的會話過期了，那么當你繼續發起請求的時候，因為你從客戶端帶過去的會話編號還是之前的那個，就會
驗證不通過，就會提示你會話過期請重新登錄。
五）拓展2：token機制
app項目為例：
一般app項目都會基於一個token做鑒權。
因為此時客戶端不是瀏覽器，因此就沒有cookie這一說了。
當用戶登錄app時，服務器會響應回來一個token信息（一般都是返回的一串唯一的標識符，比如說uuid或其他）。
服務器端會將登錄用戶跟token（票據）保存一個映射關系，一般保存在redis或者表里面，服務器端響應回來的
token會緩存在手機的本地緩存里，后面手機去訪問app的其他頁面，就會帶着這個token去服務器做驗證，如果
通過這個token能夠從redis找到登錄用戶信息那么就認為你是已經登錄了的用戶。
六）token失效：
一段時間后，服務器端的token失效了，那么就會把此token跟用戶的映射關系從redis里刪掉，那么后面再來訪問
的時候，根據你手機請求帶來的token就匹配不上登錄用戶了，服務器就告訴客戶端，需要去做重新登錄了.
七）接口測試中的登錄鑒權 大部分項目都會有登錄鑒權,鑒權實現方式為以下幾種: a. 服務端會話session機制 b. 服務端分發token機制 這里分享一下這兩種機制的實現原理和特點,希望能給大家一些啟發,代碼設計和實現在大家可以在騰訊課堂搜索"多測師"公開課里面有講到。 首先聊一聊服務端session,它就相當於一個容器,一種緩存技術,用戶登錄個網站后,服務端創建會話session保存登錄用戶的信息,並緩存
此session的會訊id-JSESSIONID到客戶端瀏覽器,緩存形式為cookie,用戶再訪問其他頁面的時候請求頭里帶上這個cookie中的這個信
息,用作服務器端校驗,校驗通過則可以正常訪問,一旦服務端的session過期,校驗失敗,從而系統完成重定向,讓你去先登錄。 而接口項目中從服務器端返回的會話id,我們怎么取出來緩存起來,然后其他接口如何帶上這個信息去訪問成為我們的關注點。 再來說說token,在一些app項目中,我們會看到登錄鑒權很多都是通過toker機制來實現的。登錄成功后,服務器端響應一串唯一的信息作
為這個token,客戶端獲取到這個token緩存在手機本地,在后續訪問這個app的時候會帶上這個token去服務端做校驗,如果能校驗通過,
那么則放行資源的訪問,否則重定向到登錄界面要求重新登錄。這里分享一篇的博客給大家,幫助大家更好的去了解下cookie和session,以及token:
https://www.cnblogs.com/xiaoshubass/p/13114740.html
八、token項目實戰【重點】 1、首先訪問多測師P2P金融項目首頁、調通登錄接口后會在響應體中返回token值
2、然后拿到登錄接口返回的token值作為登錄之后的接口的參數、放置在請求頭當中
