CN105320701B - 功能点测试实现方式的筛选方法、装置及终端 - Google Patents

Abstract

本发明公开了一种功能点测试实现方式的筛选方法、装置及终端，属于软件测试领域。本发明通过根据待测功能点的软件对象类型和规模特征确定测试实现框架，并获取通过测试设计框架编写的测试方法对应的测试用例，从而根据测试实现框架的完成情况生成测试实现质量报告，通过过滤不满足预设测试实现条件的测试方法实现对待测功能点的测试实现方式进行筛选，使得可针对不满足预设测试实现条件的测试方法进行评审，不仅节省人力成本和时间成本，而且能提高功能点测试实现方式的筛选效率。由于可根据软件对象类型和规模特征及预设测试模型经验库实现功能点的测试实现方式的筛选，不仅适用范围更广，且能减少人为筛选的随意性和不确定性，从而更具可靠性。

Description

功能点测试实现方式的筛选方法、装置及终端

技术领域

本发明涉及计算机技术领域，特别涉及一种功能点测试实现方式的筛选方法、装置及终端。

背景技术

功能点测试是指对软件的单个功能点进行代表用户行为的测试，功能点测试的实现方式是测试人员运用测试方法和个人发散思维实现用于发现和验证软件质量风险的活动。通常，功能点测试实现方式的好坏直接影响着功能点测试的成败，甚至影响着软件测试的成败，因此，良好的功能点测试的实现方法至关重要。为了获得良好的功能点测试实现方式，需要对功能点测试实现方式进行筛选。

相关技术中在筛选功能点测试的实现方式时，通常采用如下三种方式：

第一种方式：首先，由软件测试人员运用常见的功能点测试方法如边界值、等价类、因果图、判定表，以及测试人员个人的自由发散思维进行测试用例设计，得到测试功能点的测试用例集；然后，由有经验的测试人员人工逐条对设计好的测试用例集进行评审，以筛选出良好的功能点测试实现方式，从而提升测试用例集的质量，减少用户分支场景和异常场景的测试设计遗漏。

第二种方式：采用MBT(Model Based Testing，基于模型的测试)方法或工具实现功能点测试。具体为：详细了解功能点的实现原理和结构；由测试人员对功能点进行抽象建模，获得功能点对应的所有状态；根据功能点对应的所有状态测试设计用例，并由有经验的测试人员人工逐条对设计好的测试用例集进行评审，以筛选出良好的功能点测试实现方式，从而提升测试用例集的质量，减少用户分支场景和异常场景的测试设计遗漏。

第三种方式：基于功能实现代码分析，自动生成代码覆盖测试用例。具体为：分析功能点新增代码和修改代码的差异；根据代码差异，生成对每行代码的覆盖测试用例模板，并由有经验的测试人员人工逐条对设计好的测试用例集进行评审，以筛选出良好的功能点测试实现方式，从而提升测试用例集的质量，减少用户分支场景和异常场景的测试设计遗漏。

在实现本发明的过程中，发明人发现相关技术至少存在以下问题：

采用上述第一种方式实现功能点测试实现方式的筛选时，主要依赖于测试人员的个人经验思考，导致功能点测试实现方式的质量的随意性和不确定性很高，容易由于思考不充分导致测试实现遗漏，影响测试质量。另外，在设计好测试用例集后，有经验的测试人员需要逐个评审测试用例，以筛选功能的测试实现方式，导致耗费很多人力和时间，不仅测试成本较高，而且影响测试整体工作的效率。

采用上述第二种方式实现功能点测试实现方式的筛选时，对每个功能点需要测试人员较多的学习成本，对测试人员个人的建模能力要求很高。另外，MBT的适用场景更多是稳定的协议类软件，对于功能频繁变更的用户交互类软件每次变更都要重新人工进行一次建模，因此，适用范围有限。

采用上述第三种方式实现功能点测试实现方式的筛选时，可以对已实现的代码进行语句覆盖，但对于代码应该实现却没有实现的用户场景可能会发生的组合分支或异常情况，则无能为力。因此，采用方案三存在覆盖不了部分用户场景分支和异常的风险，可靠性不高。

发明内容

为了解决相关技术的问题，本发明实施例提供了一种功能点测试实现方式的筛选方法、装置及终端。所述技术方案如下：

第一方面，提供了一种功能点测试实现方式的筛选方法，所述方法包括：

获取人工标注的待测功能点的软件对象类型及规模特征；

根据所述软件对象类型及所述规模特征查询预设的测试模型经验库，得到所述待测功能点的测试实现框架，所述测试实现框架至少包括与所述软件对象类型关联的至少一个测试方法及每个测试方法对应所述规模特征的最少测试用例数；

获取通过所述测试实现框架编写的每个测试方法对应的测试用例，并根据所述测试实现框架的完成情况生成所述待测功能点的测试实现质量报告；

根据所述测试实现质量报告过滤所述测试实现框架中不满足所述待测功能点的预设测试实现条件的测试方法。

第二方面，提供了一种功能点测试实现方式的筛选装置，所述装置包括：

第一获取模块，用于获取人工标注的待测功能点的软件对象类型及规模特征；

查询模块，用于根据所述软件对象类型及所述规模特征查询预设的测试模型经验库，得到所述待测功能点的测试实现框架，所述测试实现框架至少包括与所述软件对象类型关联的至少一个测试方法及每个测试方法对应所述规模特征的最少测试用例数；

第二获取模块，用于获取通过所述测试实现框架编写的每个测试方法对应的测试用例；

生成模块，用于根据所述测试实现框架的完成情况生成所述待测功能点的测试实现质量报告；

过滤模块，用于根据所述测试实现质量报告过滤所述测试实现框架中不满足所述待测功能点的预设测试实现条件的测试方法。

第三方面，提供了一种终端，所述终端包括：

获取人工标注的待测功能点的软件对象类型及规模特征；

根据所述软件对象类型及所述规模特征查询预设的测试模型经验库，得到所述待测功能点的测试实现框架，所述测试实现框架至少包括与所述软件对象类型关联的至少一个测试方法及每个测试方法对应所述规模特征的最少测试用例数；

获取通过所述测试实现框架编写的每个测试方法对应的测试用例，并根据所述测试实现框架的完成情况生成所述待测功能点的测试实现质量报告；

根据所述测试实现质量报告过滤所述测试实现框架中不满足所述待测功能点的预设测试实现条件的测试方法。

本发明实施例提供的技术方案带来的有益效果是：

通过根据待测功能点的软件对象类型和规模特征查询预设的测试模型经验库，得到待测功能点的测试实现框架，并获取通过测试设计框架编写的每个测试方法对应的测试用例，从而根据测试实现框架的完成情况生成测试实现质量报告，并通过过滤测试实现框架中不满足待测功能点的预设测试实现条件的测试方法实现对待测功能点的测试实现方式进行筛选，使软件测试人员可以针对不满足预设测试实现条件的测试方法进行评审，不仅能节省人力成本和时间成本，而且能够提高功能点测试实现方式的筛选效率。由于可根据软件对象类型和规模特征及预设的测试模型经验库实现待测功能点的测试实现方式的筛选，因此，不仅适用范围更广，而且能减少人为筛选的随意性和不确定性，从而更具可靠性。

附图说明

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

图1是本发明一实施例提供的一种功能点测试实现方式的筛选方法的流程图；

图2是本发明一实施例提供的一种功能点测试实现方式的筛选方法的流程图；

图3是本发明另一实施例提供的一种功能点测试实现方式的筛选装置的结构示意图；

图4是本发明另一实施例提供的一种功能点测试实现方式的筛选装置的结构示意图；

图5是本发明另一实施例提供的一种功能点测试实现方式的筛选装置的结构示意图；

图6是本发明另一实施例提供的一种功能点测试实现方式的筛选装置的结构示意图；

图7是本发明另一实施例提供的一种终端的结构示意图。

具体实施方式

为使本发明的目的、技术方案和优点更加清楚，下面将结合附图对本发明实施方式作进一步地详细描述。

图1是根据一示例性实施例提供的一种功能点测试实现方式的筛选方法的流程图。参见图1，本发明实施例提供的方法流程包括：

