短视频SDK测试tips
前言：
测试短视频SDK有半年多了，曾经跟组内小伙伴感叹，“再苦再累我都要坚持测试短视频”。虽然每次版本测试都被短视频SDK虐的不行，但是短视频SDK仍然是我最喜欢测试的一款SDK，没有之一。
短视频SDK介绍：
2016年底的时候出现了不少短视频类的应用，随着piapi酱等等的火爆，短视频成为下一年的视频风口。在这个时候市面上出现了一款短视频编辑神器VUE，融合了小视频录制，添加伴音、贴图、时长编辑、特效编辑等功能。所待的项目组也紧跟潮流推出了短视频SDK，主要实现短视频录制、增加特效、伴音、贴图、时长裁剪等功能。实际上只对外提供三个接口，但是由于视频文件的多样性、以及Android设备的不同兼容性、以及转码本身就需要耗费一定的时间，测试起来其实并不简单，总结了下面两点用于提升测试的效率。
测试tip1，引入单元测试框架Androidtestcase，减少手工操作成本
在前期测试准备中就发现，短视频SDK虽然只对外提供三个接口，但是最主要的转码接口有十几个参数，每个参数需要覆盖多种不同的数据以及不同的文件。比如短视频提供的拼接功能，其实并未涉及到参数，但是需要覆盖不同分辨率的文件，不同码率的文件，不同帧率的文件，以及宽高不规则的文件，单主流分辨率就有1280X720、960X540、640X480、480X320这四档，然后做为一个专注找bug的QA来说，这些分辨率肯定是远远不够的，那如果要全部覆盖的话，只依赖手工测试，会是一个事倍功半的过程。简单查看了下短视频SDK，因为不涉及到摄像头操作，操作均在本地，不调用网络，应该可以通过单元测试框架跑接口。曾经在很早之前使用过Androidtestcase这个单元测试框架，经过简单的调试，有了下面的工程。
在测试代码中，使用数组的方式来存储数据，来进行不同文件、不同参数类型的覆盖，具体如下：
//动态水印位置测试
intdataprovidercharletpositon[][]
= {{341,451}, {432,234},
{123,322}, {436,765},{436,765}};
for(inti
= 0; i <5; i++) {
String[] waters;
Bitmap[] bitmaps;
try{
waters =this.getContext().getResources().getAssets().list("dynamicWater");
bitmaps =newBitmap[waters.length];
for(inti1
= 0; i1 < waters.length; i1++) {
waters[i1] ="dynamicWater/"+
waters[i1];
BitmapFactory.Options options =newBitmapFactory.Options();
options.inPreferredConfig=
Bitmap.Config.ARGB_8888;
Bitmap tmp = BitmapFactory.decodeStream(this.getContext().getResources().getAssets().open(waters[i1]));
bitmaps[i1] = tmp;
}
除了覆盖不同类型的文件，参数类型之外，做为SDK，需要保证接口的易用性，对各种异常情况下的参数返回，接口保护等也做了覆盖，具体的覆盖类似文件类型的覆盖，在数据池中增加了对返回参数的断言。
String outfile ="/sdcard/unnormalparameter"+String.valueOf(i)
+".mp4";
tranOut.setFilePath(outfile);
TranscodingAPI.TranscodeParatranscodePara
=new TranscodingAPI.TranscodePara();
transcodePara.setSource(tranSource);//必须
transcodePara.setOut(tranOut);//必须
transcodePara.setDynamicWater(tranDynamicWater);//动态水印，需要时添加，否则不用设置
intret = TranscodingAPI.getInstance().VODProcess(transcodePara);
Assert.assertEquals(dataproviderunnormalparameter[i][6],
ret);
Log.i(TAG,"短视频处理成功"+
ret);
通过上述这种方式，减少了我的工作量，在准备好测试文件，编写完测试代码之后，在Android Stduio中执行用例，我就可以开始人工审查转码生成的文件，基本上转码和检查文件可以进行并行，并且在接口功能固定之后，这部分测试代码在后续的回归测试中不断复用。
在上述接口自动化的基础上，接入jenkins实现了SDK的自动打包、脚本运行、生成测试报告、已经代码覆盖率检查。
测试tips2，使用“手刹”生成各类型奇葩MP4文件，尽量多的覆盖MP4文件的类型
先简单介绍下MP4文件，MP4做为一个封装格式，也就是容器，可以装不同编码格式的音频和视频文件进去。在测试前期，找开发使用ffmpeg生成了主流编码格式的文件，包括音频封装格式为AAC、MP3的文件，视频封装格式为H.264、H.263、MPEG2、MPEG4。在测试期间发现不同的帧率、音频采样率、分辨率等均会对视频合成和转码的结果产生影响，后续发现了“手刹”这个工具，原名为handbrake。相对于直接使用ffmpeg，手刹有图形界面，而且操作相对简单，安装成本也较低。
使用界面如下：
以上三张截图分别展示了设置目标文件的视频编码格式、帧率、分辨率音频编码格式、采样率等参数。
参考文档：
http://www.360doc.com/content/10/0517/20/11192_28101750.shtml 测试case建立
http://blog.csdn.net/kouwoo/article/details/39227125 接口测试自动化测试工程配置