fbpx

什么是班次左测试? 这对 DevOps 意味着什么?

向左移动的测试方法是一种软件测试方法,它更早地将测试要求引入软件开发周期。

 

在过去的几十年里,软件开发已经相当的发展。 如今,性能工程师和测试人员可以将大量自动化、机器学习和 AI 工具集成到他们的测试中。 不久以前,软件测试只是旁注。 事实上,早期的软件开发甚至没有一个正式的测试阶段。 直到软件变得更加复杂,生产环境中的错误和缺陷开始影响业务,测试才开始引入。 开发人员自己执行测试,而不是单独的团队。 这就是功能测试如何出现并成为传统瀑布模型的一部分,该模型由单独的阶段(分析、要求、设计、编码、测试、验收、生产和后期生产)组成,这些阶段通过线性路径移动,类似于工厂中的装配线。

Waterfall Model

瀑布模型由保罗·霍德利。 在知识共享许可证下使用。

 

每个阶段完成后,它传递到下一组,并向下移动。 它在纸面上看起来不错,但 QA 直到大多数这些阶段完成之后才测试代码。 因此,这意味着在生产之前,对代码进行修改的时间非常少。 如果问题或错误足够严重,这意味着放弃或延迟项目。 此外,这意味着潜在的巨大损失,公司,这取决于软件应用程序的意义。

 

向左移测试 – 打下基础

幸运的是,从以前的开发错误中吸取的代价高昂的教训帮助带来了向左移动的方法。 组织意识到,在游戏后期识别问题不仅成本太高,而且风险也大。2019 年 5 月 ,TechRepublic 的一篇文章报告说,修复软件中的视觉错误的平均年成本超过 400,000 美元。 不完全是笨拙的变化。

此外,整个行业都在发生变化。 企业不得不应对数字化转型。 组织开始意识到,他们不能再依赖一到两个发布周期了。 客户的期望和要求很高。 发布设计不良的产品意味着在竞争中失去客户。 有些事情必须改变。

组织开始将开发周期分解为更小、可管理的块,并将测试合并到每个阶段。 这允许一个更具协作性的环境,使团队能够更快地发现问题。 例如,通过更好地了解流程的早期软件要求,测试团队可以帮助开发更好的测试用例来修复任何潜在的错误。 这也称为”早期和经常失败”或”快速失败”。在流程的早期考虑用户方案和软件行为消除了潜在的错误并优化了代码。 这允许团队交付一致的产品。

显然,有时候测试是没有意义的。 例如,在具有 GUI 之前,您不能执行 GUI 测试。 然而,向左移动更多的是一种心态,而不仅仅是一个发展过程。 最重要的是,团队应该始终思考什么能提供更好的用户体验。 归根结底,最终产品掌握在用户手中。 任何在应用程序投入生产之前改进应用程序的东西都使所有人都受益。

 

移位左测试、敏捷和开发的兴起

由于技术进步和对数字体验的关注,出现了范式转变。 开发和测试周期变得更短、更频繁。 这导致新功能更快地推向市场。 最重要的是,这不仅让公司保持竞争力,而且让客户满意和参与。 例如,移动和 Web 应用程序通常在两周发布周期内工作。 有些组织每天发布更新 , 甚至每小时发布一次更新!

应用程序和软件开发的重点是快速、敏捷和降低风险。 组织正在通过敏捷软件开发和 DevOps 实践来应对这一挑战。 敏捷软件开发类似于瀑布模型;然而,关键的区别是,在瀑布模型中,设计阶段之后总会有一个测试阶段。 敏捷方法将开发分解为称为冲刺 (sprint) 的小型迭代,这种迭代不再持续四周。 每个冲刺 (sprint) 都涉及跨职能团队成员处理冲刺 (sprint) 的所有方面,每次迭代都完成测试。 这允许团队成员之间进行更多协作,缩短反馈周期,提高产品质量。

这是关于班次左测试的另一个重要因素。 在传统的瀑布测试中,测试和管理产品质量的责任在于QA团队。 在班次离开测试和敏捷环境中,开发人员和测试人员执行实际测试,但由于开发过程中采用协作的跨职能方法,最终责任落在每个人的责任上。 今天,有四种不同的方法可以转移左测试:传统、增量、敏捷/DevOps 和基于模型的向左移动测试。

 

班次左侧测试的类型

大多数人认为,传统的左移测试将测试移低,稍微向左移动经典 V 模型。

传统的移位左测试

唐 · 火匠的传统移位左测试。 在知识共享许可证下使用。

增量移左测试

唐 · 火史密斯的增量移位左测试。 在知识共享许可证下使用。

