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

如果是 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

这个话题已经变成是辩论题了，和人性本善还是人性本恶一样，没有绝对的对错。

希望大家理性辩论哈。高飞特别纠结，应该还是在于楼主观点里包含了这句话：

少数的精英掌握了话语权，成为了布道者，然后利用自己的影响力大幅拔高行业的水准标杆，让整个行业乃至社会陷入焦虑的旋涡。你觉得你没有错？那错的是谁呢？

诚然，从情感上说，这个是会让人觉得不爽的，这些 “少数精英” 其实只是想分享下自己看到的风景，说明行业还可以往哪些方向进一步发展，进而让这个行业往更好的方向发展。然后被这么评价，我觉得还是会挺受打击的。希望后续大家交流的时候注意用语。

最后，既然是辩论，我提一下我的观点吧：
从集体趋势上说，每个行业大概率都会有把门槛拉高、水准拉高的人，提高行业的上限进而让这个行业价值更大。这个是好事。
但从一个个个体来说，不同人诉求不一样。从比例上说，大部分人其实只是想简简单单打个工，获取酬劳，平稳过日子。这个也没错。
所以，每个人找准自己的位置，也明确自己愿意承受自己选择带来的结果（奋斗者可能是过度劳累带来的身体上的伤害或者家庭没照顾好，普通者可能是竞争力不强待遇上不去），那就可以了。这方面个人觉得华为的方法是比较有借鉴意义的，愿意奋斗的给更多机会和更高待遇，只想平稳过日子的也有对应的职位和合适的酬劳。每个人的选择都能得到满足，而且能相互合作凝聚成力量。

只是也没必要对那些做出的选择和自己不一样的人提出反对意见，每个人所处的环境都不一样，所以对应的最佳选项也不一样，甚至如果把你自己切换到别人的环境，很大可能你也会做出和他一样的选择。不同选择的同学做下交流，分享下自己选择后看到的风景就好。

1、线上数据不是说明场景覆盖更全，只是说明使用最频繁的部分会被覆盖。不能保障缺陷率很低，但可以保障不出 P0、P1 这种对用户影响很大的缺陷。类似于冒烟测试之于全量测试的作用，用相对低的成本发现相对高价值的问题。也有做到非常强大的，会去进一步筛选流量达到更高覆盖率，去年 MTSC 大会百度有分享他们千万级别的录制流量怎么结合机器学习做流量的筛选。
2、这种问题确实是碰运气。。。不过这类问题属于非常偶发的问题，对于重构项目出现个别用户问题一般并非那么不可接受，而且相比人工去补回各种接口测试，录制回放性价比高不少。
3、一般使用会配合堡垒环境 + 平台脱敏，不会给测试直接接触原始线上数据的。
4、录制回放一般有两种，一种是只针对读接口，那么只需要恢复录制开始时的数据库相关内容即可。另一种是针对读和写接口。对于这种，可以这么考虑：程序员编写的程序，本质上是对输入（包括用户输入、数据库读取的数据等）进行逻辑处理，然后再进行输出（比如网络的 response ，数据库的重新写入）。在录制回放里面，录制的不仅是网络流量，包括数据库、中间件的输入和返回都会一并被录制和回放。对程序来说，感受到的输入会和线上基本一致。

至于带来多大的提升，这个估计得大厂里有这个工具能实际使用的同学才能回答了。

为什么重构之后测试的时候不能直接用，还要 Diff 平台帮助找到差别

补充一下对这个问题的回答，基本上重构项目都是比较老的项目，所以接口自动化程度嘛，基本都不会很高（和接口自动化平台强不强无关，基本都是无可奈何的历史原因）。为这次重构补充所有接口自动化，工程量太庞大，也基本不可能满足重构的时间要求。

个人理解，按照你说的描述，diff 平台指的应该是录制回放后，对比线上和新版本之间返回值差异的 diff 平台吧？

1、diff 平台通过录制回放来积累测试数据和场景，能够积累到的数据量可以轻松到十万甚至百万级，成本上比每个接口写自动化低很多。而且这个是线上流量，最接近真实用户场景，发现的问题价值也高。简单理解的话，可以理解为是一种另类的灰度，来的操作还是用户的真实操作，只是结果只用来比对，不会真实返回给用户。对于大型应用效果甚好，毕竟可能是过万的接口数量，录制 1 小时可能就能有几十万的数据了，也没啥维护成本（下次用那就下次再录好了），比给这么多接口做接口自动化爽多了。

2、如果既有 diff 平台，又有接口自动化，一般分工是接口自动化主要针对新增的接口，因为这个时候没有线上流量可供 diff；而存量接口主要通过 diff ，通过录制 - 回放流量，可以覆盖更多的场景（比如特殊的数据、特殊的用户），需要付出的只是录制的耗时和回放的耗时。

3、至于互补， diff 平台的原理决定了它对一种场景是无能为力的，那就是还没上线，没有 “正确数据” 可供 diff 的新接口、新代码。另外为了保障所有输入值一致进而输出值可比较，基本上程序的所有输入（比如查询数据库的返回值）都是被回放的，不是真实执行的，所以起不到集成测试作用。个人理解可能由于这两个原因，加上本身技术门槛（不是所有的程序都能直接做录制回放，而且目前也没有开源或者开放的、兼容性很强的 diff 平台），所以 diff 平台基本上宣扬都很好，但实际在很多公司基本没有，基本集中在基础设施投入比较大的大公司内部。

不知道是否可以另外开贴分享下您实践测试左右移的具体情况，大家可以出谋划策，看有没有什么方法改进？

从你这个现象看，个人理解有可能前面的沟通没有做好，没能让开发和运维理解做左右移的原因和目的。左右移的前提应该是大家作为技术团队，都有保障质量这个一致目标，只是仅通过测试阶段来保障成本较高而且也比较难（不知道原理，容易漏测/多测），所以想通过和开发、运维的协作来提高保障质量的效率，进而满足互联网 “既要快也要稳” 的需要。

对他们也有好处（代码质量提高，开发在测试阶段可以不用花那么多时间精力在修 bug 上，进而用这些时间去还下技术债，提高自己编码水平；线上质量提高，运维可以不用老是把时间花在 “协助救火” 上，能花更多时间在建设运维能力上）。

可能没沟通好，导致他们单纯理解成了测试要抢他们活干，觉得受到了挑战，所以直接给测试开地狱（甩手）模式，让测试知难而退，进而保住自己的地位。

当然这个只是猜测，还是期望后面能具体说明下左右移的实践情况，这样才好继续沟通交流。

我觉得咱们都是测试人，没必要花大精力去探讨"是不是内卷"这个问题，探讨解决之道是不是更好？
至于要先做好本职工作确保好质量，再去延伸左右移这个，个人十分认同。大家多想想怎么让自己接触到甚至自己身在其中的没做好的同学纠正认识，会不会更有价值？

相信题主也是想大家正视和推动问题的解决，才提出这个贴子的吧。

我抛个砖: 大部分左右移案例背景都会提为何不左右移不行 (成本太高、效果不好等)，可以多强调下这个点。没有同类问题，不一定得引入别人的解决方案

越来越强大了

估计过了这么久，官方已经调整了。

build.xml 内容发下？看报错信息应该是语法上有错误。

社区维护者都是兼职的，会做一轮回归功能验证，但肯定比不上专业公司专职团队。

发布后如果有什么问题，也欢迎大家反馈修正。