2024最新软件测试【测试理论+ 性能测试】面试题（内附答案）

一、测试理论

3.1 你们原来项目的测试流程是怎么样的?

我们的测试流程主要有三个阶段：需求了解分析、测试准备、测试执行。 

1、需求了解分析阶段 我们的 SE 会把需求文档给我们自己先去了解一到两天这样，之后我们会有一个需求澄清会议， 我们会把不明白不理解的需求在会议上说出来，包含需求的合理性还有需求的可测性等， 产品这边解答，目的是让我们测试这边和开发对需求的理解达到一致。

2、测试准备阶段 会议结束之后我们开始准备测试工作，我们测试这边会写一个测试计划，分配每个人负责的模块， 然后我们就根据自己负责的模块用 xmind(思维导图)进行测试需求分析，分析测试点， 以及编写测试用例，之后我们会在自己的组内先进行评审，评审修改之后还会在我们的项目组评审， 评审完后进行修改测试用例。

3、测试执行阶段 开发人员编写好代码之后，我们会把代码包通过 Jelkins 部署到测试环境提测，进行 SIT 测试， 在正式测试之前我们会先做一个冒烟测试，冒烟测试通过之后我们才转测，在执行测试的过程中， 我们如果发现 bug 就会用 tapd(或者禅道)记录并且提交 bug，也会进行 bug 复测，以及回归测试， 每一轮测试结束之后我们都会写一个测试报告，一般情况下，测试 4-5 轮之后会达到上线要求， 当达到上线的标准后，测试报告会认为测试通过，上线前我们会做预发布测试，预发布通过后， 由项目组与产品决定时间上线，上线完成，一周左右我们会写一个项目总结测试报告， 总结我们在上一个版本中遇到的问题以及今后有哪些地方需要改进，在产品选代过程中， 我们会跑自动化用例来进行回归测试。

3.2 如果需求不明确的话你怎么办?

需求不明确的话我会在需求澄清会议上面提出来，问清楚这个需求只有明确需求， 才能更好的完成工作，后续工作中还是不清楚，可以找产品再去确认这个需求。

3.3 有哪些需要评审，哪些人在

1、 xmind 思维导图评审，主要是测试人员 2、测试用例需要评审，测试人员，开发人员，产品人员 3、需求文档，项目组所有的人员，都会到场

3.4 有没有写过测试计划，具体包括哪些内容?

参考答案 1： 测试计划内容： (1)目的和范围 (2)规程 (3)测试方案和方法 (4)测试的准入和准出 (5)测试计划(流程、时间安排、对应人员) (6)测试的环境配置和人员安排 (7)交付件 华测教育专属 华测教育专属 华测教育专属 华测教育专属 华测教育专属 华测教育专属 华测教育专属 华测教育专属 华测教育专属 15 参考答案 2 我们公司之前按照考核要求写过测试计划，不过后面老大觉得太耽误工作进度， 后面一般都不再写测试计划，而是写版本计划，这个在版本计划，每个人的任务列出来， 负责人列出来，自己根据自己的情况分配时间，然后汇总，大家一起开个小会评审就可以了。

3.5 用例包含哪些部分，哪些用例设计方法，你一般常用哪些方法?

