关于性能测试的这点事，干货来袭「建议收藏」

问：性能测试最好什么时候开始更好？需求阶段、设计阶段、还是测试阶段？

答：有些同事在测试几轮之后，功能稳定了开始介入性能测试，这时才发现性能根本支撑不了预期值。这个时候开发再回头进行系统调优，如果事先选的架构能支撑就好，如果不能达不到预期值，后面讨论或者请教高手发现原先的架构缺陷，再调整架构代价就非常大。基本导致前期的功能测试成果作废。其实各个阶段都有事情做。需求阶段可以整理，评审出性能需求，评审需求可行性时就考虑好数据量和用户量。设计阶段–对预估的需求做设计，举个例子。背景：我们现在使用的是mysql数据库（公司去oracle化），我们要从一个5000W的一个数据表的6个不同查询维度查询数据，比如说城市、行业、地址类型、爱好、性别、时间范围。这样对于mysql的查询常见的优化设计可能是分表、建立索引，但，对于这个场景就不好处理了。数据耦合强，没有办法分表。索引，组合索引太多。后面的处理办法是用mongodb、nosql的方法解决。对于编码和测试阶段可以这样去分不同阶段做不同事情。

编码阶段，可以提出需要，让研发通过单元测试（开多线程）的方式进行压力测试。进行一些单元压力测试测试阶段—测试阶段也有策略的，建议先做一下单一场景单一用户的性能测试。常常会遇到有些同事在没有压单个场景的情况下，就进行负载测试，到处定位瓶颈，最后发现单一用户单一场景都是问题。这就是绕了一圈回到了起点。对于不同类别测试后面会专门的chat介绍。

问：怎样才能更有效的获得性能需求？以便更好设计、执行性能测试。平时做的基本是根据项目历史数据，或者根据经验想出来的，这样经常会漏测，导致上线后新的性能问题出现，唐总有没好的建议或经验分享下。

答：获取性能需求，可以一下步骤：

收集。

分析。

比如业务人员很多，底层给中层、再给高层。

分析历史数据、竞品、业务。业务需要分析业务常见、业务高峰（大的时间和小的时间段）

性能问题还存在可以细分一下是场景遗漏、还是数据遗漏。场景遗漏常常由于需求传递变味导致。

处理方法。 做好策略和设计，如果针对现在的问题：可以做一个checklist不断优化你的策略设计能力。

问：文章有说通过数据分析识别瓶颈问题，能否稍展开，有没有具体的方法、流程步骤等，还是主要靠经验？性能测试刚入门，请大师指点。

答：性能瓶颈分析有专场的chat，本次就谈一下瓶颈分析几大原则和几个关注可以参考：

逻辑极简化原则：就是去繁为简。

割据分段法：就是假设问题最可能出现在什么地方,分段分析，使用打桩的方法。

路由堵截法：就是从压力产生的数据流向开始分析。

资源监控法：资源监控，主要关注资源有：

CPU（用户占用<通过算法优化等方法解决>、系统占用<堵筛>）

内存（页面失效（软页面和硬页面）可以剩余内存、可以缓存）

磁盘I/O

网络

进程（处理器时间、进程产生的页面失效、进程所分配的无法与其他进程共享的当前字节数量，看是否有内存泄露等）

存储，也需要关注。

问：在做性能测试时，为了追求模拟数据的真实性，我倾向于把能参数化的字段都做成参数，但是很显然过多的参数会给客户端带来不少的性能压力。所以有时想想，其实我们是不是可以走另一个极端，只参数化那些已知与性能有关的那些字段，其他字段一律写死就行了？但是这样会不会导致有些字段其实也会影响性能，只是自己认为不影响，从而漏测一些性能问题？

答： 我个人是认可的，但我们要具体分析一下。为什么要参数化，更多的人会是是为了模拟真实情况。其实大家想问的是，什么才叫真实情况。有人会说是用户的实际场景。我个人认为这是表面现象。真实情况应该是：能模拟磁盘、CPU、内存的真实情况，才是我们测试人员想要的真实情况。 业务的真实情况最后都会变成对资源的消耗情况。

缓存的存在与否，比如大家都知道数据库有缓存、CPU有缓存那么产生模拟真实数据的原因更多再也此，我们要规避不需缓存的时候缓存了、以及合理的模拟缓存，根据真实架构设计来设计测试数据。

数据库历史数据（业务基础数据量和质量是否满足）；数据库业务交易数据是否满足，数据的单一问题是否带来查询压力减轻了，不能模拟真实情况。

测试数据的写死，是否到账业务场景遗漏。比一些边界场景和一下主流场景组合的综合场景。特别是这种组合很容易遗漏，非主流+主流。

