测试方法和装置与流程

本发明涉及计算机测试技术领域，尤其涉及一种测试方法和装置。

背景技术：

随着计算机测试技术的飞速发展，在计算机程序测试和开发中，特别是敏捷开发管理方式下，为满足用户需求而要求周期缩短，程序代码、测试用例和测试脚本规模增长速度提升很快。为了提升测试用例使用效率，对于测试用例抽选、调整执行顺序的方法，相关人员做了很多的研究工作，研究的假设前提是测试用例是完备的，测试用例完备性对于测试结果有非常大的影响。

无论测试用例设计如何完备，应用程序版本发布商用之后，总是会有客户在使用过程中发现影响使用的缺陷，一般这类缺陷称为外场缺陷。而这些故障在系统测试中并没有被挖掘出来，并且在后续版本发布中有一定的再现概率，应用程序的版本分支越多，这种现象会越明显。这种情况，说明已有测试用例存在缺失或不足。

需求变更和新需求的出现往往是缺陷引入一个重要因素，会引入测试用例相应变化。测试用例对于需求变更没有覆盖，程序出现缺陷的概率将会增大。在测试前评估测试用例对需求变更的覆盖情况是非常重要的。本专利将需求变更和新需求统一用需求变更表示。

另外，在程序功能没有变化的前提下，代码重构在一定概率上会引入程序缺陷，测试用例可能需要做相应的变更，以适应代码重构。

但是，目前常用的测试方法中，没有进行测试用例完备性评估和采用测试用例分层排序的方法，因此存在测试效率不高的问题。

技术实现要素：

本发明提供一种测试方法和装置。用于解决现有技术的测试效率不高，用于提升测试效率。

为达上述目的，一方面，本发明提供一种测试方法，包括：

获取与测试项目对应的测试用例，建立测试用例表；其中，每个测试项目至少有一条测试用例与之对应；

将所述测试用例表中不同测试项目对应的测试用例分别分配到不同优先级的层中，进行排序，建立测试用例执行顺序表；

根据所述测试用例执行顺序表，进行测试。

进一步，所述测试项目至少包括以下项目中一项：

外场缺陷、内部缺陷，需求变更、代码重构。

进一步，在对获取的测试用例进行排序之前，还包括对测试用例完备性进行评估，具体包括：

判断每个测试项目是否在所述测试用例表中都有与之对应的测试用例，如果是，则执行后续的测试用例排序操作；如果否，则生成与之对应的测试用例，并将生成的测试用例加入所述测试用例表中。

进一步，通过软件配置管理SCM触发测试用例完备性评估。

进一步，将所述测试用例表中不同测试项目对应的测试用例分别分配到不同优先级的层中，，具体包括：

外场缺陷和内部缺陷对应的测试用例设置为第一层；需求变更对应的测试用例设置为第二层；代码重构对应的测试用例设置为第三层；剩余的测试用例设置为第四层；第一层到第四层优先级逐渐降低。

进一步，第一层中的外场缺陷对应的测试用例利用如下规则进行排序：

获取每个外场缺陷的故障解决时间至当前时间的时长T；

对于T大于等于Ts的外场缺陷，则不再执行该外场缺陷对应的测试用例； Ts为预先设置的时长阈值；

对于T小于Ts的外场缺陷，则按照1/T的大小，对各个外场缺陷对应的测试用例进行排序；同一外场缺陷对应多个测试用例时，进行随机排序或按照编号排序。

进一步，第一层中的内部缺陷对应的测试用例利用如下规则进行排序：

按照内部缺陷对应的优先级进行排序；其中同等级内部缺陷对应多个测试用例时，进行随机排序或按照编号排序。

进一步，第二层的需求变更对应的测试用例利用如下规则进行排序：

利用Si值对需求变更对应的测试用例进行排序，同一需求变更对应的测试用例有多个时，进行随机排序或按照编号排序；

其中，Si＝Li×Ci/Cavg；

Li表示第i个需求的优先级；Ci表示第i需求变更代码圈复杂度，M为变更需求的总数量，Cavg是平均复杂度。

