当前位置:   article > 正文

45 道性能测试面试题,助力你拿下性能测试面试

性能测试面试题

面试宝典之性能安全测试

最贴近企业真实面试,每个问题都有口语化,但是这是大师兄口语化风格,还需准备成自己的面试语言


很多小伙伴都有一个误区:找不到工作是因为自己技术不行,其实,技术只占比40%,更多原因在于你不会面试。

所以,我整理了近 1.5 万字,共收集了 45 多道常见性能安全测试面试题,而且全部免费分享。

如果,你需要面试技巧专项训练,面试不止是宝典,更多是面试技巧。


第7部分:性能安全测试(共计45道)

性能安全测试,绝对是你的加分项,这一块很考验我们的学习和操作能力


1. 请解释性能测试、负载测试和压力测试的关系和区别?

回答思路: 需要先弄明白,三者的概念,然后总结三者的区别作为自己的面试语言

大师兄这样说:

  1. 性能测试、负载测试和压力测试都是用来测试软件系统的不同方面。性能测试是看看系统在正常情况下的表现,负载测试是测试系统在模拟真实负载下的表现,而压力测试则是测试系统在极端情况下的表现。简单来说,性能测试是看系统在正常情况下的表现,负载测试是看系统在有压力情况下的表现,压力测试是看系统在极端情况下的表现。

2. 在你之的得项目中,通常用哪些工具来进行性能测试?

回答思路: 可以先列出性能测试工具,然后细说其中一种工具即可

大师兄这样说:

在做性能测试时,我们主要使用的工具是JMeterLoadRunner。但是,在我之前的项目中,我们通常会选择使用JMeter工具。

选用JMeter做性能测试的话,我觉得它有 4 个好处:

  1. 它是个开源工具,免费使用,功能强大,扩展性也很好;

  2. JMeter能在多种平台上运行,不管是WindowsLinux还是Mac OS,都能用;

  3. JMeter挺容易上手的,而且支持多种协议和测试类型;

  4. JMeter的扩展性很好,可以通过插件和自定义脚本满足不同的性能测试需求。


3. 你认为性能测试工作的目的是什么?以及性能测试工作的关键是什么?

回答思路: 明白性能测试的目的,并把整个性能测试流程中的重要步骤总结成自己的面试语言

大师兄这样说:

  1. 我认为性能测试的目的主要是为了确保软件系统在高负载和大量用户的情况下,能够表现出良好的性能和稳定性。通过性能测试,我们可以模拟实际用户场景和负载,对系统进行压力测试,发现系统中的性能瓶颈和潜在的问题,并及时解决它们,以确保系统在各种负载下能够表现得更好、更稳定;

  2. 此外,性能测试还可以帮助开发人员优化系统的性能,提供有关系统性能的数据和指标,以便进行系统的优化和改进。所以,性能测试对于软件系统的开发和维护来说真的是非常重要的;

  3. 总之,做性能测试关键在于:

    • 要确定性能测试的目标,比如明确要测试哪个系统、测试的时间、测试的环境等等;

    • 设计并编写测试用例,包括输入数据、预期结果、测试场景等等;

    • 选择合适的性能测试工具,例如:JMeterLoadRunner等等;

    • 执行性能测试,记录测试结果和数据;

    • 分析性能测试结果,找出系统中的性能瓶颈和问题,提出优化建议和解决方案;

    • 重复执行性能测试,确保系统的性能和稳定性得到了改善。


4. 请列举你曾做过的性能测试项目,包括被项目环境搭建、测试数据准备和性能测试工具?

回答思路: 如果自己非常熟悉,就以自己为主导,否则,就以帮手来说

大师兄这样说:

  1. 我之前没有从零开始做过性能测试,大概半年前,我参与了一个有性能测试需求的项目。我们组长是主要负责的人,我们一起选择了5台云服务器、一台测试机、一台前端服务器、一台后端服务器和两台数据库,因为我们对数据库做了主从配置;

  2. 在工具方面,我选择使用JMeter来进行性能测试,因为我对它比较熟悉。性能测试场景和脚本主要由组长安排,我来完成。我们使用JMeter来模拟多个用户并发访问Web应用程序,测试系统的响应速度和稳定性;

  3. 在测试数据准备方面,我们准备了大量数据,特别是相关表,我使用存储过程来初始化这些数据,达到了千万级别的规模。我们确保测试数据的质量和真实性,以便更好地模拟实际用户的行为和负载。


5. 你们所进行的性能测试是针对前台还是后台?

回答思路: 其实,前台和后台都可以,但是,主要还是考察的后台服务器并发能力

大师兄这样说:

  1. 我们的性能测试主要是以后端为主,主要是给服务器施压。因为后端服务器的性能和稳定性对整个系统的性能和用户体验有着至关重要的影响;

  2. 在测试后端性能时,我们会使用工具来模拟高并发场景,给服务器施加大量的负载。我们会关注系统的吞吐量、处理器利用率、内存使用率等指标,以评估后端服务的性能和稳定性;

  3. 同时,我们还会测试数据库的性能,包括查询速度、并发访问能力等。我们会使用工具来模拟高并发场景,测试数据库的性能和扩展性。


6. 如何对性能测试需求进行分析和评估?

回答思路: 需考虑应用性质、用户行为需求、系统性能指标和测试目标,来分析性能需求,然后总结成自己的面试语言

