嗯 ，我之前看到帖子里说的了，我之前以为设计思路是直接关联某id， 再通过某id 检索到匹配某ID的具体信息 （如 url，参数 ，头等等）。 检索到后 再拿具体的信息去回放。

回放竟然还要带上params，不可思议。。。 常态不应该是只需要traceId标识就可以吗，自用的时候发现只用traceid也是失败的。。

实现逻辑一般这样。 前端请求服务端 , 这里请求时会自带一个imageid，后端会通过id返回验证码图片信息，并存储某个通过image改造加密后的id在缓存中间件，最终当你在前端输入验证码做登录请求的时候，接口层会通过你输入的验证码与缓存中的验证码来对比获取鉴权认证。 这里的关键还是在于你要获取key来取值做输入

慢慢读完了这篇帖子，内容非常的新颖，也有一些新的启发，做新的东西都是很了不起的。 首先说一下优点，只由视频来确定表层的性能因素，我可以理解为跨平台了，因为无论哪个平台记录的表象，都可以最终由视频来输出确立。 然后 我想说一下我的疑惑，视频算是一种介质，但如果我作为测试，我可能会更想确立内因，比如在Android上，我确立某个场景发生了Jank，可以分析SufaceFlinger去得到这类信息（app开始绘制时间， Sync把帧给至硬件时间，显示到屏幕上的时间），这里跟你的<点击前、点击时与页面加载完成后>这个概念是不相同的。那么这个工具的主要用途我可以认为是：可以从导出的视频中，找到哪里可能存在性能问题吗？

提供方法的成本很低啊，就是几个函数的事情，并提供一个tcp端口给你提供控件，你不仅可以通过控件执行业务操作，还可以判断它是否存在，这里有很多很多的开源方案可以执行，且是高效稳定的方式。游戏本身的动态粒子效果就算是模板匹配很难做更别说是执行各种行为以及任务了（当然这里看游戏内容以及特征...）。其次就是 SIFT/SURF 是特征提取的方式，所谓鲁棒性不是为了在某个系数下识别成功就算成功了，比如模板匹配中，设定TM_CCOEFF的标准来控制图形识别的准确性，但是缺牺牲了图像对比的正确性来执行操作行为，但当你真正做断言的时候，各种各样的粒子效果让你没办法做到完全匹配 ，这里图形识别很难做到两全其美

特征匹配与模板匹配的优点与缺点很明显，优点易用性强，缺点鲁棒性弱，对于游戏与应用都一样，鲁棒性弱的功能价值并不大。推荐了解一下SIFT（尺度不变特征变换算法） 。如果是是应用在游戏上建议还是用gameObject的取件方式来做。

这个小工具挺赞的 ，顶一下

。。超越的速度。。