大话持续测试

软件质量保障

所寫即所思|一个阿里质量人对测试的所感所悟。

概述

持续测试旨在软件开发的每个阶段持续确保产品的质量,它是持续集成和持续部署(CI/CD)过程的一个组成部分,采用持续测试方法论可以更早地发现问题,缩短开发者的反馈时间,提高产品质量的可见性,并加快产品上市速度。

像瀑布模型这样的传统开发模型中,开发人员被分解成负责特定任务的不同团队。这导致了一个团队完成任务后将软件移交给另一组。因为每个团队都有足够的时间专注于自己的任务,而不用担心项目的其他方面,所以质量得到了保证。

随着对更快开发速度的需求不断增加,这种传统开发模式就出现了问题。为了满足对更高开发速度的需求,出现了一种新的开发模型。在这种模型中,组织会持续引入渐进式活动以确保更高的客户满意度。

今天,大多数组织都采用了DevOps,这是一种基于协作和共同负责的环境。这种从传统做法转变使得团队能够采用自动化测试和持续性活动,如持续测试。

持续测试是什么?

持续测试是软件交付Pipeline中至关重要的一部分,可以在发布新产品之前尽早提供关于业务风险的反馈。它为组织提供了一种更加自动化和安全的方式,确保在复杂、快节奏的环境中应用程序保持安全和有效。

传统的测试方法通常涉及将项目从一个团队转移到另一个团队,并明确划分开发和质量保证(QA)阶段。QA团队会有足够的时间确保最高质量,这意味着要牺牲项目的截止日期。

然而,今天的企业需要更快地开发和向最终用户交付软件。新版本的软件比旧版本更具市场竞争力,因此更有可能为公司带来更高的收入。在持续的DevOps流程中,一个发布候选版本(软件变更)会不断从开发阶段转移到测试阶段再到部署阶段。

持续测试需要多个利益相关者的协作,包括开发团队、DevOps人员、QA人员和技术支持人员。

持续测试与传统测试有何不同?

过去,软件的测试是通过将软件从一个团队传递给另一个团队来完成的。开发阶段结束后,就会开始进行质量保证(QA)测试。QA团队总是希望有更多的时间来进行测试,因为他们希望确保软件的质量。

持续测试是指一个持续或不间断的软件测试周期。在持续的DevOps流程中,软件变更(候选版本)被持续地交付、测试和部署,也就是说,软件代码是持续地开发、测试和部署的。

举个例子,每当开发人员将代码提交到像Jenkins这样的源代码存储库时,就会自动运行单元测试。未能通过测试的构建将被拒绝,开发人员会收到通知。通过测试的构建将被部署到性能和质量保证(QA)服务器上进行并行的全面功能测试和负载测试。如果这些测试通过,软件将被部署到生产环境中。

持续测试是持续开发、集成和部署周期中不可或缺的一部分。

为什么持续测试很重要

随着软件成为近年来企业间关键的差异化因素,公司期望更快地交付新功能。开发团队采用敏捷和DevOps等精益方法来满足这些需求以缩短交付周期。尽管在其他交付环节加速之后,他们的测试过程阻碍了他们实现预期的SDLC加速计划带来的好处。以下是其中的一些原因:

  • 敏捷、DevOps和持续交付已经改变了测试过程。依赖于手动测试和需要频繁更新的自动化GUI测试的传统测试方法已经无法跟上这些新的开发周期。尽管这些较新的软件开发方法可以加快迭代周期,但许多组织认识到需要扩展其自动化测试策略。

  • 虽然自动化测试在持续交付中的作用很重要,但管理人员往往缺乏对应用程序风险水平的充分了解。为了确保能够与业务利益相关者有效沟通接受的风险水平,你必须基于他们对安全漏洞和性能问题等漏洞的容忍度设计测试。这可能导致通过所有可用测试的发布候选人,但业务领导层不会将其视为可以发布的状态。

  • 在没有全面的端到端测试质量流程的情况下,团队很难在当今压缩的交付周期内满足业务预期。例如,开发测试等缺陷预防策略可以帮助确保将质量融入产品,从而使在每次迭代结束时消除风险变得更快、更节省资源。

组织采用持续测试是因为他们认识到传统测试方法所带来的问题。他们意识到软件的重要性日益增加,并且认识到由于软件失败成本的不断上升,他们无法在时间、范围和质量之间做出妥协。

持续测试与自动化测试