大师兄这样说:

  1. 性能测试需求的分析和评估是一个非常重要的过程,需要仔细考虑并认真评估。首先,我们需要确认性能测试需求是否符合标准,并且能够被实现。如果你看到的第一版性能测试需求要求所有响应时间都小于 30 毫秒,那么这个要求就非常不合理。对于一个普通的APP来说,1000 毫秒已经是非常不错的响应时间了。

  2. 在进行性能测试需求的分析和评估时,我们需要考虑以下几个因素:

    • 应用程序的性质和用途:不同的应用程序有不同的性能要求,我们需要根据应用程序的性质和用途来评估性能测试需求是否合理;

    • 用户的行为和需求:我们需要了解用户的行为和需求,以便确定应用程序的性能要求。例如,对于一个在线购物网站来说,用户更关注的是购物的流畅性和快速性,而不是应用程序的响应时间;

    • 系统的性能指标:我们需要了解系统的性能指标,例如系统处理能力、内存使用情况、网络带宽等,以便确定应用程序的性能要求;

    • 性能测试的目标:我们需要明确性能测试的目标,例如确定应用程序能否支持预期的用户负载、发现性能瓶颈等,以便制定合理的性能测试需求;

  3. 总之,在进行性能测试需求的分析和评估时,我们需要综合考虑多个因素。


7. 如何确定并发用户数?

回答思路: 结合下面的算法来举例说明最好,如果不能举例说明,就按照大师兄的说法

  1. **用户并发数指标:**并发用户数的定义是每秒同时向服务器提交请求的用户总数量

    • n: 平均每天的访问用户数(日活)

    • L: 一天内用户从登录到退出的平均时间(平均用户使用时长)

    • T: 考察时间长度(每天多长时间有用户在使用系统)

  2. 先确定 n、L、T

    • n: 项目预估运行一年日活:10 w;
    • L: 用户平均使用时长是:10 min;
    • T: 用户每天活跃时间大约是从早上 10 点到晚上 10 点。
  3. 平均并发 = 100000 * 10 / 12 ≈ 83333.33 人/分钟 ≈ 1388 人/秒

  4. 峰值并发 ≈ 1500 人/秒

大师兄这样说:

  1. 确定并发用户数需要考虑系统用户数、在线用户数和并发用户数之间的关系,以及系统的高峰期和日常流量等情况。并发用户数不是随便确定的,需要根据系统实际情况进行数据分析和估算,一般采用经验公式或通用公式进行计算;

  2. 同时,还需要考虑系统性能指标和用户行为需求等因素,以确保系统能够支持预期的并发用户数。


8. 常见的性能测试指标有哪些?

回答思路: 可根据常见性能指标的作用来总结成自己的面试语言

大师兄这样说:

  1. 响应时间:指系统对请求做出响应的时间,通常以毫秒或秒为单位测量;

  2. 吞吐量:指系统处理请求的速率,通常以每秒处理的请求数或每秒处理的页面数为单位测量;

  3. 并发用户数:指同时发起请求的用户数量,通常用于评估系统的并发处理能力;

  4. 带宽:指系统传输数据的速率,通常以比特或字节为单位测量;

  5. CPU使用率:指系统CPU的利用率,通常以百分比表示;

  6. 内存使用率:指系统内存的利用率,通常以百分比表示;

这些指标可以帮助我们评估系统的性能表现,发现性能瓶颈和优化空间,为系统的优化和升级提供参考。在性能测试过程中,我们通常会记录这些指标的数据,并进行分析和比较,以确定系统的性能表现和需要改进的地方。


9. 性能测试中常见的性能问题有哪些?

回答思路: 其实,这个问题以上一个问题类似,就是指标不符合要求的情况

大师兄这样说:

  1. 响应时间过长:指系统对请求做出响应的时间过长,导致用户等待时间增加。例如,一个网页的响应时间超过3秒,用户可能会失去耐心并离开该网页;

  2. 吞吐量过低:指系统处理请求的速率过低,导致系统无法满足用户需求。例如,一个网站的每秒处理页面数过低,用户可能需要等待较长时间才能加载页面;

  3. 延迟过高:指系统处理请求的延迟时间过长,导致用户等待时间增加。例如,一个API的延迟时间超过 200 毫秒,可能会导致应用程序响应缓慢;

  4. 带宽不足:指系统传输数据的速率过低,导致系统无法满足用户需求。例如,一个视频网站的带宽不足,可能会导致视频播放卡顿或无法加载;

  5. CPU使用率过高或过低:指系统CPU的利用率过高或过低,导致系统处理能力不足或浪费。例如,一个数据库的CPU使用率过高,可能会导致数据库性能下降;

  6. 内存使用率过高或过低:指系统内存的利用率过高或过低,导致系统处理能力不足或浪费。例如,一个服务器的内存使用率过高,可能会导致服务器崩溃或无法满足用户需求。


10. 请简述性能测试的基本流程和关键步骤?

回答思路: 把性能测试基本流程总结出来,然后总结其关键步骤,最后编程自己的面试语言

大师兄这样说: 性能测试的基本流程,大致可以分为 6 步

  1. 需求分析:了解系统性能需求和目标,确定性能测试的目标和测试范围;

  2. 测试准备:准备测试环境、测试数据和测试工具,确保测试所需的硬件、软件和网络环境等条件满足测试要求;

  3. 测试设计:根据性能测试需求和目标,设计测试用例和测试场景,包括并发用户数、负载类型、测试时间和测试目标等;

  4. 测试执行:运行测试用例和测试场景,记录测试数据和结果,包括响应时间、吞吐量、并发用户数和错误率等;

  5. 测试分析:对测试数据和结果进行分析和评估,判断系统性能是否满足要求,发现性能瓶颈和优化空间;

  6. 报告编写:根据测试数据和结果,编写性能测试报告,包括测试环境、测试数据、测试结果和分析结论等;

