CN104331366A - 一种测试用例设计效率提升方法及系统 - Google Patents

Abstract

本发明涉及一种测试用例设计效率提升方法及系统，包括以下步骤：对业务系统按照业务类型分为多个业务大类，再将每个业务大类分别分类包括多个业务小类，每个业务小类包括多个业务模块；获取为每个业务模块设计的若干测试用例，每个测试用例分别包括若干测试属性；利用用例管理工具，根据每个测试用例对应的业务大类、业务小类，以目录的形式搭建公共用例库；根据测试条件选择测试用例为待测试的测试模块进行测试；当任一测试用例被修改时，更新公共用例库。本发明对于具体的测试需求任务，只需要调用该需求涉及的模块所对应的公共测试用例库中的测试用例，不需要再重复设计测试用例，大大提高了测试工作的效率。

Description

一种测试用例设计效率提升方法及系统

技术领域

本发明涉及软件测试领域，特别涉及一种测试用例涉及效率提升方法及系统。

背景技术

BOSS系统涉及很多关键模块，每个模块牵涉到各种品牌服务号码和测试资源以及各种复杂的业务限制条件，如果针对每个具体测试需求或者测试任务每个测试工程师去针对业务模块设计测试用例往往会对同一个模块进行多次重复测试用例设计，而且每个工程师对于测试用例设计缺乏统一的思路和标准，设计出的测试用例也是相对发散和难于维护的，占用了大量的测试用例设计时间，降低了用例设计的效率，对于每个测试用例而言十分的分散和不可复用，因此这种用例设计方式会大大降低测试用例设计的深入性、覆盖度以及极大降低测试用例设计的效率。

发明内容

本发明所要解决的技术问题是提供一种减少测试用例设计时间、提高测试用例设计效率的测试用例涉及效率提升方法及系统。

本发明解决上述技术问题的技术方案如下：一种测试用例设计效率提升方法，包括以下步骤：

步骤1：对业务系统按照业务类型分为多个业务大类，再将每个业务大类分别进行分类，每个业务大类包括多个业务小类，每个业务小类包括多个业务模块；

步骤2：获取为每个业务模块设计的若干测试用例，每个测试用例分别包括若干测试属性；

步骤3：利用用例管理工具，根据每个测试用例对应的业务大类、业务小类，以目录的形式搭建公共用例库；

步骤4：根据测试条件选择测试用例为待测试的测试模块进行测试；

步骤5：当任一测试用例被修改时，更新公共用例库。

本发明的有益效果是：本发明引入了公共用例库的概念，针对BOSS系统重要模块进行专人测试用例设计和维护，每个人在设计和维护各自负责的模块测试用例时都按照统一的标准和模式进行测试用例设计，对于需求的变动只需要分解到各个模块中，对于各个模块的公共测试用例库进行维护，对于具体的测试需求任务，只需要调用该需求涉及的模块所对应的公共测试用例库中的测试用例，不需要再重复设计测试用例，大大提高了测试工作的效率。

在上述技术方案的基础上，本发明还可以做如下改进。

进一步，每个业务模块对应至少三个测试用例。

进一步，每个测试用例分别包括前置条件信息、数据准备信息、操作步骤信息、数据验证信息和日志监控信息。

进一步，所述前置条件信息，用于声明启动当前测试用例之前系统必须满足的条件；

所述数据准备信息，包含SQL语句执行数据库及SQL语句描述，用于为测试用例的启动提供数据；

所述操作步骤信息，用于描述步骤间的连接关系；

所述数据验证信息，用于提取测试用例输出的测试数据并进行验证；

所述日志监控信息，用于监控前台日志和后台日志，同时查看测试用例的执行结果。

进一步，一种测试用例设计效率提升系统，包括分类模块，获取模块，搭建模块，测试模块和更新模块；

所述分类模块，用于对业务系统按照业务类型分为多个业务大类，再将每个业务大类分别进行分类，每个业务大类包括多个业务小类，每个业务小类包括多个业务模块；

所述获取模块，用于获取为每个业务模块设计的若干测试用例，每个测试用例分别包括若干测试属性；

所述搭建模块，用于利用用例管理工具，根据每个测试用例对应的业务大类、业务小类，以目录的形式搭建公共用例库；

所述测试模块，用于根据测试条件选择测试用例为待测试的测试模块进行测试；

所述更新模块，用于当任一测试用例被修改时，更新公共用例库。

进一步，每个由分类模块得到的业务模块对应至少三个测试用例。

进一步，每个获取模块设计的测试用例分别包括前置条件信息、数据准备信息、操作步骤信息、数据验证信息和日志监控信息。

进一步，所述前置条件信息，用于声明启动当前测试用例之前系统必须满足的条件；

所述数据准备信息，包含SQL语句执行数据库及SQL语句描述，用于为测试用例的启动提供源数据；

所述操作步骤信息，用于描述步骤间的连接关系；

所述数据验证信息，用于提取测试用例输出的测试数据并进行验证；

