持续测试
黑蓝背景
什么是持续测试?

在此基本指南中,了解集成的持续测试如何加快应用程序开发的速度。

持续测试是指将自动化反馈落实到软件开发生命周期 (SDLC) 不同阶段的过程,以支持更快速、更高效地管理部署。

持续测试是 CI/CD(持续集成/持续交付)流程背后的一个关键推力,在加速 SDLC 时间线方面发挥了重要作用,它能提高代码质量,避免高成本瓶颈并加速 DevOps 流程。

开发实用 DevOps 方法的一个基本原则是缩小快速软件交付和可靠用户体验的差距。 但是,在每个软件开发阶段(即,项目设计、编码、测试、部署和维护)手动收集反馈的传统做法会导致组织资源不足和使用效率低下,最终延长集成周期和延迟产品更新。

持续测试通过帮助 DevOps 团队“左移”,在 SDLC 早期为他们提供宝贵的反馈,同时自动执行手动测试流程,将人为错误降至最低,解决这些效率低下的问题。

持续测试的工作方式是使用自动化工具在所有生产阶段载入预先定义的 QA 脚本。 这些自动化脚本消除了在运行 QA 测试时对常规人为干预的需要,依次验证源代码的效率, 同时确保任何相关的反馈立即提供给相应的团队。

如果自动化测试失败,开发团队会在相关开发阶段收到通知,以便他们对源代码进行必要调整,以免影响到 SDLC 不同阶段的其他团队。 如果自动化测试通过检查,项目会自动传递到 SDLC 的下一个阶段,让组织能够创建可持续交付模型,最大化生产力,并改善部门间的协调。

在以下视频中,Eric Minick 将深入介绍该主题:


优点

将持续测试融入 DevOps 流程可以为发展中企业带来多项益处,包括:

更高效、更优质的部署

持续测试提供了一种自动化方法来管理软件开发生命周期 (SDLC) 各个阶段工作流之间的质量保证和质量互操作。 通过将持续反馈循环集成到用户和单元测试模块,开发者可以接收他们所需的可操作性洞察,从而在部署前改善代码的兼容性和性能。 这样的效率解决了多个 DevOps 团队成员沟通不良的问题,并支持加速软件交付计划。

针对已分发项目的快速错误发现和补救

如今的现代开发架构是多面和多层次的。 持续测试帮助开发团队瓦解了这些复杂问题,采用一个可扩展、自动化的测试解决方案来显著改善错误发现和补救时间线。

改善用户体验

高级的持续测试方法可以模拟各种独特用例和故障排除场景,并观察用户的响应方式。 从这些模拟中收集的洞察使开发人员能够尽早消除用户界面中的低效问题,避免实际产品部署后出现意外情况。

最小化或消除业务中断及其成本

尤其是在大型互连系统中,一个应用模块中的错误就可能会产生连锁反应,造成不希望出现的停机事件,对生产力和成本带来负面影响。

例如,云提供商经常报告某一端发生崩溃,导致整个区域陷入瘫痪,停机时间长达几个小时。 对于依赖高服务可用性的组织来说,这个问题尤其严重。 细粒度级别的持续测试能够识别大型软件系统中难以察觉的错误,帮助避免业务中断成本。


方法

持续测试涉及一连串的测试,以确保系统可靠性、安全性、操作性能和可使用性。 测试包括:

  • 左移测试:该方法在软件开发生命周期 (SDLC) 早期优先进行软件和系统测试,以帮助减少或预防后续发生重大调试问题。
  • 右移测试: 该方法在接近 SDLC 尾声时优先进行测试,重点是改善用户体验、总体性能、故障容限和功能。
  • 烟雾测试:这些测试可以手动执行,也可以自动执行,旨在针对软件中的明显缺陷进行粗略筛查。 虽然烟雾测试构造比较粗糙,但仍能提供一种快速且低成本的解决方案来消除软件中的重大错误。
  • 单元测试:这些测试非常适合跨多个构建的小规模压力、负载、容量或内存泄漏检查,目的是在早期开发阶段发现性能下降。
  • 集成和消息传递测试:这些测试检查软件模块彼此配合工作时是否会发生错误。 持续测试将缺少的依赖项虚拟化,以便团队能够测试端到端流程和场景的总体执行情况。 然后,组合编码会进行编译并在运行时执行,以测试它们是否按预期执行。
  • 性能测试:测试应用程序软件本身的性能时,可能不会考虑最终生产环境中的硬件和中间件。 需要进行集成系统测试来评估解决方案的总体性能。
  • 功能测试:这种测试检查用户体验是否符合预期以及功能工作流是否根据需要在软件系统中执行。 例如,当有库存要运输时,供应链软件应该能够提醒卡车前往工厂。 (相比之下,非功能测试侧重于性能、可使用性、可靠性、响应时间、加载时间、可扩展性等等,旨在衡量软件交付所需客户体验的准备情况。 )
  • 回归测试:该测试检查在更正相关软件中的错误后,性能、功能或依赖项是否有任何变化以及系统是否像以前一样工作。
  • 用户验收测试:也称为应用程序测试或最终用户测试,是指由一小部分目标用户在真实场景中对应用程序进行的测试。 Beta 测试就是用户验收测试的一个例子。