在性能测试的基本流程中,最关键的步骤是测试设计、测试执行和测试分析。测试设计阶段需要根据性能需求和目标设计合理的测试用例和测试场景,确保测试覆盖全面且具有代表性。测试执行阶段需要确保测试用例和测试场景的正确性和可重复性,同时记录完整的测试数据和结果。测试分析阶段需要对测试数据和结果进行深入的分析和评估,发现性能问题并确定优化方向。最后,报告编写阶段需要将测试结果和分析结论整理成清晰易懂的报告,为系统的优化和升级提供参考。


11. 你们的性能测试在哪个环境中执行?

回答思路: 不同的项目不同的企业都有所区别,比如:大师兄之前做的性能测试,就是直接模拟生产环境进行性能测试

大师兄这样说:

  1. 我们的性能测试会在不同的环境中进行执行,具体情况取决于测试的需求和目标。通常来说,我们会在开发环境中进行初步的性能测试,确保系统的基本性能符合预期。

  2. 接着,我们会在测试环境中进行更全面的性能测试,评估系统的真实性能表现。

  3. 如果需要模拟生产环境中的压力和负载,我们还会在模拟生产环境中进行针对性的性能测试。总之,我们会根据具体的测试需求和目标,选择合适的环境进行性能测试,以确保测试结果的准确性和有效性。


12. 你们通常在哪个时间段进行性能测试?

回答思路: 这个问题很简单,就是什么时间开始做性能测试

大师兄这样说:

  1. 性能测试通常在系统的开发阶段末期或上线前进行。在这个阶段,系统已经基本开发完成,需要进行全面的测试来确保系统的稳定性和性能;

  2. 性能测试可以发现系统中的性能瓶颈和问题,帮助开发人员及时修复,从而提高系统的性能和稳定性。


13. 如何评估系统的性能表现?

大师兄这样说:

  1. 评估系统的性能表现,可以通过一系列的测试和数据分析来进行,比如:我们可以通过响应时间来评估系统对请求的响应速度,看看系统能不能快速响应我们的操作;

  2. 通过吞吐量来评估系统处理请求的能力,看看系统能不能承受大量的请求的压力;

  3. 通过并发用户来评估系统同时处理多个用户请求的能力,看看系统能不能同时处理多个用户的操作;

  4. 通过资源利用率来评估系统各种资源的利用率,看看系统各种资源是否得到了充分的利用;

  5. 通过错误率来评估系统在处理请求时的错误率,看看系统有没有出现什么错误。


14. 假如一个网站需要满足 1 万并发访问,具体思路和实现步骤?

回答思路: 一个网站满足上万的并发测试,我们需要从测试需求、测试环境、性能指标三个方面来分析

大师兄这样说:

  1. 我们需要知道网站需要在什么样的环境下进行测试,以及测试的具体目标是什么。比如,我们想要测试网站在现实生活中的性能表现,就需要模拟真实的用户访问场景和负载;

  2. 我们需要根据测试目标和测试工具,准备相应的测试数据和负载,包括用户访问的流量、请求的类型和数量等。可以想象一下,一万人同时访问网站会给服务器带来多少压力,我们需要根据实际情况来准备好测试数据和负载;

  3. 我们需要根据测试目标和测试工具,搭建相应的测试环境,包括服务器、网络和负载均衡等。可以想象一下,一万人同时访问网站需要的服务器和网络资源,需要好好规划和准备;

  4. 根据测试计划和测试数据,执行并发访问测试,并监控测试结果,包括响应时间、吞吐量、错误率等。可以进行实际用户访问的模拟测试,以评估网站的性能表现;

  5. 根据测试结果进行分析和评估,包括系统的性能表现、瓶颈和问题等,并制定相应的优化方案和改进措施。可以根据测试结果找出网站的瓶颈和问题,比如服务器响应慢、数据库查询效率低下等,然后制定相应的优化方案和改进措施。


15. 如何找性能测试的最佳平衡点?

回答思路: 找性能测试的最佳平衡点需要考虑多个因素,在满足性能需求指标的同时,从成本和适用上来总结成自己的面试语言

大师兄这样说:

  1. 我会尽可能多地做不同并发数下的压力测试,记录下响应时间和最大TPS,同时确保服务器资源利用率在可接受范围内(不同公司不同项目可能不一样,一般80%左右都能接受);

  2. 根据获取到的不同并发下的指标数据,如:并发数、TPS、响应时间三大指标,我们可以分析:要求响应时间 1 秒以内,并发数要尽可能的多,TPS要尽可能的大,这就是最佳平衡点;

  3. 另外,如果使用JMeter作为并发工具,可以在并发过程中增加或减少并发用户数,而不必压完一次再调整并发数,但是在进行调整时,需要确保JMeter的并发过程已经稳定运行了 30 分钟以上,以保证获取的数据准确。


16. 如何识别系统性能瓶颈并进行优化?

回答思路: 可以先叙说性能瓶颈的判断标准,然后再进行优化,把这个过程整理成自己的面试语言