101：获取人工标注的待测功能点的软件对象类型及规模特征。

102：根据软件对象类型及规模特征查询预设的测试模型经验库，得到待测功能点的测试实现框架，其中，测试实现框架至少包括与软件对象类型关联的至少一个测试方法及每个测试方法对应规模特征的最少测试用例数。

可选地，根据软件对象类型及规模特征查询预设的测试模型经验库，包括：

查询测试模型经验库中与软件对象类型关联的所有测试方法；

基于规模特征确定每个测试方法对应的测试用例数，将每个测试方法对应的测试用例数作为每个测试方法对应规模特征的最少测试用例数，得到至少包括至少一个测试方法及每个测试方法对应规模特征的最少测试用例数的测试实现框架。

可选地，根据软件对象类型及规模特征查询预设的测试模型经验库之前，还包括：

建立至少包括软件对象类型、测试方法及每个测试方法对应不同规模特征的最少测试用例数的映射关系，得到测试模型经验库。

可选地，得到测试模型经验库之后，还包括：

确定测试模型经验库包括的软件对象类型是否有缺失；

如果确定测试模型经验库包括的软件对象类型有缺失，则添加缺失的软件对象类型至测试模型经验库；

确定与缺失的软件对象类型关联的所有测试方法及每个测试方法对应不同规模特征的最少测试用例数，并将与缺失的软件对象类型关联的所有测试方法及每个测试方法对应不同规模特征的最少测试用例数添加至测试模型经验库。

可选地，得到测试模型经验库之后，还包括：

确定测试模型经验库包括的与每个软件对象类型关联的测试方法是否有缺失；

如果测试模型经验库包括的与任一软件对象类型关联的测试方法有缺失，则添加任一软件对象缺失的测试方法至与任一软件对象类型关联的测试方法中；

确定为任一软件对象类型缺失的测试方法对应不同规模特征的最少测试用例数；

将任一软件对象类型缺失的测试方法对应不同规模特征的最少测试用例数添加至测试模型经验库。

103：获取通过测试实现框架编写的每个测试方法对应的测试用例，并根据测试实现框架的完成情况生成待测功能点的测试实现质量报告。

可选地，根据测试实现框架的完成情况生成待测功能点的测试实现质量报告，包括：

统计通过测试实现框架编写的每个测试方法对应的实际用例数，并统计对待测功能点进行测试实现时使用的实际测试方法数；

根据实际用例数、实际测试方法数及测试实现框架包括的测试方法数及每个测试方法对应规模特征的最少测试用例数确定待测功能点的测试实现充分度指标和测试实现多样性指标；

根据测试实现充分度指标和测试实现多样性指标生成待测功能点的测试实现质量报告。

104：根据测试实现质量报告过滤测试实现框架中不满足待测功能点的预设测试实现条件的测试方法。

本发明实施例提供的方法，通过根据待测功能点的软件对象类型和规模特征查询预设的测试模型经验库，得到待测功能点的测试实现框架，并获取通过测试设计框架编写的每个测试方法对应的测试用例，从而根据测试实现框架的完成情况生成测试实现质量报告，并通过过滤测试实现框架中不满足待测功能点的预设测试实现条件的测试方法实现对待测功能点的测试实现方式进行筛选，使软件测试人员可以针对不满足预设测试实现条件的测试方法进行评审，不仅能节省人力成本和时间成本，而且能够提高功能点测试实现方式的筛选效率。由于可根据软件对象类型和规模特征及预设的测试模型经验库实现待测功能点的测试实现方式的筛选，因此，不仅适用范围更广，而且能减少人为筛选的随意性和不确定性，从而更具可靠性。

图2是根据一示例性实施例提供的一种功能点测试实现方式的筛选方法的流程图。参见图2，本发明实施例提供的方法流程包括：

201：建立至少包括软件对象类型、测试方法及每个测试方法对应不同规模特征的最少测试用例数的映射关系，得到测试模型经验库。

由于针对于某一软件对象类型的功能点，总有一些测试方法比较有效，从而适合测试发现此类软件对象类型的潜在质量问题。又由于针对任何一款软件产品，其软件对象类型数量是一个有限值，且相似功能的软件产品又具备相似的软件对象类型集。因此，本发明实施例提供的方法对领域内的软件对象类型进行归类，从而统计出与软件对象类型关联的常用测试方法，使得后续在进行待测功能点的测试实现时，可以通过待测功能点的软件对象类型确定与其关联的测试方法。

另外，在确定相同软件对象类型的测试方法后，由于相同软件对象类型的不同功能点还存在不同的规模大小的情况。例如，在有的项目中是500行代码实现，有的项目中则是200行代码实现，有的项目中则是2000行代码实现。因此，为了保证功能点测试实现过程质量的稳定性，还需要确定每个测试方法对应不同规模特征的最少测试用例数，使得后续在进行功能点测试实现时，可以为与待测功能点的软件对象类型关联的每个测试方法确定与待测功能点的规模特征对应的最少用例数。

进一步地，为了便于后续基于待测功能点的软件对象类型及规模特征实现筛选功能点的测试实现方式时，能够根据预先建立的测试模型经验库实现，从而避免每次测试人员在对待测功能点进行测试实现设计时需要重复地从众多测试经验中搜寻和过滤出适合的测试方法来对某个功能点进行测试实现方式设计，从而造成重复使用很多人力、很多时间，且搜寻与过滤效果不确定及随意性很大的问题，本发明实施例通过预先建立至少包括软件对象类型、测试方法及每个测试方法对应不同规模特征的最少测试用例数的映射关系的测试模型经验库来对待测功能点的测试实现方式进行设计，从而确保后续可以筛选出良好的待测功能点的测试实现方式，并对筛选出的不好的测试实现方式进行局部优化，最终达到提高功能点测试实现方式的质量和效率的目的。

综上，为了便于后续可以根据待测功能点的软件对象类型和规模特征确定待测功能点的测试实现方式，需要建立至少包括软件对象类型、测试方法及每个测试方法对应不同规模特征的最少测试用例数的映射关系，以得到测试模型经验库。

关于建立至少包括软件对象类型、测试方法及每个测试方法对应不同规模特征的最少测试用例数的映射关系的方式，本发明实施例不作具体限定。具体实施时，可以由测试人员统计的常见软件对象类型、不同软件对象类型常用的软件测试方法及每个测试方法对应不同规模特征时的最少用例数，从而通过获取测试人员统计的常见软件对象类型、不同软件对象类型常用的软件测试方法及每个测试方法对应不同规模特征时的最少用例数实现。其中，规模特征包括但不限于有大规模、中规模和小规模，等等。

如表一所示，其示出了一种建立的至少包括软件对象类型、与软件对象类型关联的所有测试方法及每个测试方法对应不同规模特征的最少测试用例数的映射关系的测试模型经验库的表格示意图。

表一

在表一中，仅以软件对象类型为“XYZ”，与“XYZ”关联的所有测试方法有“测试方法A”和“测试方法B”，且每个测试方法对应大中小规模时的最少测试用例数进行了举例说明。需要说明的是，表一中仅以将规模特征划分为“大规模”、“中规模”及“小规模”为例进行了举例说明。具体实施时，还可以将规模特征划分为更多不同的规模，本发明实施例对此不作具体限定。当然，表一所示出的内容仅用于对测试模型经验库的内容进行举例说明，并不构成对本发明实施例的限制。

另外，建立的测试模型数据库还可以包括其它内容，如每个测试方法的方法要点，每个测试方法的前提条件、每个测试方法的期待结果，等等，本发明实施例不作具体限定。

需要说明的是，该步骤为建立测试模型经验库的步骤，是进行功能点测试实现方式的筛选方法之前执行的步骤，因此，并不是每次执行功能点测试实现方式的筛选方法时均需执行该步骤，保证在执行功能点测试实现方式的筛选方法时已经建立好测试模型经验库即可。

202：获取人工标注的待测功能点的软件对象类型及规模特征。

