如何測試微信小程式

TestingGDR發表於2018-11-03

小程式的架構

      小程式分為兩個主要部分:view模組和service模組。View模組負責UI展示,它由wxml和wxss轉換後的程式碼以及微信提供的輔助模組組成。一個view模組對應一個webview元件,小程式支援多個view存在,view模組通過微信jsbridge物件來跟後臺通訊。


小程式的限制和對測試的影響
目前小程式在UI、設計、樣式、頁面跳轉、訊息大小等都有自己的限制,具體的限制可以查詢如下連結:https://github.com/iamxwk/Code-wiki/issues/18

上面的限制對測試來說主要是以下幾個方面

1 數量限制
小程式一個應用只能同時開啟5個頁面,在規劃新需求的時候一般會考慮到5個頁面的限制,但是需求迭代越來越多跳轉關係比較複雜的時候很容易忽略5個頁面的限制,這個時候如果跳轉邏輯超過5個頁面會出現跳轉打不開的情況。因此在需求評審的時候就應該把小程式的跳轉關係有個整體的梳理,在新加頁面處理跳轉關係的時候能夠一目瞭然不會出現超過5層限制的問題。這裡推薦使用流程圖的形式來展現頁面的跳轉關係。

2 大小限制
小程式原始碼打包後的大小限制為1M,因此原始碼中的圖片和icon和資料等都需要壓縮。
小程式的測試4大方面
小程式雖是微信推出的新形態的產品,但是在測試思路上跟其他的客戶端測試在模式上也有類似之處。小程式的測試也可以主要分為4個方面,即功能測試、相容性測試、效能測試、後臺介面測試。對於安全性測試由於小程式整合在微信客戶端內,相比於傳統的網頁來說安全效能夠更有保障。只要在後臺介面測試上保證資料的安全性,客戶端的安全性由微信app來替我們保證。

 

1 功能測試
功能測試跟傳統的web端的功能測試類似,這裡不再贅述。用例設計方法等跟需求相關性較大。


2 相容性測試
包括作業系統相容性,螢幕相容性,微信相容性

作業系統相容性:為什麼小程式會出現作業系統相容性,因為Android和ios系統上小程式的JavaScript指令碼的執行環境不同。官方文件中有說明,在開發工具上,小程式的js程式碼時執行在nwjs中,在ios上是執行在JavaScriptCore中,在Android上是通過X5JSCore來解析的。正因為指令碼執行的環境不同,因此在開發工具上正常的小程式有可能在ios和Android系統上不符合預期。


螢幕相容性測試:微信小程式定義了一個新的尺寸單位rpx(responsive pixel)可以適配不同尺寸的螢幕,在頁面上定義物件的單位是rpx就可以在不同的螢幕上適配。因此對測試來說不需要測試各種螢幕下的頁面顯示。但是,在實際測試的過程中仍然存在螢幕適配的時候出現畫素問題,尤其是1rpx的畫素經常在iphone7p上出現斷線的情況。因此需要在測試過程中關注1rpx畫素的顯示。

微信相容性:與微信版本的相容性問題主要體現在小程式api庫的版本上,有些比較老的版本的小程式api庫不支援新版api,因此會出現相容性問題。所以測試微信版本的相容性之前要先確定小程式使用的庫版本在哪些微信版本號上支援。

3 效能測試
這裡的效能測試考慮的是客戶端的效能,伺服器的效能則按照傳統的伺服器效能測試方案即可。小程式的客戶端效能和網頁的效能測試非常類似,效能的常用指標也大致相同。包括頁面的白屏時間,首屏時間,資源佔用,頁面渲染時間,幀率等等。

小程式的開發工具提供了手動檢視效能的視窗,只要在小程式開發版中開啟效能視窗即可看到頁面的效能資料。

但是這個效能視窗的問題是隻能手動獲取資料,無法自動記錄全部頁面的資料,因此適用於定位效能問題而不適用於釋出前的效能測試。所以效能測試可以考慮效能打點上報的方式進行效能分析,上報時區分測試環境和運營環境。釋出前先在測試環境分析各個頁面的耗時,及時發現頁面的效能問題。


4 後臺介面測試


小程式的後臺介面跟其他的客戶端後臺介面測試類似,直接按照常規的後臺測試來開展就可以。
小程式的自動化測試
小程式的自動化測試是個必然的趨勢,自動化測試可以提高迴歸效率可以實現監控,是一種重要的輔助測試手段。但是由於小程式整合在微信app內部,不像其他頁面比較容易抓包和解析因此這是小程式自動化測試的難點。目前有很多自動化測試的工具和框架試圖解決這個限制提供小程式自動化測試的解決方案,比如有用wept+puppeteer來進行UI小程式UI自動化測試,但是這種方式對於測試環境和正式環境需要特殊處理,某些api也是不支援的。

結語

 最後跟大家推薦一個學習資料分享群:175317069,裡面大牛已經為我們整理好了許多的學習資料,有自動化,介面,效能等等的學習資料!

人生是一個逆水行舟的過程,不進則退,我們們一起加油吧!

相關文章