断言（检查点）是否能满足，出现过多次的真实案例，不设置检查点。去掉直接认为没有必要的请求。在动静分离的系统中，去掉了静态资源请求，结果上线后静态资源服务器被压死了。一个原则，就是会给资源带来压力的真实情况一个都不放过，这就是参数化和数据准备的原则。

问：老师怎么看待js的性能，以及测试如何下手这个环节。开发认为js性能受终端配置影响严重且多数用户会自认为是不是我的网不好之类的，从而忽略掉这个环节的性能测试。

答：首先，性能是设计出来的不是被测试出来的。这个文章中有提到。因此一个好的性能需要做好前期的性能可行性设计。没有这个流程的同学，建议研发流程中加入，性能可行性设计。给出现状（使用工具查看现状）：js性能工具: JSLitmus、jsperf、chrome浏览器的profile等。可以检查网页性能情况比如chrome的profeil，操作简单，录制+停止。

可以用工具看到js大小，加载速度等，还可以看看研发的代码。要让研发动起来就的找方法：js常见的优化方法：建议动静分离、建议压缩、建议缓存、建议版本标示、文件合并、方法抽象、避免全局、解耦html和css，具体方法很多。动静分离是常见的。就是把，js、图片、css等静态文件放到不同的服务器上。js由于是静态资源，可以做动静分离，来减轻服务器压力。js做缓存，js由于版本特征明显，需要做好版本标示，保证不会由于缓存带来功能问题。tags可以通过代码或设置中间件如gizp压缩（压缩登记等），其实不光js前台的图片等都有很多优化方法，后面的chat会提到。比如nginx中间件，设置nginx.cfg就能压缩。可以买一本js性能优化的书看看推荐《高性能JavaScript》。

问：性能测试个人觉得二点是性能数据分析及性能测试覆盖面，我们在面对性能测试是用什么想法能达到最大的覆盖面，避免遗漏某些重要的性能测试点，因为某些产品在不同的地区可能会因不同的时间差异出现不同的性能测试点，靓汤老师有没有一个好的办法来尽量避免这种“漏测”现象，也就是how的问题；数据分析基于产品历史数据或公司/市面差异化产品数据，做性能测试数据分析时有哪些坑需要注意？

答：覆盖率避免漏测：

场景。

数据分析。

问：做性能测试可以使用第三方工具，也可以自己开发代码，这两种情况分别有什么样的适用范围？您最看重性能测试工具那些方面的特性？能不能介绍一下对性能工程师来说使用工具进行测试最大的痛点在哪里？能不能描述一下您理想中的性能测试工具（或者库）要有什么功能？

答：总原则：以目标位出发点，不要受方法和工具限制。在回到为什么需要工具，工具帮我们在有限资源下，提升效率和生产力：有限制条件，有限资源。

测试需要投入大量的资源（解决方法资源共享）不可能准备10W台机器让你压奥运会售票系统。

可重复性非常差，操作步骤多，人为不一定记得住，不能重现。

测试准确性较差（人工超做有误差，比如说是集体发力，但你就可能晚了0.001s。

工具与开发比较：

先用第三方工具，当第三方工具不能满足的时候就自己写代码或者使用另外的工具。

可以得道的帮助，网上 资料 少与网上 资料 多当然不一样 轻量级和重量级。敏捷下个人更建议轻量级。比如用jmeter，而不用LR. 如果刚学习，可以学LR，因可以得道的帮助，网上资料少与网上资料多当然不一样轻量级和重量级。敏捷下个人更建议轻量级。比如用jmeter，而不用LR. 如果刚学习，可以学LR，因为知识面广什么都涉及。支持人员（开源工具，需要看社区活跃度等）；如果是自己开发、后续开发能支撑不？后续维护能支撑？这是要考虑的。性能测试工具其实就是：多线程、能模拟交易（主要是协议和代理）、能模拟真实数据。能共享资源、能分布式负载（有些工具要测试人员自己去写调度，就很累了）能不能录制，就是后面要考虑的事情了。说到用工具的痛：就是到处拼凑，找合适的工具拼凑，以前自己写过调度工具来调度其他压力测试机（SOAPUI的压力测试）。目前没有一款能完全合适自己产品的，都有学习成本，如果功能测试人员能0成本介入就好了（桥梁需要性能测试开发人员去做）所以大家可以在自己公司去搭平台的。

好的辅助工具可以是这样的：有功能开关、可以记录日志、原子性强（比如单元级别的性能测试，能去除垃圾时间，记录业务其实时间，可以记录日志）、针对性强，用推广可能（测试kafka性能、测试redis性能工具类、测试MQ推送与消费）。

问：作者觉得何时安排做性能测试比较合适？性能测试的频率是怎样的？

