不错，用的都是很快速就可以构建程序的技术栈，1 天就完成主要功能效率很高，点赞！

有计划后续基于这些录制数据，怎么进一步进行脚本生成之类的么？看到 github 项目的 TODO 有一个是代码生成，所以好奇问下。

点赞！这种汇总行业文章的方式很不错，而且汇总过程中的纪要总结，也是对这篇文章消化吸收的过程。

加油！

可以试试直接获取到元素的坐标，然后直接 click 坐标？

定位到元素但无法 click 的可能性比较多，比如元素被遮盖无法点击，或者这个元素本身就是不可点击的元素。如果想要了解为啥无法点击，需要提供更多的信息，比如 appium 完整日志、界面完整控件树及截图、元素对应的定位和点击代码。缺少这些信息，无法定位。

感谢推荐，今晚下载试用一下。

比较简单的做法：
提测时，测试对研发代码 diff 进行 review，发现全局组件变更的话（一般会放在某个固定的目录下），要求/和研发一起梳理全局组件的使用范围，进而更准确地进行相关逻辑的回归，避免遗漏。
如果 diff 成本高，也可以做一个简单的脚本，自动判定全局组件相关目录在本次提测的变更中有没有变更记录，有的话发个通知告知测试，测试再针对性找研发沟通。

不过个人倾向于，去推动提高研发对于这部分全局组件修改的影响范围评估能力。正常修改全局组件前，是必须要评估影响范围，进而确认使用何种修改方式的。这应该是修改前的一个基本操作。而且有些关键组件，是必须要求由对项目足够熟悉的人进行评审确认的，避免关键组件变更失控，影响整体架构。

从楼主描述看，研发这块没有做到位，自己都没意识到要评估和做相关的自测，更别说告知测试了。

第二篇出来得很快，32 个赞！花菜这种虚心接受意见，且快速修正的态度太赞了，32 个赞！

说不上指导批评，前端优化这块我也不够专业，大家一起学习~

话说，具体全局改局部导入怎么做的，可以也正文里补充下？

思路挺不错，每个步骤也很清晰，感谢分享

但恕我直言，标题 13 倍这个数据，有点太标题党了。。。这个优化主要是 js 瘦身了 0.4mb 左右，实际加载时间上提升应该不大明显。建议标题还是严谨一些吧。

是不是应该要加一些 sdk 采集加载速度情况，针对加载速度慢的瓶颈点进行优化，更容易出效果？比如 js 由于上行带宽限制导致人多时慢，是不是更适合上 cdn，或者拆分 + 按需加载来解决？

很完整的介绍，学习了。

济南的薪酬情况不大了解，建议你可以找下济南测试圈的人问问？boss 的薪酬大部分情况下有一些水分，不一定准。

如果不转岗，我能想到的就是：进大厂、换城市或者找风口行业。
薪酬高低很多时候是受大环境（行业、城市、公司规模等）影响的，不改变这个大环境，很难突破。

你正文都特意写了产品瓶颈高一大截，很匹配你的期望。

我理解那直接转产品是不是就可以了？或者说还有什么顾虑？

我心目中的 7 年经验水平，仅供参考：
1、测试方面，有过中大型项目的测试经历，用例设计考虑会比较全面，且基于风险大小和重要程度会有取舍，而不是一味全测。
2、技术方面，自动化是做过的，对于如何用工具提效自己也有一些想法，自动化/工具平台有实际落地且获得成效是加分项。同时对于自己测试的系统不是只是一个黑盒，至少核心业务流程对应的系统交互时序图（一个泳道是一个服务）可以画得出来。
3、管理方面，7 年我觉得至少要有中型项目的项目管理经验，或者带小团队的经验。对于一些常用的项目方面的问题（如进度风险）有一些比较靠谱的解决方法。

简单点说，7 年经验，薪酬肯定会有一定的要求，所以在团队里发挥的作用也会期望不只是一个普通一线，而是遇到中大型项目可以直接上，甚至到一个主导项目的角色的。

楼主一直只是在提技术，而且听起来楼主的强项并不在技术。楼主不妨可以也从业务、项目乃至管理这些方面总结一下自己的经历和能力，挖掘下自己的强项？

PS：好记性不如烂笔头。我也会代码写完太久没用就忘，这个是人之常情。不过我会做笔记，后面找回笔记总归能回想起来当时的思路，不至于相当于完全没做过。建议楼主学东西还是做一下总结或者笔记，这样后面也容易回想，而且这些放到博客还可以成为你能力的一部分体现。

不是瞬间，是持续的增大。也不算测最大承载数，主要看达到这个数量级时，资源使用情况以及接口响应情况是否在要求范围内。

个人遇到的比较多是产品运营做活动，需要提前压测确认当前线上配置是否可以承受活动期间大量用户涌入导致的系统负载增大。

这里的测试策略可以详细说一下么？或者举个例子说一下根据策略生成的用例大概是怎样？

有个疑问点，“说白了，就是别人给你英文文档，你返回人家需要的中文或者其他语言文档。” ，那你们的服务的核心功能是语言自动翻译吗？

如果是，那我理解核心功能应该在服务端，而和服务端交互最有效的手段就是接口。但看你下面的第一阶段还采用了 mock 专门保障被测对象范围在前端 UI，好像又不大一样。

另外，你们正常手工测试时，验证点是什么，怎么验证结果是否符合预期的？翻译这类功能，输入非常自由，我理解很难有真正意义上可以明确固定的 “预期结果” 吧。

业务测试这个可以通过定期到业务组轮岗之类的来进行，不一定就要直接转岗。需要的是你有这方面的经历和经验，对业务有一定的熟悉度。

个人觉得，作为测试团队的一员，没有业务测试经验光做工具开发，容易和测试团队缺少共鸣。

提前准备好足够多的账号，然后用集合点让所有线程同时发压。

不用 pycharm 打开，直接浏览器打开？

光这个图，没看出具体有什么问题 。

可以补充更详细的信息，特别是你的预期是什么，实际结果和你预期结果差异点是什么？

如果新增表 c，这 100 个用例只需要新增 delete 表 c 数据的语句，不需要其他变化，那可以考虑把这部分通用的内容抽离到一个专门用于存放通用清理数据的 sql 中，并进行适当参数化以便匹配各用例。

保护好团队的交互效率，这个点挺重要的。

好建议，我们看是否有做得不错的，邀请来大会分享。

学习了，我一般只是改端口，没加封 ip

很详尽的排查过程，也学习了 k8s 一些相关知识，做性能排查还是必须得懂整体原理，以及怎么通过日志等方式把原理中的每个模块拆解验证呀。

受教了。

ifconfig 检查下是不是有多网卡，所以有多 ip？