CN115964288A - 软件测试方法、设备、存储介质及程序产品 - Google Patents

Abstract

本申请实施例提供一种软件测试方法、设备、存储介质及程序产品，该方法包括获取待测试软件的特征数据，特征数据包括待测试软件的开发周期、开发团队、业务需求数量、开发模式中的至少一项，将特征数据输入质量预测模型，获得待测试软件的质量等级，根据质量等级，确定待测试软件所需的测试资源，以根据待测试软件所需的测试资源，对待测试软件进行测试。本申请实施例提供的软件测试方法，能够为待测试软件准确合理的分配测试资源，进而基于分配的测试资源对软件进行测试，从而提高软件测试进度的可控制性。

Description

软件测试方法、设备、存储介质及程序产品

技术领域

本申请实施例涉及软件测试技术领域，尤其涉及一种软件测试方法、设备、存储介质及程序产品。

背景技术

随着软件技术的发展，软件更新周期越来越短，软件测试资源(例如人力资源)是有限的，面对日益增大的测试工作量，如何有效的进行测试资源的调配，提高软件测试的进度的可控制性是至关重要的。

相关技术中，管理者可以基于个人经验进行人力资源的分配。

然而，实现本申请过程中，发明人发现现有技术中至少存在如下问题：上述分配方式准确性较低，时常出现人力资源紧张或过剩的情况。

发明内容

本申请实施例提供一种软件测试方法、设备、存储介质及程序产品，以提高测试资源调配的合理性，以及软件测试的可控制性。

第一方面，本申请实施例提供一种软件测试方法，包括：

获取待测试软件的特征数据；所述特征数据包括所述待测试软件的开发周期、开发团队、业务需求数量、开发模式中的至少一项；

将所述特征数据输入质量预测模型，获得所述待测试软件的质量等级；

根据所述质量等级，确定所述待测试软件所需的测试资源，以根据所述待测试软件所需的测试资源，对所述待测试软件进行测试。

在一种可能的设计中，所述方法还包括：

获取多个历史软件的特征数据；所述历史软件是已经完成软件测试的软件；

将所述多个历史软件的特征数据构建样本集；

基于所述样本集，对多元逻辑回归模型进行训练，获得质量预测模型。

在一种可能的设计中，所述获取多个历史软件的特征数据，包括：

获取多个历史软件的原始数据；

对所述原始数据进行清洗，获得清洗后的数据；

对所述清洗后的数据进行数据特征量化和规范化，获得多个历史软件的特征数据。

在一种可能的设计中，所述基于所述样本集，对多元逻辑回归模型进行训练，获得质量预测模型，包括：

将所述样本集划分为第一数量的训练集和第二数量的测试集；

将所述训练集输入所述多元逻辑回归模型中，训练获得所述多元逻辑回归模型的待求参数的多组解；

根据所述第二数量的测试集对所述多组解进行验证和筛选，获得最优解，并根据所述最优解确定所述质量预测模型。

在一种可能的设计中，所述根据所述第二数量的测试集对所述多组解进行验证和筛选，获得最优解，并根据所述最优解确定所述质量预测模型，包括：

根据所述多组解，构建第二数量的待选模型；

通过所述第二数量的测试集对所述第二数量的待选模型的泛化能力进行一一对应的验证，获得所述第二数量的待选模型分别对应的泛化能力值；

将所述第二数量的待选模型中泛化能力值最高的待选模型，确定为所述质量预测模型。

在一种可能的设计中，所述方法还包括：

根据所述待测试软件的测试结果确定所述待测试软件的实际质量等级；

基于所述待测试软件的实际质量等级和特征数据，对所述质量预测模型的参数进行更新，获得新的质量预测模型。

第二方面，本申请实施例提供一种软件测试设备，包括：

获取模块，用于获取待测试软件的特征数据；所述特征数据包括所述待测试软件的开发周期、开发团队、业务需求数量、开发模式中的至少一项；

输入模块，用于将所述特征数据输入质量预测模型，获得所述待测试软件的质量等级；

