性能测试计划 就应该这么写
性能测试的分析方法有哪些
性能分析是一个大课题，不同的架构、不同的应用场景、不同的程序语言分析的方法有差异，具体分为两类。
（1）白底向上：通过监控硬件及操作系统性能指标（CPU、内存、磁盘、网络等硬件资源的性能）来分析性能问题（配置、程序等的问题）。因为用户请求最终是由计算机硬件设备来完成的，做事的是CPU。
（2) 自顶向下：通过生成负载来观察被测试的系统性能，比如响应时间、吞吐量，然后从请求起点由外及里一层一层分析，从而找到性能问题所在。
不管是自底向上还是自顶向下，关键点就是生成负载、监控性能指标。
上面我们说了两种方法，大家会问哪一种方法更好呢？哪种方法更简单一点呢？我想说的是方法无所谓好坏，只是一个思路。对于没有经验的性能测试工作者，提倡自底向上；对于经验丰富的性能测试工作者，先用自顶向下的方式解决掉明显性能问题，再结合自底向上的方式分析更深层次的问题。
性能测试计划
A. 1 性能测试背景
公司准备架设一个面向社会的技术分享论坛，主要针对群体是 Java 开发人员、测试人员。受众主要是Java 开发人员，所以选择Java 开发的论坛更为合适。Jforum 是著名的开源论坛，采用 Java 开发的功能强大且稳定的论坛系统；它提供了抽象的接口、高效的论坛引擎以及易于使用的管理界面，同时具有完整的权限控制、多语言支持（包括中文）、可自定义的用户接口、支持多数据库、高性能、安全等特性；支持包括简体中文在内的多国语言，Jforum 功能强大，界面简洁友好，采用 BSD 授权，免费不用担心版权纠纷。
由于论坛面向社会，具备一定的访问量，需要进行性能测试来评估 Jfroum 性能、分析性能变化趋势、分析系统瓶颈风险、帮助规划系统容量、为硬件采购提供建议。
A. 2 性能测试目标
（1) 基于论坛业务量的要求，评估JForum能否满足性能要求。
（2) 进行配置测试，找到相对合理的配置。
（3) 对JForum进行定容定量，提供规划参考。
（4) 验证系统的稳定性，验证系统的容错能力。
（5) 测试并找出系统可能存在的性能问题，分析系统瓶颈风险。
A. 3 性能测试范围
通过性能测试需求调研，分析用户使用行为，对系统的用户及业务数据量作了定量分析，性能测试将主要集中在表A-1中列出的业务过程。
▼表A-1——测试范围
A. 4 名词术语约定
● 负载：模拟业务操作对服务器造成压力的过程，比如模拟100个用户进行发帖。
● 性能测试（Performance Testing) : 模拟用户负载来测试系统在负载情况下，系统的响应时间、吞吐量等指标是否满足性能要求。
● 负载测试（Load Testing) : 在一定软硬件环境下，通过不断加大负载（不同虚拟用户数）来确定在满足性能指标情况下能够承受的最大用户数。简单说，可以帮我们对系统进行定容定量，找出系统性能的拐点，给予生产环境规划建议。这里的性能指标包括TPS (每秒事务数）、RT (事务平均响应时间）、CPU Using (CPU利用率）、Mem Using (内存使用情况）等软硬件指标。从操作层面上来说，负载测试也是一种性能测试手段，比如下面的配置测试就需要变换不同的负载来进行测试。
● 配置测试（Configuration Testing) : 为了合理地调配资源，提高系统运行效率，通过测试手段来获取、验证、调整配置信息的过程。通过这个过程我们可以收集到不同配置反映出来的不同性能，从而为设备选择、设备配置提供参考。
● 压力／强度测试（Stress Testing) : 在一定软硬件环境下，通过高负载的手段来使服务器资源（强调服务器资源，硬件资源）处于极限状态，测试系统在极限状态下长时间运行是否稳定，确定是否稳定的指示包括 TPS、RT、CPU Using, Mem Using等。
● 稳定性测试（Endurance Testing) : 在一定软硬件环境下，长时间运行一定负载，确定系统在满足性能指标的前提下是否运行稳定。与上面的压力／强度测试区别在于负载并不强调是在极限状态下（很多测试人员会持保守观念，在测试时会验证极限状态下的稳定性）， 着重的是满足性能要求的情况下，系统的稳定性？比如响应时间是否稳定？TPS是否稳定？一般我们会在满足性能要求的负载情况下加大1. 5到2倍的负载量进行测试。
● TPS: 每秒完成的事务数，通常指每秒成功的事务数，性能测试中重要的综合性能指标。一个事务是一个业务度量单位，有时一个事务会包括多个子操作，但为了方便统计，我们会把这多个子操作计为一个事务。比如一笔电子支付操作，在后台系统中可能会经历会员系统、账务系统、支付系统、会计系统、银行网关等，但对于用户来说只想知道整笔支付花费了多长时间。
● RT/ART (Response Time/average Response Time) : 响应时间／平均响应时间，指一个事务花费多长时间完成（多长时间响应客户请求）， 为了使这个响应时间更具代表性，会统计更多的响应时间然后取平均值，即得到了事务平均响应时间（ART) , 为了方便大家通常会直接用 RT来代替 ART, 以后看到ART与RT是代表同一个意思。
● PV (Page View) : 每秒用户访问页面的次数，此参数用来分析平均每秒有多少用户访问页面。
A. 5 测试环境
A.5.3生产环境硬软件配置
生产环境硬软件配置如表A-2所列。
▼表A-2——生产环境硬软件配置
A.5.4测试环境软硬件配置
测试环境软硬件配置如表A-3所示。
▼表A-3——测试环境软硬件配置
A. 5. 5 负载机软硬件配置
负载机软硬件配置如表 A-4所列。
▼表A-4——载机软硬件配置
A. 6 需求分析
需求分析分为两部分，先进行性能需求采集；主要通过研习需求文档，走访关键干系人来完成；然后对采集的信息进行分析，确定性能测试范围与性能指标。
A. 6. 1 业务模型
从需求中获取到如图A-3业务模型。
▲图A-3业务模型模型
表A-5是业务量统计。
▼表A-5——业务量统计
表A-6是存量数据的统计。
▼表A-6——历史数据统计
注：考虑到3年之内系统数据不会进行归档操作，需要保留3年的业务数据，所以测试时需要准备3年的业务数据作为存量（历史）数据，发帖存量数量：
（0. 34万PV*365) + (0. 34*365* (1+30%) ) + (0. 34*365* (1+30%) ”） ≈495. 2万条。
A. 6.2 性能指标
A. 6.2.1 业务性能指标
业务统计如表A-7.
▼表A-7——业务统计
综合一下上午10点是访问高峰，PV约5208 (登录、浏览、回帖、发帖合计）， 按80/20 原则计算TPS=5208*80%/ (3600*20%) ≈5. 8, 具体如表A-8.
▼表A-8——业务指标
A.6.2.2 硬件性能指标
硬件指标如表A-9.
▼表A-9 ——硬件指标
A. 7 测试策略
此次性能测试的目的是：
（1) 基于论坛业务量的要求，需要评估一下 JForum 能否满足性能要求。
（2) 进行配置测试，找到相对合理的配置，充分利用硬件设备。
（3) 对Jforum进行定容定量，提供规划参考。
（4) 验证系统的稳定性，验证系统的容错能力。
（5) 测试并找出系统可能存在的性能问题，找出系统瓶颈。
测试采用 JMeter 来模拟用户请求，针对测试目标会进行多轮的测试：
第一轮在测试过程中尝试多种不同的配置进行压测，优化系统参数的配置，找出可能存在的性能问题。
第二轮进行定容定量的测试，为系统扩展提供参考，同时也回归上一轮修改的性能问题，
第三轮进行稳定性的测试，验证系统容错能力。
测试开始前准备足够的存量业务数据，测试执行过程中也需要持续一段时间，确保结果的普遍性、可参考性；同时监控系统硬件性能指标与中间件及数据库性能指标，确保能够全面的对系统性能进行评估。
A. 7. 1 测试执行策略
测试执行策略如表A-10.
▼表A-10——测试执行策略
A. 7. 2 测试监控策略
测试监控主要在于以下两个方面（见表A-11) .
（1) 业务性能指标：TPS与RT等。
（2) 硬件性能指标：CPU、Mem、Disk 等。
▼表A-11——监控策略备注
A. 8 测试场景
配合上面的测试策略，设计测试场景，其中并发数根据业务量进行换算所得，做为负载量参考，在测试执行过程中会根据TPS及ThinkTime 进行并发用户数的调整。
说明：
（1) Sec_101 基准测试，在执行时分两种情况，先单业务执行，再混合业务执行：虚拟用户数都为1个。
（2) Sec_102 配置测试，按业务量的占比来加载虚拟用户数，尽量在模拟用户实际使用情况的前提下来进行配置测试，这样调整的配置才是最适合实际使用的配置，虚拟用户数参照负载测试中的数量，在测试过程中根据需要扩大。
（3) Sec_103负载测试场景，此场景下对系统进行定容定量测试，找出系统性能变化趋势，找出性能瓶颈或者性能风险。测试时并发用户数以场景设计中的数量为基准按比例进行递增。
（4) Sec_104 稳定性测试，重点关注系统的稳定性，需要通过长时间的运行验证：按惯例要求不低于8小时，在此我们计划运行12小时。
A. 9 测试准备
测试前准备工作如下。
（1) 测试工具准备，包括负载工具、监控工具、文档管理工具等。
（2) 测试脚本及测试程序准备。
（3) 测试数据准备。
（4) 测试环境准备。
A. 9. 1 测试工具准备
测试准备见表 A-13.
▼表A-13——测试准备
A. 9. 2 测试脚本及程序准备
测试脚本开发计划见表A-14.
▼表A-14——测试脚本开发计划
A. 9. 3 测试数据准备
测试数据准备计划见表A-15.
▼表A-15——试数据准备计划
A. 9. 4 测试环境准备
测试环境准备见表 A-16.
▼表A-16——测试环境准备