CN118964219B

CN118964219B - 一种用于非功能测试的测试资源管理方法、设备及介质

Info

Publication number: CN118964219B
Application number: CN202411455683.XA
Authority: CN
Inventors: 张瑞; 徐彤; 甘泉; 孟冀; 陈春潮; 张磊; 姜武仁; 徐立宾; 张莉涓
Original assignee: Hengfeng Bank Co ltd
Current assignee: Hengfeng Bank Co ltd
Priority date: 2024-10-18
Filing date: 2024-10-18
Publication date: 2025-02-28
Anticipated expiration: 2044-10-18
Also published as: CN118964219A

Abstract

本申请公开了一种用于非功能测试的测试资源管理方法、设备及介质，涉及电数字数据处理技术领域。包括：确定非功能测试项目对应的项目类型以及项目类型对应的项目模式；根据项目模式以及非功能需求类别对应的项目组件组装逻辑，确定非功能测试项目是否需进行非功能测试；若是，对非功能测试项目对应的测试内容进行分析，以确定完成测试内容所需的目标测试项，并将非功能测试项目与预设的持续集成工具建立连接；对目标测试项所需的测试预算时间进行预测，并根据测试预算时间对非功能测试项目分配相应的测试资源；在满足预设的触发条件时，通过持续集成工具，触发针对目标测试项的测试流程，实现对非功能测试项目的非功能测试。

Description

一种用于非功能测试的测试资源管理方法、设备及介质

技术领域

本申请涉及电数字数据处理技术领域，具体涉及一种用于非功能测试的测试资源管理方法、设备及介质。

背景技术

当前的软件开发中，非功能测试（Non-FunctionalTesting，NFR）在保证软件系统的稳定性、性能、可用性和安全性方面起着至关重要的作用。然而，现有的非功能测试技术在多个方面仍存在不足。例如，在传统的瀑布开发模型中，非功能测试往往被推迟到项目后期才进行，这增加了项目风险和成本。此外，非功能需求的定义和量化也是一大挑战，尤其是在敏捷开发中，非功能需求需要在每个短周期内反复测试和验证，这对资源和时间提出了更高的要求。

近些年，虽然一些新技术试图在敏捷环境中更好地集成非功能测试，如在每个开发周期中对非功能需求进行持续关注，并通过分析用户行为数据和系统运行数据来改进非功能需求定义。然而，这些技术在处理动态需求变化和多样化的测试场景时，依然面临挑战，尤其是测试耗时和资源的准确估计仍未能得到有效解决。

发明内容

为了解决上述问题，本申请提出了一种用于非功能测试的测试资源管理方法，包括：

针对待测试的非功能测试项目，确定所述非功能测试项目对应的项目类型以及所述项目类型对应的项目模式；

确定所述项目类型对应的非功能需求类别，根据所述项目模式以及所述非功能需求类别对应的项目组件组装逻辑，确定所述非功能测试项目是否需进行非功能测试；

若是，对所述非功能测试项目对应的测试内容进行分析，以确定完成所述测试内容所需的目标测试项，并将所述非功能测试项目与预设的持续集成工具建立连接；

对所述目标测试项所需的测试预算时间进行预测，并根据所述测试预算时间对所述非功能测试项目分配相应的测试资源；

基于所述测试资源，在满足预设的触发条件时，通过所述持续集成工具，触发针对所述目标测试项的测试流程，实现对所述非功能测试项目的非功能测试。

在本申请的一种实现方式中，根据所述项目模式以及所述非功能需求类别对应的项目组件组装逻辑，确定所述非功能测试项目是否需进行非功能测试，具体包括：

所述项目模式包括新建重构模式和改造模式；

获取所述非功能需求类别对应的项目组件组装逻辑，根据所述项目组件组装逻辑，确定所述非功能需求类别是否需进行非功能测试；

在所述项目模式为所述新建重构模式，或者存在部分所述非功能需求类别需要进行非功能测试的情况下，确定所述非功能测试项目需进行非功能测试；

在所述项目模式为所述改造模式且所有非功能需求类别均不需进行非功能测试的情况下，确定所述非功能测试项目不需要进行非功能测试。

在本申请的一种实现方式中，根据所述项目组件组装逻辑，确定所述非功能需求类别是否需进行非功能测试，具体包括：

根据所述项目组件组装逻辑，确定所述非功能需求类别对应的至少一个评估项，以及所述评估项对应的测试评估标准；

