嗯嗯，认同磨合这个点，每个开发都有自己的特点，只要能做到互补并不一定就是坏事。

不过有一个点可能还是想讨论下，我接触到技术比较好且比较上进的，会以出低级 bug 为耻，所以自测一般会做得更完善，确保不会出低级错误，避免影响优化带来的好印象。优化后容易出错的容易是炫技型的，这种埋得坑可能更深。。。

如果是我的话，会分两种场景看：

场景一：连冒烟都跑不过的
沟通方式：调整下提测方式，改为提测的时候直接到开发座位，开发操作演示冒烟流程（控制在 30-60 分钟内可以操作完，服务端要部署到测试环境中）是 OK 的才算正式提测。如果现场都演示不过的那现场打回，开发修到演示过了再算作提测。

场景二：冒烟能跑过，后续修复 bug 中出问题
沟通方式：提醒开发做好自测，记录缺陷的时候也标记下哪些是修复 bug 引起的。同时也和开发沟通下，看是不是有什么困难导致没法做好自测（比如多项目并行、此场景不知道怎么自测）。直接沟通无效的话就向上级组长汇报，带上修复 bug 引起新增缺陷的数量数据增强说服力。

点了几个进去看，阅读全文都是要付费的？

已经工作 7 年多了。

如果只是单纯批量远程到 windows 并启动 Jenkins agent ，直接写个脚本循环 ssh 到 windows 上，下载 agent 的 jar 包并运行起来，是不是比较简单？

很认同复盘的目的之一是对未来的优化。至于对认知的修正，个人觉得改进下统一认知的机制，遇到分歧能更快速统一认知就好。互联网项目基本需求文档不可能事无巨细，有分歧很正常，能快速统一认知就行。

个人经历，复盘后最大的难点在于如何落地复盘得出的结论，这方面主要有几个原因：

1、这个结论本身比较虚。比如很多时候有些代码里的隐藏问题，会得出一个 “加强代码 review ” 这种结论。但实际这个结论实际操作很难，怎么算加强，多看几次？谁去加强，leader 还是开发自己？连怎么确认是否有落地都难，那落地就更难了。

2、这个结论操作起来不符合人性。比如楼主举的例子 “分页不传参数的 BUG 多次出现” ，有时候产生的结论是 “以后每次分页记得传参数” 。说实话，这类 bug 容易出现，是不是说明这个地方写起来不符合人性所以容易遗漏？那是不是应该改进写法，比如这个传参数内置到分页库里，而不是开发每次手动加？

3、结论具体了，但没有负责人和约定的完成时间，或者就算有也没有人监督。复盘产生的结论很多时候不是业务中的日常事务，更多是额外增加的优化工作，优先级不高。如果没有明确负责人和约定的完成时间，可能项目一忙起来就都忘了。没有监督人在接近完成时间时及时催促提醒，也很容易导致超时甚至不了了之。

至于解决么，前两个主要依赖复盘主持人带节奏，主持人要注意不要得出这两类结论。第三个主要就是靠 leader 或者指定的监督者了，也可以依赖制度，比如周会的时候最近 1 周到期的改进项需要明确同步目前进度。前期大家还没自觉需要多刻意提醒，有了自觉后会逐渐变好。

想起了以前看到的一篇文章，为何小孩子有相对较高比例能达到什么钢琴十级之类的需要比较长时间积累的成就，而大人能做到的却不多。其中一个很重要的原因是大人考虑比较多，像 “学了有没有用啊” 之类的杂念比较多，所以很容易在还没学会前就因为觉得 “没用” 而放弃。

感觉楼主负能量比较多，而且看起来还没有找到走出低潮的路径，长期如此会比较危险。既然楼主有这么多时间 “闲” 着，不妨试试两件事：

1、和你的 leader 聊聊，看流程规范缺乏导致测试很多东西施展不开的，他想法如何，是否有准备改变？