进一步，第三层重构代码对应的测试用例的排序方法与第二层一致。

另一方面，本发明提供一种测试装置，包括：

获取模块，用于获取与测试项目对应的测试用例，建立测试用例表；其中，每个测试项目至少有一条测试用例与之对应；

排序模块，用于将所述测试用例表中不同测试项目对应的测试用例分别分配到不同优先级的层中，进行排序，建立测试用例执行顺序表；

测试模块，用于根据所述测试用例执行顺序表，进行测试。

进一步，所述获取模块还包括：

在对获取的测试用例进行排序之前，对测试用例完备性进行评估，具体为：判断每个测试项目是否在所述测试用例表中都有与之对应的测试用例，如果是，则执行后续的测试用例排序操作；如果否，则生成与之对应的测试用例，并将生成的测试用例加入所述测试用例表中；

其中，所述测试项目至少包括以下项目中一项：外场缺陷、内部缺陷，需 求变更、代码重构。

进一步，所述排序模块还用于：

将外场缺陷和内部缺陷对应的测试用例设置为第一层；将需求变更对应的测试用例设置为第二层；将代码重构对应的测试用例设置为第三层；将剩余的测试用例设置为第四层；第一层到第四层优先级逐渐降低。

进一步，所述排序模块对第一层中的外场缺陷对应的测试用例利用如下规则进行排序：

获取每个外场缺陷的故障解决时间至当前时间的时长T；

对于T大于等于Ts的外场缺陷，则不再执行该外场缺陷对应的测试用例；Ts为预先设置的时长阈值；

对于T小于Ts的外场缺陷，则按照1/T的大小，对各个外场缺陷对应的测试用例进行排序；同一外场缺陷对应多个测试用例时，进行随机排序或按照编号排序。

进一步，所述排序模块对第一层中的内部缺陷对应的测试用例利用如下规则进行排序：

按照内部缺陷对应的优先级进行排序；其中同等级内部缺陷对应多个测试用例时，进行随机排序或按照编号排序。

进一步，所述排序模块对第二层的需求变更对应的测试用例利用如下规则进行排序：

利用Si值对需求变更对应的测试用例进行排序，同一需求变更对应的测试用例有多个时，进行随机排序或按照编号排序；

其中，Si＝Li×Ci/Cavg；

Li表示第i个需求的优先级；Ci表示第i需求变更代码圈复杂度，M为变更需求的总数量，Cavg是平均复杂度。

进一步，所述排序模块对第三层重构代码对应的测试用例的排序规则与第二层一致。

采用上述技术方案，本发明具有下列优点：

本发明通过对测试用例进行排序，突出了测试重点，能够尽早发现软件中存在缺陷，提升测试效率，避免外场缺陷再次出现，一定程度上提升了客户满意度。

附图说明

图1为本发明实施例中一种测试方法的流程图；

图2为本发明实施例中一种测试装置的结构示意图；

图3为本发明涉及的实施例1的测试用例分层排序流程图；

图4为本发明涉及的实施例1中测试用例管理库与数据池关联示意图；

图5为本发明涉及的实施例2中基于触发机制的测试用例完备性评估流程图。

具体实施方式

首先，本专利对以下实施例中涉及的专业术语进行解释：

需求变更：指在签订了项目或程序开发协议后，在完成交付之前，客户提出的对项目或者程序的功能或非功能性的更改要求。本专利将新增需求和需求变更都统称为需求变更。

缺陷：为计算机应用程序、程序或软件中存在的某种破坏其正常运行能力的问题、错误。

外场缺陷：应用程序商用之后，由客户和维护人员发现影响程序使用功能的缺陷。

内部缺陷：程序商用前由测试人员或者脚本发现的程序缺陷。

软件配置管理(Software Configuration Management，简称为SCM)：是一种标识、组织和控制修改的技术，在专利中是软件代码管理工具的统称，缩写为SCM。

如图1所示，为本发明实施例涉及一种测试方法，包括：

步骤S101，获取与测试项目对应的测试用例，建立测试用例表；其中，每个测试项目至少有一条测试用例与之对应。

