感觉 why 这个层面说得很到位了，解决了一些实际场景存在的问题，思路也挺不错的。

期望关于平台完整的功能设计，可以说得更详细一些，配上一些截图说明更佳~

感觉最近社区有不少人突然意识到自己 30+ 了，感觉还在一线/还没转管理，比较焦虑。

其实可以反过来想下，自己 35 岁想要达到什么水平，现在继续这个状态是否能达到？如果可以，那保持就行。如果不行，那就要加把劲找下转机。

管理岗这个，要看公司和机遇，一般小公司机会会多一些。不过关键点还是你自己，包括团队协调能力、影响力等。能力强、表现出色，上面 leader 一走首选接班人就是你，就算不走，你自己做个 B 岗也能学习不少。

从大的 IT 行业来看，可能更多的 35+ 转管理前途会更宽广（更符合大部分公司的需要），但具体到每个人都是个体，也有 35+ 还在一线而且做得还非常不错的呀。

这个类比很有意思，不过也确实在理。

这种事都是高级开发，什么架构师的工作

可能说得直白点，这种思想才是阻碍你前进的最大原因。心里都想着最关键的、最有价值的都是别人的工作，那你自然只会去做不关键、价值不高的工作呀。实际大部分情况是，不是因为你有这个 tittle ，所以给你这个活，而是因为你表现出了能干这个活，别人才给你这个 tittle 。

测试就点点点就好了，整这么多概念，倒是给点实例，给点可行性的案例啊

建议看看社区里很受欢迎的这篇文章，里面的例子你应该会有点感觉：聊一聊职业发展

35 前对开发来说升级大多应该还是挺平稳的，那测试？

不知道这个结论怎么得出来的？至少我自己身边没感受到开发有这样的 “平稳” 气氛。

如果把测试看成只是检查质量，那确实价值不大。因为有没有你，质量都在那里，不升不降。

但如果把测试看成保障质量，那价值就不一样了。你能去让开发、产品提高质量，甚至参与到需求、技术设计中把控方向，减少故障损失成本，创造价值。别小看保障质量的价值，小则减少故障损失，大则简化和提炼需求及设计（简单本身也代表着出问题概率的减少）。最终能节省成本，以及缩短交付时间，间接增加收入（互联网行业，都是在抢速度，第一名可以获得很多额外红利）。

365 行，行行出状元，而且当你成为状元时，你可以选择的行当可能也更多了。当你深度和广度到一定程度时，你就发现你可以不只是局限在测试了，可以跨界到研发团队管理，甚至负责一个业务线。如果你的深度和广度不变，那永远是工具人，不至于没有价值，但可替代性很强，过几年就会被更年轻的人替代。

按影响程度定级，每个月统计各个级别的数量。看影响比较严重的级别个数是否在下降。

同时做好每次影响严重故障的复盘，落实改进措施。相比大的统计数据，找到根因、避免再犯更重要。

正统一点的手段，基础会比较扎实一些：
1、看招聘，各家公司测试工程师的岗位要求和内容描述，提取会被多次提到的项，了解下行业最需要的时候什么
2、看书，比如《全程软件测试》，对目前软件测试的方方面面有个大致的了解
3、基于 1、2，选择在项目中能用得上的技能或工具，重点突破，做出成果，踏出第一步

但耗时比较长，需要耐心和坚持。建议你直接跳到 3，找一个有价值的点单点突破，突破过程中你会发现你的广度和深度都会随着不断突破而扩大。

可是可能能力太低知识面不广，发现不了什么问题

你可以详细记录下自己在项目中的各个阶段的耗时（比如熟悉需求、设计用例、执行用例、输出报告等）及自己的熟练度，看看哪部分耗时长，熟练度不高。这就是你的潜力。也建议可以和你的老大沟通交流下，也许能得到一些启发。或者最简单，比较下自己的工作效率和组里面其他人相比，哪些方面比别人差，去学习提高。

看完这个简历，如果我是面试官，可能会问几个问题。你可以自己先想下是否都能答到面试官满意的水平，然后取舍它们是否需要按现在的描述继续留在简历里：

