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

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

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

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

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

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

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 内容发下？看报错信息应该是语法上有错误。

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

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

嗯嗯，现在开源项目评论方面做得比较简陋，后面补充一下。

但对于提交者来讲还是希望能知道未通过原因以及通知消息形式的提醒。希望官方考虑下这个需求！

感谢反馈。目前社区正在做代码重构，预计国庆完成。重构后再基于重构的代码补充这方面的通知功能。

看来我 out 了，现在的 tittle 都升级了。

我经历过的 OKR 是整个部门甚至公司实行的，OKR 不是提升个人某方面的能力，而是把目标以 O（方向）、KR（可确定是否有达到的结果）的方式给出。比如 O 是提高测试效率，KR 是通过有效精简测试用例，某类型项目测试耗时从 1 天缩短到 0.5 天。提升个人能力本身并不是 OKR 本身的目标，只是会在这个过程中带来的收益。

不管 OKR 还是 KPI ，本质都是把公司的目标以某种形式展现出来，确保大家不会把力用到其他无关的地方。

如果从是否解决业务问题的角度，技术部门的 OKR 确实会有一定比例在技术优化（内功）上，而非直接支撑业务目标。OKR 会便于明确一些不那么好通过 KPI 量化的东西。

截图里没看出哪里错误了？

warn 只是警告，不影响安装吧。

你是哪个包可以在手机跑起来，是上面截图的 WebDriverAgentRunner 么？

搜了一下，你最后的 "2020-09-15 10:24:33.198 xcodebuild[40577:1239983] DTDeviceKit: deviceType from 72361214b0e10a067959051eecf0d69fad0af186 was NULL" 好像和证书签名有关。所以要确认下你给 wda 配置了什么证书。

PS：有几个回答，和我认知有点不同，大家可以一起探讨下？

1、一个是浏览器启动到浏览器关闭.(浏览器页面一关 ,session 就消失了)
据我了解，浏览器页面关闭服务端是不知情的，所以服务端一般不是这么控制 session ，而是通过超时控制。只要超过一定时间这个用户没有再产生交互，那就自动销毁。

2、HTTPS 协议是由 SSL/TLS+HTTP 协议构建的可进行加密传输、身份认证的网络协议
不知道这里的 身份认证 具体是指什么认证？https 只是对传输双方进行证书认证，确认中间数据没有被篡改且证书是有效的，应该做不到用户账户这种级别的认证。

有点奇怪，开发类问的好少，更像业务测试的面试题。

一般测开应该会问一些测试框架或者开发框架的，毕竟以后主要要和这些打交道。

1、你用的是啥证书？
2、单独用 xcode 打开 wda 项目，然后 run WebDriverAgentRunner 这个 target ，可以成功在你那台测试机上跑起来吗？

1，晚些优化下，不直接打 nginx 错误出来。

错误信息太少了，只知道是什么命令错了，但不知道具体错误原因。

需要给出产生错误那个部分的关键日志。如果不好分辨，直接把完整的日志贴上来呗。

用例拆成两个部分，一个是触发数据的生成，另一个是校验生成后的数据？

不过可以的话，建议还是看下是否可以加速。每次重新测试都要等待 10 分钟时间还是挺久的。

选择一个对你工作更有利的。

考虑到开发都用 go ，建议也用 go 。一方面以后如果要做一些内嵌到应用的测试工具可以比较无缝内嵌，另一方面也方便你们之间增强交流。

一般一门语言足够熟悉了，以后有需要换语言并没有那么难。

感觉 content-dispostion 不一定够。真要做很仔细的校验，可能还得下载文件后比对 md5 ，或者直接解析文件内容。

这个开关除了不提示正在受到自动测试软件的控制外，还有什么别的影响吗？