增量移左测试非常适合具有硬件依赖性的大型复杂项目。 通过增量测试,它可确保系统的每个部分在进入下一步之前都正常运行。

敏捷/DevOps 班次使测试在短时间内完成,迭代冲刺(sprint)通常执行于开发测试,而不是开发测试。 系统投入运行后,将发生这种情况。

敏捷 DevOps 移位左测试

敏捷/DevOps 班次左测试由唐·火史密斯。 在知识共享许可证下使用。

基于模型的班次左测试

唐 ·火史密斯基于模型的移位左测试。 在知识共享许可证下使用。

基于模型的班次左测试设置,以解决需求阶段的缺陷,其中大多数缺陷被引入。 上述前一班左方法在开发周期中开始测试。 这允许尽早完成测试。

近年来,DevOps 一词已成为营销、软件产品甚至工作描述的流行语。 简单地说,DevOps 是敏捷方法中的一个替代框架,旨在将开发和运营团队聚集在一起。 从历史上看,每个部门都有各自的目标,有时是相互矛盾的。 开发人员创建、设计和创新。 运营团队专注于基础设施,并持续监控”保持照明”,以确保可用性。 同样,DevOps 是专门为在这些部门之间实现更多协作、反馈和敏捷性而创建的。 在谈到 CI/CD(持续集成和持续部署)和自动化时,也提到了 DevOps,但组织使用 CI/CD 和自动化这一事实并不会自动使它们获得 DevOps 认证。

 

DevOps 环境的负载测试最佳实践

如果您的团队采用过时的负载测试和监视方法,DevOps 会快速将您推入性能灾难。 QA 团队必须处理频繁的新版本部署。 除了灵活的监控之外,DevOps 团队还需要一种简单的方法来管理他们的测试,以提供足够的见解。

连续负载测试。

有太多的更改可能会影响 UI 并导致负载测试崩溃。 最初的重点应该是执行完全自动化 的 API 测试 ,并安排它每天运行。 一旦关键业务流程稳定下来,您就可以向测试方案添加其他端到端测试

分享有价值的见解。

让 DevOps 团队参与结果分析活动。 不要练习隐藏信息。 与工程师共享所有负载测试和监控结果,以确定所有问题的原因。

监视所有层。

左移还意味着对开发和 QA 阶段进行生产式监控。 您没有时间在敏捷开发管道中不断重现错误。 确保为非生产阶段收集前端、前端和基础架构利用率指标 24/7。

基线和基准。

连续负载测试会产生大量数据。 设置基线并使用基准在周期早期检测偏差。 您越早了解减速,开发团队处理此类问题的时间越早。

 

将性能测试集成到班次左方法

当今的应用程序利用多种技术,依靠庞大的第三方提供商网络和 CDN 网络。 此外,用户可以从世界任何地方、从任意数量的设备访问您的应用程序,所有这些设备都具有不同的连接速度。 在尝试为用户提供出色的体验时,这有很多要考虑。 响应时间、质量和可用性是推动应用程序投入生产之前需要注意的关键因素。

一旦进入生产阶段,您的应用程序或站点将需要高达数百个,甚至数千个并发用户。 对代码的增量更改会影响性能,因此越早找到与性能相关的 Bug,修复它们就越容易,成本就越高。 在大多数情况下,团队应该能够在一两天内解决任何性能问题。 同样,与发现这些改进进行预部署相比,执行这些改进要容易得多。

理想情况下,一旦代码通过必要的功能测试,并进行了功能审查和注销,团队应执行非功能测试,如压力和负载测试,以查看功能测试项目如何经得起虚拟用户的考验。 LoadView 是班次左测试方法不可或缺的一部分,允许用户使用时间、资金并提供优化的代码和应用程序。

 

LoadView 平台:真实浏览器中的基于云的负载测试

LoadView 平台是一个灵活的负载测试平台,可以解决负载模式无效的问题,模拟从基于协议的测试到基于实际的基于浏览器的测试的所有内容。 它完全基于云,因此无需设置和部署任何内部负载喷射器、管理第三方云帐户或担心硬件或软件要求。 性能测试通常需要某些组织可能无法支持的其他基础结构和资源。 LoadView 通过平台管理此内容。

LoadView Shift Left Infograph

LoadView 是早期测试代码或 Web 服务的的理想之选,有助于基准测试性能特征,因为它可以轻松地从单个负载喷油器中启动和模拟后端的高级别负载,从而节省与其他工具相比的时间和金钱。 这使得它非常适合测试 Web API 体系结构,如 JSON、SOAP 和 REST。 此外,非功能性测试通常需要较长的设置时间以及复杂的脚本,这些脚本要求开发人员和工程师具备特定编程语言的工作知识。 这有时可能难以自动化,因为它们往往只在特定于供应商的生态系统中工作。 LoadView 的情况并非如此。

 