由于测试模型经验库中包括软件对象类型、与每个软件软件对象类型关联的所有测试方法以及每个测试方法对应不同规模特征的最少测试用例数，为了以测试模型经验库为参考实现功能点测试实现方式的筛选，需要获取待测功能点的软件对象类型及规模特征。通常，待测功能点的软件对象类型和规模特征由测试人员标注，因此，需要获取人工标注的待测功能点的软件对象类型及规模特征。关于获取人工标注的待测功能点的软件对象类型及规模特征的方式，本发明实施例不作具体限定。

203：根据软件对象类型及规模特征查询预设的测试模型经验库，得到待测功能点的测试实现框架，其中，测试实现框架至少包括与软件对象类型关联的至少一个测试方法及每个测试方法对应规模特征的最少测试用例数。

为了确定对待测功能点进行测试实现时使用哪些测试方法、针对每个测试方法应该设计多少个测试用例，需要确定待测功能点的至少包括与其软件对象类型关联的至少一个测试方法及每个测试方法对应不同规模特征的最少测试用例数的测试实现框架。由于本发明实施例提供的方法支持根据预设的测试模型经验库确定测试待测功能点需要使用哪些测试方法、以及针对每个测试方法应该设计多少测试用例，因此，需要根据待测软件的软件对象类型及规模特征查询预设的测试模型经验库，得到待测功能点的至少包括与软件对象类型关联的至少一个测试方法及每个测试方法对应不同规模特征的最少测试用例数的测试实现框架。

其中，根据软件对象类型及规模特征查询预设的测试模型经验库的方式，包括但不限于：

查询测试模型经验库中与待测功能点的软件对象类型关联的所有测试方法，并基于待测功能点的规模特征确定每个测试方法对应的测试用例数，将每个测试方法对应的测试用例数作为每个测试方法对应规模特征的最少测试用例数，得到至少包括至少一个测试方法及每个测试方法对应不同规模特征的最少测试用例数的测试实现框架。

关于查询测试模型经验库中与待测功能点的软件对象类型关联的所有测试方法的方式，本发明实施例不作具体限定。具体实施时，可以通过将待测功能点的软件对象类型与测试模型经验库中的每个软件对象类型进行一一比对，并将测试模型经验库中与待测功能点的软件对象类型一致的软件对象类型对应的所有测试方法确定为与待测功能点的软件对象类型关联的所有测试方法。

例如，如表二所示，其示出了一种测试模型经验库中包括的软件对象类型与每个软件对象类型对应的测试方法的表格示意图。其中，为了使划分的软件对象类型比较准确，可以将测试模型经验库中的软件对象类型划分为“软件对象类型一级分类”和“软件对象类型二级分类”。

表二

以表二所示的内容为例，表二所示的测试模型经验库即为包括“软件对象类型一级分类”和“软件对象类型二级分类”的测试模型经验库。如果步骤202中获取到的待测功能点的软件对象类型为“用户交互-输入输出”，则在查询测试模型经验库中与待测功能点的软件对象类型关联的所有测试方法时，通过将“用户交互-输入输出”与表二所示的测试模型经验库中由“软件对象类型一级分类”和“软件对象类型二级分类”共同组成的每个软件对象类型一一比对，得到与“用户交互-输入输出”关联的所有测试方法包括表二中第二行至第四行所示的测试方法，即“常规测试法”、“七类数值测试法”和“危险字符测试法”。因此，将表二中第二行至第四行所示的“常规测试法”、“七类数值测试法”和“危险字符测试法”作为与待测功能点的软件对象类型“用户交互-输入输出”关联的所有测试方法。

关于基于待测功能点的规模特征确定每个测试方法对应的测试用例数的方式，本发明实施例同样不作具体限定。具体实施时，可以基于步骤202中人工标注的待测功能点的规模特征在测试经验数据库中查询与待测功能点的软件对象类型关联的每个测试方法在该规模特征下的测试用例数，并将该测试用例数作为基于待测功能点的规模特征确定的每个测试方法对应该规模特征的测试用例数。

例如，结合表一所示的内容，如果待测功能点的软件对象类型为“XYZ”，且与该软件对象类型关联的所有测试方法包括“测试方法A”和“测试方法B”，且人工标注的待测功能点的规模特征为“大规模”，则可以将表一中“测试方法A”对应“大规模”的测试用例数“B1”确定为“测试方法A”对应的测试用例数；将表一中“测试方法B”对应“大规模”的测试用例数“B2”确定为“测试方法B”对应的测试用例数。

当确定与待测功能点的软件对象类型关联的所有测试方法、每个测试方法对应待测功能点的规模特征的最少测试用例数后，便可以得到待测功能点的测试实现框架。如表三所示，其示出了某一待测功能点的测试实现框架的结构示意图。

表三

其中，在表三中，待测功能点为“发牌优化算法”，且通过查询测试模型经验库确定的与“发牌优化算法”的软件类型相关的所有测试方法包括“常规测试法”、“测一送一法”、“极限测试法”和“边界值测试法”。另外，通过查询测试模型经验库确定的每个测试方法对应“发牌优化算法”的规模特征的测试用例数均为两个。

204：获取通过测试实现框架编写的每个测试方法对应的测试用例，并根据测试实现框架的完成情况生成待测功能点的测试实现质量报告。

当确定待测功能点的测试实现框架后，测试人员便可以通过测试实现框架编写与待测功能点的软件对象类型关联的所有测试方法对应的测试用例，且当测试人员通过测试实现框架编写完与待测功能点的软件对象类型关联的所有测试方法对应的测试用例后，便可以获取通过测试实现框架编写的每个测试方法对应的测试用例。进一步地，为了确定对待测功能点的测试用例编写的是否准确或者是否可以用于后续测试待测功能点的测试用例，还可以根据测试实现框架的完成情况生成待测功能点的测试实现质量报告。

关于获取通过测试实现框架编写的每个测试方法对应的测试用例的方式，本发明实施例不作具体限定。具体实施时，可以提供提交按钮或提交选项。当测试人员在测试实现框架中编写完测试用例后，可以通过选中该提交按钮或提交选项来提交编写好的测试用例。因此，可以通过检测该提交按钮或提交选项是否选中来获取通过测试实现框架编写的每个测试方法对应的测试用例。如果检测到该提交按钮或提交选项被选中，则确定获取到通过测试实现框架编写的每个测试方法对应的测试用例；如果未检测到该提交按钮或提交选项被选中，则确定未获取到通过测试实现框架编写的每个测试方法对应的测试用例。

其中，根据测试实现框架的完成情况生成待测功能点的测试实现质量报告时，包括但不限于通过如下步骤来实现：

第一步：统计通过测试实现框架编写的每个测试方法对应的实际用例数，并统计对待测功能点进行测试实现时使用的实际测试方法数。

由于在通过测试实现框架编写测试用例时，可能出现对于某一种测试方法并没有设计出步骤203中确定的对应规模特征的最少测试用例数的情况，或者针对于某一种测试方法完全没有设计出测试用例的情况。因此，在根据测试实现框架的完成情况生成待测功能点的测试实现质量报告时，需要统计通过测试实现框架编写的每个测试方法对应的实际用例数，并统计对待测功能点进行测试实现时使用的实际测试方法数。

关于统计通过测试实现框架编写的每个测试方法对应的实际用例数的方式，以及统计对待测功能点进行测试实现时使用的实际测试方法数的方式，本发明实施例均不作具体限定。具体实施时，可以结合测试实现框架的具体结构实现。

例如，如果测试实现框架如表三所示，则在通过测试实现框架编写测试用例时，应该保证每个测试方法对应的“用例名称”和“操作步骤”不能为空。如果某一测试方法对应的“用例名称”和“操作步骤”这两个项中的任一项为空，则确定未编写该测试方法对应的一个测试用例。因此，在统计通过测试实现框架编写的每个测试方法对应的实际用例数时，可以通过统计测试实现框架中每个测试方法对应的“用例名称”和“操作步骤”均不为空的测试用例数来实现。其中，在统计测试实现框架中每个测试方法对应的“用例名称”和“操作步骤”均不为空的测试用例数之前，需要检测测试实现框架中每个测试方法对应的“用例名称”和“操作步骤”是否为空。关于检测测试实现框架中每个测试方法对应的“用例名称”和“操作步骤”是否为空的方式，本发明实施例不作具体限定。

