涉及到
web服务的功能在不断的增加，对于我们
测试来说，我们不仅要保证服务端功能的正确性，也要验证服务端程序的性能是否符合要求。那么
性能测试都要做些什么呢？我们该怎样进行性能测试呢？
性能测试一般会围绕以下这些问题而进行：
1. 什么情况下需要做性能测试？
2. 什么时候做性能测试？
3. 做性能测试需要准备哪些内容？
4. 什么样的性能指标是符合要求的？
5. 性能测试需要收集的数据有哪些？
6. 怎样收集这些数据？
7. 如何分析收集到的数据？
8. 如何给出性能测试报告？
性能测试的执行过程及要做的事儿主要包含以下内容：
1. 测试评估阶段
在这个阶段，我们要评估被测的产品是否要进行性能测试，并且对目前的服务器环境进行粗估，服务的性能是否满足条件。
首先要明确只要涉及到准备上线的服务端产品，就需要进行性能测试。其次如果产品需求中明确提到了性能指标，那也必须要做性能测试。
测试人员在进行性能测试前，需要根据当前的收集到的各种信息，预先做性能的评估，收集的内容主要包括带宽、请求包大小、并发用户数和当前web服务的带宽等
2. 测试准备阶段
在这个阶段，我们要了解以下内容：
a. 服务器的架构是什么样的，例如：web服务器是什么？是如何配置的？
数据库用的是什么？服务用的是什么语言编写的？；
b. 服务端功能的内部逻辑实现；
c. 服务端与数据库是如何交互的，例如：数据库的表结构是什么样的？服务端功能是怎样操作数据库的？
d. 服务端与客户端之间是如何进行交互的，即接口定义；
通过收集以上信息，测试人员整理出服务器端各模块之间的交互图，客户端与服务端之间的交互图以及服务端内部功能逻辑实现的流程图。
e. 该服务上线后的用户量预估是多少，如果无法评估出用户量，那么可以通过设计测试执行的场景得出这个值；
f. 上线要部署到多少台机器上，每台机器的负载均衡是如何设计的，每台机器的配置什么样的，网络环境是什么样的。
g. 了解测试环境与线上环境的不同，例如网络环境、硬件配置等
h. 制定测试执行的策略，是需要验证需求中的指标能否达到，还是评估系统的最大处理能力。
i. 沟通上线的指标
通过收集以上信息，确定性能
测试用例该如何设计，如何设计性能测试用例执行的场景，以及上线指标的评估。
3. 测试设计阶段
根据测试人员通过之前整理的交互图和流程图，设计相应的性能测试用例。性能测试用例主要分为预期目标用户测试，用户并发测试，疲劳强度与大数量测试，网络性能测试，服务器性能测试，具体编写的测试用例要更具实际情况进行裁减。
用例编写的步骤大致分为：
a. 通过脚本模拟单一用户是如何使用这个web服务的。这里模拟的可以是用户使用web服务的某一个动作或某几个动作，某一个功能或几个功能，也可以是使用web服务的整个过程。
b. 根据客户端的实际情况和服务器端的策略，通过将脚本中可变的数据进行参数化，来模拟多个用户的操作。
c. 验证参数化后脚本功能的正确性。
d. 添加检查点
e. 设计脚本执行的策略，如每个功能的执行次数，各个功能的执行顺序等
4. 测试执行阶段
根据客户端的产品行为设计web服务的测试执行场景及测试执行的过程，即测试执行期间发生的事儿。通过监控程序收集web服务的性能数据和web服务所在系统的性能数据。
在测试执行过程中，还要不断的关注以下内容：
a. web服务的连接速度如何？
b. 每秒的点击数如何？
c. Web服务能允许多少个用户同时在线？
d. 如果超过了这个数量，会出现什么现象？
e. Web服务能否处理大量用户对同一个页面的请求？
f. 如果web服务崩溃，是否会自动恢复？
g. 系统能否同一时间响应大量用户的请求？
h. 打压机的系统负载状态。
5. 测试分析阶段
将收集到的数据制成图表，查看各指标的性能变化曲线，结合之前确定的上线指标，对各项数据进行分析，已确定是否继续对web服务进行测试，结果是否达到了期望值。
6. 测试验证阶段
在开发针对发现的性能问题进行修复后，要再执行性能测试的用例对问题进行验证。这里需要关注的是开发在解决问题的同时可能无意中修改了某些功能，所以在验证性能的同时，也要关注原有功能是否受到了影响
性能测试
是一项浩大的工程，若你只想随便找台机器装上ld后，造几条数据，弄几个并发用户简单跑一下出来结果就可以万事大吉了，那你就大错特错了！（这样得出的测试结果没有任何价值和意义，当然更无法依此评估出你贵公司系统的性能了。
真正开始执行之前除了编写详细的性能测试计划【所需的资源（软件＋硬件＋人力）】、设计测试脚本、准备测试数据、搭建测试环境外，还需要注意一下细节：
如何保证性能测试的顺利开展和执行？
-
首先考虑你性能测试的目标是什么，需要哪些人员协助你才能完成，然后协调相关人员（DBA、网管、开发人员等），保证在真正开展过程中能有效得到他们的协助和支持（性能测试不是一个人就能完成的，除非你“全才”啦）；
-
你计划中需要申请的资源，比如运行contoller的机器，是否符合你的预期要求，Cpu是否有足够的处理能力，安装的操作系统是否符合你的要求（loadrunner9.5除load Generator外都不能安装在64位机操作系统下，若没看清楚安装文件（安装程序下help\install.pdf）中system requirements for installing说明的话，你安装完成会发现自己白忙活了，还得重装OS，然后重来一次）；
-
你要测试的程序是否功能都没问题了，若程序还有变更，请千万不要在录制部分后又变更了，你需要的版本是一个功能稳定的版本，能顺利录制脚本的的版本）；
-
在测试执行前你是否召集开发和相关人员对程序中明显需要优化的地方（你功能测试执行时系统有些功能就无法忍受的慢）进行了优化，这样可以大大缩短你的性能测试周期；
-
在选择loadrunner工具前，一定要慎重，你的程序设计语言和架构及其所运用的技术，此工具是否都支持，不然后续你需要自行开发的脚本就太多了，可能面临重新选择测试工具的严重问题）；
-
分险分析：技术风险、风险分析、分险应对措施和风险监控方法。
设计测试脚本？
- 识别可能的系统性能问题，多与相关人员分析讨论。
- 你所测系统的重点业务是什么？都有哪些角色参与？业务逻辑是什么样的？用户频繁使用的功能是否都考虑周全了？
- 参数化数据的来源？都需要哪些检查点？脚本的精简程度？
准备测试数据？
- 基础数据：要更符合实际需求，人员、角色、初始化数据等；
- 业务数据；要更符合实际业务，数据最好不要相同的数据，无效的数据，要类别丰富、覆盖所有业务逻辑的基础数据；可以通过自动化工具直接生成；数据库脚本生成（单一数据，关联几个表的数据最好不用脚本生成）；用ld生成。
搭建测试环境？
- 网络（带宽、可使用的有效ip地址个数）；
- 服务器的配置；
- 当前测试环境的局限性（无法模拟的测试环境都有哪些）。
需求分析和需求转化
客户的性能需求不可测试、没有需求、需求模糊，要通过与客户、开发人员的沟通获得可测试、可衡量和可量化的性能需求
1.8/2原则
2.经验值
3.平均并发用户数C＝nL/T（n：用户数量[login session的数量]，L：用户平均使用时长[login session的时长]，T：考察的时间段）
4.并发用户峰值：C1＝C＋3√C
