如何進行遊戲陪玩系統原始碼中音視訊的自動化測試？

在完整的遊戲陪玩系統開發環節中，測試是必不可少的，而具備音視訊連麥功能的遊戲陪玩系統原始碼自然還需要進行音視訊的測試，像功能測試、效能測試、壓力測試等，接下來我們就一起來了解一下如何進行音視訊的自動化測試吧。

1.測項設計

1.1.功能測試

• 對各類傳輸協議、封裝格式、編碼格式的支援，在遊戲陪玩系統原始碼編碼格式測試方面，又涉及到各類編碼引數的組合，測項數量會瘋狂膨脹起來
• 各類基礎播放控制，包括播放、暫停、倍速、seek等
• 和遊戲陪玩系統原始碼相關的feature測試，如無縫切換、音訊輸出通路、DRM等

1.2.效能測試

• 遊戲陪玩系統原始碼啟播（首屏）時間，更細粒度的考量因素可能有啟播各個環節細分的耗時
• seek耗時
• 遊戲陪玩系統原始碼的丟幀（卡頓）率，更細粒度的考量因素可能有連續丟幀數、每秒丟幀數等
• 緩衝（rebuffer）率，更細粒度的考量因素可能有每次bufferd的時長
• AV同步情況
• 錯誤率

1.3.壓力測試

• 長時間播放
• 遊戲陪玩系統原始碼中音視訊的弱網環境播放
• 低效能裝置環境播放
• 高頻播放操作控制，如頻繁啟播、頻繁seek、頻繁切換碼流等

在這一環節，還要考慮好測項的組織和展示形式。常規的選擇一般是json或xml，如下面這個例子

{
    	cases:[
    {
      "name": "DASH-LIVE-001",
      "brief": "Live - number template",
      "data":
       {
         "exe-type": "TYPE_CUSTOM",
         "urls":["http://vm2.dashif.org/livesim-dev/periods_1/testpic_2s/Manifest.mpd"]
       }
    },
    {
      "name": "DASH-LIVE-002",
      "brief": "Live - time template",
      "data":
       {
         "exe-type": "TYPE_CUSTOM",
         "urls":["http://vm2.dashif.org/livesim-dev/segtimeline_1/testpic_6s/Manifest.mpd"]
       }
    },
  ]
}`

2.測試方法

無論是用黑盒測試還是白盒測試，其實就兩個關鍵問題：如何發起測試以及如何驗證測試結果。

2.1. 黑盒測試

發起遊戲陪玩系統原始碼音視訊測試的方式有以下幾種：

• 直接給遊戲陪玩系統原始碼播放器傳送播放指令以android平臺為例，可以通過測試工具給播放器應用傳送Intent來調起不同的測項，但這限制了只能在本機上發起測試。如果考慮遠端測試的話，可以利用http請求傳送測項內容（上一節提到的json就用上了），測試工具接收http請求後解析測項內容，再轉換為Intent或其他指令形式調起播放器。
• 模擬使用者操作

可以通過模擬觸控式螢幕操作、遙控器按鍵操作等各種方式來實現。還是以android平臺為例，uiAutomator就是一個現成的工具。

驗證測試結果的方法則有以下幾種：

• 利用遊戲陪玩系統原始碼日誌分析。利用提前加好的關鍵日誌，可以方便的驗證結果。
• 利用影像、聲音感測器進行分析

可以抓取遊戲陪玩系統原始碼螢幕影像資料、揚聲器輸出的音訊資料，然後對這些輸出資料結果進行分析。一個簡單的例子是用外部camera拍攝螢幕並分析螢幕畫面的幀差，如果發現畫面長時間沒有變化，則很有可能是發生了卡頓。更復雜的比如分析AVSync用的SyncOne裝置、Netflix的EyePatch裝置，都是著名的案例，當然開發難度也更高。

2.2.白盒測試

遊戲陪玩系統原始碼播放器的白盒測試就用插樁測試方法即可。還是以android平臺為例，CTS media中的測試程式碼就是很好的參考，舉一例如下

public void testPlayMidi() throws Exception {
        final int resid = R.raw.midi8sec;
        final int midiDuration = 8000;
        final int tolerance = 70;
        final int seekDuration = 1000;
        MediaPlayer mp = MediaPlayer.create(mContext, resid);
        try {
            mp.setAudioStreamType(AudioManager.STREAM_MUSIC);
            mp.setWakeMode(mContext, PowerManager.PARTIAL_WAKE_LOCK);
            mp.start();
            assertFalse(mp.isLooping());
            mp.setLooping(true);
            assertTrue(mp.isLooping());
            assertEquals(midiDuration, mp.getDuration(), tolerance);
            int pos = mp.getCurrentPosition();
            assertTrue(pos >= 0);
            assertTrue(pos < midiDuration - seekDuration);
            mp.seekTo(pos + seekDuration);
            assertEquals(pos + seekDuration, mp.getCurrentPosition(), tolerance);
            // test stop and restart
            mp.stop();
            mp.reset();
            AssetFileDescriptor afd = mResources.openRawResourceFd(resid);
            mp.setDataSource(afd.getFileDescriptor(), afd.getStartOffset(), afd.getLength());
            afd.close();
            mp.prepare();
            mp.start();
            Thread.sleep(SLEEP_TIME);
        } finally {
            mp.release();
        }
    }

插樁測試程式碼編寫完成之後，同樣可以選擇直接在本機用指令方式調起或者遠端通過http請求調起。各種插樁測試方案一般都會提供測試結果的格式化工具，所以測試結果的驗證與展示不是什麼大問題。

設計可擴充套件的測項

在前面我們提到可以用json形式來記錄測項，其實還可以在此基礎上進行發散，讓遊戲陪玩系統原始碼測項可以隨時定製、隨時擴充套件。
如果我們預定義一些播放器指令欄位，如“play”，“pause”, “loop”, "change_track"等，然後將這些指令組合起來，就可以實現測項的指令碼化編寫。遊戲陪玩系統原始碼播放器只要解析這樣一個簡單的json指令碼，按照其中定義的指令順序執行，即可達到執行測項的目標。這種簡單的指令碼對測試人員的技術要求也很低。
舉一個示例如下，在這個例子中，將會執行啟播，然後等待10秒後，停止播放。用類似的思路，可以快速擴充套件已有測項。

{
    "source":"/sdcard/test.mp4"
    "commands": [
        {
            "command":"play",
            "value":0
        },
        {
            "command":"sleep",
            "value":10000
        },
        {
            "command":"stop",
            "value":0
        }
    ]
}

以上便是“淺談遊戲陪玩系統原始碼開發中音視訊的自動化測試”的全部內容，希望對大家有幫助。

本文轉載自網路，轉載僅為分享乾貨知識，如有侵權歡迎聯絡雲豹科技進行刪除處理
原文連結：