这段时间面试了一些做过性能测试的应聘者，从结果来罕有能让人满意的。整理了一些我常问的性能测试问题，希望对有志于转型性能测试或者正在找性能测试相关工作的同行有所帮助。若对于以下问题有想法也欢迎加我微信进行沟通。 性能测试的意义和作用，说出因为性能不良造成的质量事故？ 如何进行性能测试，整体的性能测试流程是什么？ 确定需求-制定计划和策略-准备环境（干净的，数据）-编写脚本-设计测试场景-运行-监控执行-分析测试结果 性能测试的难点在哪里？如何克服？ 如何选择性能测试工具？ 如何确定性能测试团队的人力资源需求
相信你如果掌握了上面的面试内容，并且能够灵活的运用的话，月薪20k以上并不会是什么问题
在我认为，对于测试面试以及进阶的最佳学习方法莫过于刷题+博客+书籍+视频+总结，前几者博主将淋漓尽致地挥毫于这篇博客文章中，至于总结在于个人，实际上越到后面你会发现面试并不难，其次就是在刷题的过程中有没有去思考，刷题只是次之，这又是一个层次了，这里暂时不提后面再谈。
笔者专注性能测试的时间大概有5年时间，其间也经历了性能测试主流工具从LR到Jmeter转变，监控工具从最早的Linux原生命令到界面花里胡哨的Glances、Zabbix等等。技术架构从单一的节点到多集群，业务对性能的要求越来越高，对于性能测试，有一点小的体会，后续会分多篇来聊聊。今天先说说我对性能测试的一些感观。
虽然一直在吐槽性能测试变得越来越简单（压测的工具越来越多，框架的规范越来越好，可供调优的空间越来越有限，只要合理地使用，性能问题基本上很少，但也架不住有些开发真的乱来，所以性能测试还是有空间的，但已经没必要去组建专职的性能团队了，特殊场景除外，高端的性能测试人员需要足够多的实际场景去培养，中小企业也没必要。性能测试人员能力两级分化极其严重）
上一篇文章聊到了性能测试最基本的三个术语：并发、TPS、响应时间，并且以高速收费站的故事为例，详细的分析了这三个术语在实际的应用实践中该如何理解，以及三者之间的关系。
在当前软件测试行业，熟练掌握性能测试是测试工程师们面试的敲门砖，但是还有很多测试朋友们每天的工作更多的是点点点，性能方面可能也只是做过简单的并发测试，对于编写脚本，搭建环境方面也比较陌生。究竟该如何去做性能测试，怎么熟练掌握性能测试呢？这些问题，我们通过以下问题展开说说。
答案：系统在一定的压力情况下，查看cpu，内存，磁盘，网络带宽，TPS、响应时间、并发用户数、等各项指标，通过模拟生产运行的业务压力量和使用场景组合，测试系统的性能是否满足生产性能要求，就是在特定的运行条件下验证系统的能力状况。
这个简单的问题很多朋友都无法完整的回答。可能知道的朋友会说性能测试就是用LoadRunner或者Jmeter工具来压测系统，也有人会说性能测试就是同时让很多人访问系统看系统能否扛得住。这些回答只能说对，但不够全面也不够深刻，只是把表象描述了一下而已。其实真正的性能测试无法用一两句话来简单概括，因为它涉及的东西太多。
话接上回(我眼中的性能测试)，聊了个人对性能测试的一些看法。后来在直播间和老张，CC一起聊了如何构建个人的性能知识体系这个话题，本文做个总结，个人觉得这个话题非常有意义。单纯的碎片化知识很难产生效应，应该学会如何把这些零散知识点串联起来，形成自己的知识体系，才能更好地运用。那么，如何构建自己的性能知识体系呢？
1.查看聚合报告和服务器的资源使用图，检查响应时间，事务成功率，CPU，内存和IO使用率是否达到要求，如果出错率达到了总请求的3%，我们会检查是什么原因导致的，修改好后，重新测试；
跟着芒果一起，好好学习，天天向上。上周六是我们TestOps性能课程的第五天，我们来为这一天的课程做个小总结~（关于第四天的课程总结，芒果之后再为大家推出）
其实很多测试同学可能都会面临这样的问题，辛辛苦苦加班干活儿，结果绩效一般般，升职加薪也没啥机会，久而久之工作状态下降，搞得自己心气儿没了。
是什么让阿里双11近几年购物体验越来越好，支持高达54万订单/秒呢？是什么让钉钉、企业微信，快速恢复，支持1000万家企业在线办公呢？618快到了，你如何开展性能测试呢？
性能测试已经是一个老生常谈的话题了，不同的项目或多或少都会涉及到，但是每个人的经验肯定有所不同。今天我想从以下几个方面分享一下我认为关于性能测试需要重视的要点。
谷歌开发的一个免费的网页分析工具，在地址栏中输入被分析的网站 url 地址，点击分析，
为了方便大家领悟性能测试微妙心印，本次从老师极客时间专栏中抽出精彩对话，希望大家走上成功之路。
1.基于协议。性能测试的对象是网络分布式架构的软件，而网络分布式架构的核心是网络协议 2.多线程。人的大脑是单线程的，电脑的cpu是多线程的。性能测试就是利用多线程的技术模拟多用户去负载 3.模拟真实场景。用户的访问时间，访问频率都不是固定的。
在上一篇性能专题的文章：性能专题：性能测试实施全过程指南，已提前剧透告知了，从本篇开始，将结合服务端性能测试的两款常用工具进行实战操作介绍：Jmeter和Locust。
我们经常看到的性能测试概念，有人或称之为性能策略，或称之为性能方法，或称之为性能场景分类，大概可以看到性能测试、负载测试、压力测试、强度测试等一堆专有名词的解释。
最近做了一个XXX项目，背景是老服务重构，预期指标是在原有系统基础上性能提升3倍，架构设计是XXX。针对这个项目我梳理了核心应用和接口有XXX个，对应的场景有XXX，我的压测策略是XXX。测试过程中发现了XXX问题，问题表现是XXX，通过XXX(日志、工具)分析原因为XXX，最终优化策略是XXX，优化后结果为XXX
昨天一个前同事找我，问有没有性能测试岗位的面试题，正好之前帮业务团队加面过几次性能测试岗位的候选人，我将面试时候会问的一些问题以及要考察的点列了出来，供大家参考。
之前的文章大多都是介绍性能测试的方法、思路以及测试工具的使用，可以称之为“务实”。这篇文章，聊聊“务虚”——如何建立团队的性能文化。。。
随着软件行业的快速发展，现代的软件系统越来越复杂，功能越来越多，测试人员除了需要保证基本的功能测试质量，性能也随越来越受到人们的关注。但是一提到性能测试，很多人就直接连想到Loadrunner。认为LR就等于性能测试，其实这是不对的。LR只是性能测试的一个工具，但性能测试不仅仅是LR。本文会从以下几个方面介绍基础的性能测试理论，后续也会持续更新相关文章，尽量理论结合实践，让性能测试学习不在是工具的学习。
很多人会问，性能测试需要设计方案吗？需要测试用例（性能场景）吗？拿一个性能测试工具，比如loadrunner，对被测系统进行压测，不就是性能测试了吗？是的，这种拿性能测试工具来进行压测，就以为是做性能测试的思维，仍然存在很大一部分的人心里。 我可以大声的告诉你：不是！性能测试是一门系统性的工作，包括：测试方案的设计、性能环境的搭建，编写性能脚本进行压测，分析测试结果，调优&回归，出性能报告。针对每一个步骤，我都尽量写一篇文章来描述。如果你拿性能测试工具进行压测，那么只是其中的一小步而已。本文先重点描述如何设计性能测试方案。 首先要确认性能测试的目的是什么？有个成语叫：有的放矢。这是我们做事的原则。我遇到很多开发，他们很喜欢说一句话就是：“这个帮我压下，看下性能如何？”当然这也是目的。那我们性能测试工程师的价值体现在哪里？每天屁颠屁颠跟在开发后面，帮他压一下这个项目，帮她压一下这个页面，帮TA压一下。。。。。？ 我觉得作为性能测试工程师，要从系统的性能角度出发，从用户的角度出发，如何更好的模拟用户行为？找出系统的性能瓶颈所在，预估系统的容量。性能测试方案的设计也是基于这几点出发。 为了更好的理解，举个例子，就拿www.juhuasuan.com聚划算来说明。
大概介绍一下个人情况，女，本科，三年多测试工作经验，懂python，会写脚本，会selenium，会性能，然而到今天都没有收到一份offer！从年后就开始准备简历，年后上班的第一天就开始投，开始只是投了一些官网已久的岗位，并没有收到面试邀请，得到的都是不匹配的反馈，一度怀疑是不是简历写的不好，后来大批量投递简历，确实是接到了几个面试邀请
写这篇文章的初衷来源于朋友圈CC的动态：“今年很多写测试工具平台没有成就业务价值的同学，被落入自由市场了”。我俩在评论区交流了下性能测试如何成就业务价值的问题。
做性能测试工作的人总是离不了性能测试工具，但当我们刚开始接触这类工具或者压测平台的时候，总是难免处在一种顾此失彼，焦虑又没想法的状态。
本篇主要介绍前两部分内容，分别是性能测试基础知识和性能测试的应用场景及价值，目的是让大家对性能测试有一个基础和全面的理解，为下一篇工具选型&流程建设以及落地过程打好基础。
最近也有一些面试，整理下常用的测试题目，没有标准答案，需要结合自身的工作实践去应答。
Web 服务器性能评估是评定服务器承载能力和效率的重要手段。主要关注几个关键指标：最大并发连接数、响应延迟、吞吐量。不同的评测方法可以帮助我们从多角度了解服务器性能，包括基准性能测试、压力测试、可靠性测试。系统检测通常采用系统本身提供的命令、系统记录文件、集成监控工具等方法进行。
5、问简历上的第一个项目的详细情况，包括测试用例怎么写？怎么判断测试通过？项目的原理？
技术交流群有同学问了一个问题：性能测试手动执行效率太低，能否通过自动化来快速执行，提前发现潜在的性能问题。有没有什么工具或者方法可以提高压测的执行效率，或者落地过程要注意的事项。正好之前工作中有过这方面的实践，这篇文章聊聊这个话题。
性能测试 活动时间：2017年8月29日 QQ群视频交流 活动介绍：TMQ在线沙龙第二十八期分享 本次分享的主题是：性能测试 共有152位测试小伙伴参加活动，在线观看视频人数 60人！ 想知道活动分享了啥吗， 请往下看吧！ 嘉宾 赵先炮，腾讯系统测试高级工程师。10年工作经验，之前在IBM从事数据库DB2的性能测试，以及SQL的性能调优。目前独立负责PC浏览器的性能测试，PC浏览器主版本测试等。 在性能测试和自动化方面有着丰富的经验，是《DB2性能管理与实战》的作者之一。 分享主题 1. 如何理解性能
这篇来讲压测，压测本质上其实就是经验的问题，至于技术我认为现在都是配套了，也有人配套的东西也搞不清，那还是经验的问题；提醒下，这篇对野路子玩压测的人蛮有用的。
4.你在测试中发现了一个bug，但是开发经理认为这不是一个bug，你应该怎样解决？
在【rainbowzhou 面试3/101】技术提问--大数据测试是什么，你如何测？中，如果细看的小伙伴会发现通篇仅在基准测试的时候，提到过性能，那么是否在大数据领域基准测试即性能测试呢？本篇带着这个疑问，我将和大家聊聊大数据中的性能测试，性能测试的步骤，以及分享一个大数据性能测试案例，希望对大家有所帮助。
首先，让我们从性能测试的基础知识开始，弄清楚它究竟是什么。性能测试是一种测试方法，主要用于评估系统在特定工作负载下的性能表现。我们可以把性能测试比作给你的应用“体检”，确保它在面对用户激增、大量数据等情况下仍然能够保持高效。
就算所有人都不支持你。这条路会很曲折，你也会一度认为是不是自己选错了，但只要坚持，就算最后没有成功，但努力了就不会有遗憾。
首先比较高兴的是专栏评论数和好评还是很多的，我说过一些共同问题将会集中答疑，第7篇《如何制定性能测试的目标》是提问比较多的一篇，有一些问题集中在如何确定并发数，我在原文中有这么一段话
你也许听过这样一句至理名言：“计算机科学领域里的任何问题，都可以通过引入一个中间层来解决”。TCP/IP 协议栈是这样，而代理也是这样。
如果你理解了今天的内容，不妨说说为什么说现在市场上的概念对性能项目的实施并没有太大的价值？其次，性能场景为什么要连续？而不是断开？
负载测试是模拟实际软件系统所承受的负载条件的系统负荷，通过不断加载（如逐渐增加模拟用户的数量）或其它加载方式来观察不同负载下系统的响应时间和数据吞吐量、系统占用的资源（如CPU、内存）等，以检验系统的行为和特性，以发现系统可能存在的性能瓶颈、内存泄漏、不能实时同步等问题。负载测试更多地体现了一种方法或一种技术。
01. 为什么要在一个团队中开展软件测试工作？ 因为没有经过测试的软件很难在发布之前知道该软件的质量，就好比ISO质量认证一样，测试同样也需要质量的保证，这个时候就需要在团队中开展软件测试的工作。在测试的过程发现软件中存在的问题，及时让开发人员得知并修改问题，在即将发布时，从测试报告中得出软件的质量情况。 02. 您在以往的测试工作中都曾经具体从事过哪些工作？其中最擅长哪部分工作？ 我曾经做过web测试，后台测试，客户端软件，其中包括功能测试，性能测试，用户体验测试。最擅长的是功能测试 03. 您所熟悉的软件测试类型都有哪些？请试着分别比较这些不同04. 的测试类型的区别与联系（如功能测试、性能测试……） 测试类型有：功能测试，性能测试，界面测试。 功能测试在测试工作中占的比例最大，功能测试也叫黑盒测试。是把测试对象看作一个黑盒子。利用黑盒测试法进行动态测试时，需要测试软件产品的功能，不需测试软件产品的内部结构和处理过程。采用黑盒技术设计测试用例的方法有：等价类划分、边界值分析、错误推测、因果图和综合策略。 性能测试是通过自动化的测试工具模拟多种正常、峰值以及异常负载条件来对系统的各项性能指标进行测试。负载测试和压力测试都属于性能测试，两者可以结合进行。通过负载测试，确定在各种工作负载下系统的性能，目标是测试当负载逐渐增加时，系统各项性能指标的变化情况。压力测试是通过确定一个系统的瓶颈或者不能接收的性能点，来获得系统能提供的最大服务级别的测试。 界面测试，界面是软件与用户交互的最直接的层，界面的好坏决定用户对软件的第一印象。而且设计良好的界面能够引导用户自己完成相应的操作，起到向导的作用。同时界面如同人的面孔，具有吸引用户的直接优势。设计合理的界面能给用户带来轻松愉悦的感受和成功的感觉，相反由于界面设计的失败，让用户有挫败感，再实用强大的功能都可能在用户的畏惧与放弃中付诸东流。 区别在于，功能测试关注产品的所有功能上，要考虑到每个细节功能，每个可能存在的功能问题。性能测试主要关注于产品整体的多用户并发下的稳定性和健壮性。界面测试更关注于用户体验上，用户使用该产品的时候是否易用，是否易懂，是否规范（快捷键之类的），是否美观（能否吸引用户的注意力），是否安全（尽量在前台避免用户无意输入无效的数据，当然考虑到体验性，不能太粗鲁的弹出警告）？做某个性能测试的时候，首先它可能是个功能点，首先要保证它的功能是没问题的，然后再考虑该功能点的性能测试 04．您认为做好测试用例设计工作的关键是什么？ 白盒测试用例设计的关键是以较少的用例覆盖尽可能多的内部程序逻辑结果 黑盒法用例设计的关键同样也是以较少的用例覆盖模块输出和输入接口。不可能做到完全测试，以最少的用例在合理的时间内发现最多的问题 05. 请试着比较一下黑盒测试、白盒测试、单元测试、集成测试、系统测试、验收测试的区别与联系。 黑盒测试：已知产品的功能设计规格，可以进行测试证明每个实现了的功能是否符合要求。 白盒测试：已知产品的内部工作过程，可以通过测试证明每种内部操作是否符合设计规格要求，所有内部成分是否以经过检查。 软件的黑盒测试意味着测试要在软件的接口处进行。这种方法是把测试对象看做一个黑盒子，测试人员完全不考虑程序内部的逻辑结构和内部特性，只依据程序的需求规格说明书，检查程序的功能是否符合它的功能说明。因此黑盒测试又叫功能测试或数据驱动测试。黑盒测试主要是为了发现以下几类错误： 1、是否有不正确或遗漏的功能？ 2、在接口上，输入是否能正确的接受？能否输出正确的结果？ 3、是否有数据结构错误或外部信息（例如数据文件）访问错误？ 4、性能上是否能够满足要求？ 5、是否有初始化或终止性错误？ 软件的白盒测试是对软件的过程性细节做细致的检查。这种方法是把测试对象看做一个打开的盒子，它允许测试人员利用程序内部的逻辑结构及有关信息，设计或选择测试用例，对程序所有逻辑路径进行测试。通过在不同点检查程序状态，确定实际状态是否与预期的状态一致。因此白盒测试又称为结构测试或逻辑驱动测试。白盒测试主要是想对程序模块进行如下检查： 1、对程序模块的所有独立的执行路径至少测试一遍。 2、对所有的逻辑判定，取“真”与取“假”的两种情况都能至少测一遍。 3、在循环的边界和运行的界限内执行循环体。 4、测试内部数据结构的有效性，等等。 单元测试（模块测试）是开发者编写的一小段代码，用于检验被测代码的一个很小的、很明确的功能是否正确。通常而言，一个单元测试是用于判断某个特定条件（或者场景）下某个特定函数的行为。 单元测试是由程序员自己来完成，最终受益的也是程序员自己。可以这么说，程序员有责任编写功能代码，同时也就有责任为自己的代码编写单元测试。执行单元测试，就是为了证明这段代码的行为和我们期望的一致。 集成测试（也叫组装测试
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
ICP备案
对象存储
即时通信 IM
实时音视频
