软件质量评价方法、装置、终端设备及存储介质与流程

本申请属于研发管理
技术领域：
，尤其涉及一种软件质量评价方法、装置、终端设备及存储介质。
背景技术：
：目前，在对软件的软件质量进行评价时，通常是根据软件的某一因素进行评估。然而，影响软件质量的因素涵盖多个方面，只通过单一因素评估软件的软件质量，具有严重的局限性。另外，用于生成软件质量评价模型的测试用例通常与待测试软件没有联系。因此，根据该测试用例得到的软件质量测试模型，在对软件进行评估时的准确率也无法保证。技术实现要素：本申请实施例提供了一种软件质量评价方法、装置、终端设备及存储介质，可以解决现有技术中难以生成高质量的软件测试模型，无法保证对软件进行评估时的准确率的问题。第一方面，本申请实施例提供了一种软件质量评价方法，包括：从多个软件质量因素中确定当前用于评价软件质量的目标因素，所述目标因素包括软件中脚本文件的代码复杂度、开发脚本文件的人力时间以及脚本文件的代码规模；基于待测试软件的测试功能，从具有相同所述测试功能的测试库中获取测试用例；获取所述测试用例中属于所述目标因素的目标信息，并根据所述目标信息对预设的回归方程进行回归分析，生成软件质量测试模型；其中，所述目标信息包括所述测试用例的测试脚本文件的代码复杂度、开发测试脚本文件的人力时间和测试脚本文件的代码规模；获取所述待测试软件中属于所述目标因素的待测试信息，将所述待测试信息输入至所述软件质量测试模型，得到软件质量评价信息。在一实施例中，在所述基于待测试软件的测试功能，从具有相同所述测试功能的测试库中获取测试用例之前，还包括：获取初始测试用例，以及获取用于描述所述初始测试用例的初始描述信息；计算所述初始描述信息与所述测试库中存储的所述测试用例的描述信息之间的相似度；若所述相似度小于预设相似度，则计算所述初始测试用例的第一用例质量；若所述第一用例质量大于或等于预设质量，则将所述初始测试用例和所述初始描述信息存储至所述测试库中。在一实施例中，在所述计算所述初始描述信息与所述测试库中存储的所述测试用例的描述信息之间的相似度之后，还包括：若所述相似度大于或等于预设相似度，则获取与所述初始测试用例的相似度大于或等于预设相似度的第一测试用例；计算所述初始测试用例的第一用例质量，并获取所述第一测试用例的第二用例质量；若所述第一用例质量大于所述第二用例质量，则删除所述第一测试用例，将所述初始测试用例存储至所述测试库中。在一实施例中，所述计算所述初始测试用例的第一用例质量，包括：获取所述初始测试用例的第一脚本文件，并统计所述第一脚本文件中逻辑语句的第一数量；确定包含所述初始测试用例的对比软件，并统计所述对比软件的第二脚本文件中逻辑语句的第二数量；获取所述初始测试用例中的漏洞信息；根据所述第一数量、所述第二数量以及所述漏洞信息，计算所述初始测试用例的第一用例质量。在一实施例中，所述初始测试用例中包括多个漏洞信息；所述根据所述第一数量、所述第二数量以及所述漏洞信息，计算所述初始测试用例的第一用例质量，包括：根据预设的漏洞信息与漏洞等级之间的对应关系，分别确定每个漏洞信息的漏洞等级；分别统计每个漏洞等级的对应的漏洞信息的漏洞数量，并根据所述漏洞等级对应的权重值和所述漏洞数量，计算所述初始测试用例的漏洞质量；根据所述第一数量、所述第二数量以及所述漏洞质量，计算所述初始测试用例的第一用例质量。在一实施例中，所述获取所述测试用例中属于所述目标因素的目标信息，并根据所述目标信息对预设的回归方程进行回归分析，生成软件质量测试模型，包括：获取所述测试用例的测试脚本文件，并计算所述测试脚本文件中的代码复杂度；获取开发所述测试脚本文件的人力时间以及所述测试脚本文件的代码规模；根据所述测试脚本文件中的代码复杂度、所述测试脚本文件的代码规模以及所述测试脚本文件的人力时间，对预设的回归方程进行回归分析，生成软件质量测试模型。在一实施例中，所述获取所述测试用例的测试脚本文件，并计算所述测试脚本文件中的代码复杂度，包括：根据所述测试用例的测试脚本文件生成控制流图，所述控制流图包含所述测试用例在执行过程中所需遍历的路径；统计所述路径的路径数量以及形成所述路径的节点数量；根据所述路径数量和所述节点数量计算所述代码复杂度。第二方面，本申请实施例提供了一种软件质量评价装置，包括：确定模块，用于从多个软件质量因素中确定当前用于评价软件质量的目标因素，所述目标因素包括软件中脚本文件的代码复杂度、开发脚本文件的人力时间以及脚本文件的代码规模；第一获取模块，用于基于待测试软件的测试功能，从具有相同所述测试功能的测试库中获取测试用例；生成模块，用于获取所述测试用例中属于所述目标因素的目标信息，并根据所述目标信息对预设的回归方程进行回归分析，生成软件质量测试模型；其中，所述目标信息包括所述测试用例的测试脚本文件的代码复杂度、开发测试脚本文件的人力时间和测试脚本文件的代码规模；第二获取模块，用于获取所述待测试软件中属于所述目标因素的待测试信息，将所述待测试信息输入至所述软件质量测试模型，得到软件质量评价信息。第三方面，本申请实施例提供了一种终端设备，包括存储器、处理器以及存储在所述存储器中并可在所述处理器上运行的计算机程序，所述处理器执行所述计算机程序时实现如上述第一方面任一项所述的方法。第四方面，本申请实施例提供了一种计算机可读存储介质，所述计算机可读存储介质存储有计算机程序，其特征在于，所述计算机程序被处理器执行时实现如上述第一方面任一项所述的方法。第五方面，本申请实施例提供了一种计算机程序产品，当计算机程序产品在终端设备上运行时，使得终端设备执行上述第一方面中任一项所述的方法。在本申请实施例中，通过确定用于评价软件质量的多个目标因素，并从具有相同功能的测试库中获取测试用例，根据测试用例中属于多个目标因素的目标信息去优化软件质量测试模型，使得生成的软件质量测试模型在对软件质量进行评价时的评价效果，比随机使用不同功能的测试用例生成的软件质量测试模型对软件质量进行评价时的效果更准确。同时，软件质量模型为根据回归方程进行建立的模型，可通过回归方程对多个目标因素进行回归分析，进而在优化软件质量测试模型的过程中，修正因目标因素的个数过多而导致模型拟合效果过高的情况，使得生成软件质量测试模型在对待测试软件的软件质量进行评估时，其准确率更高。附图说明为了更清楚地说明本申请实施例中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。图1是本申请一实施例提供的一种软件质量评价方法的实现流程图；图2是本申请另一实施例提供的一种软件质量评价方法的实现流程图；图3是本申请再一实施例提供的一种软件质量评价方法的实现流程图；图4是本申请另一实施例提供的一种软件质量评价方法的s202的一种实现方式示意图；图5是本申请另一实施例提供的一种软件质量评价方法的s404的一种实现方式示意图；图6是本申请一实施例提供的一种软件质量评价方法的s103的一种实现方式示意图；图7是本申请一实施例提供的一种软件质量评价方法的s601的一种实现方式示意图；图8是本申请一实施例提供的一种软件质量评价方法中的一种控制流图；图9是本申请一实施例提供的一种软件质量评价方法中的另一种控制流图；图10是本申请实施例提供的一种软件质量评价装置的结构框图；图11是本申请实施例提供的一种终端设备的结构框图。具体实施方式以下描述中，为了说明而不是为了限定，提出了诸如特定系统结构、技术之类的具体细节，以便透彻理解本申请实施例。然而，本领域的技术人员应当清楚，在没有这些具体细节的其他实施例中也可以实现本申请。在其他情况中，省略对众所周知的系统、装置、电路以及方法的详细说明，以免不必要的细节妨碍本申请的描述。应当理解，当在本申请说明书和所附权利要求书中使用时，术语“包括”指示所描述特征、整体、步骤、操作、元素和/或组件的存在，但并不排除一个或多个其他特征、整体、步骤、操作、元素、组件和/或其集合的存在或添加。另外，在本申请说明书和所附权利要求书的描述中，术语“第一”、“第二”、“第三”等仅用于区分描述，而不能理解为指示或暗示相对重要性。请参阅图1，图1示出了本申请实施例提供的一种软件质量评价方法的实现流程图，包括如下步骤：s101、从多个软件质量因素中确定当前用于评价软件质量的目标因素，所述目标因素包括软件中脚本文件的代码复杂度、开发脚本文件的人力时间以及脚本文件的代码规模。在本实施例中，上述软件质量因素为用于评判软件质量好坏的因素，其包括软件中脚本文件的代码复杂度、开发脚本文件的人力时间以及脚本文件的代码规模。还可包括软件的初期故障率、软件偶然故障率、缺陷密度等。因确定的软件质量因素不同，得到的软件评估结果也相应不同。同时因软件质量的不确定因素较多，可认为软件质量因素还包括人力资源、时间因素、团队合作等因素，对此不作限定。在本实施例中，上述确定目标因素可以为终端设备接收测试人员的确定指令，并根据确定指令从多个软件质量因素中，确定出对软件质量最具影响的一个或多个因素。在其他示例中，为排除人为主观性的选择干扰，可以在上述多个软件质量因素随机挑选目标因素，用于对软件质量进行评估。其中，目标因素具体包括软件中脚本文件的代码复杂度、开发脚本文件的人力时间以及脚本文件的代码规模。s102、基于待测试软件的测试功能，从具有相同所述测试功能的测试库中获取测试用例。在本实施例中，上述待测试软件通常具有多个功能，例如，界面显示功能、系统响应功能等。在本实施例中，软件质量的评估贯穿软件开发过程的各个方面，在开发并实现软件的某一功能后，便可对该待测试软件的功能进行评估，了解并纠正软件的运行状况。其中，测试库中可预先存储有与测试功能相对应的测试用例，每个测试用例是测试人员在对软件功能完整性及稳定性进行测试的过程中，由测试人员编写的包含测试手段、测试步骤、预期结果、实际结果等内容的脚本或文档。其中，相同功能的测试用例可更好的反映待测试软件在实施时存在的问题。示例性的，测试用例的来源具体可以为将某个软件中的各个功能对应的脚本文件作为测试用例。在具体实施例中，测试库中为包含某个软件所有功能对应的脚本文件，每个脚本文件可对应实现该软件中的一个功能。测试库在存储所有脚本文件之后，可标记该软件实现的所有功能。之后，若待测试软件中的任一功能或多个功能，均与测试库中已标记的功能相同，则该测试库即为具有相同测试功能的数据库，并可从该测试库中获取测试用例。s103、获取所述测试用例中属于所述目标因素的目标信息，并根据所述目标信息对预设的回归方程进行回归分析，生成软件质量测试模型；其中，所述目标信息包括所述测试用例的测试脚本文件的代码复杂度、测试脚本文件的人力时间和测试脚本文件的代码规模。在本实施例中，上述代码复杂度为判定实现相应功能的脚本文件结构的复杂程度。也可以理解为，上述代码复杂度表现为测试测试脚本文件中运行路径条数。因此，可通过计算测试脚本文件中运行路径条数得到代码复杂度。例如，测试脚本文件中包含一条if语句，则表示将有两条路径来执行:if(条件满足)...，else(否则条件满足)...。因此，可确定此时代码复杂度为2。在本实施例中，软件质量一般受多个目标因素的共同影响，因此，为了更好的根据多个因素对软件质量进行评估，可建立多个因素与软件质量之间的多元回归模型。因多元回归模型可表明自变量(多个目标信息)和因变量(软件质量)之间的显著关系，且可衡量不同尺度变量之间的相互影响。例如，代码规模与时间之间的相互影响。因此，得到的软件质量测试模型可以更好的根据多个不同尺度之间的目标因素对软件进行评估。在本实施例中，对于一个测试用例，其可实现相应功能则具有可实现相应功能的脚本文件，且可认为该脚本文件同样包含上述多个软件质量因素。因此，可在测试用例中获取到属于目标因素的目标信息。例如，目标因素为代码规模，根据测试用例对应的测试脚本文件，可对应获取测试脚本文件包含的脚本行数作为测试脚本文件的代码规模，并获取开发测试脚本文件的人力时间和代码复杂度等信息，作为目标因素的目标信息参与软件质量测试模型的优化。在本实施例中，对代码复杂度、代码规模行以及人力时间进行回归分析，即将代码复杂度、代码规模行以及人力时间作为自变量，同时将该测试用例在运行时产生的漏洞信息(漏洞数量或漏洞等级)作为因变量，进行回归分析。具体的，对于三个自变量进行回归分析时，其回归方程可以为：y＝j0+j1a1+j2a2+j3a3。其中，具体软件质量测试模型的分析方法如下：请参照如下表格，表1为目标因素的目标信息：具体的，根据对上面表1的数据进行回归分析，得到的结果如下表2：表2：其中，multipler：相关系数r的值，可设置r值大于0.8表示强正相关；rsquare：是r平方值，即判定系数、拟合优度，取值范围是[0，1]。r2值越大表示得到的软件质量测试模型拟合效果越好。可设定r2大于等于70％时，软件质量测试模型的拟合效果好。adjustedr：调整后的r方，用于修正因自变量个数增加而导致模型拟合效果过高的情况，在本实施例中，自变量的个数只有3个，因此可忽略该数值。对上述表2数据进行分析，得到的结果如下表3：表3：其中：df是回归自由度，ss是平方和，ms是均方，f是f统计量，significancef是回归方程总体的显著性检验。对于得到的软件质量模型中，最重要的即为significancef值，它可检验因变量与各个自变量之间的线性关系是否显著，越小即更能用该线性模型分析当前数据。其中，残差是实际值与预测值之间的差，残差图用于回归诊断，回归模型在理想条件下，其残差图服从正态分布。对上述表3数据进行分析，得到的结果如下表4：表4：系数j标准误差p-value函数46.25116.1040.063a10.0190.0020.005a2-0.0340.2670.906a30.6500.7540.451其中：p-value，也就是p值，用来检验回归方程中各个系数的显著性，根据各个因变量(系数)对应的数值，可在多个因变量之间确定出对软件质量的影响程度，找出显著因素，进而可根据显著因素实现评价软件质量的效果。其中，显著性具体评判标准可根据实际情况进行设置。根据上述表4内容，可得回归方程(软件质量模型)为：y＝46.251+0.019a1-0.034a2+0.650a3。需要说明的是，通过回归方程计算软件质量测试模型，可以在计算过程中，从多个目标因素的目标信息中确定出对软件质量影响程度的重要因素和次要因素，并确定各个因素对软件质量的影响程度，进而可根据重要因素计算得到软件质量测试模型，提高软件质量测试模型对应待测试软件评价的准确率。s104、获取所述待测试软件中属于所述目标因素的待测试信息，将所述待测试信息输入至所述软件质量测试模型，得到软件质量评价信息。在本实施例中，上述待测试信息包括待测试软件中待测试脚本文件的代码复杂度、开发待测试脚本文件的人力时间以及待测试脚本文件的代码规模。在本实施例中，上述软件质量模型为根据目标因素进行分析计算得到的，因此，为准确对待测试软件进行评估，也需使用待测试软件中目标因素对应的待测试信息。即获取待测试软件中待测试脚本文件的代码复杂度、开发待测试脚本文件的人力时间以及待测试脚本文件的代码规模。另外，从具有相同测试功能的测试库中获取测试用例的目的在于：根据该测试库中的测试用例得到的软件质量测试模型，在对待测试软件的软件质量进行评估的评价效果，比随机使用不同功能的测试用例生成的软件质量测试模型对软件质量进行评估的评价效果更准确。在本实施例中，上述软件质量评价信息为描述软件质量的信息，其中，软件质量测试模型可根据上述待测试信息输出相应的评价数值。而终端设备内部可预先存储有多个阈值区间，且每个阈值区间对应一个软件质量评价信息。终端设备可根据评价数值处于的阈值区间，对应输出软件质量评价信息。示例性的，上述阈值区间可以为用户根据实际情况进行设定，例如，可设定阈值区间[0，100]，[100，200]，[200，+∞]等，对应的软件质量评价信息分别软件质量良好，软件质量一般，软件质量差。在确定上述待测试脚本文件的代码复杂度、人力时间以及代码规模后，将上述数值依次代替软件质量测试模型中的自变量(a1，a2，a3)进行计算得到评价数值。可认为在对待测试软件的人力时间、代码规模以及代码复杂度进行综合考虑时，软件质量评价模型输出的评价数值越小，即计算得到的漏洞数量(回归方程输出的y值)越小。进而，可认为输出的软件质量评价信息为软件质量良好的评价信息。在本实施例中，上述获取待测试信息可以为终端设备预先存储有待测试软件中的待测试信息，在对待测试软件进行评估时，终端设备可在指定的存储路径下进行获取。在本实施例中，通过确定用于评价软件质量的多个目标因素，并从具有相同功能的测试库中获取测试用例，根据测试用例中属于多个目标因素的目标信息去优化软件质量测试模型，使得生成的软件质量测试模型在对软件质量进行评价时的评价效果，比随机使用不同功能的测试用例生成的软件质量测试模型对软件质量进行评价时的效果更准确。同时，软件质量模型为根据回归方程进行建立的模型，可通过回归方程对多个目标因素进行回归分析，进而在优化软件质量测试模型的过程中，修正因目标因素的个数过多而导致模型拟合效果过高的情况，使得生成软件质量测试模型在对待测试软件的软件质量进行评估时，其准确率更高。请参照图2，在一具体实施例中，在s102基于待测试软件的测试功能，从具有相同所述测试功能的测试库中获取测试用例之前，还包括如下步骤s201-s204，详述如下：s201、获取初始测试用例，以及获取用于描述所述初始测试用例的初始描述信息。在本实施例中，上述初始测试用例的来源可以与测试用例的来源一致，即具体可以为将对比软件中一个或多个功能对应的脚本文件作为初始测试用例，对此不再详细说明。上述初始描述信息包括但不限于描述该测试用例的测试步骤、测试结果以及功能的一种或多种信息。s202、计算所述初始描述信息与所述测试库中存储的所述测试用例的描述信息之间的相似度。在本实施例中，对于一个完整的测试库应该包含实现某个软件所有功能对应的脚本文件，以及描述每个脚本文件的描述信息。因此，对于该测试库中任一存储的测试用例，可直接从测试库中进行获取，且还可直接获取测试用例对应的描述信息。其中，描述信息可以与测试用例建立关联关系存储在测试库中，以便终端设备可根据测试用例获取描述信息，或者，根据描述信息获取测试用例。在本实施例中，在获取到初始描述信息与描述信息之后，可比对初始描述信息和描述信息之间的相似度。即比对两者之间的测试步骤、测试结果以及功能之间的相似度。具体的，可以根据建立的相似度模型计算初始描述信息与描述信息之间的相似度。其中，上述描述信息均可以文字的形式进行存储。因此，可预先建立包含测试步骤、测试结果以及功能的训练文本数据，而后建立深度神经网络模型，分别提取测试步骤、测试结果以及功能的文本特征。例如，分别提取每个训练文本数据中，关于描述信息的测试步骤的步骤文本特征、测试结果的结果文本特征、以及功能的功能文本特征。并分别对每个训练文本数据的上述多个特征进行特征融合，得到两个融合特征。将两个融合特征输入至模型中，输出训练模型对两个融合特征之间进行预测的预测相似度。之后，根据两个训练文本数据的实际相似度与预测相似度计算训练损失，根据训练损失迭代更新训练模型。而后，根据训练后的训练模型提取初始描述信息中的文本特征，以及提取各个测试用例的描述信息对应的文本特征，分别进行比较输出初始描述信息中的文本特征与各个描述信息对应的文本特征的比对结果。其中，可认为训练模型输出的比对结果即为初始描述信息与测试用例的描述信息相似度。s203、若所述相似度小于预设相似度，则计算所述初始测试用例的第一用例质量。在本实施例中，上述预设相似度可以由测试人员根据实际情况进行设置。相似度小于预设相似度时，可认为初始测试用例未存储在测试库。示例性的，测试库中预先存储有实现a软件所有功能的脚本文件，并标记了a软件对应的各个功能。若a软件版本更新后增添了新的功能，则测试库在接收到新功能对应的初始测试用例后，测试库可依次将该初始测试用例的初始描述信息与已存储的各个测试用例中的各个描述信息进行比较，确定是否存储过初始测试用例。在本实施例中，第一用例质量为使用的初始测试用例的质量优劣。现有技术中，对于测试用例没有很好的分类，也没有完整的评价体系来评价一个测试用例质量的优劣，测试用例之间的用例质量也无法进行比较。因此，为便于区分测试用例质量的优劣，上述计算初始测试用例的第一用例质量可以为计算初始测试用例中漏洞(bug)的严重程度，来确定第一用例质量。或者，计算初始测试用例对应的逻辑代码语句数量，与包含初始测试用例的对比软件中所有逻辑代码语句数量的比值，作为初始测试用例中的第一用例质量。s204、若所述第一用例质量大于或等于预设质量，则将所述初始测试用例和所述初始描述信息存储至所述测试库中。在本实施例中，上述预设质量可以为根据实际情况进行设定的数值。在第一用例质量大于或等于预设质量时，可认为使用初始测试用例计算得到的软件质量测试模型，对待测试软件进行评价的准确率效果，比使用第一测试用例计算得到软件质量测试模型，对待测试软件进行评价的准确率效果更好。在本实施例中，通过计算初始测试用例与测试库中已有测试用例之间的相似度，并在相似度小于预设相似度，以及初始测试用例的第一用例质量大于或等于预设质量时，将初始测试用例和初始描述信息存储至所述测试库中。不仅可以丰富测试库中的测试用例，还可保证测试库中各个测试用例的用例质量，使得通过该测试库中的测试用例计算得到的软件质量测试模型，可以更准确的对待测试软件进行评价。请参照图3，在一具体实施例中，在s202计算所述初始描述信息与所述测试库中存储的所述测试用例的描述信息之间的相似度之后，还包括如下步骤s301-s303，详述如下：s301、若所述相似度大于或等于预设相似度，则获取与所述初始测试用例的相似度大于或等于预设相似度的第一测试用例。s302、计算所述初始测试用例的第一用例质量，并获取所述第一测试用例的第二用例质量。在本实施例中，若相似度大于或等于预设相似度，则表明初始测试用例与测试库中已存储的第一测试用例之间相似或相同。因此，可删除相似的第一测试用例，将初始测试用例存储至相同功能类别的测试库中，或者保留原有的第一测试用例，不存储初始测试用例。在本实施例中，上述第一用例质量的计算方式已在s203中进行描述，对此不在详细说明。其中，第二用例质量可以认为是第一测试用例在存储至测试库时已经计算得到，且与第一测试用例同时存储在测试库中。s303、若所述第一用例质量大于所述第二用例质量，则删除所述第一测试用例，将所述初始测试用例存储至所述测试库中。在本实施例中，在第一用例质量大于第二用例质量时，可认为初始测试用例与第一测试用例不仅相似，且可认为使用初始测试用例计算得到的软件质量测试模型，对待测试软件进行评价的准确率效果，比使用第一测试用例计算得到软件质量测试模型，对待测试软件进行评价的准确率效果更好。可以理解的是，若第一用例质量小于或等于第二用例质量，则可认为初始测试用例与第一测试用例虽然相似，但是可认为使用初始测试用例计算得到的软件质量测试模型，对待测试软件进行评价的准确率效果，比使用第一测试用例计算得到软件质量测试模型，对待测试软件进行评价的准确率效果差或效果相同。此时，可直接删除初始测试用例，保留第一测试用例，减少了更新测试库的步骤。另外，需要说明的是，若初始描述信息与第一测试用例的描述信息之间的相似度为100％，即可表明初始测试用例与已有测试用例完全一致。因此，也可直接删除初始测试用例，保留第一测试用例，减少了更新测试库的步骤，且无需s302与s303的步骤。使测试库内的测试用例可经过不断的迭代和更新，以及不断增加用例质量高的测试用例至测试库，提高测试库中整体的用例质量，以及增加测试库中包含的测试用例对应实现的功能。在其他应用中，对于一个测试库应该包含软件所有功能对应的脚本文件，然而，该测试库是否包含软件所有功能对应的脚本文件则需要进行检测。例如，根据最新版本的对比软件对应的所有功能，可检测该测试库中包含的软件相对应的测试用例功能覆盖率是否达到100％。如果测试库的功能覆盖率未达100％，则表明该测试库中还有对比软件的其余功能的测试用例未添加，此时需继续往测试库中添加测试用例。如果测试库的功能覆盖率达100％，则表明该测试库中已全部添加对比软件所有功能的测试用例。如果测试库的功能覆盖率超过100％，则表明测试库中的测试用例存在冗余用例，即存在实现相同功能的测试用例，则需判断各个测试用例的相似度，并根据用例质量进行剔除优化。其中，测试库在存储脚本文件时，可标记该脚本文件实现的功能。因此，可获取测试库中所有脚本文件对应实现的功能及数量，与最新版本的对比软件包含的所有功能及数量进行计算得到功能覆盖率。在本实施例中，在确定第一测试用例与初始测试用例相似时，计算初始测试用例的第一用例质量，并与第一测试用例的第二用例质量进行比较，在第一用例质量大于第二用例质量，则删除已存储的第一测试用例，并将初始测试用例存储至测试库中。使测试库内的测试用例可经过不断的迭代和更新，提高测试库中整体的用例质量。请参照图4，在一具体实施例中，在s203或s302计算所述初始测试用例的第一用例质量中，还包括如下子步骤s401-s404，详述如下：s401、获取所述初始测试用例的第一脚本文件，并统计所述第一脚本文件中逻辑语句的第一数量。在本实施例中，脚本文件包含执行应用程序中相应功能的代码，可认为上述第一脚本文件包含执行初始测试用例对应功能的代码。其中，第一脚本文件的脚本语言包括但不限于sql、javascript、vbscript等语言。其中，逻辑语句包括但不限于if、else等语句，可认为一个逻辑语句即为一条代码分支或逻辑分支。上述逻辑语句的第一数量可以认为是统计第一脚本文件中属于逻辑语句的数量，也可以认为是统计第一脚本文件中逻辑分支或代码分支的数量。s402、确定包含所述初始测试用例的对比软件，并统计所述对比软件的第二脚本文件中逻辑语句的第二数量。在本实施例中，s201中已说明将已有的对比软件中一个或多个功能对应的脚本文件作为初始测试用例，因此，可认为在获取初始测试用例时，已经确定包含初始测试用例的对比软件。上述第二脚本文件即为该对比软件中包含的所有脚本文件，可认为第二脚本文件也包含了初始测试用例对应的第一脚本文件。因此，根据统计第一脚本文件中逻辑语句的第一数量的方法，可同样获取第二脚本文件中所有逻辑语句的第二数量。s403、获取所述初始测试用例中的漏洞信息。在本实施例中，漏洞可认为是对比软件中存在的弱点或缺陷信息，上述漏洞信息可以理解为对比软件中漏洞的数量、漏洞的严重程度等。该漏洞信息可以预先由测试人员进行记录，并存储在终端设备的指定路径下。也可以为终端设备在运行对比软件中的初始测试用例时，自动统计出现的漏洞数量，同时还可基于预设的漏洞影响对应的漏洞等级，在运行初始测试用例出现漏洞时，根据出现的漏洞对对比软件产生的漏洞影响，标记漏洞对应的漏洞等级。s404、根据所述第一数量、所述第二数量以及所述漏洞信息，计算所述初始测试用例的第一用例质量。在本实施例中，根据第一数量以及第二数量，可以计算初始测试用例中第一脚本文件的代码在对比软件的第二脚本文件中的覆盖率，将覆盖率作为第一用例质量的参考值。示例性，对于一个对比软件，如果共有m条逻辑语句，而初始测试用例的第一脚本文件中包含n条逻辑语句，则可确定初始测试用例的代码覆盖率为n/m。其中，第一用例质量的参考值还包括漏洞信息。例如，可以计算初始测试用例中的漏洞信息数量在对比软件所有漏洞信息数量的比值，将比值作为第一用例质量的参考值，之后根据覆盖率与比值综合计算第一用例质量。请参照图5，在一具体实施例中，所述初始测试用例中包括多个漏洞信息；s404根据所述第一数量、所述第二数量以及所述漏洞信息，计算所述初始测试用例的第一用例质量，还包括如下子步骤s501-s503，详述如下：s501、根据预设的漏洞信息与漏洞等级之间的对应关系，分别确定每个漏洞信息的漏洞等级；在本实施例中，上述s403中已经描述终端设备如何确定漏洞信息对应的漏洞等级，对此不再详细描述。其中，上述漏洞信息包括s403中描述的漏洞出现时对对比软件产生的漏洞影响。在本实施例中，上述根据漏洞对软件的影响程度，可以将漏洞分为低程度漏洞、中程度漏洞以及高程度漏洞。示例性的，对于软件运行时图片加载不清楚的漏洞可认为是低程度的漏洞，对于造成软件运行时崩溃的漏洞即为高程度漏洞，对此可根据实际情况进行设定。s502、分别统计每个漏洞等级的对应的漏洞信息的漏洞数量，并根据所述漏洞等级对应的权重值和所述漏洞数量，计算所述初始测试用例的漏洞质量。在本实施例中，上述漏洞数量可以为初始测试用例中包含的低程度漏洞的数量、初始测试用例中包含的中程度漏洞的数量，以及初始测试用例中包含的高程度漏洞数量中的任意一种或多种，对此不作限定。可以理解的是，不同漏洞等级对应的漏洞对对比软件产生的影响程度不同。可在终端设备内部预先设置多个漏洞等级分别对应的权重值。因此，可在计算初始测试用例的漏洞质量时，对不同漏洞等级的漏洞可赋予不同的权重值参与计算。具体的，计算漏洞质量的公式可以为：计算第一用例质量可以为：其中，n为第一数量，m为第二数量，x1为低程度漏洞的数量、x2为中程度漏洞的数量，x3为高程度漏洞的数量，w1为低程度漏洞的权重值、w2为中程度漏洞的权重值，w3为高程度漏洞的权重值。另外，在实际计算过程中，可设置w1的值小于w2的值，w2的值小于w3的值。以便对于计算得到的y值，可认为y值越高，初始测试用例在对比软件中包含代码覆盖率越高，或者包含的漏洞严重程度越重。即可认为使用初始测试用例计算得到软件质量评价模型，可以更好的发现待测试软件中的各个漏洞问题。请参照图6，在一具体实施例中，s103获取所述测试用例中属于所述目标因素的目标信息，并根据所述目标信息对预设的回归方程进行回归分析，生成软件质量测试模型；还包括如下子步骤s601-s603，详述如下：s601、获取所述测试用例的测试脚本文件，并计算所述测试脚本文件中的代码复杂度。s602、获取开发所述测试脚本文件的人力时间以及所述测试脚本文件的代码规模。s603、根据所述测试脚本文件中的代码复杂度、所述测试脚本文件的代码规模以及所述测试脚本文件的人力时间，对预设的回归方程进行回归分析，生成软件质量测试模型。在本实施例中，上述计算测试脚本文件中的代码复杂度具体可参照上述s103中通过计算测试脚本文件中运行路径条数得到代码复杂度的内容，对此不再详细描述。在本实施例中，在获取到测试脚本文件中的代码复杂度、测试脚本文件的代码规模以及测试脚本文件的人力时间后，对预设的回归方程进行回归分析，生成软件质量测试模型。具体可参照上述s103中的实施例，对此不再详细描述。请参照图7，在一具体实施例中，s601获取所述测试用例的测试脚本文件，并计算所述测试脚本文件中的代码复杂度，还包括如下子步骤s701-s703，详述如下：s701、根据所述测试用例的测试脚本文件生成控制流图，所述控制流图包含所述测试用例在执行过程中所需遍历的路径。在本实施例中，上述控制流图可以为根据测试脚本文件中对应的代码顺序结构，以及代码分支语句生成的控制流图。上述路径包含测试脚本文件中所有代码函数的所有可执行路径。s702、统计所述路径的路径数量以及形成所述路径的节点数量。s703、根据所述路径数量和所述节点数量计算所述代码复杂度。在本实施例中，上述路径数量即为s701中所有代码函数的所有可执行路径的数量，路径数量也可以理解为控制流图中边的数量，或者理解为对应代码中的顺序结构部分。上述节点数量为控制流图中的判定节点数量，其包括起点和终点。在实际计算过程中，测试脚本文件的代码中，所有的终点均只计算一次。例如，一段代码中即使有多个return或者throw也均只计算一次。在本实施例中，上述代码复杂度的计算公式如下：v(g)＝e–f+2*p；其中，v(g)为代码复杂度，e为路径数量(控制流图中边的数量)，f为节点数量(控制流图中的判定节点数量)，p为独立组件个数，也为控制流图的连接组件数目，然而控制流图都是连通且完整的，因此p为1。即v(g)＝e–f+2。在一具体实施例中，为具体说明根据测试脚本文件的代码计算代码复杂度，其示例如下：对应的，根据上述代码生成的控制流图可参考图8和图9。基于此，从演变过程中看到，上述测试脚本文件中的代码中有4个if语句(分支语句)，对应4个判定节点，加上开始一个节起点，结束的多个终点计算为一个终点，共6个判定节点，即f＝6。控制流图中边的数量如图9可知，e＝9。即v(g)＝9-6+2＝5。在本实施例中，根据测试用例生成的控制流图，并统计路径的路径数量以及形成路径的节点数量计算代码复杂度，使得到的代码复杂度可以准确的反应待测试脚本文件的代码质量。在一实施例中，在s104获取所述待测试软件中属于所述目标因素的待测试信息，将所述待测试信息输入至所述软件质量测试模型，得到软件质量评价信息之后,还包括：将所述软件质量评价信息上传至区块链中。具体的，在本申请的所有实施例中，基于终端设备得到对应的软件质量评价信息，具体来说，软件质量评价信息由终端工具进行处理得到。将软件质量评价信息上传至区块链可保证其安全性和对用户的公正透明性。用户设备可以从区块链中下载得该软件质量评价信息，以便查证软件质量评价信息是否被篡改。本示例所指区块链是分布式数据存储、点对点传输、共识机制、加密算法等计算机技术的新型应用模式。区块链(blockchain)，本质上是一个去中心化的数据库，是一串使用密码学方法相关联产生的数据块，每一个数据块中包含了一批次网络交易的信息，用于验证其信息的有效性(防伪)和生成下一个区块。区块链可以包括区块链底层平台、平台产品服务层以及应用服务层等。请参阅图10，图10是本申请实施例提供的一种软件质量评价装置的结构框图。本实施例中该终端设备包括的各单元用于执行图1至图7对应的实施例中的各步骤。具体请参阅图1至图7以及图1至图7所对应的实施例中的相关描述。为了便于说明，仅示出了与本实施例相关的部分。参见图10，软件质量评价装置100包括：确定模块110、第一获取模块120、生成模块130和第二获取模块140，其中：确定模块110，用于从多个软件质量因素中确定当前用于评价软件质量的目标因素，所述目标因素包括软件中脚本文件的代码复杂度、开发脚本文件的人力时间以及脚本文件的代码规模。第一获取模块120，用于基于待测试软件的测试功能，从具有相同所述测试功能的测试库中获取测试用例。生成模块130，用于获取所述测试用例中属于所述目标因素的目标信息，并根据所述目标信息对预设的回归方程进行回归分析，生成软件质量测试模型；其中，所述目标信息包括所述测试用例的测试脚本文件的代码复杂度、开发测试脚本文件的人力时间和测试脚本文件的代码规模。第二获取模块140，用于获取所述待测试软件中属于所述目标因素的待测试信息，将所述待测试信息输入至所述软件质量测试模型，得到软件质量评价信息。在一实施例中，软件质量评价装置100还包括：第三获取模块，用于获取初始测试用例，以及获取用于描述所述初始测试用例的初始描述信息。第一计算模块，用于计算所述初始描述信息与所述测试库中存储的所述测试用例的描述信息之间的相似度。第二计算模块，用于若所述相似度小于预设相似度，则计算所述初始测试用例的第一用例质量。第一存储模块，用于若所述第一用例质量大于或等于预设质量，则将所述初始测试用例和所述初始描述信息存储至所述测试库中。在一实施例中，软件质量评价装置100还包括：第四获取模块，用于若所述相似度大于或等于预设相似度，则获取与所述初始测试用例的相似度大于或等于预设相似度的第一测试用例；第三计算模块，用于计算所述初始测试用例的第一用例质量，并获取所述第一测试用例的第二用例质量。第二存储模块，用于若所述第一用例质量大于所述第二用例质量，则删除所述第一测试用例，将所述初始测试用例存储至所述测试库中。在一实施例中，第二计算模块或第三计算模块还用于：获取所述初始测试用例的第一脚本文件，并统计所述第一脚本文件中逻辑语句的第一数量；确定包含所述初始测试用例的对比软件，并统计所述对比软件的第二脚本文件中逻辑语句的第二数量；获取所述初始测试用例中的漏洞信息；根据所述第一数量、所述第二数量以及所述漏洞信息，计算所述初始测试用例的第一用例质量。在一实施例中，所述初始测试用例中包括多个漏洞信息；第三计算模块或第四计算模块还用于：根据预设的漏洞信息与漏洞等级之间的对应关系，分别确定每个漏洞信息的漏洞等级；分别统计每个漏洞等级的对应的漏洞信息的漏洞数量，并根据所述漏洞等级对应的权重值和所述漏洞数量，计算所述初始测试用例的漏洞质量；根据所述第一数量、所述第二数量以及所述漏洞质量，计算所述初始测试用例的第一用例质量。在一实施例中，生成模块130还用于：获取所述测试用例的测试脚本文件，并计算所述测试脚本文件中的代码复杂度；获取开发所述测试脚本文件的人力时间以及所述测试脚本文件的代码规模；根据所述测试脚本文件中的代码复杂度、所述测试脚本文件的代码规模以及所述测试脚本文件的人力时间，对预设的回归方程进行回归分析，生成软件质量测试模型。在一实施例中，生成模块130还用于：根据所述测试用例的测试脚本文件生成控制流图，所述控制流图包含所述测试用例在执行过程中所需遍历的路径；统计所述路径的路径数量以及形成所述路径的节点数量；根据所述路径数量和所述节点数量计算所述代码复杂度。应当理解的是，图10示出的软件质量评价装置的结构框图中，各单元/模块用于执行图1至图7对应的实施例中的各步骤，而对于图1至图7对应的实施例中的各步骤已在上述实施例中进行详细解释，具体请参阅图1至图7以及图1至图7所对应的实施例中的相关描述，此处不再赘述。图11是本申请另一实施例提供的一种终端设备的结构框图。如图11所示，该实施例的终端设备1100包括：处理器1101、存储器1102以及存储在存储器1102中并可在处理器1101运行的计算机程序1103，例如软件质量评价方法的程序。处理器1101执行计算机程序1103时实现上述各个软件质量评价方法各实施例中的步骤，例如图1所示的s101至s104。或者，处理器1101执行计算机程序1103时实现上述图10对应的实施例中各单元的功能，例如，图10所示的单元110至140的功能，具体请参阅图10对应的实施例中的相关描述。示例性的，计算机程序1103可以被分割成一个或多个单元，一个或者多个单元被存储在存储器1102中，并由处理器1101执行，以完成本申请。一个或多个单元可以是能够完成特定功能的一系列计算机程序指令段，该指令段用于描述计算机程序1103在终端设备1100中的执行过程。例如，计算机程序1103可以被分割成确定单元、第一获取单元、生成单元以及第二获取单元，各单元具体功能如上。终端设备可包括，但不仅限于，处理器1101、存储器1102。本领域技术人员可以理解，图11仅仅是终端设备1100的示例，并不构成对终端设备1100的限定，可以包括比图示更多或更少的部件，或者组合某些部件，或者不同的部件，例如终端设备还可以包括输入输出设备、网络接入设备、总线等。所称处理器1101可以是中央处理单元，还可以是其他通用处理器、数字信号处理器、专用集成电路、现成可编程门阵列或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件等。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。存储器1102可以是终端设备1100的内部存储单元，例如终端设备1100的硬盘或内存。存储器1102也可以是终端设备1100的外部存储设备，例如终端设备1100上配备的插接式硬盘，智能存储卡，闪存卡等。进一步地，存储器1102还可以既包括终端设备1100的内部存储单元也包括外部存储设备。以上实施例仅用以说明本申请的技术方案，而非对其限制；尽管参照前述实施例对本申请进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本申请各实施例技术方案的精神和范围，均应包含在本申请的保护范围之内。当前第1页12