确定模块，用于根据所述质量等级，确定所述待测试软件所需的测试资源。

第三方面，本申请实施例提供一种软件测试设备，包括：至少一个处理器和存储器；

所述存储器存储计算机执行指令；

所述至少一个处理器执行所述存储器存储的计算机执行指令，使得所述至少一个处理器执行如上第一方面以及第一方面各种可能的设计所述的方法。

第四方面，本申请实施例提供一种计算机可读存储介质，所述计算机可读存储介质中存储有计算机执行指令，当处理器执行所述计算机执行指令时，实现如上第一方面以及第一方面各种可能的设计所述的方法。

第五方面，本申请实施例提供一种计算机程序产品，包括计算机程序，所述计算机程序被处理器执行时，实现如上第一方面以及第一方面各种可能的设计所述的方法。

本实施例提供的软件测试方法、设备、存储介质及程序产品，该方法包括获取待测试软件的特征数据，特征数据包括待测试软件的开发周期、开发团队、业务需求数量、开发模式中的至少一项，将特征数据输入质量预测模型，获得待测试软件的质量等级，根据质量等级，确定待测试软件所需的测试资源，以根据待测试软件所需的测试资源，对待测试软件进行测试。本申请实施例提供的软件测试方法，通过基于构建的质量预测模型，根据待测试软件的开发周期、开发团队、业务需求数量、开发模式等特征数据，预测获得待测试软件按的质量等级，并根据预测的质量等级为待测试软件准确合理的分配测试资源，进而基于分配的测试资源对软件进行测试，从而提高软件测试进度的可控制性。

附图说明

为了更清楚地说明本申请实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作一简单地介绍，显而易见地，下面描述中的附图是本申请的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动性的前提下，还可以根据这些附图获得其他的附图。

图1为本申请实施例提供的软件测试方法的应用场景示意图；

图2为本申请实施例提供的软件测试方法的流程示意图一；

图3为本申请实施例提供的质量预测模型的训练过程的流程示意图；

图4为本申请实施例提供的质量预测模型的训练和测试过程的原理示意图；

图5为本申请实施例提供的软件测试方法的流程示意图二；

图6为本申请实施例提供的软件测试设备的结构示意图；

图7为本申请实施例提供的软件测试设备的硬件结构示意图。

具体实施方式

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

随着软件技术的飞速发展以及软件快速迭代，软件质量的稳定性和可靠性变得尤为重要，而软件测试作为保障软件质量的关键环节，目的就在于以耗费尽可能少的人力、物力在短时间内尽可能多的找出软件中的缺陷，以对软件进行修复。软件更新周期越来越短，软件测试人力资源是有限的，面对日益增大的测试工作量，如何有效的进行人力资源的调配，提高软件测试的进度的可控制性是至关重要的。

相关技术中，管理者可以基于个人经验进行人力资源的分配。然而，上述分配方式准确性较低，时常出现人力资源紧张或过剩的情况。

为了解决上述技术问题，本申请发明人研究发现，不同的软件测试中，影响人力资源准确性的关键因素是需要准确知晓待测试软件的软件质量(例如缺陷密度)，质量高的待测试软件，测试工作量会相对较低，发明人还发现影响软件质量的因素有版本开发周期、项目组名称、业务需求数量、开发模式等因素。从而，可以训练一个质量预测模型(示例性的，可以通过对已经完成软件测试的历史软件的相关数据进行梳理，来基于该数据训练获得质量预测模型)，通过该模型来根据待测试软件的特征数据(版本开发周期、项目组名称、业务需求数量、开发模式等)预测待测试软件的软件质量，进而可以基于预测得到的软件质量进行待测试软件的人力资源调配。基于此，本申请实施例提供一种软件测试方法，通过基于构建的质量预测模型，根据待测试软件的开发周期、开发团队、业务需求数量、开发模式等特征数据，预测获得待测试软件按的质量等级，并根据预测的质量等级为待测试软件准确合理的分配测试资源，进而基于分配的测试资源对软件进行测试，从而提高软件测试进度的可控制性。

