问：性能测试最好什么时候开始更好？需求阶段、设计阶段、还是测试阶段？
答：有些同事在测试几轮之后，功能稳定了开始介入性能测试，这时才发现性能根本支撑不了预期值。这个时候开发再回头进行系统调优，如果事先选的架构能支撑就好，如果不能达不到预期值，后面讨论或者请教高手发现原先的架构缺陷，再调整架构代价就非常大。基本导致前期的功能测试成果作废。其实各个阶段都有事情做。需求阶段可以整理，评审出性能需求，评审需求可行性时就考虑好数据量和用户量。设计阶段--对预估的需求做设计，举个例子。背景：我们现在使用的是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的问题；数据分析基于产品历史数据或公司/市面差异化产品数据，做性能测试数据分析时有哪些坑需要注意？
答：覆盖率避免漏测：
场景。
数据分析。
问：希望能结合具体的案例，讲讲怎么设计场景，增加压力的策略是怎么样的，如果在性能指标不明确的情况下，又该怎么探索去测试，对于测试结果的分析也希望以后多讲讲。
答：场景设计、用例设计、性能分析在后面的chat有专门的分享，一下子说不完整。我把主要的提一下：一把性能测试的关键字段都列出来如：参数化、关联、集合点、思考时间、虚拟IP、负载机请求数、带宽要求、参数化策略、集合点策略等，每一项都写清楚。其实这个同漏测有很大关系：
上文内容不用于商业目的，如涉及知识产权问题，请权利人联系博为峰小编(021-64471599-8017)，我们将立即处理。
