Clear the idea of audio and video/multimedia/player automation testing, can be from the following several angles to think.
1. Test item design
1.1. Functional testing
- Support for various transport protocols, encapsulation formats and encoding formats. In terms of encoding format testing, the combination of various encoding parameters is involved, and the number of testing items will be wildly expanded
- All kinds of basic play control, including play, pause, double speed, seek, etc
- Feature tests strongly related to its own products, such as seamless switching, audio output path, DRM, etc
1.2. Performance testing
- Time to start the broadcast (first screen). More granular considerations may include the time taken to subdivide each part of the broadcast
- The seek time consuming
- More granular considerations may include the number of frames lost consecutie, frames lost per second, etc
- A more granular consideration for the rebuffer rate might be the length of each bufferd
- AV synchronization
- Error rate
1.3. Stress test
- Long play
- Play in weak network environment
- Low performance device environment playback
- High frequency play operation control, such as frequent start broadcast, frequent seek, frequent switch bit stream, etc
At this stage, the organization and presentation of the test items should also be considered. The usual choices are JSON or XML, as in the following example
{
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"]
}
},
]
}`
Copy the code2. Test method
Whether you use black box testing or white box testing, there are two key issues: how to initiate the testing and how to validate the results.
2.1. Black box test
There are several ways to initiate tests:
- Take Android platform as an example, testing tools can be used to send Intent to player applications to initiate different test items, but this limits the ability to initiate tests only on the local machine. If you consider remote testing, you can send the content of the test using an HTTP request (like JSON in the previous section). The test tool receives the HTTP request, parses the content of the test, and then converts it into an Intent or other instruction to activate the player.
- Simulated user operations
It can be realized by simulating touch screen operation, remote control button operation and other ways. Again on the Android platform, uiAutomator is a ready-made tool.
There are several ways to verify the test results:
- Use log analysis. Using the pre-added key logs, you can easily verify the results.
- Image and sound sensors are used for analysis
You can capture screen image data, audio data from speakers, and then analyze the results of these output data. A simple example is to take pictures of the screen with an external camera and analyze the frame difference of the screen picture. If it is found that the picture has not changed for a long time, it is likely that there is a lag. More complex devices, such as The SyncOne device for AVSync and Netflix’s EyePatch device, are well-known examples, but are also more difficult to develop.
2.2. White box testing
The white box test of the player can be done using the pile test method. Using the Android platform as an example, the test code in CTS Media is a good reference, as shown in the following example
public void testPlayMidi(a) 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(); }}Copy the codeOnce the stub test code has been written, you can also choose to call it directly on the machine as an instruction or remotely via an HTTP request. Various pile-test solutions generally provide a format tool for the test results, so verification and presentation of test results is not a major issue.
Design extensible test items
Earlier, we mentioned that you can record test items in JSON form, but in fact, you can also diverge on this basis, so that the test items can be customized and extended at any time.
If we pre-define some player instruction fields, such as “play “,” pause “, “loop”, “Change_track “, etc., and then combine these instructions, we can achieve the scripting of test items. The player can achieve the goal of running the test items by parsing such a simple JSON script and following the order of instructions defined therein. This simple script also has low technical requirements for testers.
An example is shown below. In this example, the play is started and then stopped after 10 seconds. Using similar thinking, you can quickly extend existing tests.
{
"source":"/sdcard/test.mp4"
"commands": [
{
"command":"play",
"value":0
},
{
"command":"sleep",
"value":10000
},
{
"command":"stop",
"value":0
}
]
}
Copy the codeWelcome to pay attention to my public number gray 50, share all kinds of audio and video, mobile development knowledge ~
Did the article help you? You can scan the following TWO-DIMENSIONAL code for tipping. You can reward as much as you like
