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

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

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

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

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

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

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

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