CN109582578A - 软件测试用例的系统、方法、计算机可读介质及电子设备 - Google Patents

Abstract

本发明公开一种软件测试用例的系统、方法、计算机可读介质及电子设备。在本发明的一实施例中，一种软件测试用例质量评分方法包括完成初始测试用例；收集对所述初始测试用例的修正请求；根据所述修正请求完成最终测试用例并对所述初始测试用例执行第一次质量评分；执行线上验证并接收反馈信息；根据所述反馈信息对所述最终测试用例执行第二次质量评分；并储存所述初始测试用例、所述修正请求、所述最终测试用例及所述反馈信息。

Description

软件测试用例的系统、方法、计算机可读介质及电子设备

技术领域

本公开涉及软件测试技术领域，特别是涉及软件测试用例信息的信息管理系统、质量评分方法、计算机可读介质及电子设备。

背景技术

在软件的开发流程中，线上之前的软件测试对于完善软件功能占了相当重要的地位。其中，评分测试团队的工作质量是提升软件测试质量的重要举措。然而，软件测试往往是软件开发周期中的最后一个阶段，不利于反馈信息的收集，因此，对测试团队的工作质量无法提供很好的评分指标。此外，在软件上线时，业务方或用户反馈的问题常常不能直接反应给测试团队，导致测试团队无法了解测试完后的软件是否有问题，或无法藉此提升测试技巧或者方法。因此有需要改善目前软件测试的质量评估方式。

发明内容

本公开的目的之一在于通过线上公开、流通和输入功能，实现软件开发的参与者针对测试用例评审和线上反馈信息的沟通确认以及记录。通过记录的结果可将收集的信息量化而得出测试质量评分指标(例如测试用例覆盖率和漏测率)，并进行用例未覆盖和漏测范围的总结分析学习。

本发明一实施例公开一种软件测试用例质量评分方法，其包括完成初始测试用例；收集对所述初始测试用例的修正请求；根据所述修正请求完成最终测试用例并对所述初始测试用例执行第一次质量评分；执行线上验证并接收反馈信息；根据所述反馈信息对所述最终测试用例执行第二次质量评分；并储存所述初始测试用例、所述修正请求、所述最终测试用例及所述反馈信息。

在本发明的一实施例中，所述根据所述修正请求完成最终测试用例并对所述初始测试用例执行第一次质量评分包括根据所述修正请求对所述初始测试用例进行查核并对所述初始测试用例进行修改、删除、或新增而得到所述最终测试用例。

在本发明的一实施例中，所述根据所述修正请求完成最终测试用例并对所述初始测试用例执行第一次质量评分包括：计算所述初始测试用例的个数；计算所述初始测试用例的修正数；并根据所述个数以及所述修正数决定测试用例覆盖率。

在本发明的一实施例中，根据所述个数以及所述修正数决定测试用例覆盖率包括：

其中所述初始测试用例个数及所述修正数均为大于或等于零的整数。

在本发明的一实施例中，软件测试用例质量评分方法还包括在所述执行线上验证并接收反馈信息的步骤前，根据所述最终测试用例对软件进行软件测试。

在本发明的一实施例中，根据所述反馈信息对所述最终测试用例执行第二次质量评分包括：根据所述反馈信息计算漏测问题数；根据所述最终测试用例计算测试阶段发现问题数；并根据所述测试阶段发现问题数与所述漏测问题数决定漏测率。

在本发明的一实施例中，根据所述测试阶段发现问题数与所述漏测问题数决定漏测率包括：

其中所述漏测问题数与所述测试阶段发现问题数均为大于或等于零的整数。

本发明一实施例公开一种软件测试用例信息管理系统，包括：第一信息收集模块，用于收集初始测试用例及对初始测试用例的修正请求；第一评分模块，用于对所述初始测试用例执行第一次质量评分；第二信息收集模块，用于接收执行线上验证后的反馈信息；第二评分模块，用于根据所述反馈信息对所述最终测试用例执行第二次质量评分；及共享知识库，用于储存所述初始测试用例、所述修正请求、所述最终测试用例及所述反馈信息。

本发明一实施例公开一种计算机可读介质，其上存储有计算机程序，所述计算机程序被处理器执行时实现所述的软件测试用例质量评分方法。

