方法二缺点：实时截图进行对比的判断，会在执行时循环判断是否出现基准图片，本身有一定耗时，图像判断也受限于图像对比的准确度和稳定性的问题，如果判断错误，会影响整个的时间计算。同时，图像对比方法也不适用于动态变化的页面，比如动态首页等。同时也需要额外维护测试case。

方法三缺点：经常性需要维护的测试case，已经是一个门槛，这种方式计算的稳定性和扩展性也不够。

方法四缺点：方法四结果是最接近于用户感知的响应时间，但需要安装额外pc软件，安装复杂，不能扩展到多用户使用，成本较高。

基于上面的分析，我们利用方法四的分帧图片计算的原理，开发出一种易于使用和扩展的工具平台。

3、测基于帧计算的精确app响应时间计算

工具原理

上文提过，视频录制后通过帧计算是最接近于用户感知的响应时间，这里提供一种基于帧分析的方法，但避免了复杂操作，来精确计算App响应时间。

工具整体的流程如下：

图3.1 工具原理

区域1：用户可以通过平台直接上传视频（mp4为佳），视频来源可以是手机录屏或者其他高速摄像头的录制。

区域2：为了降低用户手动上传视频的复杂度，和pandora工具集结合，用户可以通过pandora工具集->gif好帮手->录屏，录制完成后，转gif时点击测试响应时间，视频会自动上传到后台进行分析，最后的结果展现在平台上。也就是说，可以通过手机录屏，自动上传的方法，解决了手动上传视频的问题。

区域3：本工具没有采用全自动化的方式，但提供了一种半人工的方式，来根据精确的计算响应时间。视频处理模块会把视频按每一帧，转成图片的方式，在平台上直接展现，然后选择开始帧和结束帧，计算响应时间，可以同时选择多个场景，比如启动App时间、点击按钮进入下一个页面的响应时间等，一次计算，后台保存，以便有报表需求使用（比如不同版本的同一场景进行对比，或者竞品间启动时间进行对比等）。

区域4：这一块是后台核心的处理模块，基本原理是，采用ffmpeg工具，截取视频的每一帧图片。为了避免前端展现图片过多的问题，首先采用了Md5去重的方式，因为通过手机录屏，在同一静态页面，会产生大量的相同图片，这一步需要保留Md5相同图片的第一张和最后一张图片，因为在响应时间的计算过程中，第一张图片是上一个场景跳转到新场景的时刻，而最后一张图片是跳转到下一个场景前的开始时刻。

Md5去重后，可以减少一部分同步，利于下一步去重的处理速度。相似度去重采用的是pyssim工具，保留前后相似度低于90%的图片，之所以阀值选择这么高，是为了避免丢失关键帧，也可以在尽可能减少图片的情况下，避免产生选择开始帧和结束帧的误差问题。同样，这一步需要保留一批相似图片的第一张和最后一张。最近的一次视频处理，552张图片，最后平台展示143张。

相似度去重的具体算法是：

以第一张图片作为基准，a=该图片

b=下一张图片，如果a和b相似度>=90%，b=下下张图片，继续对比a和b

如果a和b的相似度<90%，保留a和b之前的上一张图片（a!=b之前的上一张图片），然后a=b，b=下一张图片

这样就把一批相似度>90%的图片的第一张和最后一张保留下来，最后的图片集，就是前端会展现并可以计算的图片

以第一张图片作为基准，a=该图片

b=下一张图片，如果a和b相似度>=90%，b=下下张图片，继续对比a和b

如果a和b的相似度<90%，保留a和b之前的上一张图片（a!=b之前的上一张图片），然后a=b，b=下一张图片

这样就把一批相似度>90%的图片的第一张和最后一张保留下来，最后的图片集，就是前端会展现并可以计算的图片

这里要说明一点的是，保留下来的是图片地址，并不会把图片删除，调整参数，比如相似度阀值，再次跑一遍处理脚本，可以生成新的展示图片集合。

工具使用

平台地址：http://metric.baidu.com:8080/duapps/restimeupload

Pdr工具集地址：http://pdr.baidu.com/可以下载pandoraandroid工具。

简要说明下，pdr工具集是ebgqa团队精心打造的一款Android端工具箱，可以使用多种App端的包括分发、性能、网络等各种小工具来辅助测试。

平台上传视频和pandora录屏后上传较为简单，不做过多介绍，下面介绍下视频处理完成后的操作。

上传视频后，如果没有执行完成，可以继续等待，等处理完成后hi通知。

图3.2 未处理完成截图

视频处理完成后，可以直接点击复选框，同时可以选择多个场景，这里选择meet Android启动时间场景和点击匹配到匹配成功的两个场景。

图3.3 meet启动时间场景

图3.4 点击匹配到匹配成功场景

点击计算后，得到两个场景的响应时间，同时保存到数据库。

工具的基本使用方法就完成了，很简单。

工具优缺点

优点：

执行基于帧计算，较为准确；误差小，按帧截图，没有实时循环截图的误差

没有图像识别带来的误差，以及页面动态变化带来的无法利用图像识别计算的问题

没有使用成本，不受限于ios、Android、竞品等，都可以使用

没有额外开发成本，适用于不同场景

理论上，除了端的响应时间，也可以计算wap、webview的应用

执行基于帧计算，较为准确；误差小，按帧截图，没有实时循环截图的误差

没有图像识别带来的误差，以及页面动态变化带来的无法利用图像识别计算的问题

没有使用成本，不受限于ios、Android、竞品等，都可以使用

没有额外开发成本，适用于不同场景

理论上，除了端的响应时间，也可以计算wap、webview的应用

缺点：

执行时间相对较长，但上传视频后等待即可，执行完成后进行hi通知

对于帧率变化的视频录制，存在误差，但录屏方式，一般不会有此问题

还没有引入自动化方案，可以实现通过上传基准图片的方式进行自动化判断，但也带来了章节二说述的图片对比问题

最后的时间计算，受用户开始帧和结束帧选择的影响，工具保留了相似度超过90%的图片，基本不会丢失关键帧，所以一般较少选择错误（通过传统分帧选择的方式，也可能挑选错开始帧和结束帧）

执行时间相对较长，但上传视频后等待即可，执行完成后进行hi通知

对于帧率变化的视频录制，存在误差，但录屏方式，一般不会有此问题

还没有引入自动化方案，可以实现通过上传基准图片的方式进行自动化判断，但也带来了章节二说述的图片对比问题

最后的时间计算，受用户开始帧和结束帧选择的影响，工具保留了相似度超过90%的图片，基本不会丢失关键帧，所以一般较少选择错误（通过传统分帧选择的方式，也可能挑选错开始帧和结束帧）

作者介绍

吴舰 百度-EBG测试部

先后在推荐与个性化、国际化、文库进行测试开发工作，喜欢开发各种能省时省力的小工具。

返回搜狐，查看更多