另外，在统计对待测功能点进行测试实现时使用的实际测试方法数时，也可以与统计通过测试实现框架编写的每个测试方法对应的实际用例数的原理一致。例如，仍以表三所示的测试实现框架为例，可以通过统计测试实现框架中每个测试方法对应的“用例名称”和“操作步骤”是否全为空或是否不全为空来实现。例如，如果表三中“边界值测试法”对应的四行中每行中的“用例名称”和“操作步骤”均为空，则确定未获取到使用“边界值测试法”编写的测试用例，则在统计使用的实际测试方法数不算该“边界值测试法”。另外，如果表三种所示的其它测试方法对应的四行中至少有一行中的“用例名称”和“操作步骤”不为空，则确定获取到使用通过其它三种测试方法编写的测试用例，则在统计使用的实际测试方法数时，将这三种方法计算在内。

第二步：根据实际用例数、实际测试方法数及测试实现框架包括的测试方法数及每个测试方法对应规模特征的最少测试用例数确定待测功能点的测试实现充分度指标和测试实现多样性指标。

关于根据实际用例数、实际测试方法数及测试实现框架包括的测试方法数及每个测试方法对应规模特征的最少测试用例数确定待测功能点的测试实现充分度指标和测试实现多样性指标的方式，本发明实施例不作具体限定。

其中，在确定测试实现充分度指标时，包括但不限于通过将每个测试方法的实际用例数与步骤203中确定的每个测试方法对应待测功能点的规模特征的最少用例数作除法运算实现。例如，如果统计得到某一测试方法的实际用例数为3，而通过步骤203确定的该测试方法对应待测功能点的规模特征的最少用例数为5，则该测试方法的测试实现充分度指标为60％。

同理，在确定测试实现多样性指标时，包括但不限于通过将为待测功能点设计的实际测试方法数与测试实现框架包括的测试方法数作除法运算实现。例如，如果统计得到测试实现框架中编写的待测功能点的实际测试方法数为8，而测试实现框架包括的测试方法数为10，则该测试方法的测试实现多样性指标为80％。

第三步：根据测试实现充分度指标和测试实现多样性指标生成待测功能点的测试实现质量报告。

关于根据测试实现充分度指标和测试实现多样性指标生成待测功能点的测试实现质量报告的方式，本发明实施例不作具体限定。

如表四所示，其示出了一种测试实现质量报告的形式表格。其中，表四所示的测试质量报告为根据表三所示的测试实现框架的编写情况确定的测试实现质量报告。

表四

其中，如表四所示，待测功能点为“发牌优化算法”，与“发牌优化算法”的软件对象类型关联的测试方法有“常规测试法”、“测一送一法”、“极限测试法”及“边界值测试法”。其中，“常规测试法”对应的实际用例数为2，由于通过表三确定的“常规测试法”对应的测试用例数应该为2，因此，“常规测试法”对应的测试充分度指标为100％。同理，“测一送一法”对应的测试充分度指标为50％；“极限测试法”对应的设计充分度指标为100％；“边界值测试法”对应的设计充分度指标为0％。另外，由于针对“边界值测试法”未编写测试用例，其它几种测试方法均编写了至少一个测试用例，且通过表三确定的测试方法数为3，因此，计算得到的测试实现多样性指标为75％。

205：根据测试实现质量报告过滤测试实现框架中不满足待测功能点的预设测试实现条件的测试方法。

由于测试实现质量报告中包括了与待测功能点的软件对象类型关联的所有测试方法的测试充分度指标以及待测功能点的测试实现多样性指标，因此，可以根据测试质量报告确定待测功能点的哪些测试方法不满足待测功能点的测试实现条件，从而根据测试实现质量报告过滤测试实现框架中不满足待测功能点的预设测试实现条件的测试方法。关于待测功能点的测试实现条件的具体内容，本发明实施例不作具体限定。例如，可以将测试充分度指标以及测试实现多样性指标不满足100％的均确定为不满足待测功能点的预设测试实现条件的测试方法。

关于根据测试实现质量报告过滤测试实现框架中不满足待测功能点的预设测试实现条件的测试方法的方式，本发明实施例不作具体限定。具体实施时，可以分别设置每个测试方法的测试实现充分度指标和待测功能点的测试实现多样性指标的第一预设阈值和第二预设阈值，当测试质量报告中某一测试方法的测试实现充分度指标低于第一预设阈值，则确定该测试方法为不满足待测功能点的预设测试实现条件的测试方法，从而可以将该测试方法过滤出来。针对于某一待测功能点来讲，如果测试质量报告确定其测试多样性指标低于第二预设阈值，则确定其为低实现质量的功能点。

进一步地，在根据测试实现质量报告过滤出测试实现框架中不满足待测功能点的预设测试实现条件的测试方法后，可以显示过滤出的不满足待测功能点的预设测试实现条件的测试方法，从而将过滤出的测试方法作为筛选出的不满足待测功能点的测试实现方式的测试方法，使得后续在对待测功能点的测试实现方式进行评审时，可以将评审重点放在不满足待测功能点的预设测试实现条件的测试方法上，从而减少评审工作量，进而提高评审效率甚至提高软件测试的效率。

可选地，随着功能点测试的不断积累，可能会根据测试人员的经验或者某些软件版本发布之后存在的问题总结出很多新的软件对象类型，因此，得到测试模型经验库之后，还可以：确定测试模型经验库包括的软件对象类型是否有缺失；如果确定测试模型经验库包括的软件对象类型有缺失，则添加缺失的软件对象类型至测试模型经验库。进一步地，由于针对于每一种软件对象类型，总会有与其关联的测试方法以及每种测试方法在进行测试实现时基于不同规模特征的测试用例数，因此，还可以确定与缺失的软件对象类型关联的所有测试方法及每个测试方法对应不同规模特征的最少测试用例数，并将与缺失的软件对象类型关联的所有测试方法及每个测试方法对应不同规模特征的最少测试用例数添加至测试模型经验库。

关于确定测试模型经验库包括的软件对象类型是否有缺失的方式，包括但不限于：设置漏测数据库，并将实时发现的软件对象类型、与每种软件对象类型关联的测试方法、及每个测试方法基于不同规模特征的测试用例数存储至该漏测数据。因此，包括但不限于通过确定漏测数据库中存储的软件对象类型是否有更新，且如果漏测数据库中存储有软件对象类型有更新，则确定测试模型经验库包括的软件对象类型有缺失。

关于添加缺失的软件对象类型至测试模型经验库的方式，以及确定与缺失的软件对象类型关联的所有测试方法及每个测试方法对应不同规模特征的最少测试用例数，并将与缺失的软件对象类型关联的所有测试方法及每个测试方法对应不同规模特征的最少测试用例数添加至测试模型经验库的方式，本发明实施例均不作具体限定。

具体地，在将缺失的软件对象类型、与软件对象类型关联的所有测试方法、以及每个测试方法基于不同规模特征的测试用例数添加至测试模型经验库时，也需要形成软件对象类型、与软件对象类型关联的所有测试方法、以及每个测试方法基于不同规模特征的测试用例数的映射关系。

可选地，由于针对于每个软件对象类型，与其关联的测试方法也可能是实时更新的，因此，在得到测试模型经验库之后，还可以确定测试模型经验库包括的与每个软件对象类型关联的测试方法是否有缺失；如果测试模型经验库包括的与任一软件对象类型关联的测试方法有缺失，则添加任一软件对象缺失的测试方法至与任一软件对象类型关联的测试方法中；确定为任一软件对象类型缺失的测试方法对应不同规模特征的最少测试用例数；将任一软件对象类型缺失的测试方法对应不同规模特征的最少测试用例数添加至测试模型经验库。

关于确定测试模型经验库包括的与每个软件对象类型关联的测试方法是否有缺失的方式，本发明实施例不作具体限定。具体实施时，可以与上述确定测试模型经验库包括的软件对象类型是否有缺失的方式的原理一致，具体可参见上述确定测试模型经验库包括的软件对象类型是否有缺失的方式的内容，在此不再赘述。

