这是很现实的。
有的时候可能真的不是不想去努力，而是不能去努力。
随着年龄的增长你可能顾及和考虑的东西就更多了 (父母、爱人、孩子、房子、车子) 等等。
一堆的压力全部积压下来时，你可能无法在像年轻时那么热衷的一味去追求技术了。
活在当今这社会下，其实想两全真的很难。
不进则退，活到老学到老，只要活着，就是一种幸福。

努力与年龄无关，如果你想追求自己的梦想，年龄只是借口。

边学习边开发大半年左右

要是个人的话开源是没什么影响

我们公司内部一直在使用，也一直持续更新

噢啦

我竟然中奖了 ，发过来的邮件被我删除了求重发一份 ......

过奖了过奖了！

windows 上的，视频回放是用 javacv 实现的

1、点点点
2、自动点点点
3、开发点点点

1.整体做的不错，赞个
2.接口那边建议加个用例关联变量，有的场景可能会需要用到上一个用例返回的 json 中的指定值作为下一个用例的参数
3.接口请求体和响应体可以做下展示

因为是咸鱼测试 等翻身了到点就走

1、没用 testng、多线程异步
2、用例顺序和依赖是用户前端选择来设定的，后台只需要根据这些条件进行匹配执行就可以
3、还有用例中有个业务调用功能，这个也是另一种的依赖方法

这个锅测试不背

交给需求，让它去一个一个像素比对吧

目前哪个能体现你自身价值就学哪个，精不精通的都是后话了

选择是小朋友做的事情，成年人都学，技多不压身！

枸杞配奶，味道上佳。

1、UI 验证的是前端，功能页面交互、接口请求、接口响应是否在页面实际上达到预期
2、接口验证的是服务端，接口数据输入输出是否达到预期
3、这 2 个八辈子打不着边的东西想不懂为什么会被混在一起
4、举个例子比如你接口正确的，可是前端在请求接口的时候比如参数请求错误，返回的结果没有写在正确的标签下等等

seleniumgrid

我指的是手机屏幕上 xy 轴的相对坐标

坐标

社会亦是如此，无需自我烦恼，努力向钱看

1、首先框架再怎么封装也没有平台化来的效果显著，多人协作脚本、数据、版本等等无法实时统一和规范，数据量大了还会显得很臃肿，导致后期维护成本极高。个人建议是平台化将所有脚本数据版本等统一管理和指定规范，数据脚本实时共享和脚本结果可视化，对于后期 ci/cd、集成、拓展都比较方便。
2、手工参与那就是上面的平台化，根据给定的规则进行用例编写。不管是任何框架或是平台，增加工作量是不可避免的，所以这个我就不做解释了。
3、一般自动化满足冒烟、回归、主要流程就可以了，需要更细化的流程或者异向流程那就看你们自身公司是否有这人力了。
4、如何推动，这个不是你能左右的，这个需要你的 leader 和 pm 来推动，需要把编写自动化脚本的时间计算在每个测试的身上。