图1为本申请实施例提供的软件测试方法的应用场景示意图。如图1所示，终端设备101安装有软件测试平台的客户端。终端设备101可以为计算机、平板电脑、手机等设备。

在具体实现过程中，终端设备101可以响应于用户的触控操作，登录软件测试平台的客户端，并将待测试软件的特征数据通过交互界面输入至后台的质量预测模型，预测获得待测试软件的质量等级，基于测试资源与软件质量等级之间的对应关系，根据所述质量等级，确定所述待测试软件所需的测试资源，以根据所述待测试软件所需的测试资源，对所述待测试软件进行测试。本申请实施例提供的软件测试方法，通过基于构建的质量预测模型，根据待测试软件的开发周期、开发团队、业务需求数量、开发模式等特征数据，预测获得待测试软件按的质量等级，并根据预测的质量等级为待测试软件准确合理的分配测试资源，进而基于分配的测试资源对软件进行测试，从而提高软件测试进度的可控制性。

需要说明的是，图1所示的场景示意图仅仅是一个示例，本申请实施例描述的软件测试方法以及场景是为了更加清楚地说明本申请实施例的技术方案，并不构成对于本申请实施例提供的技术方案的限定，本领域普通技术人员可知，随着系统的演变和新业务场景的出现，本申请实施例提供的技术方案对于类似的技术问题，同样适用。

下面以具体地实施例对本申请的技术方案进行详细说明。下面这几个具体的实施例可以相互结合，对于相同或相似的概念或过程可能在某些实施例不再赘述。

图2为本申请实施例提供的软件测试方法的流程示意图一。如图2所示，该方法包括：

201、获取待测试软件的特征数据；所述特征数据包括所述待测试软件的开发周期、开发团队、业务需求数量、开发模式中的至少一项。

本实施例的执行主体可以为图1所示的终端设备101。

其中，开发周期是指软件从开始立项到完成开发交付测试的时长。通常开发周期与软件质量等级为正相关，即开发周期越长软件质量等级会越高。开发团队是指待测试软件的所有开发人员构成的团队。不同的开发团队的作业习惯、作业理念会有不同，因此不同的开发团队开发的软件的质量水平通常不一样。业务需求数量是指待测试软件中包括多少项业务需求，通常不同业务需求的代码开发工作量是基本相同的，即相对于代码行数，采用业务需求数量可以更加准确的表征待测试软件的开发工作量。开发模式可以包括敏捷开发模式、瀑布开发模式等。瀑布开发模式适用于软件需求十分明确并且不会有频繁变化的项目，敏捷开发模式适用于需求不明确、具有创新性或者需要抢占市场的项目。通常情况下采用瀑布开发模式的待测试软件的质量等级会较高。

本实施例中，特征数据可以采用开发周期、开发团队、业务需求数量、开发模式中的至少一项。具体采用其中的几项特征因素，可以在训练过程中，根据训练得到的质量预测模型的测试情况来确定。示例性的，如果仅采用其中一两个特征因素时出现欠拟合情况，则可以增加特征因素。如果同时采用四个特征因素，开发周期、开发团队、业务需求数量、开发模式会出现过拟合现象，则可以减少特征因素。

202、将所述特征数据输入质量预测模型，获得所述待测试软件的质量等级。

203、根据所述质量等级，确定所述待测试软件所需的测试资源，以根据所述待测试软件所需的测试资源，对所述待测试软件进行测试。

具体的，可以将质量等级划分为多个质量等级，例如等级1-5，等级越高质量越好，缺陷密度越小。可以预先设定不同质量等级与测试资源的对应关系，例如等级5所需的测试资源是每个需求对应n个测试资源，等级4所需的测试资源是每个需求对应1.5n个测试资源。从而在预测获得质量等级后，可以基于质量等级与测试资源的对应关系，确定待测试软件所需的测试资源的多少。进而可以基于分配的测试资源对待测试软件进行测试。合理的测试资源的分配，能够保证测试工作的顺利进行，避免出现人力紧缺或人力过剩的情况。