所述日志监控信息，用于监控前台日志和后台日志，同时查看测试用例的执行结果。

附图说明

图1为本发明方法步骤流程图；

图2为本发明装置结构图。

附图中，各标号所代表的部件列表如下：

1、分类模块，2、获取模块，3、搭建模块，4、测试模块，5、更新模块。

具体实施方式

以下结合附图对本发明的原理和特征进行描述，所举实例只用于解释本发明，并非用于限定本发明的范围。

如图1所示，为本发明方法步骤流程图；图2为本发明装置结构图。

实施例1

一种测试用例设计效率提升方法，包括以下步骤：

步骤1：对业务系统按照业务类型分为多个业务大类，再将每个业务大类分别进行分类，每个业务大类包括多个业务小类，每个业务小类包括多个业务模块；

步骤2：获取为每个业务模块设计的若干测试用例，每个测试用例分别包括若干测试属性；

步骤3：利用用例管理工具，根据每个测试用例对应的业务大类、业务小类，以目录的形式搭建公共用例库；

步骤4：根据测试条件选择测试用例为待测试的测试模块进行测试；

步骤5：当任一测试用例被修改时，更新公共用例库。

每个业务模块对应至少三个测试用例。每个测试用例分别包括前置条件信息、数据准备信息、操作步骤信息、数据验证信息和日志监控信息。

所述前置条件信息，用于声明启动当前测试用例之前系统必须满足的条件；用例的前置条件(precondition即前置条件信息)声明了启动该用例之前系统必须满足的条件。通常，前置条件是指该条件已经通过其他用例的执行进行了设置。最简单的例子，在论坛里发贴子用例的前置条件是用户登录。往往层次高的用例中前后两个没有可选路径的步骤，降低一级层次后，两个步骤独立为两个用例，那么前一个用例就是后一个用例的前置条件。如在“病人看病”用例里，第一步骤是“挂号”，第二步骤是“去诊室见医生就诊”，那么“在去诊室就诊”用例里，“挂号”就是其前置条件。以BOSS系统1121开户冲正模块为例，其业务实现类测试用例的前置条件为服务号码资源必须已经通过1104开户模块开户成功。前置条件的描述信息可以帮助测试用例执行者对模块业务的熟悉和了解。

所述数据准备信息，包含SQL语句执行数据库及SQL语句描述，用于为测试用例的启动提供数据；数据准备信息包含两个元素：a、SQL语句执行数据库(CRM库CEN库ACC库以及A/B/C三个大区)；b、SQL语句描述(需要定位到具体字段值)；

所述操作步骤信息，用于描述步骤间的连接关系；操作步骤信息的设计以简单易读作为基准，步骤与步骤之间采用”→”进行连接，预期结果描述信息需要作为页面级验证依据；

所述数据验证信息，用于提取测试用例输出的测试数据并进行验证；数据验证信息作为业务办理成功后数据库层面的验证依据，SQL语句的查询条件和查询字段值以变量的形式进行描述。

例子：SELECT ID_NO FROM DCUSTMSGNG WHERE PHONE_NO＝‘$PHONE_NO’AND ROWNUM<＝20；

备注：$PHONE_NO即为数据准备中SQL语句提取出来的测试数据。

所述日志监控信息，用于监控前台日志和后台日志，同时查看测试用例的执行结果。

前台和后台日志都需要进行监控，通过查看日志更好的理解代码实现，同时查看该测试用例在测试实现实验室的执行实际结果可以查看日志记录的系统时间，保障对测试用例执行的跟踪和监控。

备注：如果该需求开发人员修改的是后台C程序，则测试工程师在执行测试用例时需要监控后台服务日志；如果开发人员修改的是前台JSP，测试工程师在执行测试用例时应该更多的关注前台WEB日志。

一种测试用例设计效率提升系统，包括分类模块1，获取模块2，搭建模块3，测试模块4和更新模块5；

所述分类模块1，用于对业务系统按照业务类型分为多个业务大类，再将每个业务大类分别进行分类，每个业务大类包括多个业务小类，每个业务小类包括多个业务模块；

所述获取模块2，用于获取为每个业务模块设计的若干测试用例，每个测试用例分别包括若干测试属性；

所述搭建模块3，用于利用用例管理工具，根据每个测试用例对应的业务大类、业务小类，以目录的形式搭建公共用例库；

所述测试模块4，用于根据测试条件选择测试用例为待测试的测试模块进行测试；

所述更新模块5，用于当任一测试用例被修改时，更新公共用例库。

每个由分类模块1得到的业务模块对应至少三个测试用例。

每个获取模块2设计的测试用例分别包括前置条件信息、数据准备信息、操作步骤信息、数据验证信息和日志监控信息。

所述前置条件信息，用于声明启动当前测试用例之前系统必须满足的条件；

所述数据准备信息，包含SQL语句执行数据库及SQL语句描述，用于为测试用例的启动提供源数据；

所述操作步骤信息，用于描述步骤间的连接关系；

