微信受權登陸mock（在沒有真實微信帳號的狀況下測試大量微信帳戶受權登陸的狀況）

場景介紹

對於構建在微信公衆號的系統，賬號體系每每使用微信受權登陸（如各種微信商城應用系統）。

這樣操做不只能夠實現靜默註冊，對用戶幾乎是無感的，同時也達到了區分用戶，獲取用戶基本信息（頭像，暱稱等）。

使用微信受權的模式能夠說一次性替代用戶註冊及用戶登陸。

也是基於上面優點，咱們日常也能夠看到在微信公衆號上的應用有很多都是使用微信的這種受權登陸（ https://mp.weixin.qq.com/wiki?t=resource/res_main&id=mp1421140842）

 

由於這種賬號體系是以微信賬號爲主體的，平時咱們若是要對該類系統進行測試，就必須使用到真實的微信賬號完成登陸或註冊。

若是想要對登陸或註冊曾經進行性能方面的測試那會比較棘手（由於咱們可能沒有足夠的微信號）

 

 

如下圖爲例咱們先分析這個註冊/登陸流程

如圖上面的1，2，3步都是在微信APP裏完成的（與咱們做爲測試對象的應用服務器未產生聯繫）

直到第4步驟微信瀏覽器才向咱們的應用服務器發送了請求（該請求負責將前面步驟獲得的code傳遞到咱們本身的業務服務，該請求才是咱們本身業務服務器開始驗證登陸的開始）

通常咱們的服務器獲得code後，會在向微信服務請求用戶信息，拿到用戶信息後處理本身的業務邏輯（註冊或是登陸）

因此能看出來，登陸或測試的關鍵就是第4步這個接口。

咱們在進行性能測試時，設計的登陸或註冊邏輯（事務）主要就在於第4步請求測試數據的準備。

由於咱們應用服務從第4步拿到code後會用此code向微信查詢用戶信息，即這個code是微信即時生成的，咱們是不可能提早拿到一批能用的code用來測試的。

如今若是爲了測試能夠選擇修改服務邏輯讓其接收虛擬code，對虛擬code進行特殊處理完成虛擬的註冊。可是這樣爲了測試來改變遠工程的邏輯是十分不可取的，測試的對象應儘可能與實際用戶使用到的維持一致，並且這裏的場景就是爲了測試註冊或登陸的性能，爲了測試而故意改了一份針對測試的註冊或登陸的邏輯顯然不合適。

 

咱們進一步分析業務服務的邏輯，業務服務器會拿得到的code向微信換取用戶信息

 

 

 

如上圖業務服務器使用code向微信服務器換來了openid 及 access_token等關鍵信息 （第一幅圖是微信接口說明，第二副圖是應用服務器向微信請求的一個實例）

這時其實拿到openid便可以肯定用戶是新用戶仍是老用戶，若是新用戶能夠進行新建用戶的操做，若是是老用戶則能夠進行用戶登陸的邏輯。

固然現實中應用服務可能還會使用access_token去向微信拉取用戶頭像，暱稱等信息（https://api.weixin.qq.com/sns/userinfo?access_token=ACCESS_TOKEN&openid=OPENID&lang=zh_CN），這取決於你們產品本身的業務。

 

如上所述不難發現，若是使用錯誤的code，微信服務必定會返回錯誤，致使註冊或登陸業務中斷。如今咱們要克服的就是，如何讓錯誤的code也能有正常的返回。接口是微信的，微信顯然不會作這種事情。那咱們在不更改業務服務的任何邏輯的同時能不能在咱們應用服務器的網絡層面上mock微信的這個接口，讓不被微信認可的code也能返回正常的數據。

 

答案是能夠的，上面這個需求是能夠經過FreeHttp來完成對。藉助FreeHttp能夠截獲使用code換openid及access_token的請求，而後返回咱們本身構建的測試數據給業務服務使用。（FreeHttp 的說明及安裝能夠看這裏  http://www.javashuo.com/article/p-dflfncnc-nc.html）

 

下面以一個實際微信登陸場景爲例說明如何使用FreeHttp完成微信認證

 

1：配置代理（Fiddler）

爲了完成需求，咱們首先要爲業務服務器配置HTTP代理到咱們的Fiddler上。

通常咱們的服務器都是Linux，這裏咱們以CentOS，應用容器Tomcat 爲例說明代理配置過程

配置機器全局代理很容易

修改 /etc/profile 文件

添加上面的信息便可

不過JVM可能不會使用系統HTTP代理，因此咱們須要單獨配置Tomcat的代理 

經過設置jvm的proxyhost來實現設置tomcat中引用程序的代理

在tomcat的配置文件catalina.bat/sh中設置-Dhttp.proxySet=true -Dhttp.proxyHost=proxyserver -Dhttp.proxyPort=8888

配置示例如上圖在以上位置加上指定參數便可（不一樣應用容器或服務框架都有本身的代理設置方式，你們能夠在網絡上搜索到）

添加配置信息後重啓tomcat便可（記得服務器與代理服務所在網絡上必須是能連通的）

還有一步添加fiddler證書到服務器（爲了能解析HTTPS請求）