本发明一实施例公开一种电子设备，包括：一个或多个处理器；及存储装置，用于存储一个或多个程序，当所述一个或多个程序被所述一个或多个处理器执行时，使得所述一个或多个处理器实现所述的软件测试用例质量评分方法。

本公开的技术手段可达成多个技术效果。线下测试用例评审需要需求方、开发方和测试方同时参加，本公开使用线上测试用例评审，可改善参加方组会时间不好确定的问题，藉此降低组会成本。

此外，本公开将收集的意见储存到共享知识库，便于经验的总结和扩散。

本公开还包括在测试执行前，进行测试用例修改前后对比分析的功能，透过分析测试用例修改前后的差异程度，评判测试用例的编写质量。

附图说明

图1为本发明一实施例的测试用例质量评分流程图；

图2为本发明一实施例的第一次测试用例质量评分流程图；

图3为本发明一实施例的用例补充点统计分析流程图；

图4为本发明一实施例的第二次测试用例质量评分流程图；

图5为本发明一实施例的漏测问题与测试环境发现问题统计分析；以及

图6为本发明一实施例的测试用例信息管理系统示意图。

具体实施方式

为更好的理解本发明的精神，以下结合本发明的部分优选实施例对其作进一步说明。

为了使本技术领域中具有通常知识者能制造并使用本发明的实施例，以下描述是针对一个特别的应用及其条件的情况。各种针对本发明的实施例所进行的修改方式，对本技术领域中具有通常知识者是显而易见的。而在此所定义的一般原理，在不偏离本发明的实施例的精神与范围下，可用于其他的实施方式和应用。因此，本发明的实施方式并不局限于已显示的实施例，而可得到与在此所揭示内容的原理与特征相符的最宽广范围。

在本公开中，需求方是指向开发方提出软件需求的客户或使用者，开发方是指依照需求方所提出的需求进行软件编程的人员，测试人员是指负责编写测试用例并测试软件的人员。

图1显示本发明一实施例的测试用例质量评分流程图100。在步骤102中，完成初始测试用例。在一实施例中，“初始测试用例”是指测试人员第一次上传的测试用例，尚未经过修改并且尚未执行。在一实施例中，测试人员可上传多个初始测试用例，每个初始测试用例包括测试用例编号、软件执行步骤、软件应用场景、预期结果等条目。

在步骤104中，收集对初始测试用例的修正请求。在一实施例中，“修正请求”是指开发方与需求方针对初始测试用例所提出的评审意见或者补充点。

在一实施例中，修正请求包括对初始测试用例进行修改、删除、或新增初始测试用例。例如，对初始测试用例的步骤、场景、预期结果等条目进行修改。例如，删除多余或重复的测试用例、及新增漏掉的测试用例。

在一实施例中，在步骤104中，修正请求被格式化地收集。在一实施例中，“格式化地收集”是指评审意见或者补充点逐条细分，不让其有一条多点的情况。例如，开发方与需求方的修正请求，包括需要在测试用例中增加保额保费、结算、财务等环节测试用例，格式化后，请求包括1.增加保额保费的场景、2.增加结算的场景、3.增加财务的场景。

在步骤106中，根据修正请求完成最终测试用例并对初始测试用例执行第一次质量评分。在一实施例中，根据修正请求，对初始测试用例进行查核，而得到最终测试用例。在一实施例中，根据修正请求，对所述初始测试用例进行修改、删除、或新增而得到所述最终测试用例。在一实施例中，每个反馈与修正的回合可产生一修正版本。经过一个或多个回合的修正流程后，可得到最终测试用例。

在一实施例中，第一次质量评分包括测试用例覆盖率分析，参照图2及图3进一步描述如后。

在步骤108中，执行线上验证并接收反馈信息。在一实施例中，在步骤108前，根据最终测试用例对软件进行软件测试。软件通过测试后，若发现软件缺陷，需要先解决才进入线上验证。例如，测试人员将软件应用于最终测试用例，以期在软件上线前，先解决已发现的软件缺陷。

在一实施例中，软件进入线上验证，验证后的结果会传送给需求方，让需求方判定软件是否符合需求，若需求方提出反馈信息，则予以接收。

在步骤110中，根据反馈信息对最终测试用例执行第二次质量评分。在一实施例中，第二次质量评分包括漏测率分析，参照图4及图5进一步描述如后。

