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

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

同时对于不同年龄经验的候选人，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 评审都是在与开发对场景逻辑中度过，要么测试帮开发补充逻辑场景，要么开发帮测试补充逻辑场景，这样才是测试用例评审的意义，测试用例不是宣讲，是对齐。

测试可以做很多事情来提升自我价值，这些价值也可以被上下游认可，但问题是大部分的测试缺少这样创造价值的土壤
让做
你能做
做完落地
落地能推广
推广产生业务价值

很多做的事情死在其中的步骤中。开发从无到有可以依赖业务方、产品提供原型创造符合业务需要的软硬件产品，测试很难创造落地东西，因为没有明确的需求方。现在各种平台层出不穷，我觉得开发这些平台给自身带来的技术享受、技术提升应该是要大于平台本身对质量、效率、团队带来的价值成就的。

其实不用否认，不用证明，测试在研发测试流程中是必不可少的，但是测试人员是很容易被替代的，幸运的是我们很卷，开发卷，产品也卷，需要快速迭代，需要开发不停的写业务而不是写单测，这样给了测试生存空间，就像上面说的存在即是价值，不用怀疑自己价值，不用拔高自己价值，不要一昧追求技术广度，单一领域内的技术深耕、业务深耕可能对混口饭吃更有帮助