确定所述测试评估标准对应的最小测试范围，根据所述最小测试范围对所述测试评估标准依次进行验证，以确定所述评估项是否满足所述测试评估标准；其中，所述最小测试范围指的是完成所述测试评估标准所需的必要测试项；

若是，确定所述非功能需求类别需进行非功能测试。

在本申请的一种实现方式中，对所述非功能测试项目对应的测试内容进行分析，以确定完成所述测试内容所需的目标测试项，具体包括：

对所述非功能测试项目对应的测试需求进行划分，根据所述测试需求，确定所述测试资源对应的管理粒度；其中，所述管理粒度包括模糊管理粒度和精细管理粒度；

基于不同的管理粒度，对所述非功能测试项目对应的测试内容进行分析，以对目标测试项进行定位。

在本申请的一种实现方式中，对所述非功能测试项目对应的测试需求进行划分，根据所述测试需求，确定所述测试资源对应的管理粒度，具体包括：

对所述非功能测试项目对应的测试需求进行划分，并确定所述测试需求涉及的测试单元层级；其中，所述测试单元层级包括活动单元和工作子类型单元；

在所述测试单元层级为所述活动单元的情况下，确定所述测试资源对应的管理粒度为模糊管理粒度；

在所述测试单元层级为所述工作子类型单元的情况下，确定所述测试资源对应的管理粒度为精细管理粒度。

基于所述模糊管理粒度，将所述非功能测试项目划分为若干工作阶段，并确定所述工作阶段包含的多个活动单元；

基于所述精细管理粒度，确定所述活动单元覆盖的工作子类型，根据所述非功能测试项目对应的测试内容，从所述工作子类型中选取指定工作子类型，作为完成所述测试内容所需的目标测试项。

在本申请的一种实现方式中，对所述目标测试项所需的测试预算时间进行预测之后，所述方法还包括：

确定所述非功能测试项目对应物理子系统的系统类型；其中，所述系统类型包括引入系统和自建系统；

在所述系统类型为所述引入系统的情况下，确定所述非功能测试项目需进行验证测试，并确定所述验证测试对应的验证测试时间；

根据所述验证测试时间，对所述测试预算时间进行更新，以按照更新后的测试预算时间对所述非功能测试项目分配相应的测试资源。

本申请实施例提供了一种用于非功能测试的测试资源管理设备，所述设备包括：

至少一个处理器；

以及，与所述至少一个处理器通信连接的存储器；

其中，所述存储器存储有可被所述至少一个处理器执行的指令，所述指令被所述至少一个处理器执行，以使所述至少一个处理器能够执行如上任一项所述的一种用于非功能测试的测试资源管理方法。

本申请实施例提供了一种非易失性计算机存储介质，存储有计算机可执行指令，所述计算机可执行指令设置为：

如上任一项所述的一种用于非功能测试的测试资源管理方法。

通过本申请提出的一种用于非功能测试的测试资源管理方法能够带来如下有益效果：

对不同项目类型的非功能需求进行分类和量化评估，能够精确地识别出需要进行非功能测试的项目，避免了不必要的测试资源浪费，确保测试覆盖全面并能及时发现潜在问题。通过集成一个基于多个维度的时间计算工具，对目标测试项的测试预算时间进行预测，从而合理分配测试资源，确保资源的有效利用。通过自动化的测试评估标准和持续集成方法，将非功能性测试贯穿于整个开发周期，不仅提高了测试的执行效率，还确保了测试的全面覆盖。

附图说明

此处所说明的附图用来提供对本申请的进一步理解，构成本申请的一部分，本申请的示意性实施例及其说明用于解释本申请，并不构成对本申请的不当限定。在附图中：

图1为本申请实施例提供的一种用于非功能测试的测试资源管理方法的流程示意图；

图2为本申请实施例提供的一种用于非功能测试的测试资源管理设备的结构示意图。

具体实施方式

为使本申请的目的、技术方案和优点更加清楚，下面将结合本申请具体实施例及相应的附图对本申请技术方案进行清楚、完整地描述。显然，所描述的实施例仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。

在当前的软件开发实践中，尤其是复杂的企业级系统开发中，非功能性需求测试面临以下几个关键问题：

（1）非功能性需求的模糊性与难以量化：

非功能性需求（如性能、可用性、可维护性等）通常难以明确量化和定义，导致这些需求在开发周期内被忽视或推迟测试。这不仅增加了项目的风险，还导致问题往往在项目后期才被发现，修复成本高昂。

（2）非功能性测试时间和资源的精确估算难题：