在步骤112中，储存初始测试用例、修正请求、最终测试用例及反馈信息。在一实施例中，储存两个版本的测试用例：初始测试用例(修改前)与最终测试用例(修改后)。在一实施例中，上述两版本之间还包括一个以上的修改版本，则储存所有的修改版本。与测试用例有关的信息经储存，便于经验的总结和扩散，例如，储存的信息可被用于进行总结分析学习，并对下一次流程循环中的步骤102完成下一次初始测试用例形成正向回馈。

图1显示的实施例公开使用线上测试用例质量评分，可改善参加方组会时间不好确定的问题，藉此降低组会成本。此外，本公开将收集的意见储存到共享知识库，便于经验的总结和扩散。

图2为本发明一实施例的第一次测试用例质量评分流程图200。在步骤202中，开始测试用例评审。在步骤204中，开发方与需求方针对初始测试用例所提出的评审意见或者补充点进行意见收集以及线上反馈。在步骤206中，所收集的用例评审意见以及线上反馈可被储存在共享知识库中，而在步骤208中，所收集的用例评审意见以及线上反馈用于进行补充点统计分析以及测试用例质量评分。

图3显示本发明一实施例的用例补充点统计分析流程图300。在一实施例中，流程图300可对应图1的步骤106，根据修正请求完成最终测试用例并对初始测试用例执行第一次质量评分。

在步骤301中，计算初始测试用例的个数。

在步骤302中，将初始测试用例抄送需求方及开发方。在一实施例中，初始测试用例经上传后自动地抄送给需求方及开发方，以让需求方及开发方审阅初始测试用例并根据初始测试用例提供相对应的修正请求。

在步骤303中，判定是否提供修正请求。在一实施例中，需求方及开发方未输入修正请求，则在步骤303判定无修正请求，流程300进行到步骤304，得到测试用例覆盖率为100％。

若需求方及开发方输入修正请求，则修正请求会被储存。在步骤303判定有修正请求，流程300进行到步骤305，逐个添加对应测试点，而测试点状态为待确认。在一实施例中，需求方及开发方输入修正请求，每一项修正请求即为一测试点。

在步骤306中，确认是否将修正请求加入初始测试用例。在一实施例中，测试人员与开发方及需求方沟通确认是否将修正请求添加入初始测试用例。若确认所有的修正请求皆不用加入，则流程300进行到步骤308，将测试点的状态改为无效，并在步骤304得到测试用例覆盖率为100％。若确认有至少一修正请求需加入初始测试用例，则流程300进行到步骤307，将至少一测试点的状态改为有效。

在步骤309中，根据修正请求对初始测试用例进行查核而得到最终测试用例。在一实施例中，进行多数查核，例如根据一个有效的修正请求，查核初始测试用例后得到第一修改版本。又根据另一个有效的修正请求，查核第一修改版本后得到第二修改版本。再根据另一个有效的修正请求，查核第二修改版本后得到最终测试用例。

在步骤310中，根据最终测试用例计算初始测试用例的修正数。在一实施例中，初始测试用例的修正数即是有效测试点的个数。

在步骤311中，根据初始测试用例的个数以及修正数决定测试用例覆盖率。

在一实施例中，采用如下公式计算测试用例覆盖率：

其中个数及修正数均为大于或等于零的整数。当修正数为零，则测试用例覆盖率为100％。测试用例覆盖率越高，代表测试用例编写质量越好。

需说明的是，本实施方式可不限于上述特定的步骤顺序，用以计算测试用例覆盖率的两个变量可由不同顺序得到，亦可同时得到。例如，虽然在图3中绘示先计算初始测试用例个数(步骤301)，再计算修正数(步骤310)，但亦可先计算修正数(步骤310)，再计算初始测试用例个数(步骤301)。此外，步骤301亦可与步骤302到310平行地进行，进而更快速地计算测试用例覆盖率。

图2以及图3显示的实施例公开在测试用例撰写阶段进行质量评分，可改善编写质量。此外，将收集的意见储存到共享知识库，便于经验的总结和扩散。

图4为本发明一实施例的第二次测试用例质量评分流程图400。在步骤402中，开始测试用例线上验证。在步骤404中，需求方针对线上验证进行意见收集以及线上反馈。在步骤406中，需求方针对线上验证结果所提出的反馈信息可被储存在共享知识库中。在步骤408中，针对线上验证结果所提出的反馈信息进行漏测问题与测试环境发现问题统计分析并且用于测试执行质量评分。

