好吧，大致看懂了。

• 你可以排除 gitlab 这个原因了，gitlab 或者 git 都只管代码，不管环境。你现在的配置能保障 pycharm 拉到的代码和你 jenkins 拉到的代码一样，那这个部分的职责就完成了。

• selenium 获取具体 webdriver 执行文件，默认是通过遍历环境变量里配置的路径实现的。从现象上看，chromedriver.exe 在你这台电脑有不止一个，而且版本不一样。可以所有盘都搜索一下，把多余的都扔到回收站，做到这台电脑只保留 1 个 chromedriver.exe 文件，然后再试试。

怎么确定的？可以详细说下吗？

提醒一下，不能认为用的同一台电脑就确定一样的哦。加载的环境变量和配置不一样，最终用到的版本也会不一样。jenkins 打开的 shell 本身就和我们在操作系统界面打开的有差异的，就算同一台电脑也有差异。

PS：有点没看懂正文的内容和 jenkins 有啥关系，标题有提到 jenkins ，正文完全没提及。建议也详细说下到底 jenkins、gitlab 和 appium 在你这个环境下是怎么串起来的。

建议另外开一个帖子，把你的具体情况和问题点说清楚吧？

并行多少台设备？有试过换台电脑或者换台手机么？

善用社区的搜索，给你举个例子：

改变不了的困难点是什么？资源（人）？时间？
看你的描述应该是这个团队的 leader ，这些应该是有足够的权限和能力去改变的。如果真的没有，可以找你的上级沟通下，如果上级支持，那你就会获得资源和时间；如果不支持，那你也没啥需要想的，说明维持现状就好了，只是你要想想自己再过几年的前途，继续保持现状是否合适了。

比较好奇是到哪些学校校招的，这么多研究生来投测试开发？

虽然也理解研究生在项目经验和学历上确实大多能直接吊打本科生，但这个比例也太出乎意料了。

android: content-desc
iOS: accessibility-id
这 2 个本身设计都是给残疾人读屏软件用的，基本不会有业务逻辑用到，可以放心加。只是基本这个是额外工作量了，建议可以让研发搞一些 hook 之类的给全部元素按指定规则直接加，一个个加太累了。

参考 appium 官方文档：http://appium.io/docs/en/commands/element/find-elements/index.html#selector-strategies

给我我也只能想到这些，可能会稍微多一个，就是问下函数的使用场景是什么，确认下自己对 "好" 的理解是否符合这个场景的需要。

裸辞的话不建议直接离职，未来不确定性太大了，说不定你的下家和这家也差不了多少。

可以骑驴找马，先不离职，外面找到合适的再离职。

主要是背景和项目案例要亮眼，那得亮到不看简历就能知道，业内有一定知名度的。这种比学历难多了。

如果是 xmind ，最近滴滴不是刚开源了 agileTC 么？
https://github.com/didi/AgileTC

excel 就不大知道了。

是不是有 sql 注入漏洞之类的？
删表不一定要获得主机权限或者数据库连接权限，有 sql 执行能力就行。

想先问一个问题，你们要分析的指标是啥，每个接口的请求响应时间，还是别的啥？看你的截图是响应时间百分比分布，图里内容已经反映出 95% 以上的请求响应时间在 2s 内了，但灰色线的那个请求明显比大部队慢很多，需要结合场景看是否需要优化了。不知道你想知道的是什么信息。

如果是想看每个 url 的 90% 或者 95% 响应时间以及 tps ，应该要用另一个响应时间的报表，具体名字不大记得了，横轴是各种指标（最大响应时间、95% 响应时间、每分钟请求数等），纵轴是每个请求 sample。

另外，Jmeter 有很多报表插件的，建议你在确定了自己想要的指标后，先看看有什么相关插件，找到最合适自己的。你现在用的这个插件感觉不是太适合，那条灰色线和其他数据差异太大，所以其他数据基本都看不准确了。

https://github.com/metersphere/metersphere
我的锅，打漏了一个 s。。。

个人想到 2 个点，供参考：

• 教会更多人写简单的自动化用例，提高自己测试效率（赋能）？
• 研究写起来更快更简单的自动化用例编写维护框架或平台，让用例产出量翻几倍（提效）？

你说的这几个都是体力活，听起来一句话就是继续干去年干的活，确实太平庸了，没感觉到能力上的上升。

从团队角度，没有上升的团队是很可怕的，做的事情只是 60 分及格，老板基本看不到（只会看到 80 分以上的），慢慢会觉得可有可无；团队氛围会很沉闷，看到 1 年后的自己和现在没啥差别，没啥动力；有追求的会走，没追求的会变成温水煮青蛙；而且最后真的要走的时候，这段履历面试时也容易被认为是原地踏步。

而且这种测试方案感觉比较低级，结果也不可控，没有说服力