关于添加任一软件对象缺失的测试方法至与任一软件对象类型关联的测试方法中的方式，包括但不限于在在该任一软件对象缺失的测试方法中新增一项与任一软件对象类型关联的测试方法。

另外，本发明实施例不对确定为任一软件对象类型缺失的测试方法对应不同规模特征的最少测试用例数的方式进行限定，具体实施时，可以将任一软件对象类型缺失的测试方法对应不同规模特征的最少测试用例数确定为预先设置的默认数量的某一预设比例。例如，如果针对于大规模、中规模和小规模的预先设置的测试用例数的默认数量分别为30、20和10，且预设比例为50％，则可以将任一软件对象类型缺失的测试方法对应不同规模特征的最少测试用例数分别确定为15、10和5。当然，还可以采用其它方式确定为任一软件对象类型缺失的测试方法对应不同规模特征的最少测试用例数，如，由测试人员根据经验确定为任一软件对象类型缺失的测试方法对应不同规模特征的最少测试用例数，等等。

本发明实施例提供的方法，通过根据待测功能点的软件对象类型和规模特征查询预设的测试模型经验库，得到待测功能点的测试实现框架，并获取通过测试设计框架编写的每个测试方法对应的测试用例，从而根据测试实现框架的完成情况生成测试实现质量报告，并通过过滤测试实现框架中不满足待测功能点的预设测试实现条件的测试方法实现对待测功能点的测试实现方式进行筛选，使软件测试人员可以针对不满足预设测试实现条件的测试方法进行评审，不仅能节省人力成本和时间成本，而且能够提高功能点测试实现方式的筛选效率。由于可根据软件对象类型和规模特征及预设的测试模型经验库实现待测功能点的测试实现方式的筛选，因此，不仅适用范围更广，而且能减少人为筛选的随意性和不确定性，从而更具可靠性。

图3是根据一示例性实施例提供的一种功能点测试实现方式的筛选装置，该装置用于执行上述图1或图2所示实施例提供的功能点测试实现方式的筛选方法。参见图3，该装置包括：

第一获取模块301，用于获取人工标注的待测功能点的软件对象类型及规模特征；

查询模块302，用于根据软件对象类型及规模特征查询预设的测试模型经验库，得到待测功能点的测试实现框架，其中，测试实现框架至少包括与软件对象类型关联的至少一个测试方法及每个测试方法对应规模特征的最少测试用例数；

第二获取模块303，用于获取通过测试实现框架编写的每个测试方法对应的测试用例；

生成模块304，用于根据测试实现框架的完成情况生成待测功能点的测试实现质量报告；

过滤模块305，用于根据测试实现质量报告过滤测试实现框架中不满足待测功能点的预设测试实现条件的测试方法。

可选地，查询模块302，包括：

查询单元，用于查询测试模型经验库中与软件对象类型关联的所有测试方法；

确定单元，用于基于规模特征确定每个测试方法对应的测试用例数，将每个测试方法对应的测试用例数作为每个测试方法对应规模特征的最少测试用例数，得到至少包括至少一个测试方法及每个测试方法对应规模特征的最少测试用例数的测试实现框架。

可选地，参见图4，装置，还包括：

建立模块306，用于建立至少包括软件对象类型、测试方法及每个测试方法对应不同规模特征的最少测试用例数的映射关系，得到测试模型经验库。

可选地，生成模块304，包括：

第一统计单元，用于统计通过测试实现框架编写的每个测试方法对应的实际用例数；

第二统计单元，用于统计对待测功能点进行测试实现时使用的实际测试方法数；

确定单元，用于根据实际用例数、实际测试方法数及测试实现框架包括的测试方法数及每个测试方法对应规模特征的最少测试用例数确定待测功能点的测试实现充分度指标和测试实现多样性指标；

生成单元，用于根据测试实现充分度指标和测试实现多样性指标生成待测功能点的测试实现质量报告。

可选地，参见图5，装置，还包括：

第一确定模块307，用于确定测试模型经验库包括的软件对象类型是否有缺失；

第一添加模块308，用于当确定测试模型经验库包括的软件对象类型有缺失时，添加缺失的软件对象类型至测试模型经验库；

第二确定模块309，用于确定与缺失的软件对象类型关联的所有测试方法及每个测试方法对应不同规模特征的最少测试用例数；

第二添加模块310，用于将与缺失的软件对象类型关联的所有测试方法及每个测试方法对应不同规模特征的最少测试用例数添加至测试模型经验库。

可选地，参见图6，装置，还包括：

第三确定模块311，用于确定测试模型经验库包括的与每个软件对象类型关联的测试方法是否有缺失；

第三添加模块312，用于当测试模型经验库包括的与任一软件对象类型关联的测试方法有缺失时，添加任一软件对象缺失的测试方法至与任一软件对象类型关联的测试方法中；

第四确定模块313，用于确定为任一软件对象类型缺失的测试方法对应不同规模特征的最少测试用例数；

第四添加模块314，用于将任一软件对象类型缺失的测试方法对应不同规模特征的最少测试用例数添加至测试模型经验库。

本发明实施例提供的装置，通过根据待测功能点的软件对象类型和规模特征查询预设的测试模型经验库，得到待测功能点的测试实现框架，并获取通过测试设计框架编写的每个测试方法对应的测试用例，从而根据测试实现框架的完成情况生成测试实现质量报告，并通过过滤测试实现框架中不满足待测功能点的预设测试实现条件的测试方法实现对待测功能点的测试实现方式进行筛选，使软件测试人员可以针对不满足预设测试实现条件的测试方法进行评审，不仅能节省人力成本和时间成本，而且能够提高功能点测试实现方式的筛选效率。由于可根据软件对象类型和规模特征及预设的测试模型经验库实现待测功能点的测试实现方式的筛选，因此，不仅适用范围更广，而且能减少人为筛选的随意性和不确定性，从而更具可靠性。

请参考图7，其示出了本发明实施例所涉及的终端的结构示意图，该终端可以用于实施上述实施例中提供的功能点测试实现方式的筛选方法。具体来讲：

终端700可以包括RF(Radio Frequency，射频)电路110、包括有一个或一个以上计算机可读存储介质的存储器120、输入单元130、显示单元140、传感器150、音频电路160、WiFi(Wireless Fidelity，无线保真)模块170、包括有一个或者一个以上处理核心的处理器180、以及电源190等部件。本领域技术人员可以理解，图7中示出的终端结构并不构成对终端的限定，可以包括比图示更多或更少的部件，或者组合某些部件，或者不同的部件布置。其中：

RF电路110可用于收发信息或通话过程中，信号的接收和发送，特别地，将基站的下行信息接收后，交由一个或者一个以上处理器180处理；另外，将涉及上行的数据发送给基站。通常，RF电路110包括但不限于天线、至少一个放大器、调谐器、一个或多个振荡器、用户身份模块(SIM)卡、收发信机、耦合器、LNA(Low Noise Amplifier，低噪声放大器)、双工器等。此外，RF电路110还可以通过无线通信与网络和其他设备通信。所述无线通信可以使用任一通信标准或协议，包括但不限于GSM(Global System of Mobile communication，全球移动通讯系统)、GPRS(General Packet Radio Service，通用分组无线服务)、CDMA(CodeDivision Multiple Access，码分多址)、WCDMA(Wideband Code Division MultipleAccess,宽带码分多址)、LTE(Long Term Evolution,长期演进)、电子邮件、SMS(ShortMessaging Service，短消息服务)等。

存储器120可用于存储软件程序以及模块，处理器180通过运行存储在存储器120的软件程序以及模块，从而执行各种功能应用以及数据处理。存储器120可主要包括存储程序区和存储数据区，其中，存储程序区可存储操作系统、至少一个功能所需的应用程序(比如声音播放功能、图像播放功能等)等；存储数据区可存储根据终端700的使用所创建的数据(比如音频数据、电话本等)等。此外，存储器120可以包括高速随机存取存储器，还可以包括非易失性存储器，例如至少一个磁盘存储器件、闪存器件、或其他易失性固态存储器件。相应地，存储器120还可以包括存储器控制器，以提供处理器180和输入单元130对存储器120的访问。

