浅谈音视频及播放器的自动化测试

发表于:2021-7-29 10:09

字体: | 上一篇 | 下一篇 | 我要投稿

 作者:zhanghui_cuc    来源:掘金

  理清音视频/多媒体/播放器自动化测试的思路,可以从以下几个角度来思考。
  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

        }

    ]

}

  本文内容不用于商业目的,如涉及知识产权问题,请权利人联系51Testing小编(021-64471599-8017),我们将立即处理
《2023软件测试行业现状调查报告》独家发布~

关注51Testing

联系我们

快捷面板 站点地图 联系我们 广告服务 关于我们 站长统计 发展历程

法律顾问:上海兰迪律师事务所 项棋律师
版权所有 上海博为峰软件技术股份有限公司 Copyright©51testing.com 2003-2024
投诉及意见反馈:webmaster@51testing.com; 业务联系:service@51testing.com 021-64471599-8017

沪ICP备05003035号

沪公网安备 31010102002173号