原来我们用例包含 测试项目，用例编号、测试标题、优先级、预置条件、操作步骤、测试数据、预期结果 黑盒测试用例设计方法：主要是等价类、边界值、错误推测法、判定表、因果图、正交表、 流程分析法、状态迁移法、异常分析法。 常用的：等价类、边界值、判定表、流程分析法、错误推测法。 等价类是指某个输入域的子集合，在该子集合中， 各个输入数据对于揭露程序中的错误都是等效的， 并合理地假定：测试某等价类的代表值就等于对这一类其它值的测试，因此，可以把全部 输入数据合理划分为若干等价类，在每一个等价类中取一个数据作为测试的输入条件， 就可以用少量代表性的测试数据取得较好的测试结果， 等价类划分可有两种不同的情况有效等价类和无效等价类。 边界值的话就是对等价类划分方法的补充。测试工作经验告诉我，大量的错误往往是发生在输入或输 出范围的边界上而不是发生在输入输出范围的内部，因此的话针对各种边界情况来设计测试用例，可 以查出更多的错误，使用边界值分析方法设计测试用例的话，首先应该确定边界情况，通常输入和输 出等价类的边界，就是应着重测试的边界情况应当选取正好等于，刚刚大于或刚刚小于边界的值作为 测试数据，而不是选取等价类中的典型值或任意值作为测试数据。 对于错误推断法，这个是基于经验和直觉推测程序中所有可能存在的各种错误， 从而有针对性的去设计测试用例的方法的，主要就是列举出程序中所有可能有的错误和容易发生错误 的特殊情况去根据这些情况来选择测试用例，例如，在单元测试时曾列出的许多在模块中常见的错误 以前产品测试中曾经发现的错误等，这些就是经验的总结。还有，输入数据和输出数据为 0 的情况。 输入表格为空格或输入表格只有一行。这些都是容易发生错误的情况，可选择这些情况下的例子作为 测试用例。 前面介绍的等价类划分方法和边界值分析方法都是着重考虑输入条件但都没有考虑输入条件之间的 联系，相互组合等等的情况。考虑输入条件之间的相互组合，可能会产生一些新的情况， 但是要检查输入条件的组合并不是一件容易的事情，即使把所有输入条件划分成等价类， 他们之间的组合情况也相当多，因此的话可以考虑采用一种适合于描述对于多种条件的组合，相应产生多个动作的形式来考虑设计测试用例，这就需要用到因果图(逻辑模型)。 因果图方法最终生成的就是判定表它适合检查程序输入条件的各种组合情况。

3.6 TestLink 工具使用?

(1)创建用户，并给新创建的用户指定权限。 (2)创建测试用例，对测试用例进行增、删、改、查 (3)把测试用例关联到对应的测试计划中。 (4)把测试用例指派给对应的测试人员。 (5)对应的测试人员，查看被指派的测试用例，并执行测试用例。

3.7 如何提交一个好的 BUG

对 BUG 有一个清晰明了的描述； 详细描述 BUG 重现的步骤 对于产生 BUG 的环境进行描述； 提交 BUG 相关的图片和日志; 定位好 BUG 的等级； 将预期结果与实际结果进行对比。

3.8 提 bug 需要注意哪些问题?

1) 不要急着提交，先跟开发说明 bug 的情况，定位分析下 bug。 是前端问题还是后端问题再去提交 bug。 2) 简单明了的概括 bug 标题，清晰的描述 bug 重现步骤，分析 bug 和预期正确结果，附加 bug 的截 图或者日志。描述 bug 的时候。 3) 在不能确认该情况是否为 bug 的时候，可以请教其他人。 4) 提交完 bug 以后，后面还要跟踪 bug 修复情况。

3.9 bug 怎么管理的，bug 的生命周期或者是 bug 的状态

原来 bug 是用禅道来管理的 原来我们公司 bug，提交 bug 直接给对应的开发人员，对应开发人员修复完成，交给测试复测， 复测通过关闭 bug，不通过打回给对应开发。 提交-开发人员(已激活未确认)-开发进行确认，状态变成已激活，已确认，开发修复完成， 标注状态是已修复，测试人员复测通过，已关闭，打回给对应开发，已经激活。

3.10 提交 bug 包含哪些内容

所属产品、所属模块、所属项目、影响版本、指派人员 截止日期、严重程度、优先级、bug 类型、bug 环境 Bug 标题、重现步骤、附件

3.11 你提交的 bug，开发不认可怎么办?

首先我会再看需求文档，是不是我的理解有误，如果是我对需求理解错的话我就去关闭 bug。 如果是 bug 再去让其他测试人员看看听下他们的意见，然后自己先再三去复测，并目保存好截图和日 志，确定这是一个 bug 之后我就去跟开发说明白，并且给他看 bug 重现的截图以及日志，如果开发还 是不认可的话我就跟产品或项目经理说明白情况。

3.12 对应无法重现 bug，应该怎么处理?

首先，我会多测几次，测了好多次都无法重现的话我就先把 bug 挂起，并且留意一下，看看往后的测 试中，如果在后面的测试中重现 bug 就激活，如果经过几个版本都还没发现的话就关闭 bug。

3.13 界面中的乱码可以是哪里导致的?

(1)数据库中的编码设置 (2)前端页面编码 (3)后台代码也会编码

3.14 bug 的级别有哪些，级别如何判断