答： 时间安排其实前面都有表述，应改能解决这个问题。性能测试的频率根据业务场景需要就测、评估需求的时候，发现有性能要求就计划做，但建议主要功能每隔3个小版本，关注一下业务量，业务量快达到预估值时进行一次，另外要考虑业务高峰期，比如双11、双12、618、春节等，建议之前都做一次。当然不同行业有不同的高峰期。

问：每次性能测试的内容都是一样的么？在性能测试的设计和选择上需要主要考虑哪些内容？

答：不一样，要根据目标来定。比如，产品要路演，可能只需要单个用户响应速度OK，就可以了。如果现在换成做促销，这个时候就好考虑同时有多少个用户来请求了。那么场景的设计、参数化策略也不一样了。又比如说，新功能是大数据量下载，这个时候就要对下载做功能测试，可能是多用户并发需求；有可能是少用户，大数据量，比如要下载100W条记录的数据。当然要看研发如何实现了，是后台分批压缩。还是定时任务完成。这个同研发实现有关。这也是为什么花一次chat来给大家讲性能测试目的，其实性能设计就是以目的出发的。

可以考虑一下几个方面：

测试数据（基础数据、业务数据）不多解释这个文章中有。

测试场景（基础场景、综合场景）场景一定要同业务过，看看是不是真实的，或遗漏了。最好是用户，而非业务。

参数化策略（如何参数化、如何取数、数据用完后怎么办等，这个后面的Chat会分享）。

集合点策略（全部虚拟用户都到了在压，还是等到%XX就可以压，还是业务成功达到多少在压）。

检查点（又叫断言，判读事务是否成功）这是很多初学同学容易遗漏的。

环境（网络、服务器配置、防火墙等、中间件配置、定时任务频率、应用配置等）。

负载机情况，需要把负载机的监控纳入监控范围。（很多失败原因都是没有关注负载机情况导致测试走弯路）,这也是常见问题。需要特别说明的是“网络”这是也是遇到最多的问题。（可能负载机的网络带宽限制，导致无论怎么样压，压力都上不去，一直找不到原因）。

问：经常看到有很多同行或者同事做的性能场景很复杂(非综合场景)，需要很多步骤组成，写的脚本也很长，当然我本人没做过那么复杂的，不知道实际情况，所以我想问一下是不是实际上真的存在这么复杂场景的性能测试，或者这些很复杂的场景是否可以简化成对某个接口的测试？

答：脚本一定不要太长，能抽象一定抽象，太长自己看不到逻辑关系。所有我写脚本都会先写伪代码。建议大家也这么做，先设计表格，依照表格写伪代码。比如刚刚的场景用例设计表格。文字最好懂，代码不易懂。然后能抽象出去的就抽象出去。需要加的关键点都在场景设计和用例设计时一表格的形式列出来，专家也好评审。对于接口测试，你的思路是对的，我们可以拆解，但接口测试代替不了页面测试。

提前做接口的，甚至先让研发做单元的性能测试（多线程压一下）。 数据从后端到前端，浏览器要渲染等操作会占用这个响应时间，所以接口OK了，还要测

提前做接口的，甚至先让研发做单元的性能测试（多线程压一下）。

数据从后端到前端，浏览器要渲染等操作会占用这个响应时间，所以接口OK了，还要测页面。

另外前端性能也是一个大的方向，比如，js/图片/css，缓存等。其实性能测试还要考虑好缓存到底能不能模拟真实情况。缓存在性能测试中干扰最多，又是是需要缓存来模拟真实情况，但有时参数化有会导致不需要的缓存出现。所有参数化，是结合业务的一门学问。静态服务器，就是静态资源下载带来的压力。

问： 如果部署环境和测试环境不一致，如何在性能测试过程中的测试结果具有代表性？和可证明性。

答：这个需要一定的换算标准。当然有些土豪公司就是一比一的设备来进行测试。测试的配置是否与生产一致。如果测试的配置与生产一致的话。可以按照乘以它的百分比，咱最后再乘以70%。这样的话就建议提服务器的人通常同配置，这样便于你计算。如果没有这种等比例的配置，算起来就比较麻烦。服务器型号不同，没有关系，但CPU的核数，以及CPU的频率以及内存。包括你的中间价，你的网络。建议越接近的配置最好。

问： https的手机端，在开发给不出靠谱的接口文档的时候，如何录制或抓取数据流，公司主要用的lr。

答： 可以让研发做一些单元压力测试。完善后再做，不建议用lr，可以换jmeter试试。

问： 如何快速定位数据库问题？有没有好的实例讲解？用LR如何做到？

答：可以先做一部分，比如说你先解决，性能测试监控指标，回传和展示。数据库的问题和建议进行数据库相关设置。比如说慢sql，比如spitlight工具。慢sql会记录所有系统查询较慢的sql语句，根据语句找到相应代码进行优化。根据语句，找到相应代码进行优化。