这不是胖灵的官职吗

之前我们团队分享得分最高的是分享弹吉他

面试就是你想要啥，候选人有啥的双向选择。要看候选人跟岗位的匹配度，在强制性技术要求上深挖，在加分项上稍微扩散。

同时对于不同年龄经验的候选人，3 年以下看基础技术的掌握度熟练度，3-5 年看技术的实际技术落地应用，5 年以上看技术深度广度、解决方案设计应用与所做项目的适配度。特别是 5-10 年经验的候选人最好选择在某个领域持续深耕的且与你岗位需求相对适配的，这样面试双方都有较大的发挥空间；如果候选人经历与岗位不适配，要看他的技术发散、思维发散能力，原来的技术储备能否转化；如果候选人经历分散，各个领域都干过且时间不长，这种候选人大概率和 3 年及 3-5 年的人差不多，在简历筛选时就要慎重。

越是经验丰富的，建议就不要问一些八股类的问题，通过深挖所做项目来看候选人的技术设计、选型、应用、改进等全方位能力，这样才不容易被经验丰富会背八股的老油子蒙混过关

是投递的济南的岗位吗？济南有哪些比较好的公司啊

我们是要私有化交付，docker 打包自动化验收工具，自动化依赖的数据库 中间件也都在里面。没需求也不用学，面试背背八股就好，学了不用也记不住

不考虑数据重复，用 yes 命令，创建 10G 文件 10 来秒，考虑数据复杂度，可以用 tpcds 来造数据

前置的需求分析与测试设计，后置的性能分析与性能调优都是不可或缺的关键。

认同，测试只是种手段，如何分析需求，分析架构链路，设计性能测试场景，将业务模型转为脚本模型才是比较重要的，不然做出来的结果也没意义，指标数据只是执行后的死数字罢了。

并发只是提高 TPS 或 QPS 的一种手段，实际操作中线程数=并发数，但是不等于处理并发能力

秒级 1000 并发需求可以有两种理解：

1. 场景可以支持 1000QPS 或 TPS，不论是高并发还是低并发，能达到就可以（达不到加资源），同时观察响应时间和错误率在合理范围内，给出达到预期的最小并发，另外如果资源冗余再看下资源能支撑的最高并发以及可达到的最高 TPS 或 QPS，评估是否符合预期（适用于流量高峰持续场景）
2. 当前资源下、1000 并发场景下的服务能力在合理范围（响应时间、错误率、资源指标），直接起 1000 并发，看资源情况（适用于秒杀活动那种场景）

这种都要结合实际的性能测试需求，看是哪一种再决定怎么做，不用纠结于字眼。以登陆接口为例的话，我理解更多的是 1000QPS 的概念，而不是 1000 个并发。

是的，测试用例评审就是拉齐产品与开发，开发与测试，测试与产品对项目需求的认知，防止出现返工扯皮

开发不想听的用例评审：点这个按钮，输入这个东西，......（🥱，好无聊）
开发想听的用例评审：这个场景下。。。这个逻辑下。。。（卧槽，这个逻辑好像没考虑到）

评审时注意引导讨论，简单 case 快速过，涉及到场景逻辑的要一条条认真对，不确认的 case 要提前标注与 RD、PM 讨论
测试经验比较少的经常写一堆前端 case，不考虑前端操作带来的后端逻辑，写了几百条看不到重点，异常逻辑分支重后端，前端操作几条就够了

我经历过的 case 评审都是在与开发对场景逻辑中度过，要么测试帮开发补充逻辑场景，要么开发帮测试补充逻辑场景，这样才是测试用例评审的意义，测试用例不是宣讲，是对齐。