大师兄这样说:

  1. 当观察系统的TPS指标时,我们可以分析随着用户数的增长,系统每秒可处理的事务数是否也会增长。如果系统的TPS指标随着用户数的增长而增长,说明系统的性能不错,能够处理更多的用户请求。如果TPS指标没有增长或者增长缓慢,说明系统存在性能瓶颈,需要想办法进行优化;

  2. 为了分析TPS指标,我们需要进行压力测试,模拟不同用户数的情况,观察系统的性能表现。通过压力测试,我们可以了解到系统在不同负载下的TPS指标,并且可以找到系统的性能瓶颈;

  3. 在压力测试过程中,我们需要确保测试数据和负载模拟的真实性和可靠性。同时,还需要关注服务器的资源使用情况,确保服务器不会因为测试而崩溃;

  4. 当找到系统的性能瓶颈后,我们需要采取相应的优化措施。优化措施包括但不限于优化代码、升级硬件、优化数据库等。具体实施优化措施需要根据实际情况而定,不同的系统有不同的优化方案;

  5. 在实施优化措施后,我们需要再次进行压力测试,验证优化效果。如果优化措施有效,TPS指标应该会有明显的提升。如果优化措施效果不明显,我们需要进一步分析性能瓶颈的原因,并采取更高级别的优化措施;

  6. 总之,通过分析TPS指标,我们可以了解系统的性能状况,找到系统的性能瓶颈,并采取相应的优化措施,提高系统的性能和稳定性。在优化过程中,需要综合考虑多种因素,包括服务器配置、网络带宽、应用程序代码等,以达到最佳的优化效果。


17. 如何有效地监控 MySQL 数据库服务器的性能情况?

回答思路: 结合性能监控工具和慢查询来总结成自己的面试语言

大师兄这样说:

  1. 使用第三方性能监控工具Zabbix,它可以提供实时监控和数据报告功能,让我们随时了解MySQL的运行状态和连接信息;

  2. 收集MySQL错误日志和慢查询日志,这些日志可以告诉我们系统中出现的错误和慢查询信息,帮助我们找到性能问题的根源。


18. 在进行性能测试时,如何判断网络是否存在瓶颈?

回答思路: 一般影响网络的主要因素有:网络延迟、网络丢包率和网络负载等因素,把这三点总结成自己的面试语言即可

大师兄这样说:

  1. 首先,我们可以使用网络监测工具来测量网络延迟和单向延迟,看看网络是否畅通无阻;

  2. 然后,我们可以使用网络监测工具来测量网络丢包率,看看网络是否稳定;

  3. 最后,我们还要注意网络负载是否过高,如果网络负载过高,可能会导致网络拥塞和延迟,影响性能测试结果。


19. 进行性能测试时,应该考虑哪些因素?

回答思路: 考虑的主要因素有:测试环境、业务压力和典型场景,结合这 3 点来总结成自己的面试语言

大师兄这样说:

  1. 我们要确保测试环境与实际生产环境相似,包括硬件、软件、网络等环境因素,这样才能得到更真实的结果;

  2. 我们要考虑系统的实际业务压力,比如并发用户数、交易量、数据量等,以便模拟实际场景进行测试;

  3. 我们还要针对系统的典型场景进行测试,如高峰期、低谷期、批量处理等场景,以评估系统在不同场景下的性能表现。


20. 描述一下,不同角色各自关注的性能要点。比如:开发人员、测试人员、运维人员?

回答思路: 结合项目不同的角色来总结成自己的面试语言

大师兄这样说:

  1. 开发人员关心系统的响应速度和稳定性,他们要确保系统能够快速响应用户请求,在高负载情况下也能保持稳定运行;

  2. 测试人员关注系统的性能指标和测试结果,他们会收集系统的性能数据,比如响应时间、吞吐量、并发用户数等,并分析这些数据来发现系统存在的性能问题;

  3. 运维人员关注系统的资源使用情况和可扩展性,他们要确保系统在运行过程中充分利用硬件和软件资源,并在需求增加时快速扩展系统;

  4. 总之,不同角色在性能测试中关注的性能要点不同,但他们的目标都是确保系统能够满足用户需求,提高系统的性能和稳定性。


21. 在性能测试中,如果 TPS(每秒事务数)较低,可能是哪些方面的问题?

回答思路: TPS较低可能是由多个因素导致,把几个重要的方面总结成自己的面试语言

大师兄这样说:

  1. 应用程序的代码可能存在一些问题,导致事务处理速度变慢。比如说,代码中存在慢查询、死循环或者内存泄漏等问题,都会影响到应用的性能;

  2. 系统的硬件资源可能不足,比如CPU占用过高、内存不足或者磁盘IO过高等等,这些都会影响到系统的性能,使得事务处理速度变慢;

  3. 网络延迟可能会影响到应用程序的性能,例如网络传输延迟、DNS解析时间过长等等,这些都会导致事务处理速度变慢;

  4. 总之,,我们需要针对不同的情况进行具体的分析和优化。


22. 系统瓶颈具体指的是什么,如何确定系统瓶颈问题?

回答思路: 首先,我们要知道什么是瓶颈,知道如何确认瓶颈即可

大师兄这样说:

  1. 系统瓶颈指的是整个系统中的某个环节,由于性能问题或资源限制,成为了整个系统的瓶颈,即限制了系统的整体性能。比如说,系统硬件资源不足、网络传输速度慢、数据库负载过高、应用程序配置不当等因素都可能导致系统瓶颈;

  2. 在性能测试中,如果系统的每秒事务数较低,我们可以通过压力测试等手段找到系统的性能瓶颈,进而进行优化和解决。优化系统瓶颈可以提高系统的性能和稳定性,让系统更好地满足用户的需求。


23. 如果被测系统没有带界面的客户端,应如何进行性能测试?

回答思路: 其实性能测试,更多测试的是服务器性能,可以通过接口场景来进行性能测试