图5为本发明一实施例的漏测问题与测试环境发现问题统计分析流程图500，流程图500可对应图1的步骤108及110，执行线上验证并接收反馈信息及根据反馈信息对最终测试用例执行第二次质量评分。

在步骤501中，发起用户验证测试及线上验证测试。例如，测试人员在线上验证测试前进行软件测试并且将已进行软件测试的软件应用于使用者查核测试(UserAcceptance Testing，UAT)及线上验证测试，以测试软件在UAT环境及线上环境中运行时是否会产生问题。在一实施例中，“已进行软件测试的软件”是指已经根据最终测试用例进行测试的软件。

在步骤502中，将软件运行结果抄送给需求方。在一实施例中，运行结果经上传后自动地抄送给需求方，以让需求方验证软件是否符合需求并根据运行结果提供相对应的反馈信息。当需求方提供反馈信息，则反馈信息会被接收。在一实施例中，反馈信息包括软件运行环境，表示软件在这些环境中的运行结果不如预期。

在步骤503中，判定是否接收反馈信息。在一实施例中，当软件在UAT环境及线上环境中运行的结果符合预期，需求方未输入反馈信息，则判定无接收反馈信息，流程500进行到步骤504，得到漏测率为100％。当软件在UAT环境及线上环境中运行结果与需求不符，需求方输入反馈信息，则判定有接收反馈信息，则流程500进行到步骤505。

在步骤505中，针对反馈信息逐个加入问题，这些问题状态为待确认。在一实施例中，问题被同步提供给开发方与测试人员。

在一实施例，需求方以办公室自动化(Office Automation，OA)形式发起反馈申请，在反馈申请中逐个填写问题，将问题标示为待确认，并同步提供给开发方与测试人员。

在步骤506中，测试人员与开发方、业务方沟通确认反馈信息是否为漏测问题。在一实施例中，漏测问题是指软件在软件测试系统中未测出的问题。在一实施例中，漏测问题是指将软件在UAT环境及线上环境中运行之前未测出的问题。

在一实施例中，若测试人员与开发方、业务方沟通确认所有提出问题并非漏测问题，则流程500进行到步骤507，将问题的状态改为无效，在步骤504得到漏测率为100％。若测试人员与开发方、业务方经沟通确认后，确认至少一问题是漏测问题，则流程500进行到步骤508，将至少一问题的状态改为有效。

在步骤509中，测试人员针对有效问题进行总结分析学习。

在步骤510中，计算漏测问题的个数。

在步骤511中，计算测试阶段发现问题数。在一实施例中，测试阶段发现问题数是指软件在最终测试用例中运行时出现的软件缺陷数。

在步骤512中，根据测试阶段发现问题数与漏测问题数决定漏测率。

在一实施例中，采用如下公式计算漏测率：

其中漏测问题数与测试阶段发现问题数均为大于或等于零的整数。当漏测问题数为零，则漏测率为100％。漏测率越高，代表测试用例编写质量越好。

需说明的是，本实施方式可不限于特定的步骤顺序，用以计算漏测率的两个变量可以不同顺序得到，亦可同时得到。在一实施例中，计算测试阶段发现问题数(步骤511)可在计算漏测问题数(步骤510)之前进行，或两者可平行地进行，进而更快速地计算漏测率。在一实施例中，针对有效问题进行总结分析学习(步骤509)可在任何阶段进行，例如测试人员可在得到有效问题之后的任何时候，经由共享知识库进行总结分析学习。通过弹性的学习时间及共享知识库中的丰富资源，可有效提升测试人员的测试用例编写质量。

图4以及图5显示的实施例公开在线上验证阶段进行测试用例质量评分，可改善编写质量并改善漏测问题。此外，将收集的意见储存到共享知识库，便于经验的总结和扩散。

图6显示本发明一实施例的软件测试用例信息管理系统10示意图。在一实施例中，软件测试用例信息管理系统10包括第一信息收集模块11、共享知识库12、第一评分模块13、软件测试系统14、第二信息收集模块15、第二评分模块16、及综合质量评分模块17。