自动化测试可以加快执行任务的速度,并在整个测试过程中提供一致性。它使开发人员能够专注于更复杂、更具创造性的项目,并为测试腾出时间。此外,它还可以让你执行比手动测试更多的测试,为你节省大量时间和精力。

另一方面,持续测试是一种质量保证方法,它通过在开发过程中使用反馈来提高产品的质量。这种方法可以采用许多实践和工具,包括自动化和监控。持续测试是关于真实性的,因此不要因为拥有大量数据就误认为数据就是质量;你需要的是干净、整合且一致的数据,以便采取行动来降低风险。

持续测试与自动化测试对比

在软件开发领域,自动化测试和持续测试是两个经常被混淆的概念,因为它们经常被一起使用。然而,它们在DevOps和持续交付中扮演着完全不同的角色。

自动化测试和持续测试对DevOps和持续交付都产生了深远的影响,但两者都不是对方的先决条件或后置条件。无论你担任何种角色,都可以单独选择进行自动化测试或持续测试。

下面的表格可以帮助更好地理解:

参数

持续测试

自动化测试

定义

持续测试是一种软件测试过程,它可以帮助你不断提高产品的质量。

自动化测试是一种使用工具或软件来执行重复性任务的过程。

目的

持续的测试过程可以帮助你在产品开发的早期发现风险,并在产品发布之前解决这些风险。

执行一系列重复性任务,可以将运行测试所需的时间从数天缩短至数小时。

先决条件

没有自动化测试,持续测试无法顺利实施。

将持续测试融入自动化测试框架是实现更高效、更有效自动化测试过程的重要一步。

时间

软件可能会每周、每小时甚至更频繁地发布。

软件发布可能需要很长时间。

反馈

项目的每个阶段都需要及时反馈。

每次发布后的定期测试反馈将有助于我们改进软件。

持续测试驱动开发

单元测试驱动开发(TDD)被用来让程序员快速得到代码是否正确运行的反馈。

  • 该装置运行正常。

  • 无意中更改或破坏了现有的功能。自动化测试是将单元测试和验收测试或冒烟测试作为自动化构建的一部分运行在应用程序上的过程。

测试是在项目实施之前编写的,通过这些测试可以证明项目的实施是成功的。

持续测试驱动开发(CTDD)是一种软件开发实践,它结合了TDD的优点,并允许自动执行测试,为测试人员提供持续的反馈,以确定其代码是否正常运行。

此外,测试驱动开发(TDD)的一个瓶颈是缓慢的开发者反馈和整体较慢的软件开发速度。为了克服这一问题,引入了持续测试驱动开发(CTDD),因为它可以提供更快的开发者反馈,确保快速的软件开发过程。

持续测试、持续集成、持续交付与DevOps

在竞争激烈的环境中,企业在交付软件时无法再只关注速度或质量中的一种。两者对于成功都至关重要。随着组织在采用敏捷实践和DevOps举措方面日趋成熟,以实现在保证质量的同时加快速度,持续集成(CI)、持续测试(CT)和持续交付(CD)已成为关键推动因素。在这三种方法中,持续测试目前是最具挑战性的。

持续测试是一项跨职能活动,涉及使用工具的团队、使用个人测试工具的个人以及与其他元素协同工作的自动化回归测试等服务。虽然持续集成主要是一种以工具驱动的过程,而持续交付既是工具驱动的也是团队驱动的,但持续测试则依赖于工具、团队、个人和服务的组合。

虽然构建和整合代码更改是软件开发过程中不可或缺的环节,但自动化交付流程也必须能够识别这些更改对业务风险或终端用户体验的影响。否则,持续集成和持续交付的频率和速度越高,就越有可能成为一种负担而非资产。

当正确实施时,持续测试成为交付Pipeline的核心。在现代应用交付的复杂性和速度不断提高的情况下,它对于控制业务风险至关重要。自动化测试是软件交付Pipeline的一部分,可尽快提供基于风险的反馈。

在DevOps/DevSecOps中,持续测试是如何工作的?

在这个快速发展的环境中,软件发布周期越来越短,因此组织需要调整其实践以跟上步伐。应采用DevOps实践和工具进行持续测试,以确保产品的质量高。

DevOps 和 DevSecOps 基于通过尽可能早地进行安全测试来加快所有开发活动的速度。持续测试对于加快 DevOps Pipeline至关重要。它允许在开发到部署的整个 SDLC 阶段(即软件开发生命周期)中持续进行安全测试,从而使安全测试能够尽早进行。

