我的回答：在 jmeter 测试计划下添加线程组（添加线程数和循环时间），在线程组下添加 https 请求，配置 host，路径，加请求方法和参数等信息，添加用户自定义变量，在 https 中设置变量，取出测试数据，添加聚合报告合和查看结果数，有什么问题吗。
问答环节反问一下
虽然我没有深入学习过压力测试，但是你只是描述的是 怎么写压力测试脚本，压力测试脚本在整个压力测试中，只是最基础的一环；
压测是个大课题，压测流程，流量模型设计，流量仿真，环境仿真，流量保鲜，场景保鲜，压测监控，压测预案这些都没看到，你就说写个脚本。。。
说了最简单的部分
他希望你回答对压力测试的理解。。。 工具的使用只是其中一个很小的部分 而且就单从 jmeter 的使用来看 你回答的也很浅。。。
首先虽然我也没系统学习过压测，但你的回答和我上网搜一篇博客文章看十分钟能得到的信息差不多。
确实太浅显了，哈哈
、、、、 这 确实浅得不能再浅了
这个只能体现出来会基本工具的使用
不太懂压力测试，看着别人做的，在什么环境压的，内存多少，几核，并发量多少，怎么估算的，TPS 多少，是压单接口，还是全链路，压的时候要关注哪些点，这些要说吧
公司规模不同，对于压测方案的设计也会不同。大一些的公司，会有自己的压测平台，专门组织压测的专职 QA，对于数据隔离、流量仿真、压测监控都比较完善，即可供支持的配套设施完备。但创业公司，初期流量访问并没有那么大，需要压测的场景简单，要求也不高，采用 Jmeter 或者第三方工具（比如阿里云）。建议，如果真的想专职做性能压测，推荐 https://time.geekbang.org/column/intro/100042501/ ，希望对你有帮助。
你回答的应该是：请问怎么使用 jmeter 来并发请求？
压力测试浅显的回答自我理解要回答下场景方面的东西，比如基准场景构造，目标需求场景的构造，单多接口压测的构造方法，指标监控方式，具体流程各环节操作和作用，
当然我这个自认为是符合浅显的理解
1、如果应聘的是专职的性能测试工程师，这个问题问的没毛病
2、如果应聘的只是个测试工程师，就不应该问这个问题
这个回答只能叫怎么完成一个接口的测试，去网上找专业文章看下。面试官问的也有点宽泛，不会他也没做过吧
怎么做压测这个问题很大啊，很能考验你到底做没做过，压测的整个流程和压测中要关注的指标等等。我也没坐过
1.应聘什么岗位呢，面试官为什么问这个问题呢
2.这个问题的回答太细节，没有把为什么要这样做，如想解决什么问题，需要往前想，然后回答
3.面试时回答问题，非常重要一点是能理解面试官的真正意思🤭
瞎猜下，可能问这个问题之前，面试官是看到你简历/你的回答里有提到你有压力测试的经验，所以才问你当时是怎么做的。
这么问其实也挺常见的，可以看出回答者是否真的有做过（没做过的话，会讲得很宽泛，毫无细节），以及视野情况（是只关注具体某一小块，还是懂得从全局方案去考虑，甚至已经形成自己的固定套路），然后确定是否有继续追问深挖的必要。一般做结构化面试，核心是考察冰山下的能力（思维方式、学习能力、沟通能力等，或者叫潜力。有的公司会直接固化为公司内部的通用能力项），冰山上的能力（具体某个工具的概念或者用法之类的），一般是连带的。问冰山下能力一个很常见的方式，就是看如何总结阐述自己做过项目的经验（可以一次性考察到思维能力、沟通能力）。
一般对应回答，建议用 STAR 这种套路，先说明当时为啥要做压测（Situation，场景），具体压测内容是什么（Task），然后你是怎么一步一步去做压测的（Action），最后压测结果如何，有没有发现什么问题以及做什么优化（Result）。一般我面试的话，我会尽量把问题拆成这 4 个子问题分别去问，避免面试者没 get 到浪费时间。
面试官不是你同事，不知道你当时的场景，没有场景直接说细节，面试官会满脑子疑问，也会觉得不完整/太细节。
从压测的背景 指标评估 链路分析 到压测计划 时间 周期 前置准备 并 压测脚本 数据 模型等 执行完成后的人工复查 压测结论 问题的定位 调优 及整体复盘
你这个是压力测试的一个小部分环节，压力测试重点应该放在调研方面，如测试方案，准出标准，性能测试场景，脚本调试，数据分析，问题定位，优化方面等
可以从压测的整体流程上去说明，如指标、模型、方案、监控、场景、执行、分析调优....执行只是其中一小部分。面试的时候尽量避免针对某个环境做详细描述，把格局打开～
我觉得压测思路比较重要，包括本次压测的目标，周期，范围等等，一份确定好指标的测试方案尤为重要，其次是协助开发定位问题的能力，包括资源监控，分析等。在实际执行中其实只占小部分，更多是数据的记录，在调优时会发挥很大的效果，当然一些硬性要求我觉得是需要线下多加熟悉的，至少是工具的熟练度要高，可以结合一些性能的术语来模拟一些场景，就达到一般企业的要求了。
说实话确实挺浅显的，你这个只是压测流程中最基础的一步，设计压测脚本，后面还有系统监控，结果分析，等等，
如果我是面试官，我内心预期可能会是这样：
- 了解级：了解压测的一些基本概念，理解其目标和应用场景，但是不知道怎么用工具，没有实践过。（属于看过一些文章和资料，但是没有实践过的）
- 入门级：知道工具的基本使用，有一些实践经验，但是只负责执行层面的事情，基本不参与测试方案的制定，对整体压测背景、目标、结果等均不太清楚。（属于和主力一起合作干活，但是主责打辅助的同学）
- 主力级：清楚理解压测背景、目标，能根据目标拆分设计出具体的压测方案，并利用工具将方案执行落地，给出压测结果并跟进研发的后续优化，做各类验收。（属于对整个压测前后细节清清楚楚的绝对干活主力）
- Owner 级（甚至 Leader 级）：从主力里慢慢成长出来，会有不同的方向，技术路线可能是成为压测整个系统的某方面担当，围绕公司基建去演化压测系统，帮业务实现更低成本的压测，甚至做成 ToB 化；业务路线可能是围绕业务设计一套可持续有效果的压测方案，做到常态化压测和专项压测的支持，不断迭代优化业务的性能和容量，帮业务在容量成本、可靠性等方面做到优化。
确实很浅显，你这个只是工具的使用。
最好结合实际项目去说，如何设计的性能测试方案，被测服务配置，工具使用，获取压测结果，结果分析，通过压测结果分析出哪些问题（cpu 使用率过高，oom，内存泄漏，sql 慢查询等），性能调优（sql 调优 小表驱动大表、索引查询、id 字段能使用整型就不用 string、避免使用> in not in 等语法，缓存机制，消息队列优化，淘汰机制优化等）。
确实只是基础的回答，可能也是面试官问的太宽泛了，假入楼主你要进行一个压测一个产品，你怎么执行压测，你是怎么制定压测计划的，压测性能指标你是根据哪些来确定下来的，你会怎么样进行压力测试？结果是怎么分析的？中间有没有遇到哪些问题，等等。