输入单元130可用于接收输入的数字或字符信息，以及产生与用户设置以及功能控制有关的键盘、鼠标、操作杆、光学或者轨迹球信号输入。具体地，输入单元130可包括触敏表面131以及其他输入设备132。触敏表面131，也称为触摸显示屏或者触控板，可收集用户在其上或附近的触摸操作(比如用户使用手指、触笔等任何适合的物体或附件在触敏表面131上或在触敏表面131附近的操作)，并根据预先设定的程式驱动相应的连接装置。可选的，触敏表面131可包括触摸检测装置和触摸控制器两个部分。其中，触摸检测装置检测用户的触摸方位，并检测触摸操作带来的信号，将信号传送给触摸控制器；触摸控制器从触摸检测装置上接收触摸信息，并将它转换成触点坐标，再送给处理器180，并能接收处理器180发来的命令并加以执行。此外，可以采用电阻式、电容式、红外线以及表面声波等多种类型实现触敏表面131。除了触敏表面131，输入单元130还可以包括其他输入设备132。具体地，其他输入设备132可以包括但不限于物理键盘、功能键(比如音量控制按键、开关按键等)、轨迹球、鼠标、操作杆等中的一种或多种。

显示单元140可用于显示由用户输入的信息或提供给用户的信息以及终端700的各种图形用户接口，这些图形用户接口可以由图形、文本、图标、视频和其任意组合来构成。显示单元140可包括显示面板141，可选的，可以采用LCD(Liquid Crystal Display，液晶显示器)、OLED(Organic Light-Emitting Diode,有机发光二极管)等形式来配置显示面板141。进一步的，触敏表面131可覆盖显示面板141，当触敏表面131检测到在其上或附近的触摸操作后，传送给处理器180以确定触摸事件的类型，随后处理器180根据触摸事件的类型在显示面板141上提供相应的视觉输出。虽然在图7中，触敏表面131与显示面板141是作为两个独立的部件来实现输入和输入功能，但是在某些实施例中，可以将触敏表面131与显示面板141集成而实现输入和输出功能。

终端700还可包括至少一种传感器150，比如光传感器、运动传感器以及其他传感器。具体地，光传感器可包括环境光传感器及接近传感器，其中，环境光传感器可根据环境光线的明暗来调节显示面板141的亮度，接近传感器可在终端700移动到耳边时，关闭显示面板141和/或背光。作为运动传感器的一种，重力加速度传感器可检测各个方向上(一般为三轴)加速度的大小，静止时可检测出重力的大小及方向，可用于识别手机姿态的应用(比如横竖屏切换、相关游戏、磁力计姿态校准)、振动识别相关功能(比如计步器、敲击)等；至于终端700还可配置的陀螺仪、气压计、湿度计、温度计、红外线传感器等其他传感器，在此不再赘述。

音频电路160、扬声器161，传声器162可提供用户与终端700之间的音频接口。音频电路160可将接收到的音频数据转换后的电信号，传输到扬声器161，由扬声器161转换为声音信号输出；另一方面，传声器162将收集的声音信号转换为电信号，由音频电路160接收后转换为音频数据，再将音频数据输出处理器180处理后，经RF电路110以发送给比如另一终端，或者将音频数据输出至存储器120以便进一步处理。音频电路160还可能包括耳塞插孔，以提供外设耳机与终端700的通信。

WiFi属于短距离无线传输技术，终端700通过WiFi模块170可以帮助用户收发电子邮件、浏览网页和访问流式媒体等，它为用户提供了无线的宽带互联网访问。虽然图7示出了WiFi模块170，但是可以理解的是，其并不属于终端700的必须构成，完全可以根据需要在不改变发明的本质的范围内而省略。

处理器180是终端700的控制中心，利用各种接口和线路连接整个手机的各个部分，通过运行或执行存储在存储器120内的软件程序和/或模块，以及调用存储在存储器120内的数据，执行终端700的各种功能和处理数据，从而对手机进行整体监控。可选的，处理器180可包括一个或多个处理核心；优选的，处理器180可集成应用处理器和调制解调处理器，其中，应用处理器主要处理操作系统、用户界面和应用程序等，调制解调处理器主要处理无线通信。可以理解的是，上述调制解调处理器也可以不集成到处理器180中。

终端700还包括给各个部件供电的电源190(比如电池)，优选的，电源可以通过电源管理系统与处理器180逻辑相连，从而通过电源管理系统实现管理充电、放电、以及功耗管理等功能。电源190还可以包括一个或一个以上的直流或交流电源、再充电系统、电源故障检测电路、电源转换器或者逆变器、电源状态指示器等任意组件。

尽管未示出，终端700还可以包括摄像头、蓝牙模块等，在此不再赘述。具体在本实施例中，终端的显示单元是触摸屏显示器，终端还包括有存储器，以及一个或者一个以上的程序，其中一个或者一个以上程序存储于存储器中，且经配置以由一个或者一个以上处理器执行。所述一个或者一个以上程序包含用于执行以下操作的指令：

获取人工标注的待测功能点的软件对象类型及规模特征；

根据软件对象类型及规模特征查询预设的测试模型经验库，得到待测功能点的测试实现框架，其中，测试实现框架至少包括与软件对象类型关联的至少一个测试方法及每个测试方法对应规模特征的最少测试用例数；

获取通过测试实现框架编写的每个测试方法对应的测试用例，并根据测试实现框架的完成情况生成待测功能点的测试实现质量报告；

根据测试实现质量报告过滤测试实现框架中不满足待测功能点的预设测试实现条件的测试方法。

假设上述为第一种可能的实施方式，则在第一种可能的实施方式作为基础而提供的第二种可能的实施方式中，终端的存储器中，还包含用于执行以下操作的指令：根据软件对象类型及规模特征查询预设的测试模型经验库，包括：

查询测试模型经验库中与软件对象类型关联的所有测试方法；

基于规模特征确定每个测试方法对应的测试用例数，将每个测试方法对应的测试用例数作为每个测试方法对应规模特征的最少测试用例数，得到至少包括至少一个测试方法及每个测试方法对应规模特征的最少测试用例数的测试实现框架。

在第一种可能的实施方式作为基础而提供的第三种可能的实施方式中，终端的存储器中，还包含用于执行以下操作的指令：根据软件对象类型及规模特征查询预设的测试模型经验库之前，还包括：

建立至少包括软件对象类型、测试方法及每个测试方法对应不同规模特征的最少测试用例数的映射关系，得到测试模型经验库。

在第一种可能的实施方式作为基础而提供的第四种可能的实施方式中，终端的存储器中，还包含用于执行以下操作的指令：根据测试实现框架的完成情况生成待测功能点的测试实现质量报告，包括：

统计通过测试实现框架编写的每个测试方法对应的实际用例数，并统计对待测功能点进行测试实现时使用的实际测试方法数；

根据实际用例数、实际测试方法数及测试实现框架包括的测试方法数及每个测试方法对应规模特征的最少测试用例数确定待测功能点的测试实现充分度指标和测试实现多样性指标；

根据测试实现充分度指标和测试实现多样性指标生成待测功能点的测试实现质量报告。

在第三种可能的实施方式作为基础而提供的第五种可能的实施方式中，终端的存储器中，还包含用于执行以下操作的指令：得到测试模型经验库之后，还包括：

确定测试模型经验库包括的软件对象类型是否有缺失；

如果确定测试模型经验库包括的软件对象类型有缺失，则添加缺失的软件对象类型至测试模型经验库；

确定与缺失的软件对象类型关联的所有测试方法及每个测试方法对应不同规模特征的最少测试用例数，并将与缺失的软件对象类型关联的所有测试方法及每个测试方法对应不同规模特征的最少测试用例数添加至测试模型经验库。

在第三种可能的实施方式作为基础而提供的第六种可能的实施方式中，终端的存储器中，还包含用于执行以下操作的指令：得到测试模型经验库之后，还包括：

确定测试模型经验库包括的与每个软件对象类型关联的测试方法是否有缺失；