通过实施持续测试,你可以确保软件发布具有最高的质量,并且开发工作能够不受阻碍地顺利进行。

持续测试的好处

持续测试可以带来许多好处,确保QA和测试人员能够从中获得最大的收益。以下是其中一些:

1. **提高测试效率**:持续测试允许测试人员在应用程序的整个生命周期中进行测试,从而减少了测试所需的时间。

2. **提高测试覆盖率**:持续测试可以确保应用程序在整个生命周期中得到全面的测试,从而提高了测试覆盖率。

3. **提高测试质量**:持续测试可以帮助测试人员在应用程序的早期阶段发现并修复错误,从而提高了测试质量。

4. **提高测试自动化**:持续测试可以帮助测试人员自动化测试过程,从而提高了测试效率。

5. **提高测试团队的协作**:持续测试可以帮助测试团队成员之间更好地协作,从而提高了测试效率。

总之,持续测试可以为QA和测试人员带来许多好处,确保他们能够从中获得最大的收益。

风险导向反馈

通过持续测试,你可以在发布代码之前找到并修复其中的错误。自动化工具提供的可操作性反馈使这一过程成为可能。这比手动测试更有效,手动测试耗时且容易遗漏关键缺陷。自动化工具提供的风险分析见解有助于你在代码发布之前尽可能多地发现问题,从而增强对业务风险因素的覆盖。

即时反馈有助于开发人员做出更好的设计决策,让经理们能够获取所有必要的数据来评估一个版本。

更明智的发布决策

采用敏捷、DevOps和持续交付等方法后,软件更新的设计、开发和交付时间缩短了。这些方法允许定期发布以每两周一次到每天数千次的速度进行。

商业风险正在增加,而现代软件公司加速发布软件的唯一途径是使用自动化测试。在部署发布候选版本之前,必须对商业风险有全面的了解。

采用基于风险的反馈方法进行持续测试可以帮助软件开发人员决定何时以及如何发布更改。依赖自动化工具来寻找提高代码质量机会的公司发现,他们花在分析代码复杂度上的时间比寻找代码缺陷上的时间要多。

更高效的测试

持续测试有助于开发人员和管理人员确定其交付Pipeline中是否需要进行左移测试或右移测试。

使用自动化工具进行端到端测试有助于消除假阳性和超时问题。在软件开发的每个阶段进行此类测试,可以让开发人员确信自己正在构建一个安全、高度灵活的框架。

软件公司可以通过持续测试其应用程序来避免重复劳动并节省宝贵的时间。这样可以确保他们为未来应用程序的扩展建立了最健壮的架构,尤其是当用户需要新的功能时。

更稳定的用户体验

持续测试最重要的方面是确保有缺陷的代码不会到达用户并扰乱他们的体验。必须找到在向用户提供他们想要的新功能的同时,又不破坏他们已经习惯的体验的平衡点。

因为企业依赖软件与客户沟通,所以糟糕的用户体验会对企业的成功造成不利影响。深入的测试确保了用户体验的每个方面都得到考虑和保留,这有助于在软件准备就绪后维护供应商的品牌和声誉。

整合团队

持续测试可以创建一个更高效的开发流水线,确保每个团队成员能够有效地协同工作。现代软件开发是一个协作的过程,将已准备好投入生产的代码交给孤立的QA测试人员的日子已经一去不复返了。

通过在软件开发周期的各个阶段融入质量保证措施,团队能够更清楚地了解整个开发流程中的每个步骤,从而从一开始就能够交付高质量的代码。持续的测试确保开发团队从开始编写代码的那一刻起就构建出高质量的代码。

持续测试的方法