1、使用过 java 开发 web 项目，详细说明下是什么样的项目，使用什么框架，你在里面具体负责哪些模块，详细说下它的设计？
2、你的 java 开发 web 项目经验，在你实际的测试中有起到怎样的帮助，举个具体例子说明下？
3、你这里提到有 UI 、接口自动化的熟练掌握，那具体在哪些项目里有应用，效果如何？你在里面具体负责什么？
4、掌握一定的 SQL 语句，那比如现在有两个 xx 表，我要找到 xxx ，写下对应的 sql 查询语句？
5、熟练掌握 java 基础，那如果满分 5 分，你觉得自己的 java 水平大概多少分，为什么？
6、熟练使用 fiddler 抓包，能否说明下如果要用 fiddler 抓取 https 的请求，怎么配置？有没有遇到过配置后还是抓不到 https 包的场景，如果有，你理解为何抓不到？
（都是确认简历上你写的经验，实际深度怎样）

7、你最近经历的项目是哪个，能不能以最近一个需求作为例子，详细说下你当时是怎么做测试分析的，这个项目的核心点是什么，质量风险集中在哪里，你是怎么对应应对的？
8、现在有个 xx 场景，请设计一下它的测试用例？
9、你对你的未来职业规划大概是怎样的，有没有想过 3 年后自己要达到怎样的水平？
10、对于这个 3 年后目标，你目前有在做怎样的努力，比如近期有在学习什么？
（相对通用的场景，看你是怎么做测试的，以及对自己未来怎么思考。特别是你中间还有做过产品助理，转过方向）

PS：对于项目经验，核心点是写项目内容、你负责的内容、最后的成果（比如上线后 0 故障；建立起 100+ 自动化用例，缩短测试时间 xx%；通过云服务器的有效管理，环境稳定性提升 xx%；或者别的你觉得是亮点的结果）。前两个是铺垫，拉不开差距，成果才是关键，才能让别人知道你做到什么程度，是芸芸众生还是与众不同。当然这个成果也不要夸大，要不问到发现是假消息，效果更差。

合伙或者创业，我理解都是大家奔着一个梦想、一个长期的目标一起去努力，去改变世界。比如阿里的” 让世界没有难做的生意 “。

但你这里提供的信息完全没提及这个目标，” 一起搞事情 “也没说清楚搞什么事情，那别人怎么会愿意和你合伙或者合作呢？

坦白说，这介绍太简略了，吸引力真不强。至少需要把这个饼花清楚一点，好吃一点？

建议可以说详细点，具体怎样的软件定制（业务未来），对这个测试小伙伴期望是什么（个人发展），大致能给到的待遇或者期权如何（薪酬回报）？

如果要爬这个元素树，思路上可以把这个 xml 当做 html 源码，给 bs4 去捞取有效数据。

个人更建议先抓包看看情况，如果没有加解密，或者虽然用 https 但没有做强证书校验，不妨考虑直接抓包后模拟请求获取数据。一般网络接口返回的数据直接就是 json 格式，非常容易解析，比你 app 绕个圈好很多，而且不用去处理持续滚动等场景。

666，前 3 行还以为是脉脉平均水平，最后反转好大。。。

楼主可以拐个弯，既然一个 case 可以有多个 api ，那是否也可以只有 1 个 api ？单 api 针对不同输入，是否可以变为多个 case ，每个 case 只有一个 step ，即只调用一个 api ？

至于 testsuite ，代表测试套件，或者叫用例组。面向的场景是一次性要执行多个用例（比如要执行所有单接口用例）。

1、感觉楼主是类似安全爆破的思维，把可能的组合和场景都列出逐一执行。顺着这个思维可以参考 @ 测试小书童 的文章，了解下 all pairs 的组合思想，在能找到尽可能多的问题前提下减少组合数量
2、但也建议楼主可以从另一个角度来看。一个是这个接口的 100+ 用例，成本不低，但执行后是否有发现有价值的问题？另一个是，有些校验会不会其实代码里已经用很简单的方式写了，或者其实风险不大（比如起始结束时间，是否直接透传给了 model 层拼接形成查询语句）？