2、利用这些闲下来的时间，2-3 周时间去精进自己想精进的一项技能（感觉楼主目前最需要精进的是 “如何自学” 这项技能，比如从哪里学起，有哪些适合的书/课程，做怎样的练习实践达到掌握水平）。过程中不要去想 “不知道如何结合到公司项目运用” 这类问题，专注去学习，锻炼自己的自学能力。

感谢反馈，已记录 issue ：
https://github.com/testerhome/homeland/issues/125

get，帖子内展示圈子名的时候错了。已记录 issue ：
https://github.com/testerhome/homeland/issues/124

明白。加油！

写的挺全的。很用心呀。

PS：有部分图挂了，建议修复下？

佩服楼主的自控能力。

话说，为啥会觉得自己面不过？刷题刷到这程度，面试的编程题应该都没啥问题了吧？

在 b 里不能用。打 btn. 点后不出来 find_element_XXX 那些提示

这没问题吧？btn 又不是 driver 类型，而是 web element 类型。这个类型下面没有 find_element_XXX 这些方法，所以不出现提示很正常呀。

PS：pycharm 不是万能的，有些运行时赋值的东西它不一定都能识别得到，最典型的是通过反射赋值的基本都识别不出来。不能说没有自动提示就认为不能使用，只要程序能跑没问题，就可以了。

PPS：这种在某个函数内突然声明一个 global 变量的写法，demo 写下还可以，正式程序不建议这么写，会非常难找。

2 天

Hmm，我想表达意思是，带来压力的根本原因不是在这里。在于你和其他人对比，觉得不如其他人的心态。

年龄大转不了岗位？随时有一大波励志故事可以说年龄不是问题。困难会比年轻时大很多，但不至于不可能。

身边的同学比你好所以有压力？关键是你的心态。我们改变不了客观世界，但我们可以改变我们对这个世界的看法。和半杯水一样，每个人可以有不同的看法。比如你提到的身边的朋友都比自己强，你的想法是自己怎么这么弱呀，哎选错职业了；我的看法是不同的职业原来有这么大的不同，后面要多学习取经，增强自己的竞争力让自己变得更好。

当然我也理解不可能何时何地都这么乐观，但避免悲观总会让自己好过一点。这方面推荐看一本书：《被讨厌的勇气》。

看了下正文，这个压力不是来自于年龄增长和环境，来自于你和其他人的比较。。。年龄和环境不接锅。。。

建议想清楚，自己想要的是不是就是高薪酬？如果是，那就直接朝着高薪酬走，去大厂历练、奋斗。如果不是，那就不用在这个上面纠结太多。赚钱能力再强，总会有比你强的，怎么比你都不可能稳赢。

至于说不同岗位间的薪酬差异，这个我觉得也是正常的自然规律吧。每个岗位本身的价值决定了它薪酬的水平和上限。测试的价值确实不如负责生产的岗位，然后做技术的有时候不如做业务的，打工的比不过做老板的。做老板上限是最高的，但也是最难最苦风险最高的。不要只比较收益，大部分岗位，收益和付出是成正比的。多角度分析，适合自己的才是最好的。

TPS 期望值为 25 并发-24，峰值/拐点为 35 并发-28

这一段没太看懂。你需求里这个接口的响应时间要求是多少，好像没提到？

得出其查询的性能瓶颈（响应时间和 TPS）

针对这类需求，个人的一般玩法是：不断加压（比如 50 并发持续 3 分钟，然后 100 并发 3 分钟，直到达到典型业务场景的 5-10 倍），直到看到 TPS 恒定，响应时间随着加压而对应增加的现象。见到这个现象说明已经达到系统瓶颈了。至于多大算是极限，取决于可接受的响应时间有多大。

另外，也会测试下增加节点带来的性能提升情况，因为实际线上业务很可能突然压力会增大很多，这个时候直接加节点是最有效最快速的手段。需要看看加节点是否能提升性能，进而确定线上如果突然有活动，是否可以直接加节点解决。如果加节点无法提升性能的，需要想办法优化或者找到其他的能应对压力增大的预案。