本步骤中，测试项目至少包括以下项目中一项：外场缺陷、内部缺陷，需求变更、代码重构。由于不同的项目，必须具备与之对应的测试用例，因此，首先需要对测试用例进行完备性评估。

外场缺陷是版本发布后，在商用网络使用过程中客户发现的问题，一般会影响客户使用，但是在系统测试中并没有被测试发现，可通过缺陷管理系统进行管理。

内部缺陷可不作为测试用例完备性的评估，因为内部缺陷是已有测试用例执行后发现缺陷，对其进行完备性评估意义比较小。但是上次版本测试发现内部缺陷的测试用例再次执行意义非常大，修复缺陷会导致代码变更，对应测试用例在评估过程中可以筛选出来。

需求变更可以通过需求管理系统进行跟踪，代码重构实际上属于需求重新实现，也可纳入需求管理系统进行跟踪。

将缺陷管理系统和需求管理系统提供接口，形成数据池，数据池数据和测试用例建立一种1：N的映射关系，即1条需求数据或者外场缺陷至少有1条测试用例与之对应，在测试用例管理系统对设置参数关联需求号、故障号。

测试用例评估过程可以由SCM触发，或者其他方式触发。获取测试用例管理系统和数据池数据以及SCM提供软件变更相关数据，通过评估外场缺陷、需求变更、代码重构(根据需求)对应测试用例情况，生成评估结果。评估结果主要是用来说明测试用例完备性的。如果评估结果中指出，缺少测试用例，即：一个或多个测试项目没有选出与之对应的测试用例，则需要人工或者通过脚本生成相应的测试用例，重新开始上述评估。如果评估结果中指出，每个测试项目都有测试用例与之对应，即：测试用例是完备的，则生成一张包括测试用例与外场缺陷、需求变更、代码重构、内部缺陷对应关系的测试用例表。

步骤S102，将所述测试用例表中不同测试项目对应的测试用例分别分配到不同优先级的层中，进行排序，建立测试用例执行顺序表。

本步骤中，对上一步得到的测试用例表中的测试用例设置分层优先级，外场缺陷和内部缺陷对应的测试用例优先级最高，设置为第一层，需求变更对应测试用例优先级设置为第二层，代码重构对应测试用例设置为第三层；剩余测试用例设置为第四层。

第一层是缺陷对应的测试用例。外场缺陷对应测试用例分可以通过如下规则进行排序：

获取每个外场缺陷的故障解决时间至当前时间的时长T；

对于T大于等于Ts的外场缺陷，则不再执行该外场缺陷对应的测试用例；Ts为预先设置的时长阈值。T越大，表示外场缺陷距离现在的时间越长，其重要性越低，例如，T＝5，表示该缺陷是五年前发现的外场缺陷，可能版本更迭早已不存在，或早已解决。因此，对于过早的外场缺陷可以不用进行测试。

当对于T小于Ts的外场缺陷，则按照1/T的大小，对各个外场缺陷对应的测试用例进行排序；同一外场缺陷对应多个测试用例时，进行随机排序或按照编号排序。

上一版本发现内部缺陷对应的测试用例，可以根据内部缺陷的优先级进行排序，一般内部缺陷有4个等级：致命、严重、一般、轻微。对于同等级测试用例可以随机排序，也可以按照编号排序。

第二层是需求变更对应的测试用例，根据需求的优先级和变更规模进行细分。其中需求的优先级在需求创立之初就已经确定了，变更规模通过代码变更规模进行评估。假设优先级用L表示，L的取值范围是和需求总规模有关，比如可以取1～999，Li表示第i个需求的优先级；变更规模可以用变更代码圈复杂度用C表示，Ci表示第i需求变更代码圈复杂度，Cavg是平均复杂度。

其中，M变更需求数量，根据上述公式求出平均复杂度。

Si＝Li×Ci/Cavg (2)

其中，Si值用于对需求变更对应测试用例的优先级进行排序，单个需求对应的测试用例可能有多个，为了简化处理，根据测试用例原始编号进行排序，或者随机排序。

第三层重构代码对应测试用例的排序规则可以采用和第二层需求变更的排序规则相同的规则。