当前的非功能测试方法缺乏对非功能性测试所需时间和资源的准确估算工具，这导致测试计划不合理，资源配置不当，最终可能导致项目延期或测试不充分。

（3）非功能性测试的执行效率和覆盖问题：

在传统的开发周期中，非功能性测试往往被推迟到项目的后期阶段，缺乏持续的关注和全面的覆盖，这导致测试效果不理想，并可能影响系统的稳定性和性能。

为解决上述问题，本申请提出了一种非功能测试计划模型（Non-FunctionalTesting Plan，NFTP），基于NFTP模型对待测试的非功能测试项目进行非功能测试，不仅能够大幅提高了非功能性测试的准确性、效率和资源利用率，还能确保软件系统的稳定性和高性能。这一模型适用于需要进行非功能测试的各类复杂软件系统，尤其是在企业级IT环境中，有助于提高整体项目管理的效率和质量。

NFTP模型的核心思想是将非功能性测试融入软件开发的每一个阶段，而不是仅在项目后期进行集中测试。为此，模型设计了以下几个关键模块：

非功能需求分类与量化模块：该模块负责对不同项目类型的非功能需求进行分类，并通过一套标准化方法量化这些需求。这确保了在每个项目中，所有重要的非功能性需求都得到了明确的定义和验证。

自动化测试评估模块：通过这一模块，模型提供了一套自动化的评估标准，用于实时监控和评估系统的非功能性性能。这一模块通过持续集成工具（如Jenkins、GitLabCI等）与开发流程紧密集成，确保每次代码提交或变更都经过非功能性测试的验证。

测试时间估算与资源配置模块：该模块基于历史数据和项目特点，对测试所需的时间和资源进行估算，并为项目管理者提供科学的决策支持。这一模块通过分析测试脚本开发、性能测试、容量测试等不同维度的数据，帮助合理安排测试计划。

以下结合附图，详细说明本申请各实施例提供的技术方案。

如图1所示，本申请实施例提供的一种用于非功能测试的测试资源管理方法，应用于NFTP模型，包括：

S101：针对待测试的非功能测试项目，确定非功能测试项目对应的项目类型以及项目类型对应的项目模式。

非功能测试是软件测试的一种重要类型，主要关注系统的非功能性方面，而不是具体的功能实现。其中，非功能性方面包括但不限于系统的性能、可靠性、安全性、可用性、可维护性、兼容性以及可扩展性等。因此，系统在开发过程中都需要进行非功能测试以保证系统的稳定运行，根据每个系统的测试需求，可形成相应的非功能测试项目，并且，由于系统类型的不同，非功能测试项目还需划分为不同的项目类型。其中，项目类型按照系统引入方式的不同可划分为外部引入新建系统和内部自建新建系统，外部引入新建系统指的是从外部引入需在此基础上进行二次开发的系统，而内需自建新建系统指的是企业内部按照业务需求新开发的系统。每种项目类型对应的项目模式也会因为系统类型的不同而存在区别，一般情况下存在两种模式，一种是新建重构模式，与外部引入新建系统相对应，指的是基于原有的开发项目进行相应的功能改造，另一种是改造模式，与内部自建新建系统相对应，指的是开发新的项目。

S102：确定项目类型对应的非功能需求类别，根据项目模式以及非功能需求类别对应的项目组件组装逻辑，确定非功能测试项目是否需进行非功能测试。

不同项目类型都对应有不同的非功能需求类别，比如管理要求、风险整改、系统变化等。针对不同的非功能测试项目，由于其对应的非功能需求类别存在不同，且项目模式也可能存在不同，因此，需要按照实际情况对其进行分析，以确定是否每个非功能测试项目都需要进行非功能测试。这一过程涉及到非功能需求类别对应的项目组件组装逻辑。

具体地，获取非功能需求类别对应的项目组件组装逻辑，根据项目组件组装逻辑，确定非功能需求类别是否需进行非功能测试。项目组件组装逻辑用来明确当前非功能测试项目主要针对哪些特定的非功能需求类别进行测试，在此过程中，根据项目组件组装逻辑，能够明确每个非功能需求类别对应的至少一个评估项。每个评估项都有相应的测试评估标准，如果当前测试需求符合测试评估标准，则说明该评估项对应的非功能需求类别需要进行测试。这一过程需要借助于最小测试范围来进行，最小测试范围指的是完成测试评估标准所需的必要测试项，也就是说，只需完成最小测试范围内的标准评估，便可确定当前评估项的评估标准是否通过，因此，在根据最小测试范围对测试评估标准依次进行验证后，便可确定每个非功能需求类别对应的评估项是否满足测试评估标准。

