WeTest 導讀
小程式作為微信內能被便捷地獲取和傳播的工具，吸引著越來越多的開發者加入其中。無論是小遊戲、零售、出行服務還是生活餐飲等，各行各業的小程式出現在使用者的手機上，在給使用者帶來便利的同時，也給測試者帶來不小挑戰。
下面這些困難你經歷過那些?難點1：缺少專業人士制定測試用例
缺少專業人員制定成熟的用例測試方案。不確定核心場景覆蓋是否完整，或者使用已有的測試用例又不太滿足需求。
相較於APP測試而言，小程式的互動性較強，對穩定性和體驗上有較高的要求。在定製用例的時候對小程式特有場景測試進行用例設計，如微信授權、異常打斷（微信電話），虛擬鍵盤隱藏以及群分享功能的用例設計。除此之外，有些APP和小程式間的資料互通也是需要檢測的點。
難點2：採集資料難
用例制定好後，在測試中往往因為缺乏經驗導致不了解需要採集哪些品質指標資料。
另外，在採集資料的過程中缺少有效工具一次性地將所需資料全部採集到，往往需要多次採集。甚至有時候採集到的效能資料並不精準，例如之前安卓手機獲取FPS資料的方式往往是通過下列幾種：
• 從OpenGL獲得
• 從SurfaceFlinger獲得
• 從遊戲引擎獲得
• 包含宿主容器的渲染資料
• 小遊戲的繪幀並不連續
而且常規的通用方法，採集的也不是子程序的效能資料。
難點3：難以短時間一次性適配完
大部分企業缺少測試裝置和工具，需要安排大量人力和時間去對進行測試，或者自身尋找併購買市場主流裝置進行適配測試，一一記錄問題並整理上報，最後還要統計所有測試結果。整個適配過程需要很長一段時間，甚至有可能因此耽誤上線時間。
微信小程式適配測試需要大量的微訊號，正常註冊需要大量手機號。而WeTest測試團隊儲備大量微信賬號專為小程式測試服務，並且支援上傳容器，對不同微信版本一次性進行完整測試。
難點5：無法完全靠自動化測試
小程式的核心功能在不同業務場景下有眾多不同的體現，需要通過測試用例去驗證。很多測試開發會採用外部指令碼操控小程式執行時的方法進行驗證。但是通過工具自動化執行後還需人工一一對比驗證結果。
在測試前，團隊會迅速對接客戶具體的測試需求。在對小程式進行深入了解和需求評估後，提供定製化測試用例，比如群分享、彈窗許可權干擾類等通用用例的設計。
不同於APP測試，微信小程式的測試除了對主流機型、不同系統測試外，還需要對微信各個版本進行測試，特別是在小程式更新時，對不同容器版本測試尤為重要。所以WeTest在容器方面除了建議測試最近的3個微信版本，客戶還可根據需求自行上傳。
3.獲取詳細報告，記錄豐富資料
為了獲取詳細的測試報告，微信小程式相容測試服務一次提供100或者300款機型數（不僅100，也有300），在報告中為了方便客戶進行分析，區分不同版本容器，提供每個容器測試報告介面涵蓋容器概況、問題列表、裝置詳情，效能報告四大版塊資料。詳情裡保留每臺裝置測試過程中的截圖、效能資料以及日誌資訊。
測試時能精準採集到其程序本身效能資料，而非容器的效能資料，提供豐富的效能資料，如覆蓋使用者數、每臺裝置JS Error、首屏載入、FPS（小遊戲）、CPU，記憶體等效能資料。
需要留意的一點是，客戶若需要採集首屏載入時間和Js error，則在測試前需接入JS SDK。
4.詳細記錄問題,真實還原問題現場
問題現場通過時間軸進行問題定位和截圖顯示，還原手機真實測試現場。
除了問題現場外，裝置詳情頁面下方同時配上了日誌資訊和效能資料，使客戶可以多維度的檢視測試情況，體驗每臺裝置的完整測試流程，一次性獲取豐富資料。