本实施例提供的软件测试方法，通过基于构建的质量预测模型，根据待测试软件的开发周期、开发团队、业务需求数量、开发模式等特征数据，预测获得待测试软件按的质量等级，并根据预测的质量等级为待测试软件准确合理的分配测试资源，进而基于分配的测试资源对软件进行测试，从而提高软件测试进度的可控制性。

图3为本申请实施例提供的质量预测模型的训练过程的流程示意图。如图3所示，该方法包括：

301、获取多个历史软件的特征数据；所述历史软件是已经完成软件测试的软件。

具体的，可以将已经完成软件测试且已经上线的软件的特征数据，开发周期、开发团队、业务需求数量、开发模式等进行梳理，并基于这些数据建立样本集，以基于样本集训练得到质量预测模型。

在一些实施例中，由于历史软件的不同特征数据可能来自于不同的系统(例如，业务需求数量可能来源于需求管理系统，开发周期可能来源于软件开发管理系统)，数据的格式多种多样，无法进行统一处理，因此可以首先对历史软件的不同特征数据进行清洗、量化等预处理。所述获取多个历史软件的特征数据，可以包括：获取多个历史软件的原始数据；对所述原始数据进行清洗，获得清洗后的数据；对所述清洗后的数据进行数据特征量化和规范化，获得多个历史软件的特征数据。

具体的，在获取到历史软件的原始数据后，可以对其中存在错误的数据或者重复的数据进行清洗处理，在得到清洗后的数据以后，对清洗后的数据进行特征量化是指将非数值型属性数据转化为数值型属性数据，例如特征数据中的开发团队，不同的开发团队可以采用不同的数值来代表，团队A可以用001代表，团队B可以用002代表。对清洗后的数据进行规范化是指对数据进行无量纲化处理，并将不同量纲的数据转换到同一量纲，也包括将不同格式的数据转换为同一格式。

302、将所述多个历史软件的特征数据构建样本集。

具体的，针对每一历史软件，将其特征数据进行整理，并为其标记上实际的软件质量等级，其中，实际的软件质量等级可以是根据软件测试结果来确定，示例性的，可以根据软件测试结果确定软件的缺陷密度，将该缺陷密度作为软件质量的指标，并基于缺陷密度划分不同的软件质量等级。

303、基于所述样本集，对多元逻辑回归模型进行训练，获得质量预测模型。

具体的，在获得将样本集构建完成后，可以将样本集中的样本输入多元逻辑回归模型，对多元逻辑回归模型进行训练，建立特征数据与软件质量等级之间的对应关系，得到质量预测模型。

示例性的，假设特征数据中的不同因素表示为自变量{x1，x2…，xi}(i≥2)和因变量软件质量指标y存在一定关系，表达式如下：

y＝f(x_i) (1)

本实施例中，可以采用二元逻辑回归模型、多元逻辑回归模型等机器学习算法训练得到质量预测模型。

以二元逻辑回归模型为例。

首先，线性边界的表达式为：

逻辑回归算法的拟合函数，即sigmond函数的表达式为：

表达式(3)表示分类结果为1事的概率，因此对于输入点x，分类结果为类别1和类别0的概率分别为以下表达式：

P(y＝1|x；e)＝h_θ(x)

P(y＝0|x；θ)＝1-h_θ(x) (4)

对于样本集，特征数据x＝{x1，x2…，xm}，对应的分类数据y＝{y1，y2…，ym}。对表达式(4)取最大似然函数并取对数，可以得到以下逻辑回归模型的损失函数：

后续可以基于表达式(5)的损失函数，采用梯度下降法来求解能够令损失函数为最大值的e，当然可以对表达式(5)取负数得到新的损失函数，即求解新的损失函数为最小值的e。