大师兄这样说:

  1. 进行无界面性能测试,可以测试服务器接口。通过编写测试脚本,模拟不同的请求负载、并发用户数或数据量等,来测试系统的性能表现。同时,需要特别注CPU、内存资源使用情况和网络延迟等因素。

24. 如何判断是否存在内存泄漏问题,需要关注哪些指标?

回答思路: 主要考察CPU和内存,通过这 2 点总结成自己的面试语言

大师兄这样说:

  1. 如果进程实际占用的物理内存持续“上涨”,可能存在内存泄漏问题;

  2. 如果系统的CPU“占用率”持续高居不下,可能存在内存泄漏问题,因为内存泄漏会导致程序运行变慢。


25. 一份合格的性能测试报告应包含哪些主要内容?

回答思路: 如果写过测试报告,那么这个问题很好总结,如果,没写过测试报告,可以挑重点内容并总结成自己的面试语言

大师兄这样说:

  1. 测试目标和目的:明确性能测试的目标是什么,想要达到什么目的,以及测试的环境和范围;

  2. 系统架构:描述系统的硬件和软件环境,包括服务器、网络、数据库等组成部分,让读者对系统有个整体了解;

  3. 性能指标:列出测试中关注的关键性能指标,比如系统响应时间、每秒处理的事务数、CPU使用率、内存使用率等;

  4. 测试结果:展示测试的结果,包括每个性能指标的实际数据,以及与预期目标的对比分析,让读者了解系统的实际性能表现;

  5. 问题分析:对测试中发现的性能问题进行详细分析,包括问题的原因、影响和解决方案,让读者了解性能问题的具体情况和如何解决;

  6. 测试结论:总结测试的结果和分析,提出性能优化建议和下一步的改进计划,让读者了解性能测试的意义和下一步的改进方向;

  7. 附件:包括测试脚本、测试数据和截图等附加信息,让读者更好地理解测试报告的内容,如果有疑问可以随时查看。


26. 应用服务器和数据库服务器的 CPU 过高,应该从哪些方面分析并寻找解决方案?

回答思路:CPU使用过高,一般指超过 80% 以上

大师兄这样说:

  1. 当很多人同时访问应用服务器或数据库服务器时,服务器需要处理更多的任务,导致CPU使用率增加。这种情况通常发生在高峰期或系统负载过重时。为了解决这个问题,可以增加服务器硬件资源,如:增加CPU或内存,或者使用服务器的负载均衡配置;

  2. 如果数据库查询语句没有优化好,会导致查询速度变慢,同时也会增加CPU的使用率。为了解决这个问题,可以对数据库查询语句进行优化,例如:使用索引、优化查询语句的效率等;

  3. 如果系统资源不足,例如:内存、宽带等。为了解决这个问题,可以增加系统资源,例如:增加内存、网络带宽等。


27. 在性能测试中如何计算和评估 TPS?

回答思路: 这个问题其实很复杂,评估涉及到的原因很多,实在不会回答这个问题,可以这样回答:

具体计算方法和公式,我记不太清楚,一般TPS标准有:

  1. 电子商务网站:需要处理大量客户请求,所以需要高速运行和快速响应。这种场景下的TPS标准是 1 万到 10 万;

  2. 中型网站:规模中等,需要处理的事务数量也还可以。这种场景下的TPS标准是 100 到 500;

  3. 小型网站:比较小,处理的事务不太多。这种场景下的TPS标准是 50 到 100。

大师兄这样说:

  1. TPS是指事务数/秒。即一个事务是指服务器发送请求,服务器做出反应的过程;

  2. 整体过程就是:用户做出操作 > 请求服务器 > 服务器处理 > 服务器处理完成返回到用户;

  3. 每秒能完成多少个流程就是多少个TPS,简单理解:就是登录一次算一个事务,每秒能完成2个登录事务,就是 2 个TPS

  4. 想要计算TPS,首先要先知道系统的并发用户数和平均响应时间,因为:TPS = 并发用户数 / 平均响应时间;

  5. 一般TPS标准有:

    • 电子商务网站:需要处理大量客户请求,所以需要高速运行和快速响应。这种场景下的TPS标准是 1 万到 10 万;

    • 中型网站:需要处理的事务数量也还可以。这种场景下的TPS标准是 100 到 500;

    • 小型网站:处理的事务不太多。这种场景下的TPS标准是 50 到 100。


28. 解释下什么是吞吐量?

回答思路: 吞吐量的量化指标有:TPS(每秒事务数)、QPS(每秒查询数)

大师兄这样说:

  1. 吞吐量是指系统每秒钟能处理的请求数量,也就是系统处理请求的能力。这种能力可以用TPSQPS这两个指标来量化;

  2. TPS是指服务器每秒钟能够处理的事务数,一个事务是指服务器发送请求并做出反应的过程。简单来说,就是每秒能完成多少个登录事务,比如每秒能完成 2 个登录事务,就是 2 个TPS

  3. QPS是指服务器每秒钟能够响应的查询次数,所以,TPS并不等于QPS


29. 响应时间和吞吐量之间的关系是什么?

**回答思路:**通过两者的概念,以及相互之间的平衡关系来总结成自己的面试语言

大师兄这样说:

  1. 响应时间是指系统对请求的响应速度,也就是系统回应用户请求所需要的时间。响应时间越短,说明系统响应速度越快,用户等待的时间就越少;

  2. 吞吐量是指系统每秒钟处理的请求数量,也就是系统处理请求的能力。吞吐量越高,说明系统能够处理更多的请求,能够满足更多的用户需求;

  3. 在一般情况下,响应时间越短,吞吐量就越高。因为系统处理请求的速度更快,每秒钟能够处理的请求数量就更多。但是,在某些情况下,如果响应时间过短,可能会导致系统处理能力下降,从而降低吞吐量;

  4. 因此,需要在响应时间和吞吐量之间进行平衡,以达到最佳的系统性能。


