ai 盛行测试的需求可能稍微少点，但会多出更多的需求对齐事项，ai 实现的产品是否满足客户的要求，这么说来开发被淘汰的优先级会高于测试，目前还看不到有哪些类型的产品是不需要质检。

接着说下高龄危机，没任何行业无年龄壁垒，谁到了一定的年龄能力下滑是正常的，如果你连 30+ 都不到更不应该考虑 35 岁危机问题，而是想想当前如何具备测试的核心竞争力，能满足市场诉求，能比同行从业者更优秀，在这样的前提下就可以开始考虑考虑副业，自身的提升空间没拉满的情况下去否认一个方向即使转行同样会遇到同样的问题。

和你差不多，符合岗位诉求能负责业务的测试工作、基本礼貌（穿拖鞋过来的直接刷掉）、沟通表达能力（能简单明了的介绍项目背景、数据交互逻辑，如果是需要跨部门沟通要求会高些）、积极性（除业务外，对自身有没有完整的规划，有没有专研过某一领域）、如果是志同道合是加分项（没有眼缘，也不会卡死）

你这跌不到哪里去，即使你判断正确，也省不了几个钱，还不如想一下怎么挣得更多才可以抗住更多不稳定因素，看你这情况估计还降低了生活质量。

很好奇期望薪资是多少

感觉整的太过复杂，像监控告警这块应该是有单一的服务负责告警及 oa 消息推送，如果能保障监控告警服务的可靠性、稳定性，根据协议配置将被测服务接入到监控告警服务，还有必要测阈值告警等场景吗。 像这样的故障演练能做到每次版本迭代都进行一次吗？成本太高吧

不用管那些评论，上限不是由其他人决定的，单纯就 rf 完整的落地到推广的经验就不是他们点评的了的。你出来后估计是想整测试的知识付费服务，到时得参与到流量引流、私域成交、内容交付等，想对于以往的技术挖掘，这是更强有力的挑战，加油👍

不是测试不好找工作，是全行业。。。投资市场不乐观，以往随便来个 saas 平台都能拉到好几个融资伙伴，现在没有真正创新的软件产品没人过问，拉不到钱整软件服务，也就没有新的团队。互联网项目是最烧钱的，项目解散裁员比比皆是，老测试岗位都还没着落，新血脉又涌入，之后程序员只会和公务员一样难考。

规范的后端限制即可，前端做限制主要是为了用户体验，或者在前端进行数据提交时把后端返回的异常结果映射在提示框

理解下测试左移和右移，能在提测前提前介入到测试工作或者说在线上提高 “缺陷发现时间”、“问题定位时间”、“问题解决时间”

那你的测试过程不具备可靠性

你这感悟没到位，接口测试想对于功能测试的价值是可以测到更细粒度，能更快发现底层交互问题，你去玩玩代码覆盖率看看哪些是覆盖到的 哪些没覆盖到的，再重新理解下接口层用例设计策略，为保障服务的高可用、高并发、稳定性、安全性、伸缩性等，细分来看包括：对外接口、内部交互接口、交互服务异常（三方、微服务或者中间件）、安全测试、故障演练、启动配置项等。

不是向服务器 是向某个服务应用或者某个应用实例，先理解心跳原理，是通过什么协议传输，长连接还是无状态的 http，5s 一次和 1s 一次本质上除了频率是没啥区别。还有个点要确定下，你对并发的理解，1 个并发就是 1 个用户，1w 个就是 1w 用户噢，并发和 tps 不对等。

要考虑 1w 并发的情况如果是长连接，那就是要满足 1w 个线程，1w 个长连接通道，能不能支撑 1w 消息通道同时传递处理，一台机子一般处理不了这么大的量，得换算成单机场景，单机能跑多少 考虑稳定性、可靠性，压测完后提供较有力得参考数据。脚本实现就是先建立好通道，服务端再短时间内一块发送消息包。

如果是无状态的 http 请求，就是省略了建立通道的环节，直接发起请求，原理都差不多。

深一点的话，可以针对数据存储、服务依赖、服务异常做些故障演练，数据存储可以了解缓存穿透、击穿、雪崩，比方说在读取数据时数据正在删除中，会不会抛出捕捉不到的异常。服务相关的可以参考 panic 服务的场景考虑，比方说依赖的应用程序崩溃，在测试环境 kill -9 模拟，服务请求超时，依赖服务 connect fail 等。

在 testCase 层定义个变量就好，没必要搞全量的数据驱动

可以帮忙写单测

感觉看到了曾经的自己，哈哈

一开始我用的 unittest 框架写自动化脚本，跳槽以后心血来潮，想试试 jmeter，看看投入成本和产出是否成正比，也用 jmeter 整过接口自动化测试，写完第一版就发现维护成本很大，各种检索不便利，也没啥全局替换的功能。

接着继续研究数据驱动，能否有效的提升测试脚本编写效率，如果是简单的 http 接口做点数据驱动效果确实明显，但如果遇到组合场景，不同协议的比方说 socket tcp udp，又或者说需要做参数转换参数加密，实现一些数据驱动反而新增很多框架 bug，投入的时间成本反而增加。

之前也有搭过一整套自动化生成测试脚本的，只需要编写 excel，把所有服务交互的信息列出来，把所有输入输出分类好，base 概念，精准校验哪部分内容，还衍生出 AVU 的概念。那个 excel 是真的复杂，找个 985 高材生也要熟悉一个星期，才能介入进来，理解成本很大，框架搭建时也发现很多 bug。

后来跳槽到这家厂，经常要做各种服务交接工作，有交接过 rf 的脚本、pytest 的脚本、unittest 的脚本或者没框架的脚本，现在编写脚本更多的是考虑快速定位、报告可读性、源码阅读成本。还是用回 unittest 的框架，引入比较基础的数据驱动，定义好团队编码规范，编码量虽然比之前数据驱动那些多，但时间成本反而更低，复制粘贴 2s，改个描述参数 30s，一条 case 就出来。

接口自动化除了脚本框架外，核心其实还是用例设计，怎么设计用例才能保证代码覆盖率，更细粒度的场景能不能自动化，比方说服务与三方服务的异常交互，这样就衍变出单服务的自动化测试及测试思维，从单服务入手也能模拟各种故障演练，有时间的话可以研究研究这部分，比研究框架更有价值，框架够用就行。

有研发经验转研发 不算测试转研，这种按正常的市场行情算就可以。如果是纯测试转研发，能平薪转拿到 offer 就已经很好了。

请奶茶喝就行，最好星巴克这些，贵的深刻些

appscan 有个策略选择，你在里头勾选就可以，扫描时还要保证有覆盖到所有接口。之后遇到安全问题，根据描述去复现场景，复现出来记 bug 就可以了。不过 appscan 扫不全，可以扫些注入漏洞、xss、csrf，一般还需要补充些必要的安全测试用例直接手动测试，比方说越权场景、强刷（校验是否上锁）等。

每条消息都尽可能校验下，消息数量也是测试点，还要考虑时序、状态、消息丢失处理等情况