浏览器版本啥的发下？

楼主这个方向确实比较绕，而且在实际使用中还会遇到别的问题需要处理：
1、采集的数据得另外想办法再收集、汇聚和分析
2、因为实际没有统一指挥（只是启动时机尽可能接近，不算指挥），很难准确设定发起压力的策略，只能是简单的 xN。集合点、共享变量之类的特性也没法直接用，得另外想办法继续绕。

jmeter 自带的 slave，其实就是纯粹的压力发生器，由 master 下发命令什么时候、发出多大请求量、请求内容是什么，slave 不用完整执行脚本，负荷比较低，而且数据也会自动汇聚到 master，用起来会方便不少。

既然可以用 ssh 连上，说明网络是通的。或者楼主可以发下具体是什么问题导致 slave 模式没能正常启动起来？

jmeter 本身就提供的 slave 模式不满足？

让开发在 debug 包里开一个清缓存的入口，命令行通过 Intent 调用直接清缓存？
跳到特定页面，也可以让开发加上相关的 deeplink

就是服务间调用都是封装成 rpc ，provider 把接口以独立 api 包形式提供给 consumer，consumer 引入后直接调用 api 包里提供的函数方法。可以参考下 dubbo 。

个人理解，系统间契约，基本就是客户端 - 服务端、服务端 - 服务端、内部系统 - 外部第三方三种场景。

第一种基本上会从设计层面确保向下兼容（客户端多版本并存特性决定必须这么做），比如只增不删不改。
第三种依赖第三方，一般上线后除非第三方变化，否则也不怎么会动
第二种数量最多，也最容易出现契约测试里提到的问题（一个接口 n 个服务调用，怎么确保调整后不影响其他服务）。但通过 rpc 调用，隐藏实际报文细节，再加上类似第一种的设计方式，也基本能保障不会因为某次改动影响其他服务，即使影响，只要大家更新 api 包，编译时就会发现和修正，也不用特意去测试。

所以说实话，个人没太想到契约测试在实际项目中能解决什么问题。不过这个只是我自己接触项目的情况，建议你可以结合你们实际项目中发现的问题，分析下有哪类问题是契约测试可以提前发现并解决的，如果发现有不少，也是可以去尝试落地的。

可以先统计下，发现的缺陷里有多少是可以通过这个契约测试发现的？

每个团队不大一样，关键还是看自己是否适用。我之前所在团队由于契约都是封装成 rpc 调用，每次升级只新增，不改旧的，确保向下兼容，所以不大需要专门做契约测试。

先分析下，这个问题是你推送没推送到，还是大家不想装？

建议找各团队老大支持，内部喊一句，附上二维码直接扫码安装，试用量应该能涨一波，也不依赖推送了。实在不行加上一个试用反馈的给点奖励，萝卜大棒一起上。

如何只执行 F1、F2、F3 对应接口测试呢？

简单的方法：测试手动在测试集里屏蔽掉还没开发完的接口对应用例就行，开发开发完了同步下测试，测试手动执行确认没问题后再去掉屏蔽。

复杂点的方法：特别写一个程序，识别开发这个接口有没有开发完（识别方法可以是和开发约定一个标志写在 controller 上，或者能找到现有就会有的标志直接识别也可以）。如果没有开发完，那就 skip 掉相关的用例（执行用例前调整默认用例集的内容）

个人建议用方法 1 就可以了，简单有效。

PS：这个玩法略特别，一般持续集成关注的是原有功能是否被破坏，执行的是已有功能的自动化测试。新功能一般是开发完甚至提测后才开始关注（除非开发用正统 TDD，先写测试再写实现，但这时候的测试也不是放持续集成里跑的，而是本地跑的，因为前期一定会失败）。

太早关注反而因为还没完全开发完导致不稳定额外耗费时间精力。