基于上述二元逻辑回归模型，对于多元逻辑回归模型，可以定义为包含k-1个二元逻辑回归模型。对于输入x，分类结果为各类别(各软件质量等级)的概率如下表达式所示：

其中，k为类别个数，即软件质量等级的等级个数。

对于表达式(6)，多元逻辑回归模型的权重w为一个矩阵，矩阵的行数与类别个数相关，通过最大似然估计，建立损失函数可以如以下表达式：

进而可以采用梯度下降算法求解能够使表达式(7)的损失函数达到最小值的权重值w。

在一些实施例中，为了保证质量预测模型的泛化能力，即对新鲜样本呢的适应能力。可以将样本集的样本划分为一定比例的训练集和测试集，通过训练集训练得到模型，进而通过测试集对训练得到的模型进行泛化能力的测试。具体的，所述基于所述样本集，对多元逻辑回归模型进行训练，获得质量预测模型，可以包括：将所述样本集划分为第一数量的训练集和第二数量的测试集；将所述训练集输入所述多元逻辑回归模型中，训练获得所述多元逻辑回归模型的待求参数的多组解；根据所述第二数量的测试集对所述多组解进行验证和筛选，获得最优解，并根据所述最优解确定所述质量预测模型。

所述根据所述第二数量的测试集对所述多组解进行验证和筛选，获得最优解，并根据所述最优解确定所述质量预测模型，可以包括：根据所述多组解，构建第二数量的待选模型；通过所述第二数量的测试集对所述第二数量的待选模型的泛化能力进行一一对应的验证，获得所述第二数量的待选模型分别对应的泛化能力值；将所述第二数量的待选模型中泛化能力值最高的待选模型，确定为所述质量预测模型。

示例性的，如图4所示，假设样本集中有1200个样本，那么可以将该1200个样本中的一半，即600个样本加入训练集，将剩余的的600个样本分为3个测试集，a、b和c，每个测试集中有200个样本。

可以通过训练集中的样本训练得到3组解，每一组解可以得到一个待测试模型，具体的，可以将600个样本划分为3个训练集，每个训练集训练得到一组解。另外为了保证训练集的样本数量，还可以从600个样本中随机调取500个样本，训练得到第一组解，再随机调取500个样本，训练得到第二组解，再随机调取500个样本，训练得到第三组解。每次随机调取的500个样本之间存在交叉。

在得到3个待测试模型，模型A、模型B和模型C后，可以采用测试集a对模型A的泛化能力进行测试，采用测试集b对模型B的泛化能力进行测试，采用测试集c对模型C的泛化能力进行测试。以模型A和测试集a为例，具体可以计算测试集a中的样本输入模型A后得到的软件质量等级的预测值与实际值之间的误差，将该误差确定为模型A的泛化能力。

在得到模型A、B和C的泛化能力后，可以比较获得泛化能力最高的模型，也即对新鲜样本适应能力最强的模型，并将该模型确定为最终的质量预测模型，从而可以保证质量预测模型的准确性。

在一些实施例中，如果训练获得的多个待测试模型的泛化能力均不能达到预期，则可以采取以下措施来提高训练得到的模型的泛化能力。针对欠拟合的情况，可以增加特征，减少正则化参数。针对过拟合的情况，可以重新清洗样本集中的数据，将导致过拟合的数据删除，还可以增大样本数量。还可以采用正则化方法，例如L0正则、L1正则和L2正则。

本实施例提供的软件测试方法，通过采用多元逻辑回归模型训练得到质量预测模型，能够对多个质量等级进行预测，提高了测试资源调配的灵活性。

图5为本申请实施例提供的软件测试方法的流程示意图二。如图5所示，在上述实施例的基础上，例如在图2所示实施例的基础上，本实施例中，为了提高质量预测模型的准确性，可以在当前的待测试软件完成测试后，根据待测试软件的实际质量等级对质量预测模型进行更新。该方法包括：

501、获取待测试软件的特征数据；所述特征数据包括所述待测试软件的开发周期、开发团队、业务需求数量、开发模式中的至少一项。