比如，对于风险整改这一非功能需求类别，其对应的评估项为生产事件或非功能遗留缺陷修复，测试评估标准为需根据生产事件或缺陷具体情况评估是否进行非功能测试，最小测试范围为测试指标根据生产事件或缺陷内容及本次改造内容评估确定，该过程明确了需评估的测试内容，如果根据最小测试内容评估得到上述范围内的测试指标需要进行非功测试，那么便可确定风险整改这一非功能需求类别是需要进行测试的。

如果非功能测试项目对应的项目模式为新建重构模式，此时的项目涉及大量的新组件，需要进行非功能测试，或者存在部分非功能需求类别需要进行非功能测试的情况，此时同样需要对非功能测试项目进行功能测试，以确保系统的整体性能和质量。在项目模式为改造模式的情况下，如果所有的非功能需求类型均不需要进行非功能测试，则说明当前引入的系统无需额外进行非功能测试。

S103：若是，对非功能测试项目对应的测试内容进行分析，以确定完成测试内容所需的目标测试项，并将非功能测试项目与预设的持续集成工具建立连接。

上述过程对非功能测试项目是否需要需要进行非功能测试进行了验证，若要对非功能测试项目进行测试，还需通过分析相应的测试内容，明确完成测试内容所需的目标测试项。通过将测试流程拆分为若干目标测试项，能够有针对性地为每一目标测试项提供相应的测试资源，提高分配效率和准确度。对于需要进行非功能测试的项目，需要将非功能测试项目与预设的持续集成工具建立连接，这样实现了将传统的手动测试流程转换为自动化且能够实时反馈的测试机制。

为了更为高效地执行非功能测试，需要对测试需求进行更为细致的划分，并据此确定测试资源的管理粒度。管理粒度包括模糊管理粒度和精细管理粒度，其中，模糊管理粒度指示了一个大概的测试范围，这是从测试执行阶段的整体流程上进行划分的，精细管理粒度则是在模糊管理粒度的基础上，对划分出的整体流程中需要执行的目标测试项进行了更为精确的定位。

其中，在划分测试需求时，需要明确每个测试需求涉及的测试单元层级。其中，测试单元层级包括活动单元和工作子类型单元。在测试单元层级为活动单元的情况下，确定测试资源对应的管理粒度为模糊管理粒度；在测试单元层级为工作子类型单元的情况下，确定测试资源对应的管理粒度为精细管理粒度。

可以明确的是，在模糊管理粒度这一层面上，需要确定的测试内容是涉及到非功能测试的各种活动内容，而在精细管理粒度这一层面，需要确定的测试内容则是活动内容中涉及的具体测试项。因此，基于模糊管理粒度，将非功能测试项目划分为若干工作阶段，并确定工作阶段包含的多个活动单元。基于精细管理粒度，确定活动单元覆盖的工作子类型，根据非功能测试项目对应的测试内容，从工作子类型中选取指定工作子类型，作为完成测试内容所需的目标测试项。

比如，非功能测试项目可以划分为以下活动单元：填写非功能设计指标、评估非功能测试必要性、分析测试需求、制定及评审非功能测试方案案例、准备测试环境、执行非功能测试。不同的活动单元可涉及到的工作子类型也存在不同，针对每个活动单元，都可能涉及到具体的活动内容，比如，脚本开发与调试、性能容量和批处理和数据作业、可用性数据库测试、可用性批处理测试等。每一活动内容下覆盖有不同的工作子类型，对于可用性数据库测试这一活动内容，其覆盖的工作子类型包括数据库集群切换机制有效性、数据库自动重连机制有效性、应用重连数据库机制有效性、应用分库分表机制有效性、应用缓存去数据库依赖机制有效性。

S104：对目标测试项所需的测试预算时间进行预测，并根据测试预算时间对非功能测试项目分配相应的测试资源。

在明确执行非功能测试项目所需的目标测试项后，为了更好地实现测试资源管理，需要对该非功能测试项目对应的测试耗时进行估算，进而根据测试耗时，合理地对每个目标测试项分配相应的测试资源，为项目管理者提供科学的决策支持。