在一实施例中，软件测试用例信息管理系统10可与现有的OA系统结合。在一实施例中，第一信息收集模块11嵌入现有的OA系统中，测试人员、开发方、及需求方可从现有的OA系统进入第一信息收集模块11，并透过第一信息收集模块11输入相关信息。在一实施例中，第二信息收集模块15可嵌入现有的OA系统中，需求方可通过现有的OA系统进入第二信息收集模块15输入反馈信息。

第一信息收集模块11用于收集测试用例信息。测试用例信息包括初始测试用例、及修正请求。第一信息收集模块11收集的信息会储存到共享知识库12中，并且用于在第一评分模块13中进行第一次质量评分。在一实施例中，第一信息收集模块11用于格式化地收集测试用例信息。

在一实施例中，第一信息收集模块11可包括用户界面与输入设备，其中用户界面提供多个可输入的栏位，而各个栏位指向共享知识库12中的不同的储存点，这些储存点可以是计算机或服务器中的储存媒介。使用者可利用输入设备在各个栏位输入测试用例信息，而不同栏位的测试用例信息最终会被分别储存到共享知识库12中的不同储存点。在一实施例中，共享知识库12按照系统产品分类，而所收集的信息按照系统产品分类进行归置。

在一实施例中，测试人员可通过第一信息收集模块11上传数个测试用例，每个测试用例的分类方式可包括测试用例编号、软件执行步骤、软件应用场景、预期结果等。测试人员可将测试用例编号、软件执行步骤、软件应用场景、预期结果等分别输入各个栏位，使测试用例编号、软件执行步骤、软件应用场景、预期结果等分别存入共享知识库12中的不同的储存点。

继续参照图1，共享知识库12用于接收并储存测试用例信息，例如储存初始测试用例、修正请求、最终测试用例及反馈信息。共享知识库12具有特定的分类方式，使储存后的测试用例信息可分别地归置在不同储存点。此外，共享知识库12具有备注功能，测试人员可针对测试用例信息进行描述分析，便于总结学习。

第一评分模块13用于进行第一次质量评分。在一实施例中，第一次质量评分包括测试用例覆盖率分析。

软件测试系统14用于使用最终测试用例对软件进行测试，以期在软件上线(即进入线上验证阶段)前，先解决已发现的软件缺陷。在一实施例中，测试人员根据开发方与需求方的修正请求，查核测试用例，并通过第一信息收集模块11上传最终测试用例至软件测试系统14。

在软件测试完成后，测试人员或开发方可先解决在最终测试用例中出现的软件缺陷，而后发起用户验证测试及线上验证测试，将软件应用于UAT环境及线上环境中。

在一实施例中，软件经过测试后，可进入线上验证阶段(例如图6中的线上验证)。软件通过线上验证后的结果会传送给需求方，让需求方判定软件是否符合需求，若需求方欲提出反馈信息，可透过第二信息收集模块15上传反馈信息。

第二信息收集模块15用于接收反馈信息。第二信息收集模块15收集的信息会储存到共享知识库12中，并且用于在第二评分模块16中进行第二次质量评分。

在一实施例中，第二信息收集模块15具有与第一信息收集模块11相似的格式化收集功能，均便于意见的收集，两者差别在于第一信息收集模块11收集测试人员上传的测试用例以及软件测试前的修正请求；而第二信息收集模块15收集软件进入线上验证后的反馈意见。

继续参照图1，第二评分模块16用于执行第二次质量评分。在一实施例中，第二次质量评分包括漏测率分析。

继续参照图1，综合质量评分模块17用于根据测试用例覆盖率分析与漏测率分析计算测试质量评分指标，在综合质量评分模块17计算得到的测试质量评分指标将会储存在共享知识库12中。在一实施例中，测试用例覆盖率分析与漏测率分析结果以数字量化呈现，而测试质量评分指标为将测试用例覆盖率分析与漏测率分析结果各乘一加权指数后相加所得的结果。

使用如图6所示的软件测试用例信息管理系统10，可实现软件测试用例质量评分方法。在一实施例中，第一评分模块13计算初始测试用例的个数，如图3的步骤301所示。在一实施例中，第一评分模块13可进行初始测试用例的个数自动求和运算。在一实施例中，共享知识库12可针对存入的初始测试用例进行个数自动求和运算，而第一评分模块13可从共享知识库12自动提取运算结果。

