• 客户端
  • 是否有本地观看记录的队列缓存？客户端会定期发送记录给后台，但是发送玩一次之后忘记清缓存导致重复给后端发送
  • 是否客户端发送记录给服务端存在超时失败重试逻辑，多次重试之下，给后端重复塞了数据
  • 能否一直开抓包，看看客户端是否多次发请求给后端
• 后端
  • 是否没区分好观看记录是否已入库，就直接插入数据导致出现重复记录
  • 能否看到后端的 access_log，先排除是否客户端给后端发了重复请求，从此判断是哪一方的问题

• 技术视角：通过埋点数据上报来计算。优点是简单快捷，不需要测试做太多事情；缺点是只能测自家 app 不能测竞品，同时技术视角的埋点可能不切合用户实际感受的首屏加载体验
• 业务视角：录屏分帧计算，可以是外部相机录，也可以直接被测机自己录自己。优点是能横向测其他竞品，贴合用户实际感受的首屏体验，方案可以跨端；缺点是容易不稳定引入误差

赞同这种做法。

没太大必要自己硬搞，最务实的做法还是复用开发的代码，也避免开发变更自己这边跟着出错。

搞得出来还算有结果，要是搞不出来，就是扣分。

可以先排查 pycharm 使用的 python interpretor 版本（在配置里找）是不是已经安装了 sqlalchemy 的相关依赖，如果确定版本没选错，那可能就是 pycharm 自身对依赖索引有问题，或者 sqlalchemy 对这些东西的定义没整好，不用管它，代码也能跑

1. 目标：你想要什么
2. 拆解：达成目标都需要些什么，你和目标之间的差距有多大
3. 执行：这些东西要通过做什么一件一件地完成，大体时间节点

如果觉得不够装逼，再价格 PDCA 循环下去，够了，再说就太假了。

为了不让整个东西说得太假太虚幻，再加一点现实生活的要素进去，比如说身边谁谁谁干了什么，启发到你想要这么做等等。

是啊，铺量铺得很凶，各大平台也靠给用户导这种广告赚了不少。广告主和平台都爽了，就是用户被恶心了

个人理解：

• 技术的本质是服务于业务，说的更死的一点就是没有业务场景的技术不会有价值。
• 鄙视链多数发生在研测内部，老板关心的是业务短期长期能不能赚钱。而技术只是做大行业口碑方便捞更合适的技术人才，支撑好业务当下未来盘子的一个基础。

可以考虑一下通过积分来兑换和大厂大佬们的一对一语音交流机会 @ 恒温

技术群我还真没见过一个能行的，要真想学就多泡泡国内外比较小众的论坛

离职交接时间可以谈的，也不一定非得一个月，看公司吧不好说

给一些比较虚的思路，可以做个参考：

1. 业务 app 是否有做专项测试的需求，如果有那会是什么场景下测什么东西？（性能、体验、稳定性、兼容、安全，每个方向下又可以继续按需细分）【这个其实很重要，也是大多数人从来没想过的问题，或者只有被外部推着的时候才去想】
2. 回答完第一个问题后，就知道你需要先去看什么方面的专项测试知识。从最基础的角度说，专项测试就是用特定的工具，使用特定的测试方式来测试，获取到测试数据后进行分析获得结论的过程。核心步骤是 “测试目标->场景设计->工具应用->采集数据->数据分析”。资浅的一般关注第三、四、五的执行步骤，资深需要更多关注第一、二、五步骤。
3. 按照不同的发展方向，专项测试的学习重点也可以做一些区分。
   • 往业务方向搞，多关注上述一、二、五步骤，多在脑海里验算推敲这些逻辑过程，把 “为什么” 想明白；多关注实际落地遇到的阻碍，都是很宝贵的经验，一问就看出水平高低。
   • 如果是技术方向，那要更多关注工具之间的技术原理和选型，不同场景或者不同测试目标，什么工具会更合适，为什么等。但无论哪个方向都好，一到五整个环节都不能有明显的掉链子。所以最好的学习就是在工作中使用起来

我 2022 年 9-10 月也集中面试过，没找到什么合适的工作。找工作一般预期得 2-3 个月。

正常公司几轮面试走完快的也两周起步，再走走其他流程妥妥三周。各位一定要骑驴找马，尽量不要上头裸辞。

啊，总结得挺好👍，就是让业务部门专注于业务工作

差不多就是这样，因为我没怎么直接接触 pmo 所以体会不深刻。一个最基本的印象就是这个人会干大量的沟通和文档事宜，但是一定得说，这些事并不是花瓶，都是些很必要的事情，虽然研发测试内部也能做，就是效率会降低影响项目进展。

期待 + 坐等

把别人的简历随便扔出来不太道德，如果是你的简历被到处乱发，你会是什么感想

优秀的简历就是把事情说得够简单但是有很明确，结构清晰，能体现出很好的数据导向思维和分析能力。至于怎么写一个好简历，可以搜搜社区，有好些类似的帖子

首先，流程拉通是一个具体的落地动作或者解决问题的手段，但并不是这个岗位的全部价值。

从日常我们这边的 PMO 工作来说，体感上有这些事情：

1. 有比较专业的项目管理知识，即使 ta 不了解项目本身，也能通过科学的办法对项目组内部信息交流提效，把控项目进展进度
2. 有效组织各类日常会议，做好会前会后工作
3. 一些比较麻烦的沟通可以让 PMO 来解决，不占用研发测试的时间

说起来都很虚，但是有这个人后，有很多原本研测花时间做会觉得很难受的事情，分过去就轻松很多了

如果是 android 的话，系统的事件好像是可以区分操作的？iOS 就不太清楚了

是的，大体就是这样的思路。

我没想过这么细，临时来想想，首先主控设备上要获取到你点击控件的 id，精确 id 获取不到就改成 xpath。然后把这个传送到被控设备上去寻找，存在的话那被控设备就做同样的操作，不存在那可能要报错或者出现异常了

我前面说的都是些浅表了解，我个人没做过，所以只能给个参考，不好说就真的能 work。

【获取当前操作位置的元素，是每操作一次后 dump 页面元素后，对比操作的位置去 dump 中获取吗】
我没完全看明白是什么，说的有点绕。

第二个问题涉及具体实现，我没有相关实现背景，也就不清楚在说什么了。

远程指导和带练的思路我理解是不一样的，远程指导会有它的局限性，所以就不能以现实带练的视角来看。当然我自己没做过，有什么坑我也不知道，但是我也看过不少远程指导案例，只不过教练侧都是网络上领域内比较有影响力的人，比如 斌辰力量举

【如果使用这种方法的话是主控设备每操作一次就自动获取一下当前操作位置的元素，然后再操作其他设备吗，感觉这样也不是很稳定吧】
是的，要有一定获取策略，稳定性上取决于本身预埋 id 的完整度以及 dump 控件的稳定性了，前者你们可控，后者就靠开源工具。

滑动操作，其实一样的逻辑，你不一定非要一次性滑动到位（除非产品就要求这样的交互逻辑），你可以多次少量逐渐滑到差不多的地方，【差不多】的定义也可以通过控件树比对来实现。

内容有差别，我们内部是通过 mock 所有服务端请求去实现，使得多台手机接受完全一致的服务端返回，否则这个问题你用什么神仙技术都绕不过。

考虑结合控件 id、xpath 语法 一起去做精确控制（前提是测试自己的产品，预埋好控件 id，测试别人的就很难说）