1、脚本模板
2、 场景模板
性能测试工具选择
1. 数据建模工具
DataFactory是一种强大的数据产生器，它许可开拓职员和QA很随意马虎产生百万行故意义的精确的测试数据库,该工具支持DB2、Oracle
、 Sybase、SQL Server数据库，支持ODBC连接办法，无法直策应用MySQL
数据库，可间接支持。
2. 脚本开拓工具
（1） 若考虑脚本运行效率，则可考虑底开拓措辞C或支持异步通信的措辞JS,我们可以分别选择：Loadrunner 或 Node.js
的IDE环境进行开拓。
（2） 若考虑脚本开拓效率，则可考虑代码复用性，可以选择面向工具措辞C#或Java，为此我们可以分别选择：VS2008及以上版本 +对应LR.NET
控件 或者 Eclipse4.0及以上版本 + JDK1.7及以上版本。
3. 压力仿照工具
（1） 若为Java类接口且单机并发数掌握在500内，则可选择Jmeter或者 Loadrunner。
（2） 若为WebService类接口且单机并发数掌握在500内，则可选择SoapUI或者Loadrunner。
（3） 若单机并发数超过500且掌握在5000内，则可选择Loadrunner。
（4） 若单机并发数超过5000，则建议采取负载集群，即采取“中控（Control Center）+ 多机支配（LoadGenerator）”方案。
4. 性能监控工具
4.1 监控工具
无论Windows或Linux
平台，一样平常存在的是一个或一组进程实例，我们可以选择Loadrunner 或 Nmon 来监控。有时为了获取被测运用的一些特性指标，可以选择被测组件自带的性能工具集或监控系统。常见运用做事器监控工具推举如下：
4.2 监控平台
监控机器紧张对被测集群做事器的做事或资源利用情形进行监控，比如各种开源的监控工具，MRTG：流量监控；CACTI：流量预警，性能报告Smokeping:IDC 质量监控；综合监控：Nagios、Zenoss、Ganglia 、Zabbix、Sitescope、Hyperic HQ 等，如下所示：
4.3 第三方监控云做事（APM）
APM供应端到端运用性能管理软件及运用性能监控软件办理方案,包含移动,浏览器,运用,根本举动步伐,网络,数据库性能管理等，支持Java、.NET、PHP
、Ruby、Python
、Node.js、iOS
、Android
、HTML5
等运用性能监控管理，主流云做事包括听云、OneAPM等，如下所示：
性能测试结果剖析
1. 指标剖析
性能测试的指标可分为产品指标和资源指标两类。对测试职员而言，性能测试的需求来自于用户、开拓、运维的三方面。用户和开拓关注的是与业务需求干系的产品指标，运维职员关注的是与硬件花费干系的资源指标。
（1） 从用户角度关注的指标
用户关注的是单次业务干系的体验效果，譬如一次操作的相应快慢、一次要求是否成功、一次连接是否失落败等，反响单次业务干系的指标包括：
a.成功率b.失落败率c.相应韶光
（2） 从开拓角度关注的指标
开拓职员更关注的是系统层面的指标。
a.容量：系统能够承载的最大用户访问量是多少?系统最大的业务处理量是多少?
b.稳定性:系统是否支持724小时(一周)的业务访问。
（3） 从运维角度关注的指标
运维职员更关注的是硬件资源的花费情形。
以上解释了测试职员在选择指标时需站在用户角度去思考，其余为了后续能够更好地剖析问题，更需节制与被测组件特性或运行事理干系的性能指标。
举例来说，常日接口系统均会直接或间接地访问数据库层介质（如Mysql、Oracle、SQLServer等），此时我们需考虑由接口系统产生压力下存储介质的性能情形，常日我们会选择剖析指标如下：
（1） 连接数（Connections） （2） 每秒查询数/每秒事务数（QPS/TPS） （3） 每秒磁盘IO数（IOPS） （4） 缓存命中率（Buffer Hits） （5） 每秒发生的去世锁数（Dead Locks/sec） （6） 每秒读/写字节数（Read/Write Bytes/sec）
2. 建模剖析
2.1 理发店模型
图中展示的是1个标准的软件性能模型。在图中有三条曲线，分别表示资源的利用情形（Utilization，包括硬件资源和软件资源）、吞吐量（Throughput，这里是指每秒事务数）以及相应韶光（Response Time）。图中坐标轴的横轴从左到右表现了并发用户数（Number of Concurrent Users）的不断增长。
在这张图中我们可以看到，最开始，随着并发用户数的增长，资源占用率和吞吐量会相应地增长，但是相应韶光的变革不大；不过当并发用户数增长到一定程度后，资源占用达到饱和，吞吐量增长明显放缓乃至停滞增长，而相应韶光却进一步延长。如果并发用户数连续增长，你会创造软硬件资源占用连续坚持在饱和状态，但是吞吐量开始低落，相应韶光明显的超出了用户可接管的范围，并且终极导致用户放弃了这次要求乃至离开。
根据这种性能表现，图中划分了三个区域，分别是Light Load（较轻的压力）、Heavy Load（较重的压力）和Buckle Zone（用户无法忍受并放弃要求）。在Light Load和Heavy Load 两个区域交界处的并发用户数，我们称为“最佳并发用户数（The Optimum Number of Concurrent Users）”，而Heavy Load和Buckle Zone两个区域交界处的并发用户数则称为“最大并发用户数（The Maximum Number of Concurrent Users）”。
当系统的负载即是最佳并发用户数时，系统的整体效率最高，没有资源被摧残浪费蹂躏，用户也不须要等待；当系统负载处于最佳并发用户数和最大并发用户数之间时，系统可以连续事情，但是用户的等待韶光延长，满意度开始降落，并且如果负载一贯持续，将终极会导致有些用户无法忍受而放弃；而当系统负载大于最大并发用户数时，将注定会导致某些用户无法忍受超长的相应韶光而放弃。以是我们该当担保最佳并发用户数要大于系统的均匀负载。
2.2 压力变革模型
随着单位韶光流量的不断增长，被测系统的压力不断增大，做事器资源会不断被花费，TPS 值会由于这些成分而发生变革，而且符合一定的规律。
图中：a 点：性能期望值 b 点：高于期望，系统资源处于临界点 c 点：高于期望，拐点 d 点：超过负载，系统崩溃
2.3 容量打算模型
以一网站性能测试为案例：
1. 通过剖析运营数据，可以知道当前系统每小时处理的PV数 2. 通过负载测试，可以知道系统每小时最大处理的PV数
即整理得
系统每小时PV处理剩余量 = 系统每小时最大处理的PV数 — 系统每小时处理的PV数
假设该网站用户负载基本呈线性增长，现有系统用户数为70万，根据运营推广操持，1年内该网站发展用户将达到1000万，即增长了14倍。即整理得：
系统每小时PV处理增加量 = 当前系统每小时处理的PV数 14 — 当前系统每小时处理的PV数
每天系统负载增加率 = 100% / 365 = 2.74 % （备注：此处将未来系统用户数达到1000万的负载定义为 100% ）
系统每天PV处理增加量 = 系统每小时PV处理增加量 每天系统负载增加率 24
以是，我们可以知道在正常负载条件下：
系统可支持正常运行天数 = 系统每小时PV处理剩余量 24 / 系统每天PV处理增加量
假设该网站后续支配升级天数已知，这样我们可以知道提前升级的天数：
系统可支持正常运行天数 — 支配升级天数。
性能测试通过标准
1. 所有操持的测试已经完成。
2. 所有操持网络的性能数据已经得到。
3. 所有性能瓶颈得到改进并达到设计哀求。
