关于性能测试的这点事，值得收藏~

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

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

问：文章有说通过数据分析识别瓶颈问题，能否稍展开，有没有具体的方法、流程步骤等，还是主要靠经验？性能测试刚入门，请大师指点。
答：性能瓶颈分析有专场的chat，本次就谈一下瓶颈分析几大原则和几个关注可以参考：
逻辑极简化原则：就是去繁为简。
割据分段法：就是假设问题最可能出现在什么地方,分段分析，使用打桩的方法。
路由堵截法：就是从压力产生的数据流向开始分析。
资源监控法：资源监控，主要关注资源有：
CPU（用户占用<通过算法优化等方法解决>、系统占用<堵筛>）
内存（页面失效（软页面和硬页面）可以剩余内存、可以缓存）
磁盘I/O
网络
进程（处理器时间、进程产生的页面失效、进程所分配的无法与其他进程共享的当前字节数量，看是否有内存泄露等）
存储，也需要关注。

问：老师怎么看待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语句，根据语句找到相应代码进行优化。根据语句，找到相应代码进行优化。

关于性能测试的这点事，值得收藏~相关推荐

git reset后本地拉取_一份值得收藏的 Git 异常处理清单
? 这是第 54篇不掺水的原创,想要了解更多,请戳上方蓝色字体:政采云前端团队关注我们吧- 本文首发于政采云前端团队博客:一份值得收藏的 Git 异常处理清单 https://www.zoo.team ...
Java摇骰子比大小_还在摇骰子比大小？这几款火热的KTV喝酒游戏你值得收藏
原标题:还在摇骰子比大小?这几款火热的KTV喝酒游戏你值得收藏嗨,此时屏幕前的你, 是否正在包厢里和客人尽情高歌. 曲也唱了两三首了, 不如来点酒桌游戏助助兴. 今天带来6种当下最流行的喝酒游戏, ...
程序员非常实用的十个工具网站，值得收藏
原文链接: 程序员非常实用的十个工具网站,值得收藏一.regex101 网站地址: https://regex101.com/ 强大的正则表达式工具,你可以实时查看匹配信息,并且会用不同的颜色将 G ...
明日之后无限金条服务器,明日之后：无限金条bug 你值得收藏
原标题:明日之后:无限金条bug 你值得收藏在变态游戏明日之后中,如果想要活得滋润,那么新币和金条绝对是不可少的,尤其是金条!金条可以购买到绝大多数的东西,前提是你数量足够!我们都知道在各个地图的战 ...
苹果手机聊天记录恢复方法有哪些？这2个恢复技巧值得收藏
在使用苹果手机的过程中,由于苹果手机的触屏反应过快,会导致在使用微信的时候,不小心手滑把聊天记录删除了,或者在清理微信内存的时候,误把所有聊天记录一键清空,反应过来的时候聊天记录早已不翼而飞.苹果手机 ...
【值得收藏】如此心机的老婆，不难教出一个优秀的女儿。谁娶了都是福。
2019独角兽企业重金招聘Python工程师标准>>> 特别感谢作者,分享这么好的教育经验,其中好多招都和小时候我妈妈用的基本一样,不过我妈妈不会上网,方法也更农村,但原理是一样的, ...
10个维修中最常见的蓝屏代码，值得收藏！
10个维修中最常见的蓝屏代码,值得收藏! 2015-11-03 2345王牌技术员联盟很多技术员碰到蓝屏或者是听客户说蓝屏,首先想到的都是重装系统.其实windows系统最人性化的地方就是有个日志, ...
计算机维护宝典,分分钟教你“修电脑”的宝典，值得收藏
原标题:分分钟教你"修电脑"的宝典,值得收藏电影<星际穿越>中,库珀离开地球开启星际航行之前对女儿说过:"你越是坚持一件事,这件事情越有可能变为现实&quo ...
计算机速算训练,5种速算技巧，比计算机“更神速”！值得收藏！
原标题:5种速算技巧,比计算机"更神速"!值得收藏! 小学时期的数学课被称作"算数".由名称就可见小学的数学更加看重孩子的运算能力. 运算能力看似简单普通,却是 ...
node 压缩图片_推荐10个常用的图片处理小帮手（下）「值得收藏」
作者: semlinker 转发链接:https://mp.weixin.qq.com/s/i3ynTtPJOECoAYfqHFoo3Q 前言本文给小伙伴们隆重介绍用于图片处理的十个「" ...

关于性能测试的这点事，值得收藏~

关于性能测试的这点事，值得收藏~相关推荐

最新文章

热门文章