服务器稳定性是最重要的，若是在稳定性方面不可以保证业务运行的须要，在高的性能也是无用的。数据库
正规的服务器厂商都会对产品惊醒不一样温度和湿度下的运行稳定性测试。重点要考虑的是冗余功能，如：数据冗余、网卡荣誉、电源冗余、风扇冗余等。服务器
一些测试方法主要分如下几种：网络
压力测试：已知系统高峰期使用人数，验证各事务在最大并发数（经过高峰期人数换算）下事务响应时间可以达到客户要求。系统各性能指标在这种压力下是否还在正常数值以内。系统是否会因这样的压力致使不良反应（如：宕机、应用异常停止等）。并发
Ramp Up 增量设计：如并发用户为75人，系统注册用户为1500人，以5％－7％做为并发用户参考值。通常以每15s加载5人的方式进行增压设计，该数值主要参考测试加压机性能，建议Run几回。以事务经过率与错误率衡量实际加载方式。ide
Ramp Up增量设计目标：工具
寻找已增量方式加压系统性能瓶颈位置，抓住出现的性能拐点时机，通常经常使用参考Hits点击率与吞吐量、CPU、内存使用状况综合判断。模拟高峰期使用人数，如早晨的登陆，下班后的退出，工资发送时的消息系统等。性能
另外一种极限模拟方式，可视为在峰值压力状况下同时点击事务操做的系统极限操做指标。加压方式不变，在各脚本事务点中设置同集合点名称（如：lr_rendzvous("same");）在场景设计中，使用事务点集合策略。以同时达到集合点百分率为标准，同时释放全部正在Run的Vuser。测试
稳定性测试：已知系统高峰期使用人数、各事务操做频率等。设计综合测试场景，测试时将每一个场景按照必定人数比率一块儿运行，模拟用户使用数年的状况。并监控在测试中，系统各性能指标在这种压力下是否能保持正常数值。事务响应时间是否会出现波动或随测试时间增涨而增长。系统是否会在测试期间内发生如宕机、应用停止等异常状况。优化
根据上述测试中，各事务条件下出现性能拐点的位置，已肯定稳定性测试并发用户人数。仍然根据实际测试服务器（加压机、应用服务器、数据服务器三方性能），估算最终并发用户人数。spa
场景设计思想：从稳定性测试场景的设计意义，应分多种状况考虑：
针对同一个场景为例，如下以公文附件上传为例简要分析场景设计思想：
1）场景一：已压力测试环境下性能拐点的并发用户为设计测试场景，目的验证极限压力状况下测试服务器各性能指标。
2）场景二：根据压力测试环境中CPU、内存等指标选取服务器所能承受最大压力的50%来肯定并发用户数。
测试方法：采用1)Ramp Up-Load all Vusers simultaneously
2)Duration-Run Indefinitely
3)在Sechedule-勾选Initalize all Vusers before Run
容错性测试：经过模拟一些非正常状况（如：服务器忽然断电、网络时断时续、服务器硬盘空间不足等），验证系统在发生这些状况时是否可以有自动处理机制以保障系统的正常运行或恢复运行措施。若有HA（自动容灾系统），还能够专门针对这些自动保护系统进行另外的测试。验证其可否有效触发保护措施。
问题排除性测试：经过原有案例或经验判断，针对系统中曾经发生问题或怀疑存在隐患的模块进行验证测试。验证这些模块是否还会发生一样的性能问题。如：上传附件模块的内存泄露问题、地址本模块优化、开启Tivoli性能监控对OA系统性能的影响等等。
测评测试是用于获取系统的关键性能指标点，而进行的相关测试。主要是针对预先没有明确的预期测试结果，而是要经过测试获取在特定压力场景下的性能指标（如：事务响应时间、最大并发用户数等）。
评测事务交易时间：为获取某事务在特定压力下的响应时间而进行的测试活动。经过模拟已知客户高峰期的各压力值或预期所能承受的压力值，获取事务在这种压力下的响应时间。
评测事务最大并发用户数：为获取某事务在特定系统环境下所能承受的最大并发用户数而进行的测试活动。经过模拟真实环境或直接采用真实环境，评测在这种环境下事务所能承受的最大并发用户数。断定标准阈值需预先定义（如响应时间，CPU占用率，内存占用率，已出现点击率峰值，已出现吞吐量峰值等）。
评测系统最大并发用户数：为获取整个系统所可以承受的最大并发用户数而进行的的测试活动。经过预先分析项目各主要模块的使用比率和频率，定义各事务在综合场景中所占的比率，以比率方式分配各事务并发用户数。
模拟真实环境或直接采用真实环境，评测在这种环境下系统所能承受的最大并发用户数。断定标准阀值预先定义（如响应时间，CPU占用率，内存占用率，已出现点击率峰值，已出现吞吐量峰值等）。取值标准以木桶法则为准（并发数最小的事务为整个系统的并发数）。
评测不一样数据库数据量对性能的影响：针对不一样数据库数据量的测试，将测试结果进行对比，分析发现数据库中各表的数据量对事务性能的影响。得以预先判断系统长时间运行后，或某些模块客户要求数据量较大时可能存在的隐患。
问题定位测试在经过以上测试或用户实际操做已经发现系统中的性能问题或怀疑已存在性能问题。需经过响应的测试场景重现问题或定义问题。若有可能，能够直接找出引发性能问题所在的代码或模块。
该类测试主要仍是经过测试出问题的脚本场景，并能够增长发现和检测的工具，如开启Tivoli性能监控、开启HeapDump输出、Linux资源监控命令等。并在场景运行过程当中辅以手工测试。