• 方案不建议以低级高级论高低，关键还是是否符合需要。如果你觉得用脚本是低级，搞平台是高级，也可以搞，开源的也有 meterphere 可以直接用，底层同样基于 Jmeter。

• 至于结果不可控，不知道能否详细说下，正文中没看出哪里结果不可控

• 没有说服力。这个嘛，具体是哪个部分没有说服力，是 Jmeter 这个工具本身没有说服力，还是性能测试方案里设计的场景不真实没有说服力？一般性能测试结果没有说服力，大多是后者，前者见得比较少，Jmeter 本身大家还是比较认可的。

正文建议也搬运过来吧？这样进来就只有个链接，体验不大好。

比较难，一般单元测试需要能获取或者控制被测程序的一些内部变量。python 结合 java 大部分方案都是直接通过命令行调用或者通过网络调用，能直接访问到内部变量级别的基本没有。

而且也没有这个需求，都要做单元测试了，还不想用 Java 语言，这个应该是极个别现象吧。
如果说主要是想简化单测的代码编写量，可以考虑用 java 的其他变种语言，比如 groovy + spock 单测框架，写出来的简洁程度不亚于 python ，语法上也和 python 有几分相似。

部分老大觉得做业务测试的时候，做测试开发的工作是不务正业

倒是比较好奇是哪些地方让楼主产生这种感觉？个人倒没这方面的感觉。
测试开发和业务测试只是分工上的差异，也有很多团队不会分那么明显的，按照楼主分享的工作内容，在别的公司可能岗位名称就叫做测试开发了。而由于业务上的事情很多时候比较难对外分享交流，所以社区上交流的东西比较大的比例会是技术相关的。

至于有部分测试开发会有优越感这个嘛，就要具体情况具体分析了。我理解应该只是少部分人，因为测开要出成果是依赖落地到项目的，如果测开的工具平台业务觉得不好用而不用，他这个就白干了，也没给公司带来成果，绩效好不到哪里去。

个人理解是第二点。

个人觉得，说抢饭碗其实有点过了，开发的核心饭碗是创造，用代码实现需求。运维的核心饭碗是生产环境管理，确保线上各复杂服务可以正常运行，耐得住各种意外。大部分测试左右移，再怎么左移也不会左移到直接帮开发写新功能代码，再怎么右移也不会右移到机房虚拟机等管理，所谓抢饭碗，只是一些对开发和运维来说非命脉而又和质量沾边的真空地带而已。

当时也有问楼主是不是和开发运维们沟通没做好，导致对方认为在抢饭碗。但楼主没有后续答复，所以也不知道到底是什么情况了。

楼主好像没提自己年龄、家庭状况（未婚/已婚/有孩子）？
个人觉得还是楼主自己综合自己的情况选择吧，客观条件不相上下的时候，就是主观条件占主要因素了。薪酬是重要，但更关键的是能力和前途。

赞同楼主的观点，只要要求放低，总能找到办法的。其实也可以考虑转做一些年龄大经验丰富是优势的职业，比如老师。

IT 这个行业本身的飞速发展决定了它会更青睐年轻人（知识新、价格低、更能拼），开发测试都差不多。年纪大了要不往上升带团队甚至直接负责一块业务，要不换个位置降低要求过日子。这个没啥好办法改变，你当老板你也会这么选择，所以适应就好。

以前看到过一篇文章，说 IT 是用 10-15 年赚别人 30-40 年赚的钱。只要一开始有想清楚这一点，提前做好后 20 年怎么维持生活的计划，其实还好。换个角度想，我们已经比其他行业、其他人过得好多了。

看产品线 +1。有的核心产品线，开发也未必有全部代码权限，都分开一个个库，这个库的开发只能看到自己库的代码。

大多数一般会开放给 QA 权限。不给且不机密的，也有可能是没说清楚拿权限干嘛，所以对方觉得有风险不给开。

必应找到两篇文章，介绍软缺页以及 linux 内存管理机制的，不知道是否可以解答？
https://liam.page/2017/09/01/page-fault/
https://blog.csdn.net/wangquan1992/article/details/105036282

对于标题的软缺页为何高，可以参考下第二篇文章里的一些解答，仅供参考，我目前也还没遇到过这方面的问题，没深入研究过。另外，硬缺页不高和软缺页高不高，个人理解应该没有关联关系（一个只需要建立映射，另一个还需要挪数据位置）？不明白为何楼主分析会关注硬缺页的数据。

minor page fault 也称为 soft page fault, 指需要访问的内存不在虚拟地址空间，但是在物理内存中，只需要 MMU 建立物理内存和虚拟地址空间的映射关系即可。
当一个进程在调用 malloc 获取虚拟空间地址后，首次访问该地址会发生一次 soft page fault。
通常是多个进程访问同一个共享内存中的数据，可能某些进程还没有建立起映射关系，所以访问时会出现 soft page fault