说的有道理，可以 ui 和接口都做，但是具体操作的时候还是有很多空间的，比如 ui 做一些核心流程的，接口多投一些精力，只要你的方案能够自圆其说，有理有据，而且也顺应了领导的想法，领导一般也会接受的。不建议直接否决领导的想法，毕竟所谓领导的想法，也可能是他的领导的想法，ui 投入产出低，你的领导不见得没你清楚。

现在做测试相当于 49 年入国军，大环境不好，公司砍人第一个就是测试，测试岗位不会消失，但是会很卷，属于食物链末端，背锅侠，成长性差。做开发会稍微好点，记得不要做前端，再不济还能转型做测开，更不济还能做测试。虽然我也是在这个行业十几年了，但是非常不建议科班出身的，有开发能力的，入测试行业

这内容有点虚，精华贴也改为 AI 设置了？

40 以上的比较少，主要是这一行个兴起才没多少年，互联网发达以前，测试本来就很少，再过 10 年再看，40 的测试就多起来了

这个用户量很奇怪，难道都是大客户，高净值？

确认如此，对于个人而言工具不是越复杂越好，也不是功能越多越好，反而是越简单，越便捷越好，很多平台为了完成各种各样的功能，适配各种各样的场景，会存在为了满足极少一部分场景，把系统做的很复杂，用起来成本很高，反而类似 jmeter postman 这种简单粗暴的工具类应用更得人心，就比如我管的团队，虽然有接口测试平台，但是大家平常还是喜欢用 postman 和 jmeter，只有为了做自动化和 mock 的时候才会在平台上去做。

apipost、doclever、itest、MeterSphere 类似这些工具不是你想用就能用的，除非公司买了类似服务，很多个人版、社区版、免费版商用容易收到律师函，公司 IT 懒得去研究法律问题，直接就禁用了，而且，如果只是个别人想用类似工具，在线版肯定不行，那就只能直接部署，还要找服务器等，这样比起来 postman 和 jmeter 的优势就来了。很多人用 jmeter 做接口测试，其实就是和用 pestman 一样，当成是一个私人的接口请求信息存放工具，拿来存放请求脚本，和楼主理解的不一样，不存在团队合作等等场景，而且用 jmeter，后续性能测试也方便，把请求 jmx 改改就能做简单的单接口性能测试了，其实现在大部分公司对功能测试的要求并不是很高，“分析业务模型、数据模型” 并不是手工测试要考虑的事情，那是类似楼主的专业人士考虑的事情。所以考虑为什么用 jmeter，不如思考下为什么不用 apipost、doclever、itest、MeterSphere ，这样对测开人员落地相关工具还是很有参考意义的

说的很有道理，现在测试卷的很，能看代码，做点自动化，做点白盒，算是基本素质了，没这些很难进大厂，除非是做外包，可能要求低一些。现在这个时候不再是做白盒、做测开、做自动化就高级的年代了。

这才是正解，最有效的方式是减少用例数，用别的手段分摊 ui 用例做的事情，1000+ 的用例，维护起来也是相当头疼的吧

要是每个测试都有 lz 的做事态度和思考方式，得少多少线上 bug 啊

这种很多的，人家能把领导弄得服服帖帖的，其实也是对下属的一种关怀

测试没人权

在研发这条线上做啥都比做测试有前途，现在对你来说四个好机会，以后基本没有专职测试了

这是先通过 selenium 命令行启动浏览器，操作到指定界面，然后在用代码去操作这个已经打开的浏览器的意思吗？

第三条功能期盼已久，没权限看到贴子就不要展示出来，

这要能做出来，测试都可以改行了

之前尝试过将用例与接口关联起来，通过接口代码调用关系把代码串联起来，实现用例与代码关联；还尝试过，执行单个用例，然后统计覆盖率，将覆盖的代码与用例关联起来，但是都比较复杂，比较难用，而且保持更新是个难点，成本比较高

完全可以呀，只是模拟器跑出来的结果，人家认不认是个问题

感觉这是个概念，说白了就是构造数据的多种方式，可以 create，也可以 search，也可以提前构造等等，记得之前做数据构造系统的时候，可以创建数据，然后存到构造系统数据库，也可以到测试库里找符合条件的数据，可以做个 job 将符合条件的数据抓到数据构造数据库供各种测试使用。

以为时人人网呢

上游的人没必要研究，软件流程上游做的事情越来越少，越来越细化，能固化、系统化的都做了，他们也不需要关心什么，只有苦逼的下游岗位才在关注这个

国内现在这种现象确实很普遍，但是这也是因为从业人员水平普遍偏低导致，如果把测试和测试开发在一起，会导致楼主说的现象，，但是分开也会有问题，首先手工测试人员知识面比较匮乏，不少工作中缺乏思考，他们想不到那些可以技术化，提不出有效的建议，其实哪怕是做手工测试也要了解技术，哪怕你不会写代码，也要知道哪些工具、框架是干什么的，能干些什么，这样你在工作中多多思考，就会有不少有效需求；其次目前从业的测试开发人员大部分都是手工转的或者网上找的资料自学的。导致对很多东西一知半解，做出来的东西，充其量能用，谈不上产品这种档次，也就很难体现出专业，这就导致测试人员提出的不怎么有效的需求，和测试开发做出的不怎么专业的工具之间的矛盾，导致互不信任，一个觉得你春提个需求都不会，一个觉得你垃圾，做的东西随便点点都是小问题。
还有就是管理的问题，很多测试领导只是想着要有测试开发，要做系统做工具，但是没想着有了以后怎么做，导致做了很多系统做一个废一个。

问一下 MethodDiff.methodDiffInClass(oldPath, newPath) 是如何实现的？

平安内网管控比较严格，我们 cnblog 都封了

大佬加油！