持续测试是指一系列测试,旨在确保应用程序的可靠性、安全性和可用性。这些测试包括:

  • 左移测试:通过在软件开发生命周期(SDLC)的早期优先考虑软件和系统测试,公司可以帮助减少或防止后期出现重大调试问题。“左移”是一种软件测试范例,指的是在过程中更早地采取行动。例如,左移测试意味着将你的软件移至交付Pipeline的左侧进行测试,或者在开发生命周期中较以往更早地测试你的软件。

  • 右移测试:“右移”是一种软件开发方法论,其中测试、质量控制和性能评估由距离代码最近的开发人员执行。“右移”是指将应用程序的测试移至生产环境中,由真正的用户进行。这确保了在生产环境中运行的应用程序已经经过了测试,并且保持了相同的高质量水平。

  • 烟雾测试:烟雾测试是一种用于确定已部署的软件版本是否稳定的过程。这是确认质量保证(QA)团队将继续对该版本进行进一步测试的确认。烟雾测试是在每个构建上运行的最小测试集,以测试软件的功能。“烟雾测试”这个名称来源于这样的想法:如果单个软件可以正常工作,那么可以假设其他所有软件也可以正常工作。

  • 单元测试:单元测试是一种软件开发过程,旨在确保应用程序中的每个组件都能按预期工作。通过隔离并验证各个函数、方法、过程和对象,单元测试可以让开发人员在开发过程中较早地发现并修复错误。

  • 集成与消息测试:集成与消息测试旨在确保所有软件模块在协同工作时无误。通过虚拟化缺失的依赖关系,团队可以测试整体流程和场景的性能。使用复合代码来测试这些代码在编译和运行时是否能够按预期执行。

  • 性能测试:在实验室中对应用软件进行测试时,使用的硬件和中间件与最终生产环境中使用的硬件和中间件不同,测试结果可能无法准确预测解决方案的性能。为了有效评估解决方案的整体性能,需要进行集成测试。

  • 功能测试:功能测试检查软件是否已准备好向客户提供所需的体验。例如,供应链软件应该能够在库存可用于发货时向卡车发出到达工厂的通知。(相比之下,非功能性测试侧重于性能、可用性和可靠性,并衡量软件是否已准备就绪。)

  • 回归测试:回归测试可以让你检查在修复任何依赖软件中的错误后,性能、功能或依赖性是否发生了任何变化。

用于持续测试的框架

持续测试工具旨在帮助你进行测试工作。它们通过保证在持续测试过程中获得积极的结果来确保你的成功。虽然有很多可用于持续测试的工具,但值得追求的却很少。一些知名的持续测试工具包括:

Selenium:

Selenium 是一个软件框架,拥有丰富编程经验的开发人员可以使用它进行 QA 测试。要实现 Selenium,了解框架的工作原理至关重要。此外,Selenium 支持多种流行的操作系统(Windows、macOS、Linux)和浏览器(Chrome、Firefox、Safari),使其成为跨环境测试的理想选择。

然而,当Selenium与其他CI/CDPipeline中的工具一起使用时,会遇到一些障碍。最大的阻碍是找到一个支持你所需的工具和插件的架构,以便在大规模运行Selenium测试脚本时能够无缝运行。

云测试确保可以在安全、可扩展的 Selenium 网格上大规模运行 Selenium 测试。LambdaTest 就是这样一个平台,它提供了一个可扩展的云端 Selenium 网格,让你可以在各种浏览器和平台组合上运行 Selenium 测试。此外,还可以通过与组织中已使用的最佳 CI/CD 工具集成,在组织的 CI/CD Pipeline中实现持续测试。

Jenkins:

据一份报告称,33.3%的开发团队使用Jenkins作为其持续集成/持续部署工具。在Jenkins服务器设置完成后,你可以运行一系列自动化测试和构建,确保只有经过测试的稳定代码才能进入生产环境。

使用像Jenkins这样的工具可以简化确保高代码质量和成功构建的过程。当在一个拥有大量开发人员的大型项目中工作时,传统方法可能会导致大量需要很多排查问题的冲突代码提交。使用Jenkins这样的工具可以避免这种情况。

Appium:

Appium 是一个开源的移动网页应用自动化测试框架。它允许你为桌面和移动设备创建跨浏览器测试。目前,许多云设备提供商都提供基于 Appium 的测试服务。

Appium 是一个可以在云端开发、上传、执行和查看测试结果的工具。Appium不仅可以让你在物理设备、模拟器或仿真器上自动化测试,而且还可以让你无需重新编译应用程序即可进行自动化测试。Appium 使用 JSON 线程协议与被测试的应用程序进行通信。

Eggplant:

Eggplant是一款持续测试工具,提供了一种独特的测试方法:基于图像的解决方案。与传统的提供原始测试脚本不同,Eggplant与被测试应用程序(AUT)交互,模拟用户的视角。

Eggplant提供了一个测试实验室,让你可以24/7进行持续的测试和部署。它可以与其他CI/CD工具(如Jenkins和Bamboo)集成。这种集成使得Eggplant用户可以进行全面的测试,包括单元测试、功能测试和性能测试。

持续测试的挑战