在一个实施例中，非功能测试需要落地到具体的目标测试项来进行，但是，在进行非功能测试时，首先需要基于每个活动单元进行模糊的测试耗时预测，进而对每个活动单元下需要进行的工作子类型进行更为精细的划分和预测。因此，先需要明确每个活动单元的整体测试耗时，然后针对每个活动单元，还需要对该活动单元中需要进行的工作子类型对应的局部测试耗时进行预测。根据局部测试耗时，计算目标测试项所需的测试预算时间。测试预算时间不大于整体测试耗时。

计算测试时间大多从以下几个方面进行。脚本开发与调试：初始测试脚本的编写和调试时间；性能/容量测试：确保系统在高负载条件下能够正常运行的时间评估；可用性测试：测试系统的用户体验和操作便利性的时间评估；可维护性测试：评估系统在长期运行中的维护成本的时间评估；可扩展性测试：确保系统能随着需求增长而扩展的时间评估；其它：包括安全性、兼容性等其他非功能测试的时间评估；验收测试：最终交付前的整体验收测试耗时；问题和缺陷修改：根据测试过程中发现的问题和缺陷进行修复和验证的时间评估。

上述过程仅对测试耗时进行了估算，还需确定非功能测试项目是否需要进行其他类型的测试内容。因此，确定非功能测试项目对应物理子系统的系统类型；其中，系统类型包括引入系统和自建系统。引入系统通常指的是通过采购或集成第三方服务、软件或硬件系统来构建的部分，这些系统可能已经过一定的测试和验证，但针对特定集成环境或业务需求的非功能特性（如性能、安全性、可靠性等）仍需进行验证测试。因此，对于引入系统类的非功能测试项目，需要确定验证测试对应的验证测试时间，由于验证测试不包含在初始的测试计划中，需要根据验证测试时间，对测试预算时间进行相应的更新。基于更新后的测试预算时间，合理分配测试资源，包括测试人员、测试环境、测试工具等，确保在对应的测试时间内有足够的资源支持测试活动的顺利进行。

S105：基于测试资源，在满足预设的触发条件时，通过持续集成工具，触发针对目标测试项的测试流程，实现对非功能测试项目的非功能测试。

当满足预设的触发条件时，通过持续集成工具，便可以响应于相应的操作，触发针对目标测试项的测试流程，使得测试更具有连续性和实时性。触发条件指的是存在代码提交操作或测试需求变更申请，因此，在非功能测试项目进行开发迭代的过程中，如果出现了上述两种情况，持续开发集成工具便会自动触发针对目标测试项的测试流程。该步骤将开发人员的代码提交操作与非功能性测试自动化执行过程结合，确保测试贯穿整个开发周期，及时发现并修复缺陷。

需要说明的是，NFTP模型能够进行动态的非功能需求管理，也就是动态调整非功能需求的优先级和测试覆盖范围，当开发需求内容模块中途变更或新增部署单元等，则模型动态调整改造需求，产出最新的测试内容和耗时计划，确保在项目开发过程中，即使需求发生变化，测试也能及时跟进。

以上为本申请提出的方法实施例。基于同样的思路，本申请的一些实施例还提供了上述方法对应的设备和非易失性计算机存储介质。

图2为本申请实施例提供的一种用于非功能测试的测试资源管理设备的结构示意图。如图2所示，包括：

至少一个处理器；以及，

至少一个处理器通信连接的存储器；其中，

存储器存储有可被至少一个处理器执行的指令，指令被至少一个处理器执行，以使至少一个处理器能够执行如上任一项所述的一种用于非功能测试的测试资源管理方法。

本申请实施例提供了一种非易失性计算机存储介质，存储有计算机可执行指令，计算机可执行指令设置为：

本申请中的各个实施例均采用递进的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于设备和介质实施例而言，由于其基本相似于方法实施例，所以描述的比较简单，相关之处参见方法实施例的部分说明即可。

本申请实施例提供的设备和介质与方法是一一对应的，因此，设备和介质也具有与其对应的方法类似的有益技术效果，由于上面已经对方法的有益技术效果进行了详细说明，因此，这里不再赘述设备和介质的有益技术效果。

本领域内的技术人员应明白，本申请的实施例可提供为方法、系统、或计算机程序产品。因此，本申请可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本申请可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质（包括但不限于磁盘存储器、CD-ROM、光学存储器等）上实施的计算机程序产品的形式。

本申请是参照根据本申请实施例的方法、设备（系统）、和计算机程序产品的流程图和／或方框图来描述的。应理解可由计算机程序指令实现流程图和／或方框图中的每一流程和／或方框、以及流程图和／或方框图中的流程和／或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和／或方框图一个方框或多个方框中指定的功能的装置。

