建议参考 robot framework 的 Library 方式，框架提供一种统一的模式去调用不同的库提供的不同能力，减少新库的学习成本。

不过如果预计要扩展的库不多，楼上说的是最简单有效的，由业务方法去分别调用不同的库，而非框架。如果说想要控制避免不同项目用不同版本或者不同解决方案，引起不一致和高维护成本，也可以框架里基于 request 封装一些 http 操作的方法，供业务项目使用。

楼主感到迷茫，感觉更多是想跳槽但因为年龄到了未婚不好找；维持现状也不大好；换项目组把性能和稳定性测试都做好好像也意愿不强

作为 13 年毕业的过来人，分享一些愚见：
1、迷茫期最需要的不是怎么去做长远规划，而是下决心做出具体的改变。其实前面提到的可供选择的 3 个方向已经很清晰了，需要的只是做出选择然后努力去冲。至于选哪个，个人觉得除了维持现状其它 2 个都挺不错的，最终还是要靠楼主做决定和下决心。
2、找榜样，找身边能接触到觉得能力不错的人，多交流学习别人的工作学习方式，以他为榜样。有榜样后会不那么容易陷入迷茫，榜样就是方向。
3、多思考总结和做分享，比如学到某个技术或者某个觉得有意思的点，分享到社区或者自己博客之类的。积沙成塔，以后你找工作什么的，这些积累能给你带来很好的加分点，也容易形成你的影响力。

问题已修复，麻烦你再试试确认下？

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

不过有一个点可能还是想讨论下，我接触到技术比较好且比较上进的，会以出低级 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 恒定，响应时间随着加压而对应增加的现象。见到这个现象说明已经达到系统瓶颈了。至于多大算是极限，取决于可接受的响应时间有多大。

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

浏览器版本啥的发下？

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

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

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

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

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

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

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

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

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