这就是一个常见的模板，把容易出的问题都设计上去了。所以拉80%的时间做设计，20%的时间做执行。当然所有数据的填写都是基于调研的。所以性能测试应该开始于调研的时候，而不是测试的时候。测试指标的指定是在调研后同产品或需求或业务制度出来的。一定要有明确的性能指标在进行测试，才会事半功倍。所以指标不明确是团队需要改变的地方。
问：做性能测试可以使用第三方工具，也可以自己开发代码，这两种情况分别有什么样的适用范围？您最看重性能测试工具那些方面的特性？能不能介绍一下对性能工程师来说使用工具进行测试最大的痛点在哪里？能不能描述一下您理想中的性能测试工具（或者库）要有什么功能？
答：总原则：以目标位出发点，不要受方法和工具限制。在回到为什么需要工具，工具帮我们在有限资源下，提升效率和生产力：有限制条件，有限资源。
测试需要投入大量的资源（解决方法资源共享）不可能准备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语句，根据语句找到相应代码进行优化。根据语句，找到相应代码进行优化。
上文内容不用于商业目的，如涉及知识产权问题，请权利人联系博为峰小编(021-64471599-8017)，我们将立即处理。