502、将所述特征数据输入质量预测模型，获得所述待测试软件的质量等级。

503、根据所述质量等级，确定所述待测试软件所需的测试资源，以根据所述待测试软件所需的测试资源，对所述待测试软件进行测试。

本申请实施例中步骤501至步骤504与上述实施例中步骤201至步骤203相类似，此处不再赘述。

504、根据所述待测试软件的测试结果确定所述待测试软件的实际质量等级。

505、基于所述待测试软件的实际质量等级和特征数据，对所述质量预测模型的参数进行更新，获得新的质量预测模型。

具体的，为了提高质量预测模型的准确性，可以将最近完成测试的待测试软件加入样本集，对当前的质量预测模型继续进行训练，得到新的质量预测模型。后续基于新的质量预测模型对软件的质量等级进行预测。

本实施例提供的软件测试方法，通过对质量预测模型不断更新，能够提高质量预测模型的准确性，从而能够保证软件测试的资源调配的合理性。

图6为本申请实施例提供的软件测试设备的结构示意图。如图6所示，该软件测试设备60包括：获取模块601、输入模块602以及确定模块603。

获取模块601，用于获取待测试软件的特征数据；所述特征数据包括所述待测试软件的开发周期、开发团队、业务需求数量、开发模式中的至少一项。

输入模块602，用于将所述特征数据输入质量预测模型，获得所述待测试软件的质量等级。

确定模块603，用于根据所述质量等级，确定所述待测试软件所需的测试资源。

本申请实施例提供的软件测试设备，通过基于构建的质量预测模型，根据待测试软件的开发周期、开发团队、业务需求数量、开发模式等特征数据，预测获得待测试软件按的质量等级，并根据预测的质量等级为待测试软件准确合理的分配测试资源，进而基于分配的测试资源对软件进行测试，从而提高软件测试进度的可控制性。

本申请实施例提供的软件测试设备，可用于执行上述的方法实施例，其实现原理和技术效果类似，本实施例此处不再赘述。

图7为本申请实施例提供的软件测试设备的硬件结构示意图，该设备可以是计算机，消息收发设备，平板设备，医疗设备等。

设备70可以包括以下一个或多个组件：处理组件701，存储器702，电源组件703，多媒体组件704，音频组件705，输入/输出(I/O)接口706，传感器组件707，以及通信组件708。

处理组件701通常控制设备70的整体操作，诸如与显示，电话呼叫，数据通信，相机操作和记录操作相关联的操作。处理组件701可以包括一个或多个处理器709来执行指令，以完成上述的方法的全部或部分步骤。此外，处理组件701可以包括一个或多个模块，便于处理组件701和其他组件之间的交互。例如，处理组件701可以包括多媒体模块，以方便多媒体组件704和处理组件701之间的交互。

存储器702被配置为存储各种类型的数据以支持在设备70的操作。这些数据的示例包括用于在设备70上操作的任何应用程序或方法的指令，联系人数据，电话簿数据，消息，图片，视频等。存储器702可以由任何类型的易失性或非易失性存储设备或者它们的组合实现，如静态随机存取存储器(SRAM)，电可擦除可编程只读存储器(EEPROM)，可擦除可编程只读存储器(EPROM)，可编程只读存储器(PROM)，只读存储器(ROM)，磁存储器，快闪存储器，磁盘或光盘。

电源组件703为设备70的各种组件提供电力。电源组件703可以包括电源管理系统，一个或多个电源，及其他与为设备70生成、管理和分配电力相关联的组件。

