非常非常长
测试需求分析
一、明确测试目标
不同系统有不同的业务特性，对性能测试需求和要达成的目标也会有不同的要求。在开展性能测试工作之前首先要明确性能测试目标，了解需求方想要达成什么样的目的或得到什么样的结果，
评估需求方的目标是否合理，根据性能测试经验给一些建设性的意见和建议。
明确性能测试目标是关键性的一步，也是性能测试能否成功的关键。
通常情况下，性能测试目标包括以下几种：
响应时间要求
核心业务操作在一定的压力下或者并发一定的用户下，响应时间是多少，是否符合用户要求或预期？
制定配置标准
系统的某个关键配置会影响整体性能，那配置为多少在特定场景下性能能达到最好？如分布式文件系统，文件分块大小是设置为128KB、256KB、1M或其它值上传下载文件速度能达到最快？
稳定性要求
某些系统在上线后长时间跑会不会出现性能问题？会不会有内存泄露或线程泄漏，或其它异常。需要进行稳定性测试，测试系统在一定压力下连续运行324小时、724小时是不是稳定的，确定系统足够稳定。
可靠性要求
产品上线后，在运营及推广下，用户量会持续上升。某些时候因为一些运营上的活动会出现用户激增，导致服务器负载过高，这种场景下是否能保障服务不挂掉，机器不会宕机，服务足够可靠。需要进行压力测试来保障产品的可靠性。
检测瓶颈点
测试系统的性能拐点或性能瓶颈点，根据木桶原理，系统的整体性能瓶颈肯定是某一处的短板所致，那性能瓶颈是什么？又是什么原因导致了性能瓶颈。需要利用负载测试方法，查找性能拐点，并定位性能瓶颈点，进行性能优化，提高系统整体性能。
产品性能评估
线上应用部署是否能支撑10w用户？是否能支撑同时并发10w用户？在并发10w用户下，核心业务的响应时间如何？这些需要合理设置性能测试场景进行性能评估，得到有效性能数据为产品上线进行指导。
容量规划
性能调优和容量规划有着不同的目标。性能调优是优化已存在的系统性能。容量规划则是通过使用当前性能作为基线决定你的系统需要扩容什么以及什么时候需要扩容。通过性能测试和评估得到性能基线，可以作为容量规划的一个指标，明确系统大概在什么情况下会出现失效，什么时候需要进行扩容。但是以系统实际的线上观察数据作为基础会更有效。因此容量规划通过测试环境来模拟是不充分的，仅作为一种参考。
————————————————
二、熟悉产品架构
收集和调研产品的系统架构和部署架构。尽可能的阅读产品概要设计和详细设计文档。对产品内部设计逻辑有清晰的认识。
通过系统架构理解关键业务路径的处理逻辑，数据流路径等。
系统架构
常见的web产品架构有B/S、C/S，杭研产品以B/S架构为主，也即是Browser/Server模式，B/S架构的显著优点是摆脱了C/S结构的限制，不用安装专门的软件，可以随时随地访问服务器资源。
B/S模式通常有三层结构，表现层、业务层和数据层。随着互联网的发展，对三层结构有会有不同的诠释，包括一些中间件等。
1.表现层（Presentation Layer）
表现层用于用户接口的展示，以及用业务层的类和对象来"驱动"这些接口。
2.业务层（Business Tier）
业务层用于访问数据层，从数据层取数据、修改数据以及删除数据，并将结果返回给表现层。
3.数据层（Data Tier）
数据层是数据库或者数据源。通常它是MySQL或Oracle数据库，但不仅限于此两种形式
这块不详解，自行google。
部署架构
典型的Web产品部署架构为：LVS+Apache(或nginx)+tomcat不排除其它的servlet容器如jetty，jboss等，举一反三。 参考下图常见产品架构：
LVS：
LVS是一个开源的软件，可以实现LINUX平台下的简单负载均衡。LVS是Linux Virtual Server的缩写，意思是Linux虚拟服务器。目前有三种IP负 载均衡技术（VS/NAT、VS/TUN和VS/DR）；八种调度算法（rr,wrr,lc,wlc,lblc,lblcr,dh,sh）。是国内互联网普遍使用的负载均衡策略。
Web Server：
Web服务器是指驻留于因特网上某种类型计算机的程序。当Web浏览器（客户端）连到服务器上并请求文件时，服务器将处理该请求并将文件反馈到该浏览器上，附带的信息会告诉浏览器如何查看该文件（即文件类型）。常见的web服务器有Apache、nginx等。
Servlet容器：
servlet容器是Web服务器或应用程序服务器的一部分，用于在发送的请求和响应之上提供网络服务，解码基于MIME的请求，格式化基于MIME的响应。Servlet容器在Servlet的生命周期内包容和管理Servlet。常见的Servlet容器有：Tomcat、JBoss、Jetty等。
————————————————
三、了解业务模型
对被测产品哪些功能点需要测试，哪些不需要测试，哪些并发量高，哪些业务比较特殊，这些都需要通过前期调研来确定。根据产品是否上线可以分为两种情况：
已上线产品
对已上线产品，需要根据线上数据统计来确定产品的典型业务有哪些，典型业务的比例是多少，来确定产品的业务模型，生成相应的压力模型。
比如我们的博客产品，典型的业务包括：博客首页、获取博文列表、查看博文、发表博文、评论博文等。
数据统计有几种方式获得：通过我们的BI统计平台获取、或者通过webserver的访问日志进行分析和数据处理获取。
获取的数据包括：top N产品业务、业务的日PV量、业务之间的比例，根据这些统计数据来确定典型交易和配置比例。
未上线产品
对未上线产品的典型业务抽取可以参考同类已上线产品，比如云音乐产品，可以参考同类的虾米音乐等，抽取典型的业务交易。在业务配比上或者无同类产品可以参考的情况下，建议进行单场景或组合场景的测试，不以性能预估为目标，以发现性能问题、性能瓶颈，进行性能调优为目标。 对典型业务的抽取原则可以参考章节 下面的章节：选取性能测试点。
————————————————
四、选取性能测试点
性能测试点是测试需求分析中非常重要的一个环节，针对一个较复杂的功能繁多的系统，如何设计出有效的测试场景，最大程度上覆盖系统的性能问题和瓶颈点，这需要较多的经验积累。目前我们可以按照以下原则来进行部分测试点的抽取：
核心业务功能
首先要覆盖产品的核心业务功能。如印象派产品要覆盖商品查询，商品详情，商品购买等核心业务。SDFS产品要覆盖文件上传、下载核心业务。
并发量较高的业务功能点
如我们的博客产品，用户浏览博文会比较频繁，大量的用户同时阅读博文会造成频繁的数据库读取操作，且数据量相对比较大，响应时间会不会比较慢等情况。
业务逻辑较复杂的功能点。
有复杂数据库操作或事务的功能点。
会有较频繁的磁盘读写操作的功能点。
根据线上日志分析 如线上nginx的access.log，对日志进行分析。获取请求量较高的top URL，当然要过滤一些比如静态文件访问等操作。
Web应用，性能测试点：
业务统计中几种典型业务的比例
调用频繁、占用空间大的数据库表的交易
占用最大存储空间或其它资源的交易
对磁盘、常驻内存的数据过度访问的交易
直接针对每个需求点选取功能点（如上载响应的测算选取上载操作最多的功能）
8.后台应用，性能测试点：
读（查询），写（增删改），读写（增删改查）混合
服务器配置项
功能的实现方式：同步和异步，轮询和notify等
分布式特性：单客户端和多客户端，单节点和多节点
数据规模：如数据库已存在大量记录和存储可用空间少
缓存：文件系统缓存和数据库缓存的利用等
五、了解运维数据
对于已上线产品需要了解线上运维数据，作为性能分析和预估的主要数据支持，包括日交易量，日UV数、日PV数、同时在线用户数、最大并发用户数（名词解释参考：第一节 业务指标）。
了解日PV趋势图，也就是在一天24小时内，以10分钟或其它粒度作为取样点，绘制PV数变化趋势，可以了解该产品的PV 80%在什么时间段发生，PV峰值是多少，一般情况下要满足PV峰值。
————————————————
六、了解数据规模
性能测试需要准备的数据分主要包括两部分：铺底数据和测试数据。
铺底数据
正式测试之前，数据库中已经存在的数据，这部分数据的量对性能影响比较大，特别是查询类的业务，性能差异会非常大。例如，数据库的查询，在数据量比较小的时候，响应时间相对比较快，但是随着数据量的增加，性能急剧下降，查询语句的性能问题暴露出来了。性能测试中应当极力避免基于空的数据库进行测试。
测试数据
测试脚本中需要使用到的数据，测试执行之前，应该准备一批特征和真实线上活跃业务数据接近的数据。测试数据准备的好坏对性能影响也比较大，甚至会因为测试数据不合理而导致性能问题未被发现的案例。
例如某个查询业务，需要传入正则表达式的查询条件，在条件比较少时，性能很好，但是随着查询条件增加时，因大量使用到了反射且类无法回收，导致Perm区OOM。测试数据的准备过程一定要细致，力求和线上接近。
数据规模
在数据准备阶段，需要先梳理线上数据的规模，主要是数据库中表的数据量，表之间的关联关系，数据的分布的规律，热点数据的数据量，分布等。在测试环境准备特征接近的测试数据，以使测试结果更准确。
测试数据的准备一般有以下的几种方式：
方式1：备份恢复
实施过程：线上镜像库的数据备份恢复，对数据敏感字段进行梳理，例如身份证，手机号等，统一更新可知的字段的值。
优点：数据真实，字段更新后，可以直接作为测试数据，也比较真实。
缺点：需要梳理数据库关键表的字段并进行更新，表的数据量比较大，更新会比较耗时。
方式2： 导入部分数据
实施过程：从线上的备库，抽取一定比例(根据硬件配置来确定)的数据导出，并根据关联关系把相关的表的数据也抽取导出，再load进新的数据库。基于load进来的数据，进行脱敏，更新敏感信息字段为已知字段。
优点：操作的数据比较小量，且能够保持线上的表之间的关系以及数据量的比例，比较适中的一种方式。
缺点：导出的数据可能会有遗漏，需要对数据库表以及表之间的关系进行梳理。
方式3： 造数据
实施过程：通过接口测试代码或者测试脚本往数据库造大量的测试数据。造数据之前需要先分析数据的分布特征，按照分布来造数据。
优点：不会涉及到线上数据，不存在敏感数据。
缺点：数据的准备会比较复杂，大量的数据之间有关联关系，且造出来的数据和线上的数据分布差异比较大。需要先对线上的数据的分布规律进行分析，相对比较耗时间。
性能测试过程中，可以根据实际情况，选择合适的数据准备方案，在有条件的情况下，推荐方式1和方式2。
————————————————
七、设计测试方案
了解整个产品架构、业务类型、数据规模等情况，进行性能测试分析之后，需要设计具体的性能测试方案。
性能测试方案主要覆盖的用例点，需要根据产品架构，业务类型进行设计，尽可能多的覆盖核心业务、尽可能覆盖系统架构中的核心模块。
业务的抽取除了基于产品设计文档，也可以根据线上日志统计获取，如抽取Top 20%的业务或接口进行覆盖。但仅仅抽取这些不一定够，还需要根据具体的业务重要程度进行补充。
执行策略
针对抽取出的性能测试点，在测试执行上通常会采取先进行单场景测试，然后组合场景测试、最后为整个产品建立测试模型，进行整体性能评估。也可设置benchmark基准点，持续跟进产品基准变化趋势，预示产品风险。
什么是场景？
有必要先介绍下场景的概念，场景是应用运行时的一个剖面，一般来说，一个场景可以被表述为：x％的用户在操作A业务，y％的用户在操作B业务，z％的用户在操作C业务
场景不同就意味着系统在被以不同的方式使用，在不同的场景下，很可能系统的性能表现就会不同。
单场景测试
评论(2)