这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和／或方框图一个方框或多个方框中指定的功能。

这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和／或方框图一个方框或多个方框中指定的功能的步骤。

在一个典型的配置中，计算设备包括一个或多个处理器 (CPU)、输入/输出接口、网络接口和内存。

内存可能包括计算机可读介质中的非永久性存储器，随机存取存储器 (RAM) 和/或非易失性内存等形式，如只读存储器 (ROM) 或闪存(flash RAM)。内存是计算机可读介质的示例。

计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括，但不限于相变内存 (PRAM)、静态随机存取存储器 (SRAM)、动态随机存取存储器 (DRAM)、其他类型的随机存取存储器 (RAM)、只读存储器 (ROM)、电可擦除可编程只读存储器 (EEPROM)、快闪记忆体或其他内存技术、只读光盘只读存储器(CD-ROM)、数字多功能光盘 (DVD) 或其他光学存储、磁盒式磁带，磁带磁磁盘存储或其他磁性存储设备或任何其他非传输介质，可用于存储可以被计算设备访问的信息。按照本文中的界定，计算机可读介质不包括暂存电脑可读媒体 (transitory media)，如调制的数据信号和载波。

还需要说明的是，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、商品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、商品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、商品或者设备中还存在另外的相同要素。

以上所述仅为本申请的实施例而已，并不用于限制本申请。对于本领域技术人员来说，本申请可以有各种更改和变化。凡在本申请的精神和原理之内所作的任何修改、等同替换、改进等，均应包含在本申请的权利要求范围之内。

Claims

1.一种用于非功能测试的测试资源管理方法，其特征在于，所述方法包括：

确定所述项目类型对应的非功能需求类别，根据所述项目模式以及所述非功能需求类别对应的项目组件组装逻辑，确定所述非功能测试项目是否需进行非功能测试；所述项目组件组装逻辑用于明确所述非功能测试项目需要进行测试的特定非功能需求类别；

基于所述测试资源，在满足预设的触发条件时，通过所述持续集成工具，触发针对所述目标测试项的测试流程，实现对所述非功能测试项目的非功能测试；所述触发条件指的是存在代码提交操作或测试需求变更申请；

根据所述项目模式以及所述非功能需求类别对应的项目组件组装逻辑，确定所述非功能测试项目是否需进行非功能测试，具体包括：

所述项目模式包括新建重构模式和改造模式；

2.根据权利要求1所述的一种用于非功能测试的测试资源管理方法，其特征在于，根据所述项目组件组装逻辑，确定所述非功能需求类别是否需进行非功能测试，具体包括：

若是，确定所述非功能需求类别需进行非功能测试。

3.根据权利要求1所述的一种用于非功能测试的测试资源管理方法，其特征在于，对所述非功能测试项目对应的测试内容进行分析，以确定完成所述测试内容所需的目标测试项，具体包括：

4.根据权利要求3所述的一种用于非功能测试的测试资源管理方法，其特征在于，对所述非功能测试项目对应的测试需求进行划分，根据所述测试需求，确定所述测试资源对应的管理粒度，具体包括：

5.根据权利要求4所述的一种用于非功能测试的测试资源管理方法，其特征在于，对所述非功能测试项目对应的测试内容进行分析，以确定完成所述测试内容所需的目标测试项，具体包括：

6.根据权利要求5所述的一种用于非功能测试的测试资源管理方法，其特征在于，对所述目标测试项所需的测试预算时间进行预测，具体包括：

确定所述活动单元对应的整体测试耗时以及所述目标测试项对应的局部测试耗时；

根据所述局部测试耗时，计算所述目标测试项所需的测试预算时间；其中，所述测试预算时间不大于所述整体测试耗时。

7.根据权利要求1所述的一种用于非功能测试的测试资源管理方法，其特征在于，对所述目标测试项所需的测试预算时间进行预测之后，所述方法还包括：

8.一种用于非功能测试的测试资源管理设备，其特征在于，所述设备包括：

至少一个处理器；

以及，与所述至少一个处理器通信连接的存储器；

其中，所述存储器存储有可被所述至少一个处理器执行的指令，所述指令被所述至少一个处理器执行，以使所述至少一个处理器能够执行如权利要求1-7任一项所述的一种用于非功能测试的测试资源管理方法。

9.一种非易失性计算机存储介质，存储有计算机可执行指令，其特征在于，所述计算机可执行指令设置为：

如权利要求1-7任一项所述的一种用于非功能测试的测试资源管理方法。