1、致命：对业务有至关重要的影响，业务系统完全丧失业务功能，无法再继续进行， 或业务系统丢失了业务数据且无法恢复，影响公司运营的重要业务数据出错。 2、严重：对业务有严重的影响，业务系统已经丧失可部分的重要的业务功能，或业务系统 丢失了业务数据且可以恢复，一般业务数据出错。 3、一般：对业务有较小的影响，业务系统丧失了较少的业务功能， 例如：界面错误，打印或显示格式错误。 4、提示：对业务没有影响，不影响业务过程正常进行， 例如：辅助说明描述不清楚，提示不明确的错误提示。

3.15 测试中，如何判断是前端的 bug 还是后端的 bug 呢?

通常可以利用抓包工具来进行分析。可以从三个方面进行分析：请求接口、传参数、响应。 1）请求接口 un 是否正确如果请求的接口 ur 错误，为前端的 bug 2）传参是否正确如果传参不正确，为前端的 bug 3）请求接口 u 和传参都正确，查看响应是否正确如果响应内容不正确，为后端 bug 4）也可以在浏览器控制台输入 js 代码调试进行分析

3.16 项目上线后发现 bug，测试人员应该怎么办

看严重级别：严重还是不严重 严重的：紧急变更上线  不严重：修复好后跟下个版本一起上线 用户会通过运维反馈到项目组这边，项目经理会根据功能模块的负责人，分给对应的开发与测试。 测试人员：编写对应的测试用例、测试环境中重现 bug、提交 bug、 交给开发进行修复、修复完成 bug、进行 bug 的复测。 如果测试环境无法重现，可以导入生产环境的包到测试环境中测试， 还是不能复现，查看生产环境的日志去定位问题。

3.17 如何保证质量

(1)需求要吃透，多问，多去了解。 (2)严格按照测试流程去执行：多考虑用户测试场景，使用测试用例设计方法，多评审。 (3)要有良好的测试执行：要求用例执行率达到 100%，多轮测试，进行探索性测试， 需要测试之间交叉测试，用工具来管理我们的测试工作(禅道， testlink， excel，tapd) (4)不断的反思与提升。

3.18 产品是怎么上线的?

一般我们会选择晚上上线，开发测试还有产品全部到场，进行上线测试。 首先，开发将代码打包到生产环境的服务器中，如果数据表有变化，就会运行 sql 文件， 对表的一些操作，接着，我们测试就开始先测试主体业务功能以及新增的功能模块; 测试通过之后，我们会在界面上把上线测试的数据删除，正常上线。 如果发现 bug，开发人员当场修复 bug，修复成功之后我们测试再复测，通过就可以正常上线 如果发现了 bug 开发人员在上线规定时间之前都还没有修复好的话，就看问题的严重性， 如果严重就延期上线，如果我们是迭代版本的话我们还需要版本回滚。 如果不严重，产品跟客户觉得可以上线，就正常上线。

二、性能测试

14.1 性能测试怎么测试