多媒体组件704包括在所述设备70和用户之间的提供一个输出接口的屏幕。在一些实施例中，屏幕可以包括液晶显示器(LCD)和触摸面板(TP)。如果屏幕包括触摸面板，屏幕可以被实现为触摸屏，以接收来自用户的输入信号。触摸面板包括一个或多个触摸传感器以感测触摸、滑动和触摸面板上的手势。所述触摸传感器可以不仅感测触摸或滑动动作的边界，而且还检测与所述触摸或滑动操作相关的持续时间和压力。在一些实施例中，多媒体组件704包括一个前置摄像头和/或后置摄像头。当设备70处于操作模式，如拍摄模式或视频模式时，前置摄像头和/或后置摄像头可以接收外部的多媒体数据。每个前置摄像头和后置摄像头可以是一个固定的光学透镜系统或具有焦距和光学变焦能力。

音频组件705被配置为输出和/或输入音频信号。例如，音频组件705包括一个麦克风(MIC)，当设备70处于操作模式，如呼叫模式、记录模式和语音识别模式时，麦克风被配置为接收外部音频信号。所接收的音频信号可以被进一步存储在存储器702或经由通信组件708发送。在一些实施例中，音频组件705还包括一个扬声器，用于输出音频信号。

I/O接口706为处理组件701和外围接口模块之间提供接口，上述外围接口模块可以是键盘，点击轮，按钮等。这些按钮可包括但不限于：主页按钮、音量按钮、启动按钮和锁定按钮。

传感器组件707包括一个或多个传感器，用于为设备70提供各个方面的状态评估。例如，传感器组件707可以检测到设备70的打开/关闭状态，组件的相对定位，例如所述组件为设备70的显示器和小键盘，传感器组件707还可以检测设备70或设备70一个组件的位置改变，用户与设备70接触的存在或不存在，设备70方位或加速/减速和设备70的温度变化。传感器组件707可以包括接近传感器，被配置用来在没有任何的物理接触时检测附近物体的存在。传感器组件707还可以包括光传感器，如CMOS或CCD图像传感器，用于在成像应用中使用。在一些实施例中，该传感器组件707还可以包括加速度传感器，陀螺仪传感器，磁传感器，压力传感器或温度传感器。

通信组件708被配置为便于设备70和其他设备之间有线或无线方式的通信。设备70可以接入基于通信标准的无线网络，如WiFi，2G或3G，或它们的组合。在一个示例性实施例中，通信组件708经由广播信道接收来自外部广播管理系统的广播信号或广播相关信息。在一个示例性实施例中，所述通信组件708还包括近场通信(NFC)模块，以促进短程通信。例如，在NFC模块可基于射频识别(RFID)技术，红外数据协会(IrDA)技术，超宽带(UWB)技术，蓝牙(BT)技术和其他技术来实现。

在示例性实施例中，设备70可以被一个或多个应用专用集成电路(ASIC)、数字信号处理器(DSP)、数字信号处理设备(DSPD)、可编程逻辑器件(PLD)、现场可编程门阵列(FPGA)、控制器、微控制器、微处理器或其他电子元件实现，用于执行上述方法。

在示例性实施例中，还提供了一种包括指令的非临时性计算机可读存储介质，例如包括指令的存储器702，上述指令可由设备70的处理器709执行以完成上述方法。例如，所述非临时性计算机可读存储介质可以是ROM、随机存取存储器(RAM)、CD-ROM、磁带、软盘和光数据存储设备等。

上述的计算机可读存储介质，上述可读存储介质可以是由任何类型的易失性或非易失性存储设备或者它们的组合实现，如静态随机存取存储器(SRAM)，电可擦除可编程只读存储器(EEPROM)，可擦除可编程只读存储器(EPROM)，可编程只读存储器(PROM)，只读存储器(ROM)，磁存储器，快闪存储器，磁盘或光盘。可读存储介质可以是通用或专用计算机能够存取的任何可用介质。

一种示例性的可读存储介质耦合至处理器，从而使处理器能够从该可读存储介质读取信息，且可向该可读存储介质写入信息。当然，可读存储介质也可以是处理器的组成部分。处理器和可读存储介质可以位于专用集成电路(Application Specific IntegratedCircuits，简称：ASIC)中。当然，处理器和可读存储介质也可以作为分立组件存在于设备中。