个人经验：
1、现在框架的封装性很强的，开发一个注解就能设定默认值、最基础的校验规则，为了这个做接口测试的单一字段校验（空值、类型不一致、长度不符合等），性价比不高，更建议通过 review 确认。可以了解下 swagger 注解和 JSR303 ，看楼主给的接口文档应该就是 swagger-ui 生成的。
2、分页如果用了合适的框架和正确的用法，基本不会有低级错误存在的可能性（如溢出页会报错）。同样可以通过 review 确认。
3、参数组合在查询类接口，最终其实还是组合成了 sql 进行查询。所以确认组合 sql 的部分逻辑有没有问题（比如用 AND 还是用 OR ），基本风险就控制住了。也是 review 可以确认或者去掉那些风险不高的组合的。

日志中没看出 test_b 有执行通过呀。
貌似这个插件文档里，没提及它具备自动追溯依赖用例并自动执行的能力吧？

why、what、how，楼主直接就写了 how 了，看完有点一头雾水。
why 和 what 建议补充下，文章更完整？

自己也是从外企的离岸外包做起，确实外企五险一金和工资发放会比较好。

接口测试中，新增了一个核心功能，是自动生成模糊用例，之前用的 pict，后来用了第三方模块来做，有兴趣的可以去看下，或者我有空帮忙介绍

这块比较感兴趣，后面可以细说下？

花了点时间完整看了下，确实整理得挺全的，也带有自己观点。

期望后面可以不断完善和做一下其中一些细节的分享~

外包且干得不咋地（没经验积累，就是单纯跟着公司一个一个项目做）是污点，如果是去过同类型大厂的，且有不错项目经验的，那是亮点呀。

只是外包大部分上升通道受限，也不会有太多的上升压力（基本要求就是做好分内事就行，也不要求你进一步提升），甚至很多外包几个月就换个全新项目，不好积累。所以从大样本来看，大部分人自主学习意识一般，然后外包做几年很容易会是一年经验重复几年应用。

PS：简历写外包就被刷的，大多应该是因为外包那段经历写得太简单（项目简介抄一下，加一句自己里面的岗位 tittle ，好点的加点自己做了些别人也会做的事）或者太详细（1 年干了 n 个项目，n>5）。不过说实话，不管是不是外包都会有这样的简历，都会容易被刷，因为没看出项目有你没你有啥差别，你的价值是啥。这种情况是不是外包其实差异不大。

这个总结挺不错的。期待楼主落地后的进一步总结分享，特别是哪些效果不错，哪些效果一般。个人经验，这些都能做到还是挺难的。

话说，比较好奇楼主是通过那些方式了解到以上的这些关键点，也可以分享下？

为了测试需要调整配置和环境，开发和运维都不接受，个人感觉你现在的大环境还不是太适合推覆盖率。

不管是动态还是静态的插桩，插桩后的代码和线上运行的或者其它环境的毕竟会有些区别，整体研发团队不能接受这种差异的话，基本上覆盖率不大能推起来。

人员流动后东西又给回来，这个确实比较坑。。。
不过看楼主的历史文章，楼主还是挺稳定的，比较好奇为啥其它同学都半年一年就跳槽呢？

看文章里的说明，这个平台好像主要用户和维护者都是作者本人？那确实蛮辛苦的，也善意提醒下，架子搭起来后，可以多考虑下让其他测试同学把平台用起来，个别有兴趣的可以拉拢一起维护，这样省力效果更佳。

另外，也分享下对于文中的提到的自动生成功能维护成本高，代码改动后得额外维护适配的问题，我们的解决方案，供参考：
1、自动生成背后的脚本逻辑直接是基于接口自动化脚本里面的流程型脚本进行，自动化脚本本身就会在测试中被测试人员进行应用和更新。
2、生成逻辑主要基于服务接口进行，基本不会直接插入数据库。并且尽量使用外层和客户端交互的接口（这类接口要考虑客户端发版慢，必须向下兼容），降低维护成本。

想了解下你的需求是什么，为何必须要在浏览器端做动态插桩？

学校的项目经验，可以找导师介绍，加入学校一些工作室，或者参加那些科技创新比赛之类的呗。