虚拟化和持续测试

以下特征使得 IT 系统和应用程序在运行时发生错误的风险更高:

  • 它们集成的新兴技术越来越多(例如云计算、物联网 (IoT)、软件定义网络、增强现实 (AR))。
  • 它们分布到越来越多的区域,并且这些区域具有无缝互连的核心和边缘。 智慧城市、自动驾驶汽车和智能公用事业等应用将受益于这类架构。

在这些用例中,持续测试的要求更高,因为开发不会只在一个地点或公司进行。 包括远程团队在内的第三方可能会提供系统的一些元素。 该系统可能与应用程序编程接口 (API) 集成。 每个开发团队在不同的 IT 环境中运行,包括原有软件。 不可能重现所有团队的物理环境来进行持续测试。

幸运的是,持续测试可以虚拟化以创造一个测试环境,将整个系统以虚拟方式重现在单一界面中。 虚拟环境可以轻松配置以针对不同的 IT 系统进行测试,或针对为了更正错误而已经更改的系统进行测试


在 DevOps 中的作用

在 DevOps 环境中,持续测试在软件开发生命周期 (SDLC) 中自动执行,与持续集成彼此配合,自动验证应用程序中集成的任何新代码。

测试工具中预装了测试脚本,当有新代码集成到应用程序中时,这些脚本会自动执行。 通常,测试会从集成测试开始,自动推进到系统测试、回归测试和用户验收测试。

测试从每个应用程序模块生成数据订阅源,然后对订阅源进行分析以确保新代码影响到的所有模块都按预期执行。 如果未通过测试,代码将被发回到开发团队进行更正,然后重新集成并开始新的测试周期。

当所有测试都成功后,应用程序或项目将进入 SDLC 的下一个阶段,通常是持续交付

请参阅 Andrea Crawford 对 DevOps 的解释以了解关于该主题的一些背景:


框架

许多测试都需要持续测试框架来确保在应用模块、连接器(或者 API 和容器)、平台、基础架构和定义需求的场景之间保持一致。

这些测试可以是按顺序(例如,单元测试之后是回归测试)的,也可以是并行的(例如,一个模块的新迭代往往伴随着对其依赖项进行的相应测试)。

持续测试框架围绕测试集提供包装器,以便它们能够一致地应用并为自动化做好准备。 开发商希望确保他们为一个模块采用的方法与针对其他模块应用的方法相似。 随着模块的演变,针对相关联软件的测试也会随之演变。

框架提供了一种标准方法,可以方便地修改脚本和功能以进行测试。 当测试中的不一致性消除后,自动化将会因此获益,否则会产生一系列误导性的测试结果。


持续测试与 IBM

随着越来越多的企业采用敏捷的 DevOps 实践,对应用和服务交付的质量和速度的需要成为业务发展和可持续性中至关重要的一个组成部分。 IBM 深知更智能软件测试(即集成到 SDLC 中的高质量、自动化测试)的重要性。 我们坚信,现代化应用程序最快最安全的方法就是在真实的环境中测试和验证应用程序。

采取下一步行动:

除了应用程序现代化之外,了解 IBM 如何在其他方面帮助您的组织开启腾云之旅。

立即创建  IBM Cloud 账户以使用该产品。  


相关解决方案

实现应用现代化

信心十足地在任何云中安全地构建和管理应用程序并使之现代化