本领域普通技术人员可以理解：实现上述各方法实施例的全部或部分步骤可以通过程序指令相关的硬件来完成。前述的程序可以存储于一计算机可读取存储介质中。该程序在执行时，执行包括上述各方法实施例的步骤；而前述的存储介质包括：ROM、RAM、磁碟或者光盘等各种可以存储程序代码的介质。

本申请实施例还提供一种计算机程序产品，包括计算机程序，所述计算机程序被处理器执行时，实现如上软件测试设备执行的软件测试方法。

最后应说明的是：以上各实施例仅用以说明本申请的技术方案，而非对其限制；尽管参照前述各实施例对本申请进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分或者全部技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本申请各实施例技术方案的范围。

Claims (10)

1.一种软件测试方法，其特征在于，包括：

获取待测试软件的特征数据；所述特征数据包括所述待测试软件的开发周期、开发团队、业务需求数量、开发模式中的至少一项；

将所述特征数据输入质量预测模型，获得所述待测试软件的质量等级；

根据所述质量等级，确定所述待测试软件所需的测试资源，以根据所述待测试软件所需的测试资源，对所述待测试软件进行测试。

2.根据权利要求1所述的方法，其特征在于，所述方法还包括：

获取多个历史软件的特征数据；所述历史软件是已经完成软件测试的软件；

将所述多个历史软件的特征数据构建样本集；

基于所述样本集，对多元逻辑回归模型进行训练，获得质量预测模型。

3.根据权利要求2所述的方法，其特征在于，所述获取多个历史软件的特征数据，包括：

获取多个历史软件的原始数据；

对所述原始数据进行清洗，获得清洗后的数据；

对所述清洗后的数据进行数据特征量化和规范化，获得多个历史软件的特征数据。

4.根据权利要求2所述的方法，其特征在于，所述基于所述样本集，对多元逻辑回归模型进行训练，获得质量预测模型，包括：

将所述样本集划分为第一数量的训练集和第二数量的测试集；

将所述训练集输入所述多元逻辑回归模型中，训练获得所述多元逻辑回归模型的待求参数的多组解；

根据所述第二数量的测试集对所述多组解进行验证和筛选，获得最优解，并根据所述最优解确定所述质量预测模型。

5.根据权利要求4所述的方法，其特征在于，所述根据所述第二数量的测试集对所述多组解进行验证和筛选，获得最优解，并根据所述最优解确定所述质量预测模型，包括：

根据所述多组解，构建第二数量的待选模型；

通过所述第二数量的测试集对所述第二数量的待选模型的泛化能力进行一一对应的验证，获得所述第二数量的待选模型分别对应的泛化能力值；

将所述第二数量的待选模型中泛化能力值最高的待选模型，确定为所述质量预测模型。

6.根据权利要求1-5任一项所述的方法，其特征在于，所述方法还包括：

根据所述待测试软件的测试结果确定所述待测试软件的实际质量等级；

基于所述待测试软件的实际质量等级和特征数据，对所述质量预测模型的参数进行更新，获得新的质量预测模型。

7.一种软件测试设备，其特征在于，包括：

获取模块，用于获取待测试软件的特征数据；所述特征数据包括所述待测试软件的开发周期、开发团队、业务需求数量、开发模式中的至少一项；

输入模块，用于将所述特征数据输入质量预测模型，获得所述待测试软件的质量等级；

确定模块，用于根据所述质量等级，确定所述待测试软件所需的测试资源。

8.一种软件测试设备，其特征在于，包括：至少一个处理器和存储器；

所述存储器存储计算机执行指令；

所述至少一个处理器执行所述存储器存储的计算机执行指令，使得所述至少一个处理器执行如权利要求1至6任一项所述的软件测试方法。

9.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质中存储有计算机执行指令，当处理器执行所述计算机执行指令时，实现如权利要求1至6任一项所述的软件测试方法。

10.一种计算机程序产品，包括计算机程序，其特征在于，所述计算机程序被处理器执行时实现权利要求1至6任一项所述的软件测试方法。

Images