【轉】如何測試微信應用號

如何測試微信應用號

by雲層

原文地址：http://mp.weixin.qq.com/s?__biz=MzA4NDIzNTIzNA==&mid=2654370226&idx=1&sn=38885f86e5d346f8c636d04ba82c3e68

---

每一次微信的動做都是商機，而隨着微信應用號的即將面世，微信應用號的開發和測試又會成爲一股新的風向。其實常常有人問到微信服務號或者微信訂閱號怎麼測試的相關內容，可能總以爲比較缺少技術含量不太想說，此次看了下應用號，就把全部問題都統一塊兒來一塊兒說一下吧。

---

架構

作測試首先應該從總體看起來，架構體系決定了測試的思想。微信的整個開發都基於下面幾個東西。

1.開發者信息

首先是開發者ID，包括Appid和AppSecret兩個內容，在微信開發者上設置的。一個用來惟一標示應用相似於用戶名，另一個是登錄的相似密碼的東西。

2.接口

接口測試測試工具，對於應用來講第一件事情就是經過前面的用戶名appid和密碼appsecret來獲取token令牌。

在後續的請求中，使用令牌來完成（令牌有點cookie或者sessionid的概念，應該也有超時的控制）

3.前端頁面

微信提供了一個前端調試工具（微信Web開發者工具），其實你也能夠認爲是一個chrome的定製版

在企業號、公衆號這類的開發都是在這個平臺上實現的。

4.交互

整個交互過程能夠這樣理解，經過微信的公開接口來獲取一些微信用戶的信息以及關鍵交互，而額外的內容是須要在本身服務器上實現的。

能夠這樣理解，微信上來登錄，獲取用戶信息，把用戶信息做爲參數傳送給本身應用的登錄部分而且綁定用戶的一個UID，從而實現的微信帳號和應用帳號的綁定。

如何測試

在聊過上面4點架構內容之後，測試的內容就能夠來講了。

1.功能測試

    A.若是作基本功能，可能就不須要知道appid和appsecret了，這樣的測試能夠理解成沒什麼技術含量的點點過程。真的要深刻測試，那麼包含從微信接口上獲取數據到自身系統的部分，檢查下是否是數據過來了，過來的對不對，高級點能夠抓一下包看一下，普通點就看數據庫。

    B.適配兼容，因爲是H5的內容，在不一樣瀏覽器上和手機分辨率上仍然存在適配問題。

    C.手機的一些專項測試，基本能夠不要考慮，由於是H5的內容，因此大多數問題也解決不了的。

2.非功能測試

這塊能夠談的東西比較多，包含性能、接口、自動化。

2.1性能測試

    性能問題主要有兩個點：

    A.微信接口的性能

    這個不歸你管，你也不用測，由於微信本身有個規範來限制超時和鏈接數，因此係統在別人那邊你作不了啥。
    B.本身系統的性能

    雖然你要從微信的接口上拿數據，可是最終的處理仍是會回到本身的系統上，因此這塊的性能測試會比較重，加上微信的交互體系決定了什麼都要去服務器上問，對服務器上接口的負載是很高的，一旦某一個請求或者某一個業務的請求出現點性能問題，可能就會功虧一簣。

    那麼要讀微信接口的內容怎麼辦？作個Mock服務器就是必須的了，要麼緩存掉微信服務器返回的數據，要麼本身作個假的mock應答。

2.2 接口測試

    因爲全部的內容其實都是所謂的微服務，因此對於這些服務的接口測試是十分重要的，前面性能的問題解決了，接口的問題天然也就解決了。

    能夠說接口測試是全部測試中最重要的基本保障測試。

2.3 自動化測試

H5的自動化，就涉及到瀏覽器端和手機端，幾乎就是robotium/appium+webdriver的天下。我的以爲意義不大，由於接口都測好了，而微信業務也相對簡單，手工跑跑就差很少了。若是非要頂上一個遍歷的概念，我仍是以爲走monkey這類純座標體系的也許更好點，驗證下是否是對應的請求都發出來了便可。

應用號

到這裏爲止其實都在談企業號，那麼咱們的主題不是應用號麼？

接着來講下應用號，根據雲層最近看到的文章和相關介紹，應用號是一個平行於企業號的東西，應用號的開發和企業號很像，可是有些區別，好比

能夠看到開發UI的代碼並非H5的基本標籤，而是換了一套微信本身的標籤體系，能夠這樣認爲微信爲你們定製了一套UI控件（Frame），來解決之前H5某些沒法實現的功能，而這些東西多是基於Hybrid模式的，就是非徹底H5的內容，而是基於微信體系的控件體系的。

相似於微軟WPF中的XAML，將佈局轉化到xml，事件執行走JS體系，本身的容器完成了佈局到CSS的掛接至因而不是生成一個源生的控件仍是一個特殊封裝的控件就要等結果出來了。

從開發人員的角度就是我靠，又要從B/S體系換回到C/S體系了，DOM這套不要折騰了。

對測試人員來講，其實變化不大，由於原本也不須要知道實現這層是怎麼作UI的，更多關心的是控件或者按鈕能不能用和服務器交互怎麼樣，從某些角度來講對測試是幾乎透明的。

應用號測試

    那麼應用號測試的變化在什麼地方呢？
    A.調試可能會麻煩點，看微信怎麼給平臺。由於基於微信本身的體系，若是要非要在線調試就麻煩了。也就是說之前能夠開個網頁調試跟蹤，如今要在線了，除非微信給你一個集成好自身體系的開發工具。

    B.微信本身的坑，由於是基於微信的控件及某些模塊體系，若是它本身作的有問題，那麼你是無能爲力的，因此只能躺着等微信改。之前貌似也這樣，至於應用號是否是作的更好了一點，就不得而知了。

    C.自動化能不能作，不知道最終微信這套內容下來的體系是怎麼樣的，是標準hybird仍是本身再封裝的。工具是否是能有效的識別到內部的對象，或者微信會不會給一個本身的自動化體系？

    ps.貌似之後是css定位的天下了，id沒用了，xpath估計也危險了。微信小程序是一個平臺，對於開發人員來講縮短了開發週期，下降了開發難度（APP開發又要失業一堆人了），而對於測試來講，UI和基本交互可能出現的問題會進一步減小，對技術測試（接口，性能）的要求會進一步提高，甚至在調試工具上可能也會愈來愈多的要求測試介入。

在這點上有沒有能力拿到AppID和Appsecert可能就是普通測試和高級測試的關鍵區別吧。