脚本制作简单:每一步 Web 录像机

LoadView 使用一种易于使用的脚本刻录机,称为”每步 Web 记录器”。 用户可以轻松地创建高级脚本操作,使用 API、Web 应用程序和网站模拟实际用户操作。 要验证客户端应用程序的端到端响应时间,用户只需浏览其测试用例并记录每个操作。 了解 API 或 Web 应用在早期开发阶段可以处理多少负载可以帮助开发人员处理这些关键领域:

  • 确定特定用户负载编号下的响应时间基线
  • 识别性能瓶颈
  • 查找当前系统的容量规划上限
  • 分析服务器性能(CPU、内存、带宽、磁盘 I/O)和数据库响应时间

该录像机还支持 40 多个流行的桌面/移动浏览器和设备,以及 Web 技术和编程语言,如 AJAX、HTML5、JavaScript、Flash、Silverlight 等。 LoadView 利用这些脚本执行来自全球 13 多个位置(美国、加拿大、南美、欧洲和亚太地区)的按需压力和负载测试,为测试工程师提供来自实际浏览器的实际性能数据。 请记住,执行内部测试可以告诉您应用程序或站点处理来自您自己的网络中的流量增加的运行情况,但它永远不会反映实际情况。 未经过正确测试和优化的应用程序和网站可能会对转化率和最终收入产生负面影响。

 

LoadView:测试真实场景的灵活性

LoadView 允许用户根据站点的流量百分比在地理位置之间分配用户负载的选项。 例如,如果您知道某个百分比的客户和用户来自特定的地理位置,可以选择要测试的特定区域。 该平台利用 Amazon Web 服务 (AWS) 和 Azure 云服务生成虚拟用户。 此外,用户可以通过自定义负载曲线的类型,进一步执行负载测试。 这为测试工程师提供了更大的灵活性,具体取决于他们的独特方案。 LoadView 用户可以从三种不同的负载曲线进行选择:

负载步进曲线

    • 从预先确定的并发用户数开始,逐渐增加负载,以查看您的网站如何处理流量峰值并将其与预期流量进行比较。

基于目标的曲线

    • 当您已确定在固定时间间隔内实现吞吐量目标或网站访问者数量时,这种类型的负载曲线非常有用。 非常适合验证 SLA 或非功能性要求。

动态可调曲线

    • 此测试允许用户在测试运行时调整负载,以发现网站或服务器容量的性能限制。

测试完成后,LoadView 会自动生成报告,帮助团队衡量其 KPI(关键性能指标)的成功,例如并发用户数、错误、平均响应时间、CPU 使用率、吞吐量、延迟等。 这些指标对于开发人员、DevOps 和 QA 团队至关重要,因为它们有助于发现可能影响最终用户性能的实际瓶颈。

 

向左移动后,不要忘记向左移动

由于所有的注意力都集中在班次左侧测试上,因此很难记住,在流程中还有另一个非常重要的步骤,它得到的关注较少。 应用程序投入生产后,必须确保用户继续平稳运行。 Dotcom 监视器提供 多种监控解决方案 ,以确保您的页面和应用程序继续正常运行和正常运行。

Web 服务监控

    • Web 服务的正常运行时间和性能,如 HTTP/S、SOAP/REST 等

网页 监控

    • 在真实浏览器中显示网页性能,识别一段时间中最慢和最快的元素

Web 应用程序 监视

    • 监控复杂的 Web 应用程序,如 AJAX、PHP、Ruby、闪存等

基础设施监控

    • 互联网服务器和协议的功能和性能,如 HTTP/S、电子邮件、流媒体、VoIP 等

这些平台允许用户基于自定义阈值设置持续监视,并在发生错误时可以提醒特定个人或团队,以便他们可以在可能影响更多用户之前处理问题。

 

向左移动测试:对业务和安心都好

总之,左移和右移概念都极具价值,不仅在软件开发周期内,而且在其他部门和行业内。 例如,产品经理或客户体验经理正在”向左移动”,并且更频繁地与实际客户接触以获得持续的反馈。 这使组织能够变得更加敏捷,并更接近信息和反馈的来源,以更好地了解其客户。 想想看 您不是更可能与某人合作,或者继续与重视您意见的公司开展业务吗? 所以,现在当你听到有人说,”向左换班”或”经常提前测试”时,他们扔来的东西不仅仅是一个花哨的流行语。 这是客户体验难题的关键部分,也是您应始终牢记在心的难题。 您的用户和客户不仅会感到快乐,而且将提高效率,实现更好的结果,让您和您的组织安心。