3杀手反模式在连续性能测试

这篇文章是关于如何启用系列中第二个性能测试符合连续性能测试和自动化的无缝管道。

第1部分:连续使用詹金斯管道和Kubernetes负载测试

第2部分:3杀手反模式在连续性能测试

第3部分:加速性能分析与趋势和开放API的数据

从第1部分:关键外卖

• 存储所有资产:代码,测试工件,管道,配置等使用SCM(例如,Git)
• 制定共同的分支/标记对齐所有资产的策略
• 分公司在你开始调试CI测试/重新配置需要,然后合并回来

在188金宝搏app苹果下载软件Tricentis NeoLoad,我们与世界各地的许多不同的团队工作。并不是每一个公司实现了在同一卷性能工程实践水平或者在软件开发生命周期的时间间隔。188金宝搏官网登录app没关系。最重要的要记住当决定你的敏捷,DevOps或杂草丛生的软件森林之旅”差距会阻止我们进步超出我们已经决定必须一样吗?”188金宝搏官网登录app

许多人决定建立可持续自动化和连续过程在整个生命周期,包括性能工程和测试,是一个现代的当务之急。

避免“紧赶慢下来”综合症

有一百万的原因为什么我们浪费时间。“返工”并不是唯一的类别值流,甚至关闭。敏捷和迭代产品团队经常构建原型学习问题,产生一种可用的产品。虽然我们都可以改善计划和需求收集,我们常常发现自己无法关闭的工作项,未预料到的依赖和偏差的预期。

在性能测试,很多事情必须在开始的地方:非功能性需求/标准,测试环境中,系统/服务规范、清晰的定义服务水平目标(SLOs)排列在产品、开发、运营团队,测试数据,等等。这些都是通常的嫌疑人,但是这是如何不同当你开始实施性能测试在连续交付过程?

从我们所有的经验与客户和合作伙伴的团队,这里有几个重要教训我们了解需要什么来确保你的旅程不开始关键的阻断剂:

• 测试存储、分支和版本应该匹配的开发和运营模式和周期(例如,功能工作,sprint硬化阶段,等等)。
• 明确滑行着陆促进测试工件的变化在冲刺迅速发布分支中使用持续集成和业务流程平台
• 在测试和调试问题区分实际系统缺陷测试和部署过程的问题

让我们先从第一个拦截器,测试存储策略。

开发人员需求表现“哑巴按钮”,这很好

包装性能测试之前持续构建过程,它需要完全自动化。但对负载测试一个API意味着什么?

性能测试需要在某个地方,你自动CI工作显然可以访问和快速。许多组织已经转移到某种形式的Git-compliance源代码管理(SCM)系统:GitLab, AWS CodeCommit, Azure回购,Bitbucket都等。

考虑到存储性能测试等单一的筒仓的微焦点演艺中心隔离性能工程活动的现代自动化生命周期(ALM)在CI工具(例如,詹金斯、TeamCity、竹、数字。人工智能释放,娘家姓XebiaLabs XLRelease)。这种方法使得性能测试活动的东西,只有少数有能力做的事情。

一些简化流程鼓励自主,没有

我们最近会见了DevOps /云工程、可伸缩性和性能团队在一个F20 +组织移动的所有微焦点产品。188金宝搏官网app注册虽然他们阐述了现有的经验提供更大的自治权,他们的应用程序和服务开发团队通过创建部署剧本旋转了各种技术堆栈,节点。js和基于java的系统,他们有一个奇妙的点——做一些容易的人也很难学会如何解决问题,如果他们出错。

我们知道这个问题。顾客不知道码头工人或Kubernetes要求诸如原生OpenShift集成让旋转负荷控制器和发电机一个无缝的任务。许多自动化他们的分析过程使用我们的REST api为测试执行,实时fast-fail决心,数据提取,并流可视化工具像Splunk, Kibana,普罗米修斯。他们建造这些,这样开发者就可以按一个“愚蠢”按钮,詹金斯,得到可行的性能结果。

简化Git语义non-CLI精明的人

这就是为什么188金宝搏app苹果下载软件Tricentis NeoLoad提供直接与Git源的集成,所以每个人都可以协作性能测试的细节,版本变更的方式匹配特性/ sprint分支开发源代码,并执行从任何地方,都在几分钟内,而不是时间。

Git在NeoLoad鼓励自主性和各级工程技术人员之间的协作。

对于贡献者不熟悉Git命令行界面(CLI), Git NeoLoad桌面工作台的功能简化,使它容易复制,修改,推到一个特定的分支,并最终与(促进)这些更改合并到其他主流CI / CD的事件。

NeoLoad还支持all-code-based YAML负载测试的描述。不管测试建设和维护的方法,通过图形界面工作站或IDE或您所选择的代码编辑器,NeoLoad加速API负载测试和SLO对齐跨团队通过可视化和达成业绩预期早在周期。

现在,让我们转向的主题如何处理这些版本和分支——在CI“测试推广”。

避免触及每一个分支的方法生产

我们希望我们的代码在生产中,因为这就是它赚钱。性能测试这个过程是至关重要的,也就是因为你不想船糟糕的代码不能在用户面前。但是这种测试带有versionable工件必须匹配测试的应用程序或服务的代码。

这些资产应该相互同步。当多个团队和特性同时飞出了门,如何确保版本是相同的代码和测试资产?你倾向于“测试”的所有事情一样有些厂商使用根植于?

一种无所不在地实现了对这个问题的回答是使用短分支在Git中简化变更的验证和确认测试和自动化流程定义。

分支加速测试推广