30. 对于Web系统的响应时间,行业中被广泛认可的用户可以接受的时间是多少秒?

回答思路: 通过下图就已经一目了然了

大师兄这样说:

  1. 在很久以前,一般遵循2 - 5 - 10原则,随着时代变化,硬件、网络都更新换代,响应时间也有了新的标准1 - 3 - 5

  2. 简单一点来说:即1 s内用户完全可以接受,3s内用户觉得还可以,5s用户就会开始焦躁不安。


31. 并发用户数是什么?它与在线用户数有何关系?在性能测试中如何确定并发用户数?

**回答思路:**这个问题与第 7 个问题类似

  1. **用户并发数指标:**并发用户数的定义是每秒同时向服务器提交请求的用户总数量

    • n: 平均每天的访问用户数(日活)

    • L: 一天内用户从登录到退出的平均时间(平均用户使用时长)

    • T: 考察时间长度(每天多长时间有用户在使用系统)

  2. 先确定 n、L、T

    • n: 项目预估运行一年日活:10 w;
    • L: 用户平均使用时长是:10 min;
    • T: 用户每天活跃时间大约是从早上 10 点到晚上 10 点。
  3. 平均并发 = 100000 * 10 / 12 ≈ 83333.33 人/分钟 ≈ 1388 人/秒

  4. 峰值并发 ≈ 1500 人/秒

大师兄这样说:

  1. 确定并发用户数需要考虑系统用户数、在线用户数和并发用户数之间的关系,以及系统的高峰期和日常流量等情况。并发用户数不是随便确定的,需要根据系统实际情况进行数据分析和估算,一般采用经验公式或通用公式进行计算;

  2. 同时,还需要考虑系统性能指标和用户行为需求等因素,以确保系统能够支持预期的并发用户数。


32. 你如何设计性能测试用例?

回答思路: 只要是测试用例,性能测试用例也不例外,基本包含信息都类似

大师兄这样说:

  1. 明确想要测试的性能指标,比如系统响应时间、并发用户数、系统稳定性等;

  2. 设计不同类型的数据,比如正常数据、异常数据、大规模数据等,以测试系统在不同情况下的性能表现;

  3. 设计不同的测试负载,比如轻载、重载、超载等,以测试系统的性能极限;

  4. 确定详细的测试步骤,包括测试前的准备、测试执行、测试结果记录等;

  5. 根据测试目标和测试数据,预期系统的性能表现和测试结果。


33. 通过 JMeter 如何做性能测试?

回答思路: 使用JMeter做性能基本步骤与接口测试类型

大师兄这样说:

  1. 确定要测试的目标和范围,并准备相应的测试数据和场景。例如:如果要测试一个项目的性能,需要准备不同类型的用户操作,如登录、搜索、添加到购物车、结账等场景;

  2. JMeter中创建一个测试计划,并添加线程组。如果需要模拟 500 个并发用户,可以在线程组中添加 500 个线程;

  3. 运行测试计划,并逐步增加并发用户数量,观察系统的响应时间和吞吐量等指标。通过分析这些指标,可以了解系统在不同负载下的性能表现;

  4. 对测试结果进行分析,找到系统性能的瓶颈和问题。例如:可能会发现数据库查询速度较慢,或者服务器资源不足等问题;

  5. 根据测试结果和分析,对系统进行性能优化。例如,可以增加服务器资源、优化数据库查询、调整应用程序代码等。这些优化措施可以提高系统的性能和稳定性。


34. 详细解释一下 JMeter 的聚合报告的内容

回答思路: 聚合报告中,包含的内容有:

  1. Label:请求的名称,即脚本中Sampler的名称;

  2. #Samples(样本):总共发给服务器的请求数量。如果模拟 10 个用户,每个用户迭代 10 次,那么总的请求数为:10 * 10 = 100 次;

  3. Average(平均值):Request的平均响应时间;

  4. Median(中位数):50% 用户的响应时间小于该值;

  5. 90% Line(90% 百分位):90% 用户的响应时间小于该值;

  6. 95% Line(95% 百分位):95% 用户的响应时间小于该值;

  7. 99% Line(99% 百分位):99% 用户的响应时间小于该值;

  8. Min(最小值):最小的响应时间;

  9. Maximum(最大值):最大的响应时间;

  10. Error%(异常%):错误率等于错误请求的数量与请求的总数的比值;

  11. Throughput(吞吐量):默认情况下表示每秒完成的请求数;

  12. Received KB/sec (接收数据):每秒从服务器端接收到的数据量;

  13. Sent KB/sec(发送):每秒发送到服务器端的数据量。

大师兄这样说:

JMeter的聚合报告,是一份汇总了所有请求的统计信息的报告,包括请求数、成功数、失败数、平均响应时间、90% 响应时间、95% 响应时间、99% 响应时间、吞吐量等等。通过这份报告,我们可以快速了解整个测试过程中的性能表现,帮助我们分析系统的瓶颈和问题,并进行性能优化。


35. 对于一个缺乏性能明确需求的项目,你如何提取性能需求的?

回答思路: 主要从性能指标和测试场景来提取需求,把这个提取的过程举例说明即可

