五大高效的性能测试技术分享

　　进入互联网时代，性能测试显得越来越重要，移动应用、web应用和物联网应用都需要进行性能测试和性能调优，而进行性能和负载测试会产生了大量的数据，这些数据难以分析。除了数据分析，我们还会遇到其它一些困难和挑战。

　　今天我们就介绍五大高效的性能测试技术帮助你应对挑战，能进行有效的数据分析，高效地完成性能测试和性能调优。

　　1、识别基于层的工程事务

　　在典型的性能测试工具中，加载脚本会包含事务处理或有序的API调用，以完成业务工作流。例如，我们正在为一个物联网应用程序创建一个性能管理工具，这个脚本将包含代表一个设备的事务处理逻辑或行为。

　　工程脚本包含针对部署的特定层(如网络层、应用层、消息层、数据库层等)的单个事务处理。通过发现工程事务处理的退化，我们可以隔离需要集中精力的部署层。为此，我们需要确定哪些事务到达哪些层。如果在这方面有困难，就不得不向开发或基础架构支持团队寻求帮助。

　　每个部署都是独一无二的，但这里我们可能会遇到一些和层次相关的问题：

　　●Web层：获取静态非缓存文件的事务。

　　●应用程序层：执行一个方法并创建对象的事务，但就停留在这里，没有去访问数据库层。

　　●数据库层：需要从数据库查询的事务。

　　让每个工程事务都有自己的脚本，这样我们就可以分别绘制出每个工程事务的命中率(TPS)和响应时间值。在每个工程事务之前使用一个恒定的思考时间(例如15秒)来间隔执行时间，并创建一个一致的采样率。

　　2、监控KPI

　　前端KPI(关键性能指标)通过关联用户负载、TPS、响应时间和错误率来显示当前的容量。被监视的KPI可以完整地说明为什么应用程序在某个工作负载级别上开始降级。命中率和空闲资源是每个硬件或软件服务器的两个具有启发性的KPI。

　　命中率将随着工作负载的变化而变化。在递增负载测试中，随着工作负载的增加，命中率也随之增加。以下是可以监控的命中率示例：

　　● 操作系统：TCP连接速率

　　●Web服务器：每秒请求数

　　●消息传递：入队(Enqueue)和出队(dequeue)统计

　　●数据库：每秒查询数

　　请记住，每个部署都是唯一的，因此需要确定每个服务器的良好命中率是多少，然后连接上所需的监视。

　　一般我们倾向于监视空闲资源KPI，因为与使用的资源不同，空闲资源的趋势与工作负载相反。正因为如此，可以很容易地在图上识别瓶颈(但如果免费资源不算在内，就得使用已使用的资源)。无论目标是哪个资源，如果它有排队策略，请确保添加一个排队计数器来显示正在等待的请求。以下是可以监控的免费资源：

　　●操作系统：CPU平均空闲

　　●Web服务器：等待请求

　　●应用服务器：空闲的工作线程

　　●消息传递：进入/退出队列等待时间

　　●数据库：线程池中的空闲连接

　　要确定相关的监控KPI或将它们连接起来，首先要研究部署的架构图。接收或转换数据的每一个接触点都是潜在的瓶颈，因此是监视的候选对象。所监视的KPI越相关，性能描述就越清晰。

　　开始启动工程脚本进行性能测试，完成业务工作流程的负载测试。先设置一个缓慢增长的测试(例如，每15秒增加一个用户，最多增加200个虚拟用户)。测试完成后，将所有监控的KPI绘制成图表，并确保它们与测试报告的TPS/工作负载之间存在直接或反向关系。要有耐心，把一切都画出来。从这个测试中收集的信息，在识别性能瓶颈上非常有价值。

　　另外，设置监视间隔以收集每个持续负载的三个值。在本例中，因为每15秒添加一个用户，所以希望每5秒获得负载测试工具示例，因为三个值将作为一个平台图，而一个单一的值将作为一个峰值图，三个值才能形成趋势。

　　也许不是所有的资源都将在架构图的审查期间被捕获，所以启动一个快速增长的负载测试，来发现一些新的资源或新的KPI。这只是一个探测，看看哪些进程和操作系统活动会启动。如果注意到一个外部过程，就可以作为一个KPI候选对象添加到脚本中。

　　3、减少要分析的事务的数量

　　进入了分析阶段，我们需要显著减少绘制并用于分析的事务数量。试图分析数百个带标记的业务事务是没有效率的。所有这些业务事务都使用部署的共享资源，因此只需选择其中一些事务，就可以避免分析瘫痪。至于选择哪些事务，完全取决于应用程序的特性。

　　例如面向单用户负载测试的结果，选择访问页面、登录、响应时间最长的业务事务和响应时间最短的事务。

　　还要包括并绘制所有工程事务。工程事务的数量取决于部署中有多少层：5层等于5个工程事务。

　　现在，不是分析在模拟实际负载的负载测试中执行的所有事务，而是只绘制一个子集，响应时间的图表将不会那么混乱，也更容易分析。但创建性能报告时，需要包括所有业务事务的响应时间。

　　使用分析技能来查看哪个工程事务首先开始降级。命中率和响应时间都将揭示需要集中精力的地方。

　　4、确保可重复的结果

　　对于每个测试场景，运行相同的负载测试三次直到完成为止。对于这三种测试执行，不要调整或更改性能测试工具中的任何内容：不要修改运行时设置、不要修改测试脚本、不要修改测试的持续时间、不要修改负载模式，更不要修改性能测试环境。只允许数据重置或服务器回收，并且只允许在测试运行之间将环境恢复到基线。每个测试场景运行三次，并进行初步分析，以在同一时间验证结果或TPS平台。

　　5、增加负荷

　　增加负载，就是创建并发用户负载场景。先创建一个缓慢增长的阶梯场景，它允许为每个负载集捕获三个被监视的KPI值。换句话说，在添加下一组用户之前，配置缓慢的用户斜坡以维持一个持续时间。例如，如果您每次增加10或100个用户，并每隔5秒收集KPI，那么在增加到下一个负载之前，每个负载集至少运行15秒。是的，这延长了测试(通过减缓斜坡)，但结果更容易解释。不能持续的KPI指标并不是一种趋势。

　　当性能测试时，遵循“一半-两倍”定律会极大地简化性能工程方法。从实现一半的目标负载开始，如果应用程序能加载到一半负载，然后可以把它翻倍到目标负载。如果不能加载到一半的负载，则再次将负载减少一半。如果有必要，可以反复这样做。继续减少一半，直到得到一个可扩展的测试，即使只有10个用户，而虽然目标是10,000!

　　以上内容为大家分享了五大高效的性能测试技术，本文由多测师亲自撰写，希望对大家有所帮助。了解更多软件测试相关知识：https://www.duoceshi.com/xwzx-hydt/