所述数据验证信息，用于提取测试用例输出的测试数据并进行验证；

所述日志监控信息，用于监控前台日志和后台日志，同时查看测试用例的执行结果。

所述设计大类包括：

1.1业务实现类；

业务实现类测试用例是针对模块对业务功能的实现来设计，更多的是站在终端用户的角度进行业务的分析，常见的功能实现有业务开通，业务变更，业务取消等，在设计此类测试用例时我们采取的设计方法是等价类划分和正交实验法，更多的关注于业务的实现，从正常流去实现测试用例的设计。

1.2业务限制类；

业务限制类测试用例是针对业务场景中特殊的用户群或者特殊的业务场景进行测试用例设计，更多的是关注于系统对业务限制条件的满足情况，该类测试用例的设计需要对业务场景的熟悉和实现代码的梳理，运用的设计方法是判定覆盖和路径覆盖。

1.3异常抛出类；

异常抛出类是从异常流的角度考虑系统的容错功能，用例设计人员需要从逆向思维对测试用例进行设计，设计此类用例的方法是边界值分析，对输入框的各种可能输入进行校验，防止异常输入导致程序异常；程序定义的变量长度和数据表中字段值长度进行验证，防止插入表数据溢出。

1.4关联模块类；

关联模块类用例主要是针对多个模块公用一个后台程序，或者是业务实现的上下游关系进行测试用例设计，保障相关模块业务实现的正确性和一致性。

通过此方案，能够实现如下的功能：

1、BOSS系统按照业务大类、模块进行测试用例分类；

2、直接从用例库拷贝现有有效测试用例进行新需求测试覆盖，提高测试用例复用度；

3、专人对专属业务模块用例库进行用例维护，提高用例覆盖度。

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

Claims (8)

1.一种测试用例设计效率提升方法，其特征在于，包括以下步骤：

步骤1：对业务系统按照业务类型分为多个业务大类，再将每个业务大类分别进行分类，每个业务大类包括多个业务小类，每个业务小类包括多个业务模块；

步骤2：获取为每个业务模块设计的若干测试用例，每个测试用例分别包括若干测试属性；

步骤3：利用用例管理工具，根据每个测试用例对应的业务大类、业务小类，以目录的形式搭建公共用例库；

步骤4：根据测试条件选择测试用例为待测试的测试模块进行测试；

步骤5：当任一测试用例被修改时，更新公共用例库。

2.根据权利要求1所述的测试用例设计效率提升方法，其特征在于：每个业务模块对应至少三个测试用例。

3.根据权利要求1所述的测试用例设计效率提升方法，其特征在于：每个测试用例分别包括前置条件信息、数据准备信息、操作步骤信息、数据验证信息和日志监控信息。

4.根据权利要求3所述的测试用例设计效率提升方法，其特征在于：

所述前置条件信息，用于声明启动当前测试用例之前系统必须满足的条件；

所述数据准备信息，包含SQL语句执行数据库及SQL语句描述，用于为测试用例的启动提供数据；

所述操作步骤信息，用于描述步骤间的连接关系；

所述数据验证信息，用于提取测试用例输出的测试数据并进行验证；

所述日志监控信息，用于监控前台日志和后台日志，同时查看测试用例的执行结果。

5.一种测试用例设计效率提升系统，其特征在于：包括分类模块(1)，获取模块(2)，搭建模块(3)，测试模块(4)和更新模块(5)；

所述分类模块(1)，用于对业务系统按照业务类型分为多个业务大类，再将每个业务大类分别进行分类，每个业务大类包括多个业务小类，每个业务小类包括多个业务模块；

所述获取模块(2)，用于获取为每个业务模块设计的若干测试用例，每个测试用例分别包括若干测试属性；

所述搭建模块(3)，用于利用用例管理工具，根据每个测试用例对应的业务大类、业务小类，以目录的形式搭建公共用例库；

所述测试模块(4)，用于根据测试条件选择测试用例为待测试的测试模块进行测试；

所述更新模块(5)，用于当任一测试用例被修改时，更新公共用例库。

6.根据权利要求5所述的测试用例设计效率提升系统，其特征在于：每个由分类模块(1)得到的业务模块对应至少三个测试用例。

7.根据权利要求5所述的测试用例设计效率提升系统，其特征在于：每个获取模块(2)设计的测试用例分别包括前置条件信息、数据准备信息、操作步骤信息、数据验证信息和日志监控信息。

8.根据权利要求7所述的测试用例设计效率提升系统，其特征在于：

所述前置条件信息，用于声明启动当前测试用例之前系统必须满足的条件；

所述数据准备信息，包含SQL语句执行数据库及SQL语句描述，用于为测试用例的启动提供源数据；

所述操作步骤信息，用于描述步骤间的连接关系；

所述数据验证信息，用于提取测试用例输出的测试数据并进行验证；

所述日志监控信息，用于监控前台日志和后台日志，同时查看测试用例的执行结果。