持续测试能够实现更快的持续交付(CD)。然而,必须克服一些挑战:

  • 软件缺乏测试支持:如果遗留产品中没有内置测试支持,那么实现持续测试将变得更加困难。在遗留产品中实现测试支持功能代价高昂,并且会阻碍持续测试的成功。

  • 缺乏标准工具:虽然针对不同产品的持续测试没有标准工具,但团队通常会使用缺乏适当文档和维护的内部自动化工具或框架。这将给测试团队带来额外的麻烦,他们现在必须解决与工具/框架相关的问题。

  • 缺乏完善的测试基础设施:持续测试需要对额外的测试环境进行投资,这些环境必须得到维护、保持最新状态并全天候运行。高级工具可以帮助团队实现更快的反馈循环,但这些成本与因产品质量不佳而产生的成本相比并不算高。在缺乏完善基础设施的情况下,组织需要对持续测试做出承诺,而不是半途而废,这只会给测试人员带来更多的问题。

  • 可扩展性:并非所有测试框架/工具都具有相同的可扩展性。缓慢的测试执行速度以及对大型测试套件的支持不足可能会成为实现持续测试梦想的严重障碍。这些问题并非总是在一开始就显现出来;只有在系统中添加了大量测试之后,测试系统开始承受高负载时,这些问题才会显现出来。

如何实施持续测试?

在应用程序中融入质量可以通过添加现代的测试实践来实现,比如在应用程序Pipeline的各个环节执行小型的质量检查。这使得代码的某些部分能够持续地进行测试。并非总是将自动化测试作为首要解决的问题。例如,即使API和GUI测试已经自动化并集成到持续集成代理中,这些测试也存在依赖性——测试数据、接口和环境——在执行之前必须得到满足。

虚拟化环境

持续测试是一个频繁测试代码的过程。要尽可能多地进行测试,就必须更频繁地在多个环境中运行代码。虚拟化这些环境可以让你在不考虑其他系统和环境的情况下测试代码(即,那些不会发生变化的环境)。

API测试

测试金字塔是一个概念,旨在促进组织中软件测试的正确使用。根据该概念,组织应该尽可能多地在单元级和API级进行测试,并减少对UI测试的依赖。要采用持续测试,你需要接受这个概念并加强单元和API测试;你还应该减少对UI测试的依赖。

测试数据管理

要实现持续测试,你需要正确的数据以及适用于正反两种情况的适当的数据多样性。生产环境中的数据多样性很难实现,这一点至关重要。你无法将生产环境中的数据以所需的速度引入应用Pipeline。合成数据生成允许以最高置信度进行持续测试,因为该数据中不存在任何个人身份信息。

自动化测试

在持续测试环境中,今天的脚本可能会因为与应用程序代码无关的原因而失败,没有人会信任测试结果。要实现可靠的自动化测试,必须采用持续测试。

Pipeline编排

一个健壮的持续测试Pipeline需要一个坚实的、集成的自动化套件,该套件与应用程序的核心紧密相连。了解其工作原理以及如何解读结果将使你更高效、更具可扩展性。你必须确保其透明度,确保每个人都能完全了解Pipeline中运行的内容。它是一个自动化的工作流工具,运行Pipeline中所有的测试,并完全集成到代码部署活动中。作为任何DevOps采用计划的一部分,期望在没有标准化和自动化Pipeline的情况下实现持续测试是不现实的。

TDD(测试驱动开发)和BDD(行为驱动开发)

通过开发测试来确保每个标准都得到满足。这可以使测试的重点始终集中在冲刺期间,确保开发人员按照业务预期进行开发。随着时间的推移,团队将定义更加详细的验收标准,这需要测试也要做的更加全面。

往期系列文章

阿里微服务质量保障系列:微服务知多少

阿里微服务质量保障系列:研发流程知多少

阿里微服务质量保障系列:研发环境知多少

阿里微服务质量保障系列:阿里变更三板斧

阿里微服务质量保障系列:故障演练

阿里微服务质量保障系列:研发模式&发布策略

阿里微服务质量保障系列:性能监控

阿里微服务质量保障系列:性能监控最佳实践

阿里微服务质量保障系列:基于全链路的测试分析实践

- END -


下方扫码关注 软件质量保障,与质量君一起学习成长、共同进步,做一个职场最贵Tester!

  • 关注公众号, 后台回复【测开】获取测试开发xmind脑图

  • 扫码加作者, 获取加入测试社群!

往期推荐

聊聊工作中的自我管理和向上管理

经验分享|测试工程师转型测试开发历程

聊聊UI自动化的PageObject设计模式

细读《阿里测试之道》

我在阿里做测开

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

软件质量保障

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值