如果测试模型经验库包括的与任一软件对象类型关联的测试方法有缺失，则添加任一软件对象缺失的测试方法至与任一软件对象类型关联的测试方法中；

确定为任一软件对象类型缺失的测试方法对应不同规模特征的最少测试用例数；

将任一软件对象类型缺失的测试方法对应不同规模特征的最少测试用例数添加至测试模型经验库。

本发明实施例提供的终端，通过根据待测功能点的软件对象类型和规模特征查询预设的测试模型经验库，得到待测功能点的测试实现框架，并获取通过测试设计框架编写的每个测试方法对应的测试用例，从而根据测试实现框架的完成情况生成测试实现质量报告，并通过过滤测试实现框架中不满足待测功能点的预设测试实现条件的测试方法实现对待测功能点的测试实现方式进行筛选，使软件测试人员可以针对不满足预设测试实现条件的测试方法进行评审，不仅能节省人力成本和时间成本，而且能够提高功能点测试实现方式的筛选效率。由于可根据软件对象类型和规模特征及预设的测试模型经验库实现待测功能点的测试实现方式的筛选，因此，不仅适用范围更广，而且能减少人为筛选的随意性和不确定性，从而更具可靠性。

本发明实施例提供了一种计算机可读存储介质，该计算机可读存储介质可以是上述实施例中的存储器中所包含的计算机可读存储介质；也可以是单独存在，未装配入终端中的计算机可读存储介质。该计算机可读存储介质存储有一个或者一个以上程序，该一个或者一个以上程序被一个或者一个以上的处理器用来执行功能点测试实现方式的筛选方法，该方法包括：

获取人工标注的待测功能点的软件对象类型及规模特征；

根据软件对象类型及规模特征查询预设的测试模型经验库，得到待测功能点的测试实现框架，其中，测试实现框架至少包括与软件对象类型关联的至少一个测试方法及每个测试方法对应规模特征的最少测试用例数；

获取通过测试实现框架编写的每个测试方法对应的测试用例，并根据测试实现框架的完成情况生成待测功能点的测试实现质量报告；

根据测试实现质量报告过滤测试实现框架中不满足待测功能点的预设测试实现条件的测试方法。

假设上述为第一种可能的实施方式，则在第一种可能的实施方式作为基础而提供的第二种可能的实施方式中，终端的存储器中，还包含用于执行以下操作的指令：根据软件对象类型及规模特征查询预设的测试模型经验库，包括：

查询测试模型经验库中与软件对象类型关联的所有测试方法；

基于规模特征确定每个测试方法对应的测试用例数，将每个测试方法对应的测试用例数作为每个测试方法对应规模特征的最少测试用例数，得到至少包括至少一个测试方法及每个测试方法对应规模特征的最少测试用例数的测试实现框架。

在第一种可能的实施方式作为基础而提供的第三种可能的实施方式中，终端的存储器中，还包含用于执行以下操作的指令：根据软件对象类型及规模特征查询预设的测试模型经验库之前，还包括：

建立至少包括软件对象类型、测试方法及每个测试方法对应不同规模特征的最少测试用例数的映射关系，得到测试模型经验库。

在第一种可能的实施方式作为基础而提供的第四种可能的实施方式中，终端的存储器中，还包含用于执行以下操作的指令：根据测试实现框架的完成情况生成待测功能点的测试实现质量报告，包括：

统计通过测试实现框架编写的每个测试方法对应的实际用例数，并统计对待测功能点进行测试实现时使用的实际测试方法数；

根据实际用例数、实际测试方法数及测试实现框架包括的测试方法数及每个测试方法对应规模特征的最少测试用例数确定待测功能点的测试实现充分度指标和测试实现多样性指标；

根据测试实现充分度指标和测试实现多样性指标生成待测功能点的测试实现质量报告。

在第三种可能的实施方式作为基础而提供的第五种可能的实施方式中，终端的存储器中，还包含用于执行以下操作的指令：得到测试模型经验库之后，还包括：

确定测试模型经验库包括的软件对象类型是否有缺失；

如果确定测试模型经验库包括的软件对象类型有缺失，则添加缺失的软件对象类型至测试模型经验库；

确定与缺失的软件对象类型关联的所有测试方法及每个测试方法对应不同规模特征的最少测试用例数，并将与缺失的软件对象类型关联的所有测试方法及每个测试方法对应不同规模特征的最少测试用例数添加至测试模型经验库。

在第三种可能的实施方式作为基础而提供的第六种可能的实施方式中，终端的存储器中，还包含用于执行以下操作的指令：得到测试模型经验库之后，还包括：

确定测试模型经验库包括的与每个软件对象类型关联的测试方法是否有缺失；

如果测试模型经验库包括的与任一软件对象类型关联的测试方法有缺失，则添加任一软件对象缺失的测试方法至与任一软件对象类型关联的测试方法中；

确定为任一软件对象类型缺失的测试方法对应不同规模特征的最少测试用例数；

将任一软件对象类型缺失的测试方法对应不同规模特征的最少测试用例数添加至测试模型经验库。

本发明实施例提供的计算机可读存储介质，通过根据待测功能点的软件对象类型和规模特征查询预设的测试模型经验库，得到待测功能点的测试实现框架，并获取通过测试设计框架编写的每个测试方法对应的测试用例，从而根据测试实现框架的完成情况生成测试实现质量报告，并通过过滤测试实现框架中不满足待测功能点的预设测试实现条件的测试方法实现对待测功能点的测试实现方式进行筛选，使软件测试人员可以针对不满足预设测试实现条件的测试方法进行评审，不仅能节省人力成本和时间成本，而且能够提高功能点测试实现方式的筛选效率。由于可根据软件对象类型和规模特征及预设的测试模型经验库实现待测功能点的测试实现方式的筛选，因此，不仅适用范围更广，而且能减少人为筛选的随意性和不确定性，从而更具可靠性。

本发明实施例中提供了一种图形用户接口，该图形用户接口用在终端上，该终端包括触摸屏显示器、存储器和用于执行一个或者一个以上的程序的一个或者一个以上的处理器；该图形用户接口包括：

获取人工标注的待测功能点的软件对象类型及规模特征；

根据软件对象类型及规模特征查询预设的测试模型经验库，得到待测功能点的测试实现框架，其中，测试实现框架至少包括与软件对象类型关联的至少一个测试方法及每个测试方法对应规模特征的最少测试用例数；

获取通过测试实现框架编写的每个测试方法对应的测试用例，并根据测试实现框架的完成情况生成待测功能点的测试实现质量报告；

根据测试实现质量报告过滤测试实现框架中不满足待测功能点的预设测试实现条件的测试方法。

本发明实施例提供的图形用户接口，通过根据待测功能点的软件对象类型和规模特征查询预设的测试模型经验库，得到待测功能点的测试实现框架，并获取通过测试设计框架编写的每个测试方法对应的测试用例，从而根据测试实现框架的完成情况生成测试实现质量报告，并通过过滤测试实现框架中不满足待测功能点的预设测试实现条件的测试方法实现对待测功能点的测试实现方式进行筛选，使软件测试人员可以针对不满足预设测试实现条件的测试方法进行评审，不仅能节省人力成本和时间成本，而且能够提高功能点测试实现方式的筛选效率。由于可根据软件对象类型和规模特征及预设的测试模型经验库实现待测功能点的测试实现方式的筛选，因此，不仅适用范围更广，而且能减少人为筛选的随意性和不确定性，从而更具可靠性。

需要说明的是：上述实施例提供的功能点测试实现方式的筛选装置在实现功能点测试实现方式的筛选方法时，仅以上述各功能模块的划分进行举例说明，实际应用中，可以根据需要而将上述功能分配由不同的功能模块完成，即将设备的内部结构划分成不同的功能模块，以完成以上描述的全部或者部分功能。另外，上述实施例提供的功能点测试实现方式的筛选装置及终端与功能点测试实现方式的筛选方法实施例属于同一构思，其具体实现过程详见方法实施例，这里不再赘述。