性能测试其实就是通过自动化工具模拟多种正常、峰值以及异常负载来对系统的各项性能指标进 行测试。负载测试和压力测试都属于性能测试，二者可结合使用。 性能指标主要有平均响应时间、90%响应时间、吞吐量、吞吐率，每秒事务数，以及服务器的资 源使用率(CPU 占比，mem 内存占比等)等。当并发用户数超过 300 时，为了让测试数据更准确，可以 考虑分布式压测，通过司令机控制几台奴隶机进行测试。 性能测试要先调试好脚本，主要考虑对脚本的数据参数化和添加断言。因为有些接口需要对业务 逻辑或参数格式进行校验，为了能让所有线程数跑起来，需要将数据参数化。 数据参数化有这几种做法： 1、可以将一些固定值改成随机函数; 2、利用 JDBC 从数据库读取数据并关联变量； 3、Excal 数据参数化， 4、动态关联参数化，断言是为了判断用例是否 执行成功，并验证服务器的响应错误率。响应断言常用 json 断言，xml 断言用的最少， 性能测试的目的是为了检验系统能否满足客户的性能需求，若性能需求无法满足时，则 要考虑对系统进行性能调优，一般用排除法： 1、首先考虑网络方面问题：使用 ping 命令查看与目标服务器的连接是否正常、传输速度的快慢。通 过提升服务器的带宽，看响应时间是否相应降低。 2、考虑数据库的问题，可以单独去压测数据库，查看数据库的最大连接数和 SQL 语句的执行时间， 索引命中率和 sleep 等待时间等 3、考虑 Apache 中间件的问题，查看中间件设置的最大连接数是否合理，如果设置的连接数太小， 会话数超过设定的最大连接数时会导致等待时间变长，出现响应超时情况 4、考虑服务器的硬件配置，如内存、CPU、men、磁盘读写速度等，可以用 top 命令来监控，也可以 使用 nmom 工具来监控，nmom 会把监控的数据形成表格形式，方便我们查看。 5、最后考虑开发代码写的好不好，处理时间长不长的问题。 举例：在我之前的公司，我们主要是会考虑用户操作使用比较频繁的模块，比如借贷，充值，投资模 块，我们一般会通过增加并发数来压测，观察 CPU、mem、磁盘读写、吞吐量和每秒事务数等性能指 标，以前我老大要求我并发 100 个用户，我用 jmeter 把线程数设为 100，永久循环，持续时间半个  小时，设置启动延退 55，在 Linux 启用 mmom 工具监控服务器。 当我运行脚本的时候我看聚合报告 90%的平均响应时间达到了 6s，吞吐量也比较小，用 top 命令监控 资源发现 CPU 差不多到了 100%。于是我用 Navicat 工具通过 SQL 命令 show full processlist 取当 前运行的 SQL 语句，发现有许多语句用的是左关联，在查看了这条 SQL 语句的执行计划发现没有用索 引，再查看了索引的命中率，命中率倒是还行看了下 nmom 生成的报告，发现 CPU 一直是处于爆满状 态，其中主要是 mysql 的占比很大，这个时候我基本上判断数据库的问题。 于是我就照着前面的步骤再次压测，同样还是用 nmom 工具去监控 CPU，mem 网络等状态，这次我 是主要在 Navicat 上用命令去抓取 SQL 语句，还是一样有很多语句都是左关联，并发现很多空连接 (sleep)，我就用 show global variable like"wait_time"命令查看了设置的休眠时间(等待时间) 发现时间很长 28800s，然后我就把这个休眠时间改成了 20s，因为 SQL 语句使用了很多左连接，我就 用 show variables like"tables_size"查看了临时表的空间大小、发现临时表只有 16m，我将空间 改成了 1G 再去压测了下，发现 CPU 只是降了 10%左右，nmom 报告上还是显示 mysql 占的 CPU 很大， 然后运行的时候，用 top 命令监控，发现有的时候有很多 mysq 进程同时运行(因为没有设置连接池)， 我就用命令查看了下 mysql 的最大连接数，因为 SQL 语句的执行速度还是挺快的，所以就把 mysql 的连接数调小到 50，再去跑了一遍发现 CPU 降到了 40%左右，并且其他的性能指标也都还不错。最后 把聚合报告的数据以及 nmom 的数据整理成性能报告给老大，其实做接口性能主要就是用排除法个一 个去排除，发现性能问题就要先解决了性能问题再压测，不然其他的问题也有可能是这个性能问题导 致的所以接口性能基本上就是观察，各个性能指标都在范围之内就差不多了。

14.2 性能测试流程是怎么样的?

例外一种问法：简单介绍下你们公司的性能测试流程是怎么样的? 我们那个项目的性能做得不多，公司要求也不严格。 对于流程这块，首先就要对整个系统进行详细的分析，确定基本的测试范围，看下系统的哪些业务是 需要做性能测试的，还有就是做那方面的性能测试，对于我们那个项目，当时就做了几个业务做了些 简单的井发压测(稳定性)这块，像登录的，搜索查询，下单，还有就是购物车里面的几个接口都有做 过，然后就是对各个业务场景进行详细的场景分析与设计，确定每个业务场景的并发数，是否需要设 置集合点啊，压测时间是多长，还有各个业务场景的性能指标等等，场景设计这块基本上都是老大跟 产品哪个一起弄的，我参与的不是太多。 上面把个场景设置好了之后，提交给我们，我们就是根据老大设置好的那些场景编写了基本的性能测 试用例，其实做性能测试，我觉得前期最关键的还是业务场景一定要设计好，后期我们主要的任务就 是准备各自任务需要用到的一些测试数据，搭建好测试环境，还有就是测试脚本设计与开发，执行， 并生出测试报告，对于测试结果我们一般会简单的做个分析，如果没有什么问题，基本后期就写一个性能测试报告。流程大概就是这样的。