在一实施例中，第一信息收集模块11将初始测试用例抄送需求方及开发方，如图3的步骤302所示。在一实施例中，初始测试用例经上传后，第一信息收集模块11自动地抄送给需求方及开发方，以让需求方及开发方审阅初始测试用例，并根据初始测试用例提供相对应的修正请求。需求方及开发方可透过第一信息收集模块11输入修正请求，修正请求透过第一信息收集模块11输入后，会储存到共享知识库12中。

在一实施例中，第一信息收集模块11判定是否提供修正请求，如图3的步骤303所示。

在一实施例中，第一评分模块13因应于输入的每一项修正请求而添加对应的测试点，测试点的状态显示为待确认，如图3的步骤305所示。例如，第一评分模块13在共享知识库12中添加对应的测试点，并以符号、颜色、或其他方式标记为待确认。

在一实施例中，第一评分模块13确认是否加入测试点，如图3的步骤306所示。在一实施例中，第一评分模块13将待确认的测试点传送给测试人员以确认是否应将修正请求加入初始测试用例。

在一实施例中，若确认所有的修正请求皆不用加入，则第一评分模块13将测试点的状态改为无效(步骤308)，并得到测试用例覆盖率为100％(步骤304)。在一实施例中，若确认有至少一修正请求需加入初始测试用例，则第一评分模块13将至少一测试点的状态改为有效，如图3的步骤307所示。

在一实施例中，第一评分模块13得到最终测试用例，如图3的步骤309所示。在一实施例中，第一评分模块13根据各个有效的测试点，查核初始测试用例而得到最终测试用例。最终测试用例被储存至共享知识库12，此时共享知识库12中存在两个版本的测试用例：初始测试用例(修改前)与最终测试用例(修改后)。在一实施例中，初始测试用例与完成修正测试用例被储存到共享知识库12中的特定储存点，使得第一评分模块13可自动获取修改前后两个版本的测试用例。在一实施例中，共享知识库12针对储存的信息还具有备注功能，测试人员可根据各个测试点进行描述与分析，便于总结学习。

在一实施例中，第一评分模块13计算经测试用例的修正数，如图3的步骤310所示。在一实施例中，第一评分模块13自动将初始测试用例(修改前)与最终测试用例(修改后)进行差异对比。

在一实施例中，第二评分模块16将软件在UAT环境及线上环境中的运行结果自动地抄送给需求方，以验证软件是否符合需求，如图5的步骤502所示。

在一实施例中，第二评分模块16判定是否接收反馈信息，如图5的步骤503所示。在一实施例中，第二评分模块16判定无接收反馈信息，则第二评分模块16得到漏测率为100％，如图5的步骤504所示。

在一实施例中，第二评分模块16针对反馈信息逐个加入问题，这些问题状态为待确认，如图5的步骤505所示。在一实施例中，若所有提出问题为无效，则第二评分模块16将问题的状态改为无效(步骤507)，并得到漏测率为100％(步骤504)。若确认至少一问题是漏测问题，则第二评分模块16将至少一问题的状态改为有效，如图5的步骤508所示。

在一实施例中，共享知识库12针对储存的信息有备注功能，测试人员可根据各个有效问题进行描述分析，便于测试人员针对有效问题进行总结学习，如图5的步骤509所示。

在一实施例中，第二评分模块16计算漏测问题数，如图5的步骤510所示。在一实施例中，第二评分模块16可进行有效的问题个数自动求和运算。在一实施例中，共享知识库12可针对有效问题进行个数自动求和运算，而第二评分模块16可从共享知识库12自动提取运算结果。

在一实施例中，第二评分模块16计算测试阶段发现问题数，如图5的步骤511所示。在一实施例中，软件测试系统14根据最终测试用例进行软件测试。软件测试系统14可得到软件在最终测试用例中的运行结果并计算发现问题的个数，而第二评分模块16可从软件测试系统14自动提取运算结果。在一实施例中，共享知识库12可针对该运行结果进行问题个数自动求和运算，而第二评分模块16可从共享知识库12自动提取运算结果。

在一实施例中，第二评分模块16根据测试阶段发现问题数与漏测问题数决定漏测率，如图5的步骤512所示。