本领域普通技术人员可以理解实现上述实施例的全部或部分步骤可以通过硬件来完成，也可以通过程序来指令相关的硬件完成，所述的程序可以存储于一种计算机可读存储介质中，上述提到的存储介质可以是只读存储器，磁盘或光盘等。

以上所述仅为本发明的较佳实施例，并不用以限制本发明，凡在本发明的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。

Claims (13)

1.一种功能点测试实现方式的筛选方法，其特征在于，所述方法包括：

获取待测功能点的软件对象类型及规模特征，所述待测功能点的软件对象类型及规模特征均为人工标注；

根据所述软件对象类型及所述规模特征查询预设的测试模型经验库，得到所述待测功能点的测试实现框架，所述测试实现框架至少包括与所述软件对象类型关联的至少一个测试方法及每个测试方法对应所述规模特征的最少测试用例数；

获取通过所述测试实现框架编写的每个测试方法对应的测试用例，并根据所述测试实现框架的完成情况生成所述待测功能点的测试实现质量报告；

根据所述测试实现质量报告过滤所述测试实现框架中不满足所述待测功能点的预设测试实现条件的测试方法。

2.根据权利要求1所述的方法，其特征在于，所述根据所述软件对象类型及所述规模特征查询预设的测试模型经验库，包括：

查询所述测试模型经验库中与所述软件对象类型关联的所有测试方法；

基于所述规模特征确定每个测试方法对应的测试用例数，将每个测试方法对应的测试用例数作为每个测试方法对应所述规模特征的最少测试用例数，得到至少包括至少一个测试方法及每个测试方法对应所述规模特征的最少测试用例数的测试实现框架。

3.根据权利要求1所述的方法，其特征在于，所述根据所述软件对象类型及所述规模特征查询预设的测试模型经验库之前，还包括：

建立至少包括软件对象类型、测试方法及每个测试方法对应不同规模特征的最少测试用例数的映射关系，得到所述测试模型经验库。

4.根据权利要求1所述的方法，其特征在于，所述根据所述测试实现框架的完成情况生成所述待测功能点的测试实现质量报告，包括：

统计通过所述测试实现框架编写的每个测试方法对应的实际用例数，并统计对所述待测功能点进行测试实现时使用的实际测试方法数；

根据所述实际用例数、所述实际测试方法数及所述测试实现框架包括的测试方法数及每个测试方法对应所述规模特征的最少测试用例数确定所述待测功能点的测试实现充分度指标和测试实现多样性指标；

根据所述测试实现充分度指标和所述测试实现多样性指标生成所述待测功能点的测试实现质量报告。

5.根据权利要求3所述的方法，其特征在于，所述得到所述测试模型经验库之后，还包括：

确定所述测试模型经验库包括的软件对象类型是否有缺失；

如果确定所述测试模型经验库包括的软件对象类型有缺失，则添加缺失的软件对象类型至所述测试模型经验库；

确定与所述缺失的软件对象类型关联的所有测试方法及每个测试方法对应不同规模特征的最少测试用例数，并将与所述缺失的软件对象类型关联的所有测试方法及每个测试方法对应不同规模特征的最少测试用例数添加至所述测试模型经验库。

6.根据权利要求3所述的方法，其特征在于，所述得到所述测试模型经验库之后，还包括：

确定所述测试模型经验库包括的与每个软件对象类型关联的测试方法是否有缺失；

如果所述测试模型经验库包括的与任一软件对象类型关联的测试方法有缺失，则添加所述任一软件对象缺失的测试方法至与所述任一软件对象类型关联的测试方法中；

确定为所述任一软件对象类型缺失的测试方法对应不同规模特征的最少测试用例数；

将所述任一软件对象类型缺失的测试方法对应不同规模特征的最少测试用例数添加至所述测试模型经验库。

7.一种功能点测试实现方式的筛选装置，其特征在于，所述装置包括：

第一获取模块，用于获取待测功能点的软件对象类型及规模特征，所述待测功能点的软件对象类型及规模特征均为人工标注；

查询模块，用于根据所述软件对象类型及所述规模特征查询预设的测试模型经验库，得到所述待测功能点的测试实现框架，所述测试实现框架至少包括与所述软件对象类型关联的至少一个测试方法及每个测试方法对应所述规模特征的最少测试用例数；

第二获取模块，用于获取通过所述测试实现框架编写的每个测试方法对应的测试用例；

生成模块，用于根据所述测试实现框架的完成情况生成所述待测功能点的测试实现质量报告；

过滤模块，用于根据所述测试实现质量报告过滤所述测试实现框架中不满足所述待测功能点的预设测试实现条件的测试方法。

8.根据权利要求7所述的装置，其特征在于，所述查询模块，包括：

查询单元，用于查询所述测试模型经验库中与所述软件对象类型关联的所有测试方法；

确定单元，用于基于所述规模特征确定每个测试方法对应的测试用例数，将每个测试方法对应的测试用例数作为每个测试方法对应所述规模特征的最少测试用例数，得到至少包括至少一个测试方法及每个测试方法对应所述规模特征的最少测试用例数的测试实现框架。

9.根据权利要求7所述的装置，其特征在于，所述装置，还包括：

建立模块，用于建立至少包括软件对象类型、测试方法及每个测试方法对应不同规模特征的最少测试用例数的映射关系，得到所述测试模型经验库。

10.根据权利要求7所述的装置，其特征在于，所述生成模块，包括：

第一统计单元，用于统计通过所述测试实现框架编写的每个测试方法对应的实际用例数；

第二统计单元，用于统计对所述待测功能点进行测试实现时使用的实际测试方法数；

确定单元，用于根据所述实际用例数、所述实际测试方法数及所述测试实现框架包括的测试方法数及每个测试方法对应所述规模特征的最少测试用例数确定所述待测功能点的测试实现充分度指标和测试实现多样性指标；

生成单元，用于根据所述测试实现充分度指标和所述测试实现多样性指标生成所述待测功能点的测试实现质量报告。

11.根据权利要求9所述的装置，其特征在于，所述装置，还包括：

第一确定模块，用于确定所述测试模型经验库包括的软件对象类型是否有缺失；

第一添加模块，用于当确定所述测试模型经验库包括的软件对象类型有缺失时，添加缺失的软件对象类型至所述测试模型经验库；

第二确定模块，用于确定与所述缺失的软件对象类型关联的所有测试方法及每个测试方法对应不同规模特征的最少测试用例数；

第二添加模块，用于将与所述缺失的软件对象类型关联的所有测试方法及每个测试方法对应不同规模特征的最少测试用例数添加至所述测试模型经验库。

12.根据权利要求9所述的装置，其特征在于，所述装置，还包括：

第三确定模块，用于确定所述测试模型经验库包括的与每个软件对象类型关联的测试方法是否有缺失；

第三添加模块，用于当所述测试模型经验库包括的与任一软件对象类型关联的测试方法有缺失时，添加所述任一软件对象缺失的测试方法至与所述任一软件对象类型关联的测试方法中；

第四确定模块，用于确定为所述任一软件对象类型缺失的测试方法对应不同规模特征的最少测试用例数；

第四添加模块，用于将所述任一软件对象类型缺失的测试方法对应不同规模特征的最少测试用例数添加至所述测试模型经验库。

13.一种终端，其特征在于，所述终端包括有存储器，以及一个或者一个以上的程序，其中一个或者一个以上程序存储于存储器中，且经配置以由一个或者一个以上处理器执行，所述一个或者一个以上程序包含用于执行以下操作的指令：

获取待测功能点的软件对象类型及规模特征，所述待测功能点的软件对象类型及规模特征均为人工标注；

根据所述软件对象类型及所述规模特征查询预设的测试模型经验库，得到所述待测功能点的测试实现框架，所述测试实现框架至少包括与所述软件对象类型关联的至少一个测试方法及每个测试方法对应所述规模特征的最少测试用例数；

获取通过所述测试实现框架编写的每个测试方法对应的测试用例，并根据所述测试实现框架的完成情况生成所述待测功能点的测试实现质量报告；

根据所述测试实现质量报告过滤所述测试实现框架中不满足所述待测功能点的预设测试实现条件的测试方法。