建模性能测试

的目的负载测试是模拟真实的用户活动在应用程序上。如果使用非代表性用户的旅程,或者适当的负载政策未定义,应用负载下的行为将无法被适当验证。

建模性能测试不需要技术技能,只是时间充分理解应用程序的来龙去脉:

• 系统上的用户如何工作;他们的习惯
• 时间/地点/多久他们使用应用程序
• 外部事件和活动的山峰有什么关系?
• 该公司的商业计划相关应用程序活动?
• 用户社区会在不同的地域扩张?
• 有营销计划专注于应用推广吗?如果是,观众是谁?
• 有层架构共享与其他系统?

完全理解应用程序性能建模期间,以下涉及到的角色应该:

• 功能架构师
• 业务分析师(s)
• 项目负责人

当然,不同的功能角色提供不同的反馈。目标应该是了解应用程序中,最终用户的习惯,和应用程序当前/未来的关系状态的组织。

系统日志或数据库抽取,也可以是有用的。这些很容易指出主要组件和功能区域目前用于生产。他们还将检索的事务数/小时/业务流程。

• 在考虑用户负载时,重要的是要注意并发用户的数量和用户的数量在预期的观众。应用程序交付给5000用户可能只有500用户同时访问它。
• 如果没有任何估计的体积最大的并发用户,用户的数量可以计算基于交易的数量/小时/业务操作。

建立服务水平协议(sla)和服务水平目标(SLOs)

服务水平协议和服务水平目标是自动化的关键和性能验证。项目负责人和功能架构师需要定义理想为应用程序的响应时间。没有“标准”的响应时间。

sla / SLOs使性能工程师提供状态性能测试结果。与这些性能测试可以很容易地自动识别性能之间的回归几个版本的应用程序。

如果的重要性组件测试和性能测试是正确理解在项目早期阶段,组件级SLA或SLO必须定义,使成功的自动化。

测试选择

每一次测试运行将解决一个风险,并提供状态的性能需求。

大多数项目只关注应用程序的限制。这是很重要的验证规模和体系结构配置。然而,它最有可能不能回答所有的性能需求。

还有其他的测试需要运行正确,应用程序的性能。这些测试将有助于验证性能要求:

• 单元测试:许多项目忽略了单元测试的力量。不开始运行负载测试,如果用一个单用户性能是不能接受的。允许应用程序进行单元测试仪器做深度分析工具和为开发人员提供有用的信息。这一步应该是一个强制性的任何负载测试策略的一部分。

• 连接测试:假设每天早上,所有应用程序的用户连接到系统在大致相同的时间,然后抓起一杯咖啡或与同事聊天。即使没有重大活动应用程序的业务组件,架构必须处理这个峰值用户会话场景。它应该是显而易见的,确保系统不会打破每次发生这种情况。生活会更容易为运维团队验证这一点。这个测试将增加所有预期的用户。

• 生产活性试验:每个应用程序都有主要业务操作。这些行为常常导致数据被更新或插入到数据库中。因此,应该有一个好的理解每天创建的记录的数量/小时。生产活动测试确保系统可以处理负载相关事务的数量/小时预计在生产。这个测试将负载/验证数据库中的业务组件的行为。这种类型的两个主要要求试验每用户事务的数量/小时的旅程和适当的思考时间。
• 峰值测试:每个应用程序体验高峰卷。即使这些山峰一样很少出现一年一次或两次,它是强制性的,以确保应用程序可以处理它们。峰值测试的目的是模拟用户在短时间内的一个重要增加(例如,一个零售网站的模拟活动造成典型的假日销售狂热)。

• 浸泡测试:可用的应用程序/架构很可能几天甚至几个星期。没有专用*为维护任务,是很重要的架构将没有失败长期运行。浸泡测试运行一个常数的用户数量在较长时间框架。这个测试,它将容易识别任何内存泄漏/网络连接,这样你很容易监测环境的稳定当前的配置。

• 批量测试:有些应用程序设计与异步任务或批次。什么是上一批真实用户的影响?批量测试运行的生产活动和触发执行批处理在一个特定的测试。目的是找出如果批处理有任何对用户体验的影响。

一些其他的负载测试可以利用的限制取决于业务和用户的位置。总有事件相关的公司/组织,会影响应用程序的负载。

例如,负载为交易而设计的应用程序将取决于不同市场的开放时间。应用程序有三个典型的阶段:一个用于亚洲用户,第二个为欧洲用户加上额外的亚洲用户,第三为美国结合用户来自这三个地方。每次市场打开或关闭,有山峰交易活动。因此,测试将包括不同的负载类型结合各种组合的商业用途。

另一方面,也有测试是为了验证平台的可用性在维护任务或生产事故:

• 故障转移测试:此测试程序的目的是要模拟生产环境上的失败。这种类型的测试是强制验证环境的可用性,以确保故障转移集群机制正常反应。建筑有N个节点时,重要的是要验证N - 1或- 2节点可以处理预期的负载(在生产过程中避免事件级联问题)。运维团队可能也感兴趣的是他们是否能完成维护任务,而无需设置应用程序进入维护状态。大多数高可用性应用程序有很多的节点在不同层架构:web服务器、应用服务器、数据库等。每层应该有一个测试。