在一实施例中，如上所述的软件测试用例质量评分方法和程序可以代码和/或数据加以实施，其可存储在非暂时性计算机可读取存储媒介中。当计算机(或处理器)读取并执行存储的代码和/或数据时，计算机执行具体化为数据结构和代码且存储在媒介中的方法和程序，进而实现软件测试用例质量评分方法和程序。

此外，所描述的方法和程序可以包含在硬件模块中。例如，所述硬件模块，可包括但不限于，特定应用集成电路(ASIC)芯片、可程序逻辑门阵列(FPGA)、以及其它现在已知的或以后开发的可程序化逻辑设备。当所述硬件模块被启动时，所述硬件模块执行内含于所述硬件模块中的方法和程序。

在一实施例中，电子设备包括一个或多个处理器及存储装置。存储装置存储一个或多个软件测试用例质量评分程序，当一个或多个软件测试用例质量评分程序被一个或多个处理器执行时，一个或多个处理器实现软件测试用例质量评分方法。

本发明的技术内容及技术特点已揭示如上，然而熟悉本领域的技术人员仍可能基于本发明的教示及揭示而作种种不背离本发明精神的替换及修饰。因此，本发明的保护范围应不限于实施例所揭示的内容，而应包括各种不背离本发明的替换及修饰，并为本专利申请权利要求书所涵盖。

Claims (10)

1.一种软件测试用例质量评分方法，其特征在于，包括：

完成初始测试用例；

收集对所述初始测试用例的修正请求；

根据所述修正请求完成最终测试用例并对所述初始测试用例执行第一次质量评分；

执行线上验证并接收反馈信息；

根据所述反馈信息对所述最终测试用例执行第二次质量评分；并

储存所述初始测试用例、所述修正请求、所述最终测试用例及所述反馈信息。

2.根据权利要求1所述的软件测试用例质量评分方法，其特征在于，所述根据所述修正请求完成最终测试用例并对所述初始测试用例执行第一次质量评分包括：

根据所述修正请求对所述初始测试用例进行查核并对所述初始测试用例进行修改、删除、或新增而得到所述最终测试用例。

3.根据权利要求2所述的软件测试用例质量评分方法，其特征在于，所述根据所述修正请求完成最终测试用例并对所述初始测试用例执行第一次质量评分包括：

计算所述初始测试用例的个数；

计算所述初始测试用例的修正数；并

根据所述个数以及所述修正数决定测试用例覆盖率。

4.根据权利要求3所述的软件测试用例质量评分方法，其特征在于，根据所述个数以及所述修正数决定测试用例覆盖率包括：

其中所述初始测试用例个数及所述修正数均为大于或等于零的整数。

5.根据权利要求1所述的软件测试用例质量评分方法，其特征在于，还包括：

在所述执行线上验证并接收反馈信息的步骤前，根据所述最终测试用例对软件进行软件测试。

6.根据权利要求1所述的软件测试用例质量评分方法，其特征在于，根据所述反馈信息对所述最终测试用例执行第二次质量评分包括：

根据所述反馈信息计算漏测问题数；

根据所述最终测试用例计算测试阶段发现问题数；并

根据所述测试阶段发现问题数与所述漏测问题数决定漏测率。

7.根据权利要求6所述的软件测试用例质量评分方法，其特征在于，根据所述测试阶段发现问题数与所述漏测问题数决定漏测率包括：

其中所述漏测问题数与所述测试阶段发现问题数均为大于或等于零的整数。

8.一种软件测试用例信息管理系统，其特征在于，包括：

第一信息收集模块，用于收集初始测试用例及对初始测试用例的修正请求；

第一评分模块，用于对所述初始测试用例执行第一次质量评分；

第二信息收集模块，用于接收执行线上验证后的反馈信息；

第二评分模块，用于根据所述反馈信息对所述最终测试用例执行第二次质量评分；及

共享知识库，用于储存所述初始测试用例、所述修正请求、所述最终测试用例及所述反馈信息。

9.一种计算机可读介质，其上存储有计算机程序，其特征在于，所述计算机程序被处理器执行时实现根据权利要求1至7中任一项所述的软件测试用例质量评分方法。

10.一种电子设备，其特征在于，包括：

一个或多个处理器；及

存储装置，用于存储一个或多个程序，当所述一个或多个程序被所述一个或多个处理器执行时，使得所述一个或多个处理器实现根据权利要求1至7中任一项所述的软件测试用例质量评分方法。