大师兄这样说:

  1. 系统整体性能需求提取,可以根据项目未来一段时间的用户数来扩充,比如:

    • 支持注册用户 100 万;

    • 如稳定性测试:7×24 小时等;

    • 平均响应时间:页面打开时间低于2秒;

    • CPU利用率:CPU使用率小于 75%。

  2. 不同功能/接口性能需求:

    • 高频:系统中高频率使用的功能,高频调用的接口,如刷动态;

    • 关键:系统中不能出现问题的功能,如登录、注册、支付;

    • 涉及大量数据:如报表查询。

  3. 在制定性能需求时,需要综合考虑系统的实际情况和用户需求,确保性能指标的合理性和可实现性。同时,根据不同功能和接口的重要性,可以对不同的功能和接口提出不同的性能需求,以满足系统性能的平衡和稳定运行。


36. 一个项目性能不能满足要求,应该从哪些方面去优化?

回答思路: 可以从响应时间、服务器资源、稳定性和可靠性来总结成自己的面试语言

大师兄这样说:

  1. 为了优化响应时间,可以采取以下措施:

    • 优化数据库查询语句,减少查询次数和查询时间;

    • 使用缓存技术,缓存常用数据和结果,减少数据库访问次数;

    • 优化服务器端程序逻辑,提高处理速度;

    • 使用负载均衡技术,将请求分担到多个服务器上,提高处理能力。

  2. 为了优化服务器端的处理速度,可以采取以下措施:

    • 升级服务器硬件配置,增加CPU、内存、磁盘等资源;

    • 优化服务器端程序逻辑,提高处理速度。

  3. 此外,为了确保系统的稳定性和可靠性,还需要考虑以下因素:

    • 考察系统能否支撑 7 x 24 小时运转,确保系统能够持续运行;

    • 考察内存资源、线程资源能否正常回收,避免内存泄漏和线程泄漏。


37. 线程数是压的越多越好吗?压到多少线程合理?

回答思路: 这个问题很好回答,首先答案是否定的,然后,把否定的原因总结成自己的面试语言

大师兄这样说:

  1. 线程数在压力测试中是非常重要的参数,与之关系,CPU和内存影响比较大,肯定不是压得越多越好。

  2. 举个栗子:如果,服务器只能处理 100 个请求每秒,那么,在使用JMeter进行压力测试时,我的建议不要超过 500 线程,默认从 100 线程开始施压,然后根据实际处理能力来调整线程数大小。一步步增加来查看CPU和内存,直到超出性能指标。


38. 你如何分析性能测试结果?

回答思路: 性能测试结果指的是:测试完成后拿到的测试数据,主要是对比性能指标

大师兄这样说:

  1. 首先,查看通过率,然后分析其他性能指标,例如:响应时间、吞吐量、CPU等指标是否满足需求。如果测试结果不可信,要分析异常的原因,进行修改后重新测试。通过这些步骤,如果,性能测试的结果具有随机性,就需要加长测试的时间;

  2. 然后,查看服务器分析性能瓶颈,包括 CPU使用率、内存占用、磁盘I/O等,以确定性能问题的根本原因;

  3. 最后,检查数据库的慢查询,如果,发现慢查询,可分析具体原因。


39. 你曾经遇到的性能测试挑战是什么?如何克服的?

回答思路: 如果,你本身没有做过性能,可以考虑跳过

大师兄这样说:

  1. 我曾经遇到的性能测试挑战是:第一次做性能测试,在之前,我只了解过使用 JMeter 做服务器接口性能。在当时,有三个挑战:

    • 性能指标不合理:客户性能指标要求所有接口响应时间30毫秒,通过优化改成了1000毫秒。我通过查找相关资料和请教做过性能测试的朋友,重新制定了性能测试指标,最终完成了整个性能测试;

    • 性能测试环境搭建复杂:需要实现主从数据库、分表分库等复杂环境。我通过查找相关资料和请教做过性能测试的朋友,自己完成了性能测试环境的搭建;

    • 性能测试数据庞大:需要生成千万条数据。我写了几个存储过程,成功制造了大量数据,完成了性能测试。

  2. 通过这次经历,我学会了面对挑战,并通过查找相关资料和请教专业人士,不断学习和提高自己的性能测试能力。


40. 如果让你负责团队的性能测试,你会从哪方面考虑和开展工作?

回答思路: 可以结合整个项目性能测试流程,最好举一个例子来说明

大师兄这样说:

  1. 首先,我会确认他们制定的性能测试需求是否合理,从性能指标开始分析。如果我发现有不合理的地方,我会跟他们协调修改。之前,我经历过一个性能测试项目,整个性能指标中有一个非常不合理的地方,客户要求服务器响应时间小于30 MS,但先不说是否能达到,从需求和成本来说都是不合理的。现在响应时间的规则是135,即1000 MS以下就符合行业要求;

  2. 接下来,我会制定性能测试方案、准备性能测试场景、数据、环境,并编写性能测试脚本;

  3. 最后,我会进行性能执行。在性能测试过程中,我不只是测试服务性能,还会寻找项目的瓶颈和稳定性。通过这些步骤,我可以确保系统的性能表现符合预期,并提供良好的用户体验。


41. SQL 注入与 XSS 的区别?

回答思路:SQL注入和XSS攻击都是网络攻击的方式,但它们的目标和攻击方式不太一样。结合他们的目标和攻击方式来说即可