如上圖在咱們本身的電腦中導出證書

 

在服務器上進行以下操做

• 安裝 ca-certificates 包

yum install ca-certificates

• 啓用 dynamic CA configuration

update-ca-trust enable

• 添加證書到指定目錄 （fiddler證書）

cp FiddlerRoot.cer /etc/pki/ca-trust/source/anchors/

• 生效

update-ca-trust extract

 

 

以上步驟完成後能夠測試一下Fiddler是否能獲取服務器發送的請求

觸發服務器向外發送請求，咱們在Fiddler上應該能捕獲相應請求（上圖就是一個咱們應用服務器發送給微信的https請求）

 

2:配置FreeHttp

FreeHttp做爲第三方Fiddler擴展插件須要單獨安裝，安裝方法十分簡單（安裝步驟見  https://www.cnblogs.com/lulianqi/p/10428551.html#_label0_1）

按照咱們前面的分析，實際應用服務器是須要向微信發送code（https://api.weixin.qq.com/sns/oauth2/access_token?appid=APPID&secret=SECRET&code=CODE&grant_type=authorization_code）

應用服務器須要根據返回數據再進處理一步業務邏輯

那咱們如今直接篡改這條請求返回值，讓他對不合法code的請求也返回正常的返回數據

 

先添加一個參數化數據（用於使每次返回數據都不同）

如上圖，咱們添加一個逐步遞增的openid參數數據（按圖標註1，2，3步驟添加便可，注意紅框部分選擇參數類型及參數的格式）

這個參數表示以0001開始每次取值逐步遞增(在類表處選取該參數，能夠重置或設置該參數的值)

 

再添加一個用於產生合規響應的Response Replace規則 

如上圖添加一個Response Replace規則

由於是替換響應不須要將真實發送到微信的服務器這裏勾選Response Direct（同時爲了模擬真實場景加上50ms的延時，反覆測試微信的這條接口響應時間都控制在50ms到100ms）

在圖最大編輯框中設置相應數據（正確響應數據應該是什麼格式，抓取一個正常的請求就能夠獲得），同時咱們爲返回json裏openid添加一個參數數化數據（實際就是TestOpenId加上一個遞增的ID，這個遞增ID就是前面設置的參數化數據，這裏爲了方便演示，僅對openid進行說明，實際其餘幾個返回項也是有意義的）

紅線處*#test_openid(+)*#即表示前面添加的用戶參數（由於使用到用戶參數，須要鼠標右鍵在彈出框中把use Parameter Data 勾上）

設置完成後，點擊右下角綠色確認按鈕添加規則

 

 

完成以上設置後，後注意在右側Response Rule列表處，設置啓用Response Rule,及勾選須要執行的規則（上圖紅框區域）

 

3：測試規則

前面最開始咱們也分析過https://業務域名及路徑?code=061v6AGK1pOTj40nF0EK1LNwGK1v6AGV&state=輔助參數 (文中第一張圖的第4步，這個地址也是在前面第2步的回調地址中設置的)

咱們使用Fiddler的Composer構造這個請求（固然您能夠經過其餘測試工具甚至是瀏覽器構建請求進行調試）

 

如上圖咱們主要關注的code（咱們這裏本身構造code，實際這個code不是一個真實的code）

 

點擊Execute發送測試請求

 

 

如上圖，能夠看到服務器發給微信的請求已經被咱們替換掉了，並且返回咱們設置的「合法數據」。（咱們我應用服務器這個時候會認爲是openid爲TestOpenId0001的用戶來登陸或註冊了，而後會進入相應的業務）

 

經過數據庫驗證用戶是否成功建立成功（固然正常狀況下按不一樣業務需求，註冊一個用戶還有許多數據須要驗證）

 

4：開始登陸測試

對登陸業務進行壓力測試，一樣可使用不少工具，我這裏使用經常使用的JMeter進行演示

咱們使用先使用JMeter依次發送https://業務域名及路徑?code=TestOpenId0001&state= （使code逐步遞增，這裏遞增是爲了防止應用服務有緩存策略）

 

注意JMeter默認不使用系統代理，因此須要如上圖手動配置代理

 

 這裏使用100個用戶同時登陸（持續時間30秒，固然實際測試中有更加複雜的業務，持續時間跟用戶數也會更多）

 

經過對數據庫的檢查，咱們基本上能夠確認30秒裏這10個用戶建立了311個帳戶（而實際上咱們並無使用311個微信號）

 

簡單的測試咱們應用服已經表現出性能瓶頸（平均響應達到了8秒）

 

 

 

 同時添加服務器監控，能夠查看測試中服務器的壓力狀況（上圖表面測試中應用線程數量明顯增多，JVM的GC也加快了，能夠反覆嘗試增長壓力觀察是否存在瓶頸）

 

最後咱們就能夠根據本身的業務，添加更多的業務場景進行有針對性的測試。

 

上面只是一個例子，演示如何經過截獲服務器與微信認證服務器的請求，以達到測試本身業務微信認證登陸的過程。

你們能夠利用這個思路，結合本身的需求，進行有針對性的測試。