作者：張佳
團隊：騰訊移動品質中心TMQ
【導讀】
對於非宿主的合作伙伴來說，在TBS接入環節，“共享和下載內核”的能力是最重要的，它從根本上決定着APP是否能夠使用預期的X5內核提供服務。一旦出現問題，會導致無法加載X5內核或者優化策略失效，從而降低X5佔比。但面臨的一個問題是，SDK是跟隨TBS版本持續優化的，每次SDK發佈，都會有大批小夥伴更新apk來提測。
【測試時機】
SDK發佈後，會有合作方陸續接入新SDK提測，比如：
2.4 SDK發佈：某某視頻+2.4SDK，某某會+2.4SDK、某某輸入法+2.4SDK、某某寶+2.4SDK 等 ；
2.5 SDK發佈：某某直播+2.5SDK，某二次封裝SDK+2.5SDK、某東+2.5SDK、某某音樂+2.5SDK等 ；
3.1 SDK發佈：某某新聞+3.1SDK，某某音樂+3.1SDK、某某微信+3.1SDK 等。
【測試內容】
上面可以看到，每次更新接入新SDK的小夥伴還是比較多的，而我們主要測試兩個功能點：
（1）接入是否成功 ；
（2）接入後的SDK邏輯是否符合預期 。
具體表現爲，新的SDK在各種場景下是否能正常使用到內核，比如：
首次安裝三方，能共享宿主已有的內核 ；
共享A宿主內核後，若宿主升級到更高版本，三方能跟隨升級；
已共享A主內核後，若B宿主升級到更高版本，三方能跟隨B升級 ；
下發強制下載後，三方能走強制下載 ；
強制下載後，若宿主有更高版本，三方能跟隨升級，等等。
怎麼樣？
有沒有蒙圈，but這還只是一小部分%>_<%！
【人工測試】
合作方的接入時間是不定期的，一般來說。
步驟一：模擬三大宿主場景 。
（1）後臺配置宿主內核版本 ；
（2）宿主下載、安裝 ；
（3）確認宿主下載成功 。
步驟二：配置三方後臺 。
第三步：結果檢查 。
（1）讀取三方內核版本號；
（2）判斷是否符合預期。
【自動化的思考】
1、是否重要？
是。前面有介紹，一旦SDK邏輯出問題，會導致TBS使用異常，X5佔比降低。
2、是不是重複工作？
用例可複用。因爲對於同個版本的SDK，不同app的接入邏輯是一致的，可複用（有人會問那爲什麼每個app都要測一遍？因爲人家的接入對我們是不可見的，只有個打包的apk給過來，到底SDK的調用對不對，有沒有問題，是未知的）。
3、結果是否可判斷？
是的。三方內核版本號保存在合作方目錄下，可讀取後跟預期結果對比。
【自動化過程分析】
我們對人工測試的各個步驟進行分析，統計上看，人工測試最大部分耗時集中在：
宿主環境模擬耗時佔比：70%以上 。
宿主環境作爲三方共享的前提條件，是非常重要的，一旦條件不符合預期，直接影響後面的測試結果。
方法一：模擬測試過程，後臺配置—>宿主下載—>宿主安裝—>共享檢查。
實踐結論：失敗率高，不可行。
說明：出於用戶的流量考慮，TBS宿主在邏輯上有後臺流控，異常保護等諸多限制，反覆測試情況下，經常出現無法下載、安裝失敗等問題，導致宿主環境異常，無法成功安裝預設內核。
方法二：接口層觸發宿主下載
實踐結論：對他人影響較大，不適合。
說明：配置過程可行，但有個問題是接口配置後是UI不可見的，校驗比較麻煩，還有一點，測試環境是三地共用的，不可見的配置有可能干擾其他同學的測試。
方法三：宿主環境MOCK化。
實踐結論：可行 。
說明：首先將高中低三個待測內核下載到本地，並拷貝出來備份，在需要某個環境時push進宿主目錄下，跳過“配置-下載-安裝”環節，直接模擬安裝成功後的宿主環境。
【三方配置方式】
解決了宿主的環境模擬問題，我們再來看看看三方如何配置環境。由於三方的後臺環境是基於終端的定製需求，因此我們三方測試時，實際要關注兩方面：
第一，後臺下發是否正常。後臺需要結合終端上報的情況，和預設的後臺配置，下發預期的內核版本號給終端。
第二，終端根據後臺返回的結果，是否能夠共享或下載指定內核並調起使用。
考慮到以上因素，我們選用UI自動化的測試方式，優點在於兼顧後臺和終端，並且通過記錄tbslog方便隔離分析。
我們用的是chrome driver，在測試頁面導入預設配置，並且對配置結果截圖校驗。
【自動化測試結果】
以下以“某某新聞”爲例，我們來看看測試效果。實際中，可以利用夜間時間跑自動化，大大提高了測試效率。
【持續優化】
1、重跑機制：考慮到環境的不穩定性，我們對fail用例設置重跑邏輯，即fail後自動重跑2次，以此規避異常環境干擾；
2、實時報告機制：這是聽了組內google分享的心得，不用等所有用例跑完再郵件同步結果，一旦出現fail立即報告，這在調試階段非常有效，可快速發現腳本適配等問題；
3、監控彈框：對常見文字用Watcher批量監控，比如“是否更新”、“是否反饋”，排除APP自身彈框干擾。
【時間投入分析】
1、不同app進webview的場景不同，要花時間做適配；
2、某些app可能出現彈框提醒等提示，影響腳本運行，要做定向處理（由於彈框文字不確定，目前只能對常用的做處理，無法全面規避）；
3、日常維護和問題解決跟進。
另外：某些插件化和內置等特殊形式的SDK測試不適用。
【思考和總結】
1、做前思考：自動化是手段，不是目的，做之前多想想是否適合做自動化，投入產出如何，想清楚了再動手做；
2、過程PK：當一種方式難以實現時，集思廣益，嘗試其他的方法，綜合考慮尋求最優方案；
3、持續優化：先跑起來，在過程中發現問題、解決問題 ；
4、數據積累：自動化的前期投入往往比較高，注意在應用中收集數據，發揮最大價值。
最後，附上TBS的SDK官網 http://tbs.sparta.html5.qq.com/tbs/sdk.html。
關注微信公衆號：騰訊移動品質中心TMQ，獲取更多測試乾貨！