在测试管理系统除了上述筛选出来的用例之外，还存在大量测试用例(第四层的测试用例)，这些测试用例没有代码变更和需求变更对应，但是需要做回归测试，在回归测试中测试用例排序，有很多已有方法，比如对需求优先级、缺陷检测、复杂度等参数加权求和进行排序。这里不再赘述。

步骤S103，根据所述测试用例执行顺序表，进行测试。

另外，如图2所示，本发明实施例还涉及一种实现上述方法的测试装置，包括：

获取模块201，用于获取与测试项目对应的测试用例，建立测试用例表；其中，每个测试项目至少有一条测试用例与之对应；

排序模块202，用于将所述测试用例表中不同测试项目对应的测试用例分别分配到不同优先级的层中，排序，建立测试用例执行顺序表；

测试模块203，用于根据所述测试用例执行顺序表，进行测试。

其中，获取模块201还包括：

在对获取的测试用例进行排序之前，对测试用例完备性进行评估，具体为：判断每个测试项目是否在所述测试用例表中都有与之对应的测试用例，如果是，则执行后续的测试用例排序操作；如果否，则生成与之对应的测试用例，并将生成的测试用例加入所述测试用例表中。测试项目至少包括以下项目中一项：外场缺陷、内部缺陷，需求变更、代码重构。

排序模块202还用于：

将外场缺陷和内部缺陷对应的测试用例设置为第一层；将需求变更对应的 测试用例设置为第二层；将代码重构对应的测试用例设置为第三层；将剩余的测试用例设置为第四层；第一层到第四层优先级逐渐降低。

排序模块202对第一层中的外场缺陷对应的测试用例利用如下规则进行排序：

获取每个外场缺陷的故障解决时间至当前时间的时长T；

对于T大于等于Ts的外场缺陷，则不再执行该外场缺陷对应的测试用例；Ts为预先设置的时长阈值；

对于T小于Ts的外场缺陷，则按照1/T的大小，对各个外场缺陷对应的测试用例进行排序；同一外场缺陷对应多个测试用例时，进行随机排序或按照编号排序。

排序模块202对第一层中的内部缺陷对应的测试用例利用如下规则进行排序：

按照内部缺陷对应的优先级进行排序；其中同等级内部缺陷对应多个测试用例时，进行随机排序或按照编号排序。

排序模块202对第二层的需求变更对应的测试用例利用如下规则进行排序：

利用Si值对需求变更对应的测试用例进行排序，同一需求变更对应的测试用例有多个时，进行随机排序或按照编号排序；

其中，Si＝Li×Ci/Cavg；

Li表示第i个需求的优先级；Ci表示第i需求变更代码圈复杂度，M为变更需求的总数量，Cavg是平均复杂度。

排序模块202对第三层重构代码对应的测试用例的排序规则与第二层一致。

由上述实施例可以看出，在测试执行之前加入了测试用例有效评估，提升测试用例完备性；对于缺陷、需求变更、代码重构相关测试用例进行分层排序，突出了测试重点，尽早发现软件中存在缺陷，提升测试效率；避免外场缺陷再次出现，一定程度上会提升客户满意度。

下面，给出两个具体实施例，进行详细说明。

实施例1

如图3所示，版本发布测试后，触发对用例的评估过程。数据池对缺陷(外场缺陷和内部缺陷)、需求变更、代码重构对应需求的信息统一管理，池中数据参数有编号、变更类型、时间、软件变更合入版本号等参数。外场缺陷、需求变更、代码重构需求、内部缺陷在数据池中遵循相同数据编号规则。通过变更类型区分不同种情况，变更类型通常用数字表示，例如，1-外场缺陷，2-需求变更，3-代码重构，4-内部缺陷。数字在程序处理中比较方便，当然也可以使用其他方式变更类型，在后续处理时效率会有折扣。在软件版本更迭中，需求变更、代码重构、修正内部缺陷合入哪个版本号，哪个版本才有对应的软件代码变更，