尽管trunk-based发展称赞作为首选持续交付策略鼓励小,频繁的变化,值得承诺一个一致的代码(这是一个值得称道的目标),考虑到分支中扮演重要角色的语义从作品的在您的机器上生产,即使在这种方法。Gitflow等其它代码集成模型和基于流的版本控制也继承这一问题,在大多数情况下是通过使用持续集成和编制平台删除从您的本地机器代码和繁殖端到端组装、测试、包装、部署、验证,并释放语义(通常)封闭的环境。

性能测试的CI、管道通常构造,人类或其他进程(例如,其他主管道,JIRA,人,和聊天机器人)可以触发自动化。你构建,让他们为测试套件工作匹配当前版本的应用程序或服务,然后呢?代码/环境配置更改和测试同样也必须改变。你已经有了工作管道工作版本和测试,如何确认该版本的软件和新测试工作吗?188金宝搏官网登录app

答案- - - - - -新版本代码和测试,也许使用分支命名相同的跨应用和测试库,或者使用Git标签匹配这些资产。由于功能工作或者in-sprint-based性能测试,你可能会克隆当前工作测试套件,修改它并运行本地负载测试,然后检查它到一个新的分支,管道运行分支测试资产的最新版本的服务在预发布环境中。你甚至可能版本管道代码正确与所有这些资产,这样一旦你证明一切的工作,促进(例如,合并)这些分支在不同的存储库同时发生。

案例研究:财富20 sr构建可伸缩CI约定

在之前提到的谈话中,我问DevOps工程师代表一些什么最痛苦的工作。几乎一致,他们告诉我,这是模式和惯例跨多个云平台建设。虽然他们没有部署容器内部可伸缩的方式,移动到微软Azure,现有关键云计算,大量的VMware自动化,和谷歌的云平台,为开发团队创造剧本的想法和辅助脚本部署新服务是他们团队的日常挑战。

在这种情况下,不同的是,他们使用TeamCity最终CircleCI自动化这些剧本,本质上允许的目标完全自动化驱动运动来提高整个组织的行为。他们有188金宝搏app苹果下载软件Tricentis NeoLoad周围,因为在他们看来,NeoLoad平台是唯一的负载测试和性能的解决方案,可以适合所有企业方面的现代,遗产,使用这种自动化模型和混合应用。Git支持,通过开放的基于rest的api访问数据,和灵活性来运行测试时,只要他们想要,适合他们的需要。

他们扩大了这些模式在各种云和容器提供商,自动化管道,使用简单的配置切换控制单元,集成、功能、回归、和性能测试执行允许多个开发团队在高级别上遵守风险要求。当然,一个布尔值切换需要测试和数据来完成,所以他们创造了基于约定的存储库和目录结构行为的团队可以期望在每个管道项目包含这些项目特定的工件。这使得它开发和性能工程师使用NeoLoad Git和YAML-based测试项目详细说明测试语义和目标在一起。

忽略的冲动解决测试问题的“主”分支

当性能测试失败时,不仅对理解为什么他们失败是至关重要的传统做深度分析过程但通知自动化/在管道的指标。

困难时团队不想他们可以信赖这些通过/失败的警告标志。

能够确定哪些自动化过程的一部分需要修改是让他们运行的关键。根据我们的经验,有独立版本的管道帮助工程师fault-isolate诊断问题,正确,验证,那么他们的变化融入生产版本的自动化过程。

数量我们已经看到连续的性能测试失败的一个原因是当人们还没有学会测试他们的价值变化——忽略更新这些管道无意中使他们看起来片状或折断。

分支之前变更;快速开车去可以合并修复

之前更改您的测试自动化/管道代码,或基础设施的描述(Dockerfiles Kubernetes部署文件,厨师脚本,等等),创建一个新的分支。他们都很便宜,一次性,希望短暂的。

然而,经典的单片自动管道这就产生了一个问题:你必须创建“候选”副本的CI工作和配置?答案是“通常不是。“比如,詹金斯multibranch管道,让你指向一个回购,但自动为每个分支维护单独的管道。

当还配置了支持拉/变更请求,您可以创建工作流,允许测试分开重新配置和验证发生管道的生产版本,直到最后一个已知修复工作和准备其余的团队运行。

区分“硬”和“软”故障

性能测试包含大量的数据,而不是每个失败意味着同样的事情。这里有一些他们失败的原因:

• 应用程序/服务无法处理的压力负载测试

• 基础设施供应不能执行的负载测试
• 一个或多个服务水平目标(有时称为sla工具)是违反了
• 网络或负载的基础设施和目标系统之间的连接(s)是错误的
• 验证证明完成交易失败(应该)

在这些情况下,高层去/不方便使用的指标CI工作是至关重要的,但也不足以诊断发生了什么,如果有什么需要修正。例如,流程指标如NeoLoad的命令行界面(CLI)退出代码提供早期故障级别的细节通知管道try / catch和编制事件语义。在第一个例子中,测试是成功执行,但几个关键的SLA违规行为发生:

在第二个例子中,负载的基础设施(Docker-based詹金斯构建节点)有一些附加问题詹金斯由于新的安全约束,因此完全无效测试:

更进一步,NeoLoad API总结数据可用于确定成功或失败的背景:

此外,可以用类似的方式检索特定的SLA数据从不同的API端点:

正确的细节级别的手,甚至在一个简单的bash脚本卷发,团队可以快速识别最重要的因素管道可能不是工作的原因。小,可以理解这些变化自动化构件将会节省你大量的时间。

下:现代快速反馈、分析和趋势

在本系列的最后一篇文章,加速性能分析与趋势和开放API的数据,我们看看将连续性能实践让你。简而言之,系统更好,更快的失败/修复周期,和更少的技术债务。

《华盛顿邮报》最初是出版于2019年,是最近更新的2021年7月。

一定要检查我们的白皮书连续性能测试的实用指南在开始务实的建议和帮助。