14.3 你们性能观察哪些指标，大概指标范围是怎么样的。

对于指标这块，业务方面的指标主要有：并发数，90%用户的平均响应时间 错误率，吞吐量/吞吐率这些，例外还需要关注服务器资源的使用情况，像：CPU 的使用率、内存的 占有率，磁盘 IO，网络。 我们那个项目当时只针对，登录，搜索查询，下订单，购物车相关接口，支付等业务做了些简单的并 发，压测这块，指标大概是这样的： 单基准业务并发测试登录，注册，查询 1s 以内，下订单，购物车相关接口，支付 2s 以内，混合业务 性能：5s 以内 响应时间：登录，注册业务<2s 之内查询，下订单，购物车，支付业务<3s 充值，提现，查看充值日志，查看提现日志业务查询标的，<3s 投标，申请借款<5s 错误率：0 吞吐量/吞吐率：200 左右请求/sec CPU：80%以内 内存：80%以内 I/O： %util<=80%，%nowait<=20% %util: 磁盘一秒中有百分之多少的时间用于 I/O 操作， % nowait：磁盘等待处理时间占比 带宽：<=系统带宽的 30%，无丢包，无延迟，无阻塞

14.4 这个测试的环境配置，如转速度

租用的服务器，一台数据库服务器，一台后端服务器 8 核 16G 网络带宽 100M，2.5GHZ 磁盘 15000pm 转数

14.5 性能测试计划有哪些内容

写过，主要是时间进度安排与工作安排，主要是环境，测试任务，测试需求，测试方法与策略，测试 环境准备，测试通过的标准。 比如说原来我们一个项目性能测试时做了 5 天，那我们计划是，测试策略与用例编写一天，测试准备 需要 1 天，测试执行 2 天，报告总结 1 天。

14.6 有没有写过性能测试报告，具体包括哪些内容

性能测试报告，需要每次 Jmeter 压测完成的 html 报告的数据跟 nmon 工具监控的数据，整理出一份 性能测试报告，性能测试报告，主要包含： 1，测试资源(环境，测试数据，表里面需要多少数据，测试工具) 2，测试设计(测试业务，测试类型，测试时间，并发用户数) 3，测试分析(每一个场景都需要分析) 4，测试结论(能不能上线，不上线的原因) 5，优化和建议 6，测试通过的标准，平均响应时间<5s，资源利用率<75%，事务失败率<5%

14.7 什么是内存泄漏，什么是内存溢出？

内存泄漏： 是指程序在申请内存后，无法释放已申请的内存空间，导致系统无法及时回收内存并且分配给其他进 程使用。通常少次数的内存无法及时回收并不会到程序造成什么影响，但是如果在内存本身就比较少 获取多次导致内存无法正常回收时，就会导致内存不够用，最终导致内存溢出。 内存溢出：OOM 1. 指程序申请内存时，没有足够的内存供申请者使用 1M 实际要占用 2M 内存， 就说分配的内存不够，导致内存溢出 2. 给了你一块存储 int 类型数据的存储空间，但是你却存储 long 类型的数据 3. 长期出现内存泄漏，导致系统内存越用越少，最终导致内存不够用，导致系统崩溃，出现 OOM

14.8 吞吐量，吞吐率

吞吐量：KB 指在一次性能测试过程中网络上传输的数据量的总和(单位应该 KB)也可以这样说， 在单次业务中，客户端与服务器端进行的数据交互总量；对交互式应用来说，吞吐量指标反映服务器 承受的压力。 并不是吞吐量越高越高，一个服务器的性能，要从多个方面去考虑： 90%用户的平均响应时间、错误率、吞吐量/吞吐量、CPU、内存、磁盘 I/O、网络的占用情况， 还有服务器的配置。 吞吐率： 吞吐量/传输时间，即单位时间内网络上传输的数据量，也可以指单位时间内处理客户请求数量，它 是衡量网络性能的重要指标。 12s 800M 数 800 * 1024 / 12 = 66666 KB/sec 通常情况下，吞吐率用“字节数秒”来衡量，当然，也可以用“请求数/秒”来衡量;

14.9 吞吐量与吞吐率跟负载有什么关系?