大师兄这样说:

  1. SQL注入是针对数据库的攻击。攻击者会尝试插入恶意的SQL代码,来操控应用程序的数据库查询。比如,攻击者可能会尝试修改查询,以获取敏感信息或者修改数据库的数据。SQL注入可能带来的后果包括数据泄露、数据篡改、身份冒充和数据丢失;

  2. 而跨站脚本攻击是针对用户的攻击。在XSS攻击中,攻击者会在网页中插入恶意的JavaScript代码,试图在用户的浏览器中运行这些代码。这可能使攻击者能够窃取用户的会话cookie,或者在用户的浏览器中进行其他恶意活动。XSS攻击可能带来的后果包括身份盗窃、账户劫持和恶意软件分发;

  3. 总的来说,SQL注入和XSS的主要区别在于攻击的目标和方式:SQL注入是针对数据库的攻击,通过操控SQL查询;而XSS是针对用户的攻击,通过在用户的浏览器中运行恶意代码。


42. 为什么要做安全渗透测试?

大师兄这样说: 渗透测试真的很重要,因为:

  1. 因为攻击威胁总是可能存在,黑客可能会偷走重要数据,甚至让系统瘫痪,所以系统中的安全漏洞和环路漏洞可能非常代价高昂;

  2. 不可能一直保护所有的信息。黑客总是会带来新的技术来窃取重要数据,因此测试人员需要定期执行测试以检测可能的攻击;

  3. 渗透测试通过模拟这些攻击来识别和保护系统,并帮助组织保持其数据安全。


43. 在你之前的项目中,如何进行安全测试?

回答思路: 如果你的简历中体现了安全测试,就一定要整理这个问题

大师兄这样说: 在我们之前的项目中,虽然领导对安全测试的需求看似简单,只要做一些基础的安全扫描并提交安全测试报告就可以了,但我认为这是远远不够的。为了确保我们的系统安全,我制定了一份详细的安全测试方案:

  1. 安全扫描:首先,我对整个网站进行了全面的安全扫描,我使用的是AppScan扫描软件。这个工具可以自动地检测出各种类型的安全漏洞,包括SQL注入、跨站脚本攻击等常见的网站安全问题;

  2. 系统安全测试:接着,我进行了系统安全测试,这包括了对系统的访问控制、用户认证和授权、会话管理、错误处理等关键安全控制点的测试。我们使用了一些自动化工具,同时也进行了手动的安全测试;

  3. 数据库数据安全:对于数据库,我重点关注了数据的安全性。我检查了我们的数据加密策略,以及对敏感数据的处理方式。同时,我也对数据库的访问权限进行了严格的审查,确保只有经过授权的用户才能访问;

  4. 服务器安全:最后,我对服务器进行了安全测试。我检查了服务器的配置、更新和补丁管理,以及防火墙和入侵检测系统的设置。我还对服务器的日志进行了审查,以发现可能的安全事件。


44. 列举一些可能导致软件系统存在漏洞的因素?

回答思路: 软件系统的漏洞可以从:设计问题、密码问题、软件的复杂性、人为失误、数据管理这五个模块来讲即可

大师兄这样说:

  1. 设计问题:首先,如果我们在设计阶段就有疏忽,比如说,让用户输入未经适当验证,或者有未经充分审查的开放接口,这就为黑客留下了攻击的机会。所以,我们在一开始设计的时候,就得确保安全性,避免这样的问题;

  2. 密码问题:然后,我们得谈谈密码问题。如果黑客一旦知道了密码,他们就能轻易地获取信息。因此,我们得有严格的密码规定,比如要求密码足够复杂,定期更换,甚至使用二次验证。这样,我们就能大大降低密码被盗用的风险;

  3. 软件的复杂性:其次,我们知道,软件如果太复杂,就可能留下更多漏洞。每增加一个功能或者组件,都可能带来新的安全风险。所以,我们在开发过程中,得不断审查代码,做安全测试,这样才能及时发现和修复可能的安全漏洞;

  4. 人为失误:再来说说人为失误。比如误操作或者配置错误,这些都可能导致安全问题。为了避免这种情况,我们得提供充足的培训,给出明确的操作指南,同时实施权限管理和操作审计,这样就能追踪和防止可能的误操作;

  5. 数据管理:我觉得数据管理也非常重要。如果数据管理不当,比如数据泄露,或者未经授权的数据访问,都可能导致严重的安全问题。因此,我们得有严格的数据管理规定,包括数据分类,访问控制,以及数据保护等,这样才能确保数据的安全性。


45. 一个项目让你负责安全测试,你会从哪方面考虑和开展工作?

回答思路: 其实就是从两大块,一个是安全扫描、一个是系统安全测试、数据安全三个方面,也可以结合44题中的漏洞愿意来总结

大师兄这样说:

  1. 漏洞扫描:这其实就是用自动化的方式让软件去找出我们系统中可能存在的已知漏洞,这样我们就能迅速找出那些可能被黑客利用的弱点;

  2. 安全扫描:这个呢,就是用手动或者自动的方法去发现我们的网络和系统中可能存在的弱点。这不仅包括已知的漏洞,还有配置错误、更新缺失等可能的安全风险;

  3. 渗透测试:这是一种模拟黑客攻击的方法,让我们能够深入了解系统中可能存在的漏洞,还能评估这些漏洞被真实利用的可能性和可能造成的影响;

  4. 风险评估:这就是我们对系统可能存在的风险进行详细分析和评估的过程。我们会把风险分为低、中、高三个等级,这样就能根据风险的严重程度来决定我们需要采取的防护措施;

  5. 安全审计:这其实就是我们对系统和应用程序进行全面检查的过程,帮助我们发现可能被忽视的安全问题,比如未经授权的访问、不符合策略的操作等;

本文内容由网友自发贡献,转载请注明出处:【wpsshop博客】
推荐阅读
相关标签
  

闽ICP备14008679号