• 恢复测试:退化的反面测试,恢复测试是由停止的一个节点,然后重新启动应用程序时加载。它的目的是看看节点对post-restart沉重的负载。

此外,可能会有操作情况,包括在负载测试测量应用程序行为当缓存清理。

另一个点,可能会影响应用程序的性能:数据。通常负载测试时,测试数据库和使用较少的数据,或者至少一个数据库被匿名安全目的。匿名过程通常从相同的字母/数字创造了记录。所以,在负载测试期间使用的所有索引将无与伦比的的正常的生产数据库。

数据在生产迅速增长。数据库的行为是完全不同取决于数据库的大小。如果数据库的生命周期很长,那么它可能意义来验证不同大小的数据库的性能来决定是否有轻型和重型之间的限制是不同的数据库。为了达到这个目标,一个大型数据集应该使用指向数据库的各个领域(例如,从不使用的名称列表中所有的账户从AA或AAA2)。相反,让一组代表性的数据从a到Z。

测试的类型和复杂性会改变项目生命周期期间:

包括思考时间

性能设计的一个重要元素,认为时间是由一个真实用户所需的时间在两个业务操作:

• 时间阅读信息显示在屏幕上
• 时间填写信息的一种形式
• 其他实际用户操作不会导致与应用程序服务器的交互

因为每一个真实的用户行为不同,思考时间永远是不同的。因此,重要的是:

• 收集每个业务步骤的思考时间在每一个场景。避免为每个步骤使用相同的思考时间。总有屏幕显示信息,最终用户需要阅读或表单之前他们需要填写进展到下一步。应该有一个特定的思考时间为每一个行动。
• 计算平均最低思考时间和平均最大思考时间/行动。
• 让负载测试工具随机选择一个思考时间从一个指定范围(最小和最大)。

想象大的应用程序是一个城堡的墙和门。组件将被验证(通过负载测试)是在城堡。墙将代表代理服务器、负载平衡器、缓存层,防火墙等。

如果测试运行没有包括思考时间,那么只有大门将会受到冲击。好吧,它可能打破,但有很大的机会,它将锁定一切后很短的时间内。温柔,聪明,躲避防御。大门将允许入口,城堡的内部组件位于将能够正确加载测试。

验证用户体验

正如前面提到的,一旦应用程序组装、测试目标会改变。在某种程度上,用户体验的质量也需要验证。

移动应用,富Internet应用程序(RIA),和复杂的AJAX框架具有挑战性的方式大多数都是用来测量响应时间。在过去,测量仅限于下载时间和时间第一个字节(TTFB)。

这种方法没有意义,因为大部分的呈现时间,导致用户体验取决于当地ActiveX / JavaScript或本机应用程序逻辑。因此,测试测量不能仅限于TTFB和下载时间,因为主要目标是验证全球应用程序的用户体验。

衡量用户体验是可能的通过结合两种解决方案:负载测试软件(188金宝搏官网登录app188金宝搏app苹果下载软件Tricentis NeoLoad)和一个基于浏览器或移动测试工具。

的负载测试工具将产生98%的负载应用程序。基于浏览器或者手机测试工具会生成其他2%的负载来获取真正的用户体验(包括呈现时间),而应用程序被加载。

这意味着要监视的业务流程和事务由浏览器/手机解决方案需要仔细确认。

监控

没有监控的运行测试就像看恐怖片在广播中。不知道为什么你会听到人们尖叫。监测是唯一办法相关指标体系结构的行为。

然而,许多项目往往缺乏性能监控由于:

• 缺少的工具
• 需求的恐惧需要启用监控

尽管监控并不局限于不同服务器的操作系统(s),其目的是为了验证每一层的架构是可用的和稳定的。架构师需要时间来构建最聪明的架构,所以有必要测量不同层次的行为。

监控允许更全面的理解体系结构和调查的行为环境的各个部分:

• 操作系统:CPU、内存、磁盘和网络利用率
• 应用程序服务器:内存利用率、垃圾收集器线程使用率,会话
• Web服务器:工人,会话的数量
• 数据库:缓冲池,缓存利用率,交易数量,数量的提交,%索引查询
• 缓存服务器:命中率

许多项目使用生产监控工具来检索指标的体系结构。这个方法不推荐,因为生产监控每个数据点之间有一个大粒度(每2 - 5分钟)。在负载测试中,重要的是要有监测数据收集至少每五秒。性能工程师需要给每一个机会来识别瓶颈。当峰值出现测试期间只有几秒钟,至关重要的是,要有足够的粒度指出瓶颈。

监测要求等技术要求系统账户,要启动哪些服务,防火墙端口打开,等。即使它似乎很难满足这些需求,监控与操作是可能的如果有适当的沟通;提前把他们这些需求会促进沟通。

一个关键应对监测:预测需求处于初级阶段。

下一个步骤

这是第三本系列文章包括四部分,侧重于实际指导现代性能测试:

第1部分- - - - - -一个实际的介绍性能测试

第2部分- - - - - -建立一个性能测试策略

第3部分-建模性能测试

第4部分- - - - - -执行性能测试

《华盛顿邮报》最初是发表在2018年1月,最近更新的2021年7月。