因此根据版本号只选取当前需要测试版本的合入的需求变更、代码重构、内部缺陷，然后进行测试用例关联关系核对。选择外部缺陷可以不和版本关联，只和解决缺陷时间关联。

图4为测试用例管理库与数据池关联示意图，假设当前待测试版本号为100A，在数据池中选择100A版本的“变更类型”为2对应“数据编号”为3和4，通过参数“关联需求”在测试用例管理系统中可以找到对应“测试用例编号”为(3，4，5)对应数据池中编号为3，“测试用例编号”为6对应数据池“数据编号”为4；数据池中编号为1，是外部缺陷，在测试用例对应编号为1。通过这种方式可以对测试用例完备性进行评估，“数据编号”如果在测试用例库中“关联需求”列表中匹配不到，说明测试用例有缺失，则需要把缺少测试用例的“数据编号”作为评估结果输出。如果所有的“数据编号”都能够匹配到，那么需要将对应测试用例信息筛选出来作为评估结果输出，“数据编号”评估结果为空。

在判断测试用例是否完备时，首先是根据“数据编号”评估结果是否为空进行判断，如果不为空，则输出“数据编号”，通过人工或者脚本补充相应的测试用例；如果为空，则测试用例完备，将筛选出来的测试用例表传递给排序模块。

排序模块将测试用例分为4层，第一层为外场缺陷对应的测试用例，第二层 为需求变更对应的测试用例，第三层为代码重构对应的测试用例，第四层为前三层没有包含的回归测试用例。前三层根据之前实施例描述的方法进行逐层调整测试用例优先级，进行排序。第四层级别最低，可以根据已有方法进行排序。经过排序后，输出一个分层的测试用例执行顺序表。

根据测试用例执行顺序表，可以人工或通过脚本自动执行测试。

该实施例中，测试用例和需求、缺陷关联表，可以实现高效地简单评估，做到所有变更都有测试用例去覆盖。

实施例2

实施例2所述方法与实施例1大致相同，区别在于，如图5所示，实施例2通过SCM触发测试用例评估，参考图5，当软件代码变更通过SCM提交时，比如通过svn(Subversion)软件(一种版本管理软件)提交代码变更后，触发调用自定义脚本，发起测试用例评估，同时将代码变更信息(比如变更代码圈复杂度、变更代码行数、版本号)和数据池中对应“数据编号”传递给测试用例评估模块。然后测试用例评估模块根据数据池“数据编号”在测试用例管理系统中查找对应的测试用例，如果没有找到，则任务管理模块中生成一条待处理任务，触发邮件通知相关人员完成补充用例任务。用例补充完成之后，相关人员可以在任务模块中将待处理任务设置为完成，任务模块自动触发测试用例再评估过程，如果评估通过，则将测试用例添加到待测用例列表中。

SCM的版本发布测试过程触发对外场缺陷的测试用例评估过程，待评估通过后，会进入测试用例排序流程中，这个流程同实施例1相同，就不在赘述。

实施例2和实施例1差别就在于实施例2的评估过程在于代码变更自动触发，可以做到动态评估，实时跟踪代码实现、需求变更和测试用例对应关系，更加能适应自动化测试或者大型项目管理测试。

这里再对测试用例完备性评估说明一下，测试分为黑盒测试和白盒测试，黑盒测试更关注与对软件需求的功能测试，实施粒度大小没有统一标准，很难去衡量测试用例有效性，只能在用例设计通过评审，提升用例的有效性，因此 对黑盒测试，建议用测试用例对需求覆盖情况进行完备性评估，即所有的需求都有对应的测试用例。白盒测试有很多种算法，比如路径覆盖、循环覆盖等，其精细度比较高，对于白盒测试用例完备性评估，可以建立在统计学基础上进行评估，比如代码有3条路径，那么测试用例条目要把3条路径覆盖全，至少要有3测试用例，本实施中，规则根据不同应用可以自定义。实施例2中的评估环节做修改，可以适应不同的测试要求。

通过具体实施方式的说明，应当可对本发明为达成预定目的所采取的技术手段及功效得以更加深入且具体的了解，然而所附图示仅是提供参考与说明之用，并非用来对本发明加以限制。