测试案例的有效性评估方法、计算机设备及存储介质与流程

1.本技术涉及计算机技术领域，特别是涉及一种测试案例的有效性评估方法、计算机设备及计算机可读存储介质。


背景技术：

2.在目前的软件应用中，在开发出软件后，不会直接使用软件，通常需要对软件代码进行测试，软件测试主要用于对软件正确性进行分析和对软件漏洞进行检测。
3.在对软件代码进行测试时，通常需要确定测试案例的执行完整情况，通过测试案例的执行完整情况来对测试工作进行评估，进而便于对测试案例等进行调整，在此基础上对软件代码进行完善。
4.目前，一些软件测试工具可以基于自动化的测试案例进行软件代码测试，但是，不能确定编写的测试案例是否是有效的，而测试案例的有效性会影响软件代码的测试过程。


技术实现要素：

5.本技术主要解决的技术问题是提供一种测试案例的有效性评估方法、计算机设备及存储介质，能够准确地获取测试案例的有效性。
6.为了解决上述问题，本技术第一方面提供了一种测试案例的有效性评估方法，该方法包括：基于测试案例对业务代码的覆盖度进行代码有效性评估，以获得代码有效性评估结果；基于测试案例的断言内容进行断言有效性评估，以获得断言有效性评估结果；综合代码有效性评估结果和断言有效性评估结果确定测试案例的案例有效性。
7.为了解决上述问题，本技术第二方面提供了一种计算机设备，该计算机设备包括相互耦接的存储器和处理器，存储器中存储有程序数据，处理器用于执行程序数据以实现上述测试案例的有效性评估方法的任一步骤。
8.为了解决上述问题，本技术第三方面提供了一种计算机可读存储介质，该计算机可读存储介质存储有能够被处理器运行的程序数据，程序数据用于实现上述测试案例的有效性评估方法的任一步骤。
9.上述方案，通过基于测试案例对业务代码的覆盖度进行代码有效性评估，以获得代码有效性评估结果，基于测试案例的断言内容进行断言有效性评估，以获得断言有效性评估结果，并综合代码有效性评估结果和断言有效性评估结果，确定测试案例的案例有效性，可以综合考虑代码有效性和断言有效性，可以更准确地判断测试案例的有效性，以及提高测试案例的可用性和准确性，从而，减少用户对测试代码或业务代码的排查时间，另外，通过案例有效性可以为开发人员提供有效性评价的参考信息，使得测试案例的编写更规范及更标准。
附图说明
10.为了更清楚地说明本技术中的技术方案，下面将对实施例描述中所需要的附图作
简单的介绍，显而易见地，下面描述的附图仅仅是本技术的一些实施例，对于本领域普通技术人员来说，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。其中：
11.图1是本技术测试案例的有效性评估方法一实施例的流程示意图；
12.图2是本技术图1中步骤s11一实施例的流程示意图；
13.图3是本技术测试案例测试业务代码的覆盖度一实施例的示意图；
14.图4是本技术图1中步骤s12一实施例的流程示意图；
15.图5是本技术图1中步骤s13一实施例的流程示意图；
16.图6是本技术测试案例的有效性评估装置一实施例的结构示意图；
17.图7是本技术计算机设备一实施例的结构示意图；
18.图8是本技术计算机可读存储介质一实施例的结构示意图。
具体实施方式
19.下面将结合本技术实施例中的附图，对本技术实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅是本技术的一部分实施例，而不是全部的实施例。基于本技术中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本技术保护的范围。
20.本技术中的术语“第一”、“第二”仅用于描述目的，而不能理解为指示或暗示相对重要性或者隐含指明所指示的技术特征的数量。由此，限定有“第一”、“第二”的特征可以明示或者隐含地包括至少一个该特征。本技术的描述中，“多个”的含义是至少两个，例如两个，三个等，除非另有明确具体的限定。此外，术语“包括”和“具有”以及它们任何变形，意图在于覆盖不排他的包含。例如包含了一系列步骤或单元的过程、方法、系统、产品或设备没有限定于已列出的步骤或单元，而是可选地还包括没有列出的步骤或单元，或可选地还包括对于这些过程、方法、产品或设备固有的其它步骤或单元。
21.在本技术中提及“实施例”意味着，结合实施例描述的特定特征、结构或特性可以包含在本技术的至少一个实施例中。在说明书中的各个位置出现该短语并不一定均是指相同的实施例，也不是与其它实施例互斥的独立的或备选的实施例。本领域技术人员显式地和隐式地理解的是，本文所描述的实施例可以与其它实施例相结合。
22.本技术提供以下实施例，下面对各实施例进行具体说明。
23.请参阅图1，图1是本技术测试案例的有效性评估方法一实施例的流程示意图。该方法可以包括以下步骤：
24.s11：基于测试案例对业务代码的覆盖度进行代码有效性评估，以获得代码有效性评估结果。
25.软件测试(英语：software testing)，描述一种用来促进鉴定软件的正确性、完整性、安全性和质量的过程。换句话说，软件测试是一种实际输出与预期输出之间的审核或者比较过程。软件测试的经典定义是：在规定的条件下对程序进行操作，以发现程序错误，衡量软件质量，并对其是否能满足设计要求进行评估的过程。
26.在一些实施方式中，测试案例可以是一组测试案例，例如可以包括单元测试的多个最小单元测试案例，最小单元测试案例可以用于对业务代码中对应的最小可测试单元进行检测和验证，最小可测试单元可以是业务代码中的一个模块、一个函数或一个类等。
27.在一些实施方式中，可以利用测试案例执行业务代码的覆盖度进行代码有效性评估，其中，覆盖率描述为代码覆盖率，代码覆盖率(英语：code coverage)是软件测试中的一种考量度量，用以描述业务代码中源代码被测试的比例或程度，所得比例或程度称为代码覆盖率。
28.在一些实施方式中，可利用jacoco等代码覆盖率统计工具，利用测试案例对业务代码进行测试，以收集业务代码的代码覆盖率，并基于代码覆盖率，对业务代码的代码有效性进行评估。
29.在一些实施方式中，可以利用覆盖率统计工具在业务代码中设置埋点数据，以利用埋点数据获取测试案例执行业务代码时的代码覆盖率。
30.在一些实施方式中，可以利用获取的业务代码的有效代码行被执行的行数，以基于有效代行被执行的行数确定业务代码的代码覆盖率。其中，有效代码行的概念是相对代码行的概念而言的，有效代码行可以是业务代码中实际可以运行的代码行。业务代码的有效代码行被执行的比例越高，则代码覆盖率越高，也即代码有效性也越好。
31.s12：基于测试案例的断言内容进行断言有效性评估，以获得断言有效性评估结果。
32.断言(assertion)是一种在程序中的一阶逻辑(如：一个结果为真或假的逻辑判断式，其目的是为了表示与验证软件开发者预期的结果。
33.在一些实施方式中，断言有效性可以从测试案例的编写出发，对测试案例的内容进行判断，可以判断测试案例是否做了有效的断言。
34.测试案例中包含案例值，通过测试案例中的案例值对业务代码进行测试后，得到执行后的结果，也即得到待断言值。在此之前，可以预先设置案例值执行业务代码对应的预期值，以此，可以得到断言内容，也即待断言值和预期值。
35.在一些实施方式中，将断言内容中的待断言值和预期值进行比较，若待断言值和预期值的数据数值、数据类型、逻辑效验等都彼此相等时，可以将断言有效性评估结果设置为有效。否则，则将断言有效性设置为无效。
36.通过上述方式，可以通过断言有效性评估结果，得知是否在业务代码和/或测试案例中写入有效断言，从而在业务代码开发过程中，可以提高业务代码的质量，在软件测试过程中，提高测试案例编写的质量，从而为开发人员提供有效性评价的参考信息。
37.s13：综合代码有效性评估结果和断言有效性评估结果，确定测试案例的案例有效性。
38.可以利用测试案例对业务代码进行软件测试，当业务代码出现问题时，若测试案例可以发现这个问题，则认为测试案件是有效的；反之，若测试案例不能发现这个问题，则认为测试案例是无效的。
39.本步骤中，可以综合代码有效性评估结果和断言有效性评估结果，从而，可以通过代码覆盖度和断言有效性来综合判断测试案例的案例有效性。若判断得到测试案例的案例有效性为无效时，可以对测试案例进行调整，以获取更为有效、准确地的测试案例。
40.本步骤中，通过基于测试案例对业务代码的覆盖度进行代码有效性评估，以获得代码有效性评估结果，基于测试案例的断言内容进行断言有效性评估，以获得断言有效性评估结果，并综合代码有效性评估结果和断言有效性评估结果，确定测试案例的案例有效
性，可以综合考虑代码有效性和断言有效性，可以更准确地判断测试案例的有效性，以及提高测试案例的可用性和准确性，从而减少用户对测试代码或业务代码的排查时间，另外，通过案例有效性可以为开发人员提供有效性评价的参考信息，使得测试案例的编写更规范及更标准。
41.在一些实施例中，请参阅图2，可以对上述实施例的步骤s11进一步扩展。基于测试案例对业务代码的覆盖度进行代码有效性评估，以获得代码有效性评估结果，本实施例可以包括以下步骤：
42.s111：获取业务代码在测试过程中使用到测试案例的代码行数与业务代码的总行数之间的行数比例。
43.在利用测试案例对业务代码的测试过程中，获取业务代码在测试过程中使用到测试案例的代码行数，也即在测试过程中，业务代码被执行或被测试的代码行数，从而获取使用到测试案例的代码行数与业务代码的总行数之间的行数比例，行数比例可以表示业务代码的代码覆盖率，也即覆盖度。
44.在一些实施方式中，业务代码的总行数包括业务代码的所有代码行，也即在编程中程序员编写的所有代码的行数，例如可以包括空行、注解行和代码行。
45.在一些实施方式中，业务代码的的总行数可以表示为业务代码中实际可运行的代码，如代码行或有效代码行等。
46.在一些实施方式中，业务代码的数量为多个时，可以分别获取每个业务代码在测试过程中使用到测试案例的代码行数与业务代码的总行数之间的行数比例。例如业务代码包含团队层、系统层和案例层时，可以分别获取每个团队层、系统层和案例层的代码覆盖度。
47.在一些实施方式中，业务代码包含多个测试单元时，分别可以获取业务代码中多个测试单元使用到测试案例的代码行数，例如分别获取业务代码的多个测试单元使用到测试案例的代码行数，也即分别获取多个测试单元被测试或被执行的代码行数，并分别获取每个测试单元中使用到测试案例的代码行数与业务代码的测试单元的总行数之间的行数比例，以在后续可以获取每个测试单元的代码覆盖度。其中，测试单元可以是业务代码中的一个模块、一个函数或一个类等。
48.在一些实施方式中，可以在利用测试案例对业务代码进行测试之前，在业务代码中设置埋点数据，也即对业务代码进行埋点，埋点数据可以是一段用于信息采集的代码，可以根据实际需要设置。埋点可以在不破坏业务代码原有逻辑完整性的情况下，在业务代码中插入用于埋点的代码，也即埋点数据，埋点数据可以进行信息采集，输出业务代码程序运行的特征数据。可以利用埋点数据获取测试案例执行业务代码时的行数比例，以获取代码覆盖率。
49.在一些实施方式中，行数比例或覆盖度可以用百分比进行表示，精确度可以根据应用场景进行选择，如精确度为0.001％、0.01％、0.1％等，本技术对此不做限制。
50.在一些实施方式中，业务代码可以进一步划分为主业务代码和辅助业务代码。
51.在一些应用场景中，业务代码的数据为多个时，可以在多个业务代码中选择至少一个业务代码作为主业务代码，并将其他业务代码作为辅助业务代码。
52.在一些应用场景中，可以将业务代码的有效代码行或代码行(除空白行和注解行
的代码行)作为主业务代码，将空白行和注解行的代码行作为辅助业务代码。此外，还可以将业务代码的埋点数据作为辅助业务代码。
53.本技术的主业务代码和辅助业务代码可以基于业务代码的具体应用场景进行设置，本技术对上述业务代码的主业务代码和辅助业务代码不做限制。
54.在一些实施方式中，业务代码可以进一步划分为主业务代码和辅助业务代码。可以获取主业务代码在测试过程中使用到测试案例的代码行数与主业务代码的总行数之间的行数比例。或者，获取主业务代码在测试过程中使用到测试案例的代码行数与业务代码的总行数之间的行数比例。
55.在一些实施方式中，业务代码可以进一步划分为主业务代码和辅助业务代码。可以分别获取主业务代码和辅助业务代码在测试过程中使用到测试案例的代码行数与业务代码的总行数之间的行数比例。
56.在一些实施方式中，上述过程为获取测试案例对业务代码的全量覆盖度，也即是针对业务代码的所有代码行进行测试。在一些应用场景中，在完成对业务代码软件测试之后，程序人员对业务代码进行修改，添加了一些模块的函数方法等，可以利用测试案例再次对业务代码进行测试，此情形下，可以获取业务代码的增量覆盖度，也即对增加的模块的函数方法，也即测试单元进行软件测试，该方式可以参考上述对全量覆盖度的具体实施方式，在此不做赘述。
57.请参阅图3，可以基于测试案例执行业务代码，从而获取业务代码的覆盖度，也即获取业务代码在测试过程中使用到测试案例的代码行数与业务代码的总行数之间的行数比例。若业务代码的数量为多个，可以分别获取多个业务代码的覆盖度，在软件测试执行界面，可以响应于用户在显示界面的选择，确定测试案例执行业务代码的全局覆盖度或增量覆盖度，以全局覆盖度为例，可以分别得到业务代码1-10的覆盖度。
58.在对业务代码的测试过程中，可以将多个时间段测试的覆盖度进行统计，如将多个测试时间22-01到22-06对业务代码测试的覆盖度用曲线形式进行表示，可以理解的是，覆盖度的表示和统计不限于此。
59.另外，在执行界面，还可以基于业务代码对应的覆盖度进行排序，以得到每个业务代码对应的覆盖度情况。如得到的覆盖度情况如下：
60.排序1为业务代码1对应的覆盖度为46.46％；
61.排序2为业务代码5对应的覆盖度为44.43％；
62.排序3为业务代码3对应的覆盖度为41.94％；
63.排序4为业务代码2对应的覆盖度为40.30％；
64.……
65.排序9为业务代码7对应的覆盖度为36.27％；
66.排序10为业务代码10对应的覆盖度为36.20％。
67.通过该方式，可以明确多个业务代码分别的覆盖度，从而可以确定是否需要多个业务代码的某一业务代码选择其他测试案例进行测试、对测试案例进行修改或对业务代码进行调整等。
68.s112：基于行数比例获得代码有效性评估结果。
69.可以基于行数比例与预设的比例阈值进行比较，以获取代码有效性的评估结果。
70.在一些实施方式中，可以响应于行数比例大于或等于预设的比例阈值，将代码有效性评估结果设置为有效。预设的比例阈值可以为基于历史软件测试的经验统计值，预设的比例阈值可以为根据具体的应用场景需求进行设置，本技术对此不做限制。
71.在一些实施方式中，业务代码的数量为多个时，也即包含多个业务代码时，可以获取行数比例大于或等于预设的比例阈值的业务代码的数量，也即获取多个业务代码中代码有效性为有效的数量。若数量大于或等于预设的数量阈值，可以确定业务代码是有效的，其中，预设的数量阈值为小于或等于业务代码总数的数值。此时，可以响应于行数比例大于或等于预设的比例阈值的业务代码的数量大于或等于预设的数量阈值，将代码有效性评估结果设置为有效。
72.在一些实施方式中，业务代码可以进一步划分为主业务代码和辅助业务代码。此时，可以获取主业务代码的行数比例大于或等于预设的比例阈值的数量，若数量大于预设的数量阈值，则响应于行数比例大于或等于预设的比例阈值的主业务代码的数量大于或等于预设的数量阈值，将代码有效性评估结果设置为有效。
73.在一些实施方式中，业务代码的多个测试单元的有效性可以参考上述业务代码的数量为多个的情况，此处不再赘述。
74.本实施例中，可以通过获取业务代码在测试过程中使用到测试案例的代码行数与业务代码的总行数之间的行数比例，基于行数比例获得代码有效性评估结果，可以准确地获取业务代码的有效性，节省用户对业务代码的排除时间；另外，若业务代码的覆盖度太低，还可以对测试案例进行调整，进而可以提高测试案例的可用性、准确性。
75.在一些实施例中，请参阅图4，可以对上述实施例的步骤s12进一步扩展。基于测试案例的断言内容进行断言有效性评估，以获得断言有效性评估结果，本实施例可以包括以下步骤：
76.s121：响应于断言内容中的待断言值和预期值彼此相等，将断言有效性评估结果设置为有效。
77.在一些实施方式中，将断言内容中的待断言值和预期值进行比较，若待断言值和预期值的数据数值、数据类型、逻辑效验等都彼此相等时，则可以响应于断言内容中的待断言值和预期值彼此相等，将断言有效性评估结果设置为有效。
78.在一些实施方式中，断言内容的待断言值与预期值的数值相等、数据类型相等时，还可以进行逻辑效验，进行逻辑效验时，可以引用业务代码的返回结果或引用业务代码。
79.在一些实施方式中，断言内容中的待断言值、预期值中至少有一者引用业务代码的返回结果，引用业务代码的返回结果可以为业务代码中断言内容对应的表达式，通过断言内容中的待断言值、预期值中至少有一者引用业务代码的返回结果，可以使得测试案例的断言内容的实际结果被断言，从而，在待断言值和预期值彼此相等时，则将断言有效性评估结果设置为有效。
80.s122：响应于断言内容中的待断言值和预期值均未引用业务代码的返回结果，将断言有效性评估结果设置为无效。
81.在一些实施方式中，若断言内容中的待断言值和预期值均未引用业务代码的返回结果，则可以表示测试案例的实际结果也即断言内容未被断言，可以响应于断言内容中的待断言值和预期值均未引用业务代码的返回结果，将断言有效性评估结果设置为无效。
82.在一些实施方式中，若断言内容中的待断言值和预期值存在不相等，和/或，断言内容中的待断言值和预期值均未引用业务代码的返回结果，则将断言有效性评估结果设置为无效。
83.本实施例中，通过判断断言内容中的待断言值和预期值彼此相等，将断言有效性评估结果设置为有效，断言内容中的待断言值和预期值均未引用业务代码的返回结果，则将断言有效性评估结果设置为无效，可以更准确的对测试案例进行断言有效性评估，并且可以使得测试案例的实际结果被断言。
84.在一些实施例中，请参阅图5，可以对上述实施例的步骤s13进一步扩展。综合代码有效性评估结果和断言有效性评估结果，确定测试案例的案例有效性，本实施例可以包括以下步骤：
85.s131：响应于代码有效性评估结果和断言有效性评估结果均为有效，将测试案例判定为有效案例。
86.若代码有效性评估结果和断言有效性评估结果均为有效，可以判断测试案例是有效的，则可以响应于代码有效性评估结果和断言有效性评估结果均为有效，将测试案例判定为有效案例。
87.s132：响应于代码有效性评估结果和断言有效性评估结果中的至少一个为无效，将测试案例判定为无效案例。
88.若代码有效性评估结果和断言有效性评估结果中的至少一个为无效，可以判断测试案例是无效的，则可以响应于代码有效性评估结果和断言有效性评估结果中的至少一个为无效，将测试案例判定为无效案例。
89.例如代码有效性评估结果为无效；或者断言有效性评估结果为无效；或者，代码有效性评估结果为无效且，断言有效性评估结果为无效；则可以将测试案例判断为无效案例。
90.对于上述实施例，本技术下述提供一种测试案例的有效性评估装置。具体如下：
91.请参阅图6，图6是本技术提供的试案例的有效性评估装置一实施例的结构示意图。试案例的有效性评估装置20包括代码有效性评估模块21、断言有效性评估模块22和案例有效性评估模块23。
92.代码有效性评估模块21用于基于测试案例对业务代码的覆盖度进行代码有效性评估，以获得代码有效性评估结果。
93.断言有效性评估模块22用于基于测试案例的断言内容进行断言有效性评估，以获得断言有效性评估结果。
94.案例有效性评估模块23用于综合代码有效性评估结果和断言有效性评估结果，确定测试案例的案例有效性。
95.在一些实施方式中，代码有效性评估模块21用于基于测试案例对业务代码的覆盖度进行代码有效性评估的步骤包括：获取业务代码在测试过程中使用到测试案例的代码行数与业务代码的总行数之间的行数比例；基于行数比例获得代码有效性评估结果。
96.在一些实施方式中，代码有效性评估模块21用于响应于行数比例大于或等于预设的比例阈值，将代码有效性评估结果设置为有效。
97.在一些实施方式中，业务代码的数量为多个时；代码有效性评估模块21用于响应于行数比例大于或等于预设的比例阈值的业务代码的数量大于或等于预设的数量阈值，将
代码有效性评估结果设置为有效。
98.在一些实施方式中，业务代码进一步划分为主业务代码和辅助业务代码；代码有效性评估模块21用于响应于行数比例大于或等于预设的比例阈值的主业务代码的数量大于或等于预设的数量阈值，将代码有效性评估结果设置为有效。
99.在一些实施方式中，断言有效性评估模块22用于基于测试案例的断言内容进行断言有效性评估包括：响应于断言内容中的待断言值和预期值彼此相等，将断言有效性评估结果设置为有效。以及用于响应于断言内容中的待断言值和预期值均未引用业务代码的返回结果，将断言有效性评估结果设置为无效。
100.在一些实施方式中，案例有效性评估模块23用于综合代码有效性评估结果和断言有效性评估结果，确定测试案例的案例有效性的步骤包括：响应于代码有效性评估结果和断言有效性评估结果均为有效，将测试案例判定为有效案例；以及响应于代码有效性评估结果和断言有效性评估结果中的至少一个为无效，将测试案例判定为无效案例。
101.该实施例的具体实施方式可参考上述实施例的实施过程，在此不再赘述。
102.对于上述实施例，本技术提供一种计算机设备，请参阅图7，图7是本技术计算机设备一实施例的结构示意图。该计算机设备30包括存储器31和处理器32，其中，存储器31和处理器32相互耦接，存储器31中存储有程序数据，处理器32用于执行程序数据以实现上述测试案例的有效性评估方法任一实施例的步骤。
103.在本实施例中，处理器32还可以称为cpu(central processing unit，中央处理单元)。处理器32可能是一种集成电路芯片，具有信号的处理能力。处理器32还可以是通用处理器、数字信号处理器(dsp)、专用集成电路(asic)、现场可编程门阵列(fpga)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件。通用处理器可以是微处理器或者该处理器32也可以是任何常规的处理器等。
104.该实施例的具体实施方式可参考上述实施例的实施过程，在此不再赘述。
105.对于上述实施例的方法，其可以采用计算机程序的形式实现，因而本技术提出一种计算机可读存储介质，请参阅图8，图8是本技术计算机可读存储介质一实施例的结构示意图。该计算机可读存储介质40中存储有能够被处理器运行的程序数据41，程序数据41可被处理器执行以实现上述测试案例的有效性评估方法的任一实施例的步骤。
106.本实施例计算机可读存储介质40可以是u盘、移动硬盘、只读存储器(rom，read-only memory)、随机存取存储器(ram，random access memory)、磁碟或者光盘等可以存储程序数据41的介质，或者也可以为存储有该程序数据41的服务器，该服务器可将存储的程序数据41发送给其他设备运行，或者也可以自运行该存储的程序数据41。
107.该实施例的具体实施方式可参考上述实施例的实施过程，在此不再赘述。
108.在本技术所提供的几个实施例中，应该理解的，所揭露的方法和装置，可以通过其它的方式实现。例如，以上所描述的装置实施方式仅仅是示意性的，例如，模块或单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，装置或单元的间接耦合或通信连接，可以是电性、机械或其它的形式。
109.作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的
部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施方式方案的目的。
110.另外，在本技术各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。
111.集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读存储介质中，该计算机可读存储介质是一种计算机可读取存储介质。基于这样的理解，本技术的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的全部或部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台电子设备(可以是个人计算机，服务器，或者网络设备等)或处理器(processor)执行本技术各个实施方式方法的全部或部分步骤。
112.显然，本领域的技术人员应该明白，上述的本技术的各模块或各步骤可以用通用的计算装置来实现，它们可以集中在单个的计算装置上，或者分布在多个计算装置所组成的网络上，可选地，它们可以用计算装置可执行的程序代码来实现，从而，可以将它们存储在计算机可读存储介质中由计算装置来执行，或者将它们分别制作成各个集成电路模块，或者将它们中的多个模块或步骤制作成单个集成电路模块来实现。这样，本技术不限制于任何特定的硬件和软件结合。
113.以上所述仅为本技术的实施例，并非因此限制本技术的专利范围，凡是利用本技术说明书及附图内容所作的等效结构或等效流程变换，或直接或间接运用在其他相关的技术领域，均同理包括在本技术的专利保护范围内。