吞吐量/率和负载之间的关系: 1、上升阶段：吞吐量随着负载的增加而增加，吞吐量和负载成正比; 2、平稳阶段：吞吐量随着负载的增加而保持稳定，无太大变化或波动; 3、下降阶段：吞吐量随着负载的增加而下降，吞吐量和负载成反比; 总结：吞吐量/率干不过负载!!！

14.10 当你服务器满了之后，你们吞吐量和响应时间怎么变化的

吞吐量会所有下降，响应时间会变长

14.13 每人说一个项目接口，你设置多少并发

首先涉及到并发用户数可以从以下几个方面去做数据判断 1.系统用户数(注册用户数量) 2.在线用户数(平均每天大概有多少个用户要访问该系统，可以从系统日志从获得) 3.并发用户数(高峰期的时候的在线用户数量) 三者之间的关系 1. 在线用户数的预估可以采取 20%的系统用户数。例如某个系统在系统用户数有 1000，则同时 在线用户数据有可能达到 200，或者预估 200 做参考 2. 在线用户数和并发用户数又存在着关系。即：平均并发用户数为 C=NUTL 为在线时长， T 为考核时长例如考核时长为 1 天，即 8 小时，但是用户平均在线时长为 2 小时，则 c=n2/8 n 为登录系统的用户数，L 为登录的时常，例如一个系统有 400 个用户登录，然后每个用户登录 大概停留 2 小时，则以一天 8 小时考核，算平均并发用户则为 c=400*2/8 答：就拿登录接口来讲吧 我们的并发数是根据注册用户数量及每天在线用户数综合来估算的，我们系统当时注册用户数量 大概是在 70 多万的样子，不过这里其实有一些僵尸用户，真正的用户大概在 60%的样子，也就是差 不多，46 万多一点，通过查看系统访问日志，高峰期的时候每天在线数,用户数量大概差不多在 52000 多点吧，按 52000 估算，每个用户停留时间大概在 20 分钟左右，大概平均每天同时在线用户数量在 2145 多。其中登录业务的占比大概在 10%的样子，同时在登录的大概 80%的比例计算，登录接口大概 设置的并发数在 172 多的样子，查询业务的占比大概在 30%，查询接口大概设置的井发数在 510 的样 子，下单业务大概占比在 20%，下单接口的井发数设定在 345 的样子。 [具体的指标都是 SE 跟测试主管他们经过分析出来给到我们的。他们开会的时候大概跟我们说过估算 方式，差不多是这样的...]

14.14 你们吞吐量是多少，响应时间是多少，你设置了多少井发?

登录：吞吐量大概在 13.5/sec 响应时间<1s，设置的并发数 180 个并发数。 查询：吞吐量大概在 36/sec 响应时间<3s，设置的并发数 500 个并发数。 下单：吞吐量大根在 25.6/sec 响应时间<3s，设置的并发数 350 个并发。

14.15 做井发你们一般 cpu 和内存是多少?

cpu 大概在 60%多点，内存大概占比在 65%的样子。

14.16 有没有做过稳定性测试

部分接口有做过稳定性测试。具体怎么做的? 稳定性测试主要就是看某个业务在高并发情况下是否能持续稳定运行嘛，当时大部分的核心业务都有 做过稳定性的，这个需是把并发数设置为峰值，然后循环次数设置为永远，例外要开启调度器，调度器中的持续时间设定为 3600 秒，让它持续压测 1 个小时。看下接口的各项性能指标的变化，是否在 预期的指标范围之内。

14.17 5000 个人抢购，只能 50 个人能抢到，你怎么设计并发数的

并发数，按群内最大人数计算，利用二八原则，5000 * 80%=4000，并发数的峰值为 4000

14.18 微信群里面发送红包，5000 个人群，只能 3000 个人能抢到，你怎么设计并发数的峰值

并发数，按群内最大人数计算，利用二八原则，5000 * 80%=4000，并发数的峰值为 4000

14.19 20 并发 40 次循环怎么做？

线程数设置 20 个，循环次数 40

14.20 我想从 200 慢慢加载到 300，到 400 怎么做

这个需要用到自定义线程组，自定义线程组最大的好处就在于做压测的时候，可以设置一些复杂的业 务场景，具体设置的话，就是.....

14.21 需要插入 500 条数据，你怎么插入

