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

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

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 恒定，响应时间随着加压而对应增加的现象。见到这个现象说明已经达到系统瓶颈了。至于多大算是极限，取决于可接受的响应时间有多大。

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

浏览器版本啥的发下？

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

应该是没有做好手机排版适配，已记录：https://github.com/testerhome/homeland/issues/120

一般不建议跳槽，但看到这段描述，这个环境对测试太不友好了，你的杂务事情太多了。
建议楼主趁年前年后比较多招聘，赶紧准备跳槽吧，再不跳以后就更难跳了。

那先了解清楚步骤和根因吧，没找到原因就很难消除。

听你这描述，这个问题也不容易被测出来，所以更需要查清原因，才能对应指定合理的策略避免再次出现。

UI 自动化一般着重校验功能正常，只验证个别特征值（如界面有没有某个应该出现的标志）

如果还想看排版什么的有没有问题，建议可以自动化过程中每个页面截个图，然后人工再去看一下。

具体问题具体分析，这个说明有点笼统，只看出了现象，没看出分析和思考。

具体有什么线上问题？
有分析过这些上线会出现的 bug 都是什么原因出现吗？
你当时确实是遗漏测试了还是有测试了，但当时没问题？

找到大致原因了，专栏权限相关代码升级时被冲掉了。我建个 issue 跟踪：https://github.com/testerhome/homeland/issues/117

找到原因了，和会员等级增加了几个等级有关。我把你会员等级调整了下，现在应该可以看到了。你试试？

get，今晚回去看看。开源模块是社区自己开发的，有可能和升级后的社区主应用兼容有问题。