1、使用存储过程来实现 2、可以通过 JMeter 来实现，调用注册接口，线程数设置为 500，账号，密码可以通过 JMeter 中的 随机函数 randomString()，random()函数结合计数器来实现。

14.22 响应超时，你是怎么定位的

这里一般我会采用排查发，首先考虑软件优化问题，之后考虑硬件问题，思路大概是这样的 1、首先考虑中间件(tomcat，Apache 的连接数的问题)，可以尝试增加连接数，看是否变化。 2、例外还有就是数据库的连接数问可题，也可以尝试增加，看是否有变化。 3、要不就是看数据库的访问效率问题，这里要考虑数据库的操作是否添加索引，如果没有添加索引， 可以让开发优化下数据库的访问速度，添加索引，或者优化 sql 语句。 4、再一个就可以尝试考虑后台代码的架构设计是否合理，代码算法是否足够优化。 5、如果以上问题都不能解决，那么只能考虑增加服务器的 CPU 内存，或者增加网络带宽，看响应时 间是否可以得到优化。 大概的思路差不多就是这样的吧。

14.23 压测返回数据报错，你怎么去定位的

1、如果是所有请求的数据报错，那肯定是脚本问题，认真检查脚本参数。 华测教育专属 华测教育专属 华测教育专属 华测教育专属 华测教育专属 华测教育专属 华测教育专属 华测教育专属 华测教育专属 68 2、如果只是部分请求报错，那估计是性能可题了。

14.24 你理解的性能调优是什么?

响应时间过长(排除法) -用户体验不好 1，网络情况(提升带宽) 2，服务器资源情况 3，中间件类型 4，中间件的连接数 5，代码质量问题 6，数据库类型 mysql--Redis 7，数据库连接数 8，sql 语句执行时间 show full PROCESSLIST 查看哪些 sql 语句运行比慢 1、看表是否建立索引 2、运行 sql 语句是否需要 sq 优化 9，索引命中率 低于 0.1%比较好，低于 0.01%分配比校多，适当减少缓存空间大小 show GLOBAL STATUS like "key——read%" Key_reads=568 Key_read_requests=1329114 Key_cache_miss_rate=key_reads/key_read_requests=0.000427=0.04% show VARIABLES like "key_buffer_size" #查看缓存空间大小 set GLOBAL key_buffer_size=8000000 #设置缓存空间大小 10，sleep 过多 show GLOBAL VARIABLES like "wait timeout%" show GLOBAL VARIABLES like "interactive timeout%" set GLOBAL interactive_timeout= 30 set GLOBAL wait_timeout=30 11，临时表空间大小 性能排优一些方面： 1，排除法 2，很多问题，都是同一个问题导致，需要一个个去排除优化，解决  资源使用率不足：(系统薄弱的位置) 1，用户量较少 2，网络问题 3，中间件连接数不够 4，代码质量问题 5，数据库问题 资源使用率过高：(系统会崩溃) 1，用户量比较大 2，中间件连接数太大 3，代码质量问题 4，数据库问题

14.25 如果要做万并发，你怎么做

那我们就需要考虑分布式压测，那需要准备几台测试机， master 机器要设置。。。。 奴隶机要设置。。。。。 也可以租用云测平台进行测试

14.26 如果用户并发要慢慢加载，你怎么设置的

设置并发数的时候，我们会设置启动时间，比如说设置 50 个并发用户数就是 50 个线程组， 启动时间会设置成 10 秒，让用户慢慢启动起来

14.27 并发用户数跟响应时间与吞吐的关系

1，并发用户数越多，响应时间越长 2，并发用户数越多，吞吐量会一直，增加，增加到一个临界点(系统瓶颈后)，不再增加，有少许的 回落

行动吧，在路上总比一直观望的要好，未来的你肯定会感 谢现在拼搏的自己！如果想学习提升找不到资料，没人答疑解惑时，请及时加入扣群： 320231853，里面有各种软件测试+开发资料和技术可以一起交流学习哦。

最后感谢每一个认真阅读我文章的人，礼尚往来总是要有的，虽然不是什么很值钱的东西，如果你用得到的话可以直接拿走：

这些资料，对于【软件测试】的朋友来说应该是最全面最完整的备战仓库，这个仓库也陪伴上万个测试工程师们走过最艰难的路程，希望也能帮助到你！