CN103176896A

CN103176896A - 一种测试用例的生成方法及装置

Info

Publication number: CN103176896A
Application number: CN2011104395035A
Authority: CN
Inventors: 陈逊; 曾建
Original assignee: Alibaba Group Holding Ltd
Current assignee: Alibaba Group Holding Ltd
Priority date: 2011-12-23
Filing date: 2011-12-23
Publication date: 2013-06-26
Anticipated expiration: 2031-12-23
Also published as: HK1182789A1; CN103176896B

Abstract

本申请实施例提供了一种测试用例的生成方法及装置，其中，该方法包括：依次扫描思维导图中的各逻辑事务节点和非逻辑事务节点；对于所扫描的非逻辑事务节点，生成包含测试步骤的测试用例；对于所扫描的逻辑事务节点，根据该逻辑事务节点预先设置的输入DET和输出DET，生成包含输入条件和预期结果的测试用例。本申请实施例利用可清晰地展现各逻辑事务需求架构的思维导图，对其进行解析，并根据各逻辑事务中输入和输出之间的关联关系，能够生成能够全面反映软件需求关系的测试用例，对于包含测试步骤形式的测试用例，可以通过思维导图转化生成，所生成的测试用例形式多样，满足了软件测试用例的需要。

Description

一种测试用例的生成方法及装置

技术领域

本申请涉及软件测试领域，尤其涉及一种测试用例的生成方法及装置。

背景技术

不同于传统的应用软件，互联网应用软件多使用浏览器/服务器(Browser/Server，BS)结构，模型-视图-控制MVC的框架模型，这种框架模型将互联网应用定义为3个部分，每个部分负责完成特定的任务：

Model模型：程序员编写程序应有的功能(实现算法等等)、数据库专家进行数据管理和数据库设计(可以实现具体的功能)。

View视图：界面设计人员进行图形界面设计。

Controller控制器：负责转发请求，对请求进行处理。

互联网应用软件的MVC这种开发模型，有庞大的数据库作为支撑，需求和用户界面多变，测试工程也变得浩繁复杂，并且互联网应用软件需要快速地面对大量新需求和需求变更，使得如何快速编写测试用例实现对应用程序的全面测试，找出应用程序存在的BUG，成为了急待解决的问题。

传统测试用例的编写方式是建立在某种测试系统(如QC，Zephyr，Testlink)上手工编写测试用例，组织测试结构，用这种测试用例的编写方式，所生成的测试用例数量众多，细节零碎，结构五花八门，所生成的测试用例很难清晰地表达出应用程序的需求逻辑，不能很好地满足互联网软件测试的需要。

发明内容

本申请实施例提供了一种测试用例的生成方法及装置，用以解决现有测试用例的生成方法很难清晰地表达出互联网应用程序的需求逻辑，不能很好地满足互联网软件测试的需要的问题。

基于上述问题，本申请实施例提供的一种测试用例的生成方法，包括：

依次扫描思维导图中的各逻辑事务节点和非逻辑事务节点；

对于所扫描的非逻辑事务节点，生成包含测试步骤的测试用例；

对于所扫描的逻辑事务节点，根据该逻辑事务节点预先设置的输入DET和输出DET，生成包含输入条件和预期结果的测试用例。

本申请实施例提供的一种试用例的生成装置，包括：

扫描模块，用于依次扫描思维导图中的各逻辑事务节点和非逻辑事务节点；

第一测试用例生成模块，用于对于所扫描的非逻辑事务节点，生成包含测试步骤的测试用例；

第二测试用例生成模块，用于对于所扫描的逻辑事务节点，根据该逻辑事务节点预先设置的输入DET和输出DET，生成包含输入条件和预期结果的测试用例。

本申请实施例的有益效果包括：

本申请实施例提供的测试用例的生成方法及装置，依次扫描思维导图中的各逻辑事务节点和非逻辑事务节点；对于所扫描的非逻辑事务节点，生成包含测试步骤的测试用例；对于所扫描的逻辑事务节点，根据该逻辑事务节点预先设置的输入DET和输出DET，生成包含输入条件和预期结果的测试用例。本申请实施例利用可清晰地展现各逻辑事务需求架构的思维导图，对其进行解析，并根据各逻辑事务中输入和输出之间的关联关系，生成能够全面反映软件需求关系的测试用例，对于包含测试步骤形式的测试用例，可以通过思维导图转化生成，所生成的测试用例形式多样，满足了软件测试用例的需要，并且，由于采用同样方式对各逻辑事务进行处理得到相应的测试用例，避免了手工编写测试用例所带来的测试用例结构不统一、细节零碎等问题。

附图说明

图1为现有技术中思维导图的结构示意图；

图2为本申请实施例提供的测试用例的生成方法的流程图；

图3为本申请实施例提供的思维导图的一个实例的结构图；

图4为本申请实施例提供的思维导图中输入DET和输出DET的结构图；

图5为本申请实施例提供的测试用例的生成装置的结构图。

具体实施方式

下面结合说明书附图，对本申请实施例提供的一种测试用例的生成方法及装置的具体实施方式进行说明。

本申请实施例提供的一种测试用例的生成方法，基于现有技术中的思维导图生成测试用例，因此，在对本申请实施例提供的测试用例的生成方法进行说明之前，对现有思维导图进行简单说明：

现有思维导图采用树形结构，由一个个节点组成，由根节点散发出一系列的树状节点。思维导图可以清晰地表现各级主题之间的互相隶属以及关联关系，如图1所示是现有技术中电子商务软件的思维导图的目录结构的一个实例，在该实例中，“01点击立即购买”、“02左侧查看宝贝”、......、“06确认订单”是电子商务过程涉及的各个逻辑事务(在电子商务软件中可以是以软件模块方式存在)，每个逻辑事务下级又包含相关的逻辑功能的节点。思维导图可以使用XML格式存储。

本申请实施例在思维导图的基础上，对思维导图中的节点进行扫描，从而将其转换成测试用例，具体地，本申请实施例提供的测试用例的生成方法，如图2所示，包括下述步骤：

S201、依次扫描思维导图中的各逻辑事务节点和非逻辑事务节点；

S202、对于所扫描的非逻辑事务节点，生成包含测试步骤的测试用例；

S203、对于所扫描的逻辑事务节点，根据该逻辑事务节点预先设置的输入输入数据元素类型(Data Element Type，DET)和输出DET，生成包含输入条件和预期结果的测试用例。

上述步骤S202和S203相互独立，并没有严格的时间先后顺序。

在本申请实施例提供的上述测试用例的生成方法的步骤S201～S203之前，还可预先执行下述步骤：

在树形结构的思维导图中，创建各逻辑事务节点及其各下级节点，以及各非逻辑事务节点及其下级节点。

其中，逻辑事务节点即跟软件功能模块相对应的为了实现某项特定事务的节点，非逻辑事务节点，是思维导图中采用测试步骤方式存在的测试用例的节点。

其中，在思维导图中，生成逻辑事务的各下级节点，具体通过下述流程实现：

1、在各逻辑事务节点下创建输入节点、输出节点和实体节点；

2、在输入节点下，对该逻辑事务相关操作进行拆解，分别生成该输入节点的下级节点，并根据所述相关操作输入和输出的关系，在输入节点的下级节点中，分别标识出输入DET以及输出DET；

3、将该逻辑事务的所涉及的实体类型及描述信息写入实体节点中。

以图3所示的思维导图为例说明，首先创建逻辑事务节点：01、点击立即购买，02_左侧查看宝贝简要信息、03_查看收货地址列表、04_管理我的收货地址、05_查看实付款和06_确认订单。创建出的逻辑事务节点可以使用“It：”的前缀标识。

然后在逻辑事务节点下创建其各级下级节点，例如在01点击立即购买创建输入节点、输出节点和实体节点，输入节点的下级节点为点击立即购买这一逻辑事务相关的各项参数条件，其中，与测试点密切相关的各项输入和输出，会被分别标识为DET和输出DET。

例如，在本申请实施例中，输入DET采用“i：”的前缀标识，输出DET用“o：”的前缀标识，从图3中可以看出，在输入节点下，包含若干输入DET例如宝贝id、买家id和卖家id、买家身份、卖家状态和宝贝状态等，还包含若干输出DET，例如“卖家包邮，仅见面交易”、“您没有绑定支付宝，不能购买”、“商品库存不足，无法购买”、“购买数量必须输入整数”等等。输出DET往往是指应用程序给用户提供的所有的提示信息，以文字提示的方式知会用户一个输入DET中可以包含若干输入项，彼此之间使用设定的分隔符例如“，”等分隔，一个输出DET中也可以包含若干输出项，彼此之间也可以使用设定的分隔符分隔。

当然，本申请实施例中，在思维导图中，还可以通过设置例如特定的图形用来标识输入DET和输出DET，具体采用何种图形在此对此不做限定。

之所以在输入节点的下级设置输入DET的同时，还设置有输出DET，是因为：这些输出DET往往是一些异常输出的检查点，例如，在图3所示的例子中，当买家的资金被冻结，那么按照该逻辑事务预先设计的逻辑，其输出结果为“您被冻结不能购买”的否定结果，由于针对软件的测试主要任务是针对这些异常检查点的检查，并且，这些异常输出往往与一定的输入相关度非常高，因此就将其放置在输入节点下。在对思维导图进行处理时，可以根据输入DET和输出DET的关系，生成相应的测试例。

输出节点中往往记录的是该逻辑事务正确输出的检查点，例如各项条件都符合正常条件下，输出“购买成功”，由于这种输出往往不是测试用例所重点关注的，将其放置于输出节点中。

实体(Entity Type)节点中，主要记录该逻辑事务所涉及的实体类型以及相关的描述信息，以图3中的例子来说，实体类型可以包括：卖家、买家、宝贝等实体类型，这些实体类型圈定了该逻辑事务所涉及的对象。实体节点中，还可以包含对于该逻辑事务的一些描述信息。

在思维导图中，创建非逻辑事务节点及其各下级节点，具体通过下述流程实现：

1、按照预先设定的测试用例前缀标识+测试用例优先级+测试用例类型(自动化类型、手动类型等)+测试用例名称的节点生成规则，生成非逻辑事务节点；

2、根据该非逻辑事务节点对应的测试用例的各个步骤，在非逻辑事务节点下分别生成与各个测试步骤对应的下级节点，各下级节点的标识中包含对应测试步骤的执行顺序和测试步骤的内容。

非逻辑事务节点的标识，采用“TC_”作为前缀，如图3中的“TC_P0_A_交易主流程”的非逻辑事务节点，该非逻辑事务节点的属性值之间采用下划线进行分隔，此非逻辑事务节点对应的测试用例的名称为“交易主流程”，其优先级为P0级，类型为A(即自动化类型)。

非逻辑事务节点的下级节点，是该测试用例的各个测试步骤对应的节点，每个下级节点的标识，包含该下级节点对应的测试步骤的执行顺序和测试步骤内容。

上述对思维导图的处理过程，在具体实施时，可以使用现有的思维导图软件例如freemind或者xmind实现。

在经过在树形结构的思维导图中创建各逻辑事务节点及其各下级节点，以及各非逻辑事务节点及其下级节点的步骤之后，上述图2的步骤S201～S203在对思维导图进行处理过程中，会对思维导图中逻辑事务节点的输入DET和输出DET以及非逻辑事务节点进行解析，得到对应的测试用例。

具体来说，本申请实施例提供的测试用例的生成方法中的步骤S202，包括下述步骤：

遍历所扫描的逻辑事务节点中的每个输入DET，在遍历每个输入DET的过程中，按照下述5种情况的描述进行处理：

第一种情况，当输入DET的父级节点为除了输入DET和输出DET之外的节点时，将输入DET的所有父节点分别生成对应的测试用例树结构；

第二种情况，当输入DET仅有一个子节点，且该子节点为输出DET时，将输入DET和输出DET分别作为输入条件和预期结果，生成单个测试用例；

第三种情况，当输入DET没有子节点时，不做任何处理；

第四种情况，当存在多个输入DET和一个输出DET在同一个节点下，将多个输入DET作为输入条件，将输出DET作为预期结果，生成判定表用例；

第五种情况，当一个输入DET的下级有多个输出DET，则按照每个输出DET，分别生成包含该输入DET作为数据条件，各输出DET作为预期结果的测试数据驱动模式的测试用例。

如图4所示，在买家状态的输入DET下，包括四个输入DET：“买家被处罚”、“买家被冻结”、“买家被CC”和“买家被删除”，其中，“买家被处罚”的下级还包括一个输出DET：“提示用户被处罚不能购买”，“买家被冻结”的下级还包括一个输出DET：“提示用户被冻结不能购买”，“买家被删除”的下级还包括一个输出DET：“提示用户被删除不能购买”，“买家被CC”的下级还包括一个输出DET：“提示用户被CC不能购买”。那么按照上述第二种情况，会分别生成四个单个测试用例如下表1：

表1

测试用例名称	测试结果	期望结果
			买家被处罚	？未执行	提示用户被处罚不能购买
买家被冻结	？未执行	提示用户被冻结不能购买
			买家被删除	？未执行	提示用户被删除不能购买
买家被CC	？未执行	提示用户被CC不能购买

又例如页面表单的输入框对应的输入DET，会产生例如“不能为空”、“不能超过20字符”，在思维导图中，这样的输入DET的下一级，往往会存在对应的输出DET。这样会产生对应的一组测试用例，这种测试用例即页面校验测试用例。

上述第四种情况，是往往是针对多个输入DET组合到一起的时候，才会有相应的输出DET的情况，例如多个输入DET：“买家未付款的订单个数”、“买家信用”、“子订单个数”和“支付宝付款状态”，对应一个输出DET即“不可购买”，这种复杂的组合，本申请实施例只能生成对应的判定表用例的结构，其中的具体的数值，需要测试人员在执行测试时填写。

具体来说，本申请实施例提供的测试用例的生成方法中的步骤S203，再具体实施时，可下述流程实现：

按照设定的规则，提取非逻辑事务节点中的测试用例的名称、优先级和类型的信息；创建与提取的名称、类型和优先级对应的测试用例；

根据非逻辑事务节点的各下级节点的标识中记录的测试步骤的执行顺序和测试步骤内容，生成该测试用例的各测试步骤。

例如图3中“TC_P0_A交易主流程”的非逻辑事务节点，扫描该节点时，将其生成包含测试步骤的测试用例，该测试用例的名称为“交易主流程”、优先级为“P0”、类型为“A”(即自动化模式)。该节点下的各节点为该测试用例的各个测试步骤，每个步骤的顺序都可以通过读取该步骤节点的名称识别，例如标识分别为：“01****”、“02******”、“03******”的三个步骤节点，按照先执行“01****”、然后执行“02******”，最后执行“03******”的顺序，将这三个节点中的内容拼接成流程中各个步骤的内容，完成测试用例的生成过程。

较佳地，本申请实施例在生成测试用例之前，还需要将思维导图中相应的逻辑事务、输入DET、输出DET等的前缀标识或者用于标识的图形去除。

较佳地，本申请实施例在对思维导图中的逻辑事务节点和非逻辑事务节点进行扫描处理之前，还包括将思维导图中的空节点去掉的步骤，去除空节点需要从根节点开始，如果空节点的下级还有节点，那么，依次递归，直至找到一个非空的节点为止，将找到的非空的节点上移。

较佳地，本申请实施例提供的测试用例的生成方法，在上述步骤S201～S203的步骤之后，还包括执行下述步骤：统计该逻辑事务节点中输入DET的数量、输出DET的数量以及实体节点中实体类型的数量，根据设定的功能点算法，计算出每个逻辑事务的功能点指数并存储于所述实体节点中。

功能点算法可以采用现有的MkII功能点算法，或者其他常见的功能点算法，以MkII功能点算法为例，MkII功能点算法的算法公式如下：

功能点指数＝输入DET的数量*0.58+实体类型的数量*1.66+输出DET的数量*0.26；

功能点指数能够对测试工作的工作量和复杂程度进行量化，在完成测试用例的生成的同时，能够对该逻辑事务测试的工作量和复杂程度进行衡量，以便更好地安排软件测试的进度，对测试工程师的工作量进行评估等。

基于同一申请构思，本申请实施例还提供了一种测试用例的生成装置，由于该装置所解决问题的原理与前述测试用例的生成方法相似，因此该装置和设备的实施可以参见前述方法的实施，重复之处不再赘述。

本申请实施例提供的测试用例的生成装置，如图5所示，包括：

扫描模块501，用于依次扫描思维导图中的各逻辑事务节点和非逻辑事务节点；

第一测试用例生成模块502，用于对于所扫描的非逻辑事务节点，生成包含测试步骤的测试用例；

第二测试用例生成模块503，用于对于所扫描的逻辑事务节点，根据该逻辑事务节点预先设置的输入DET和输出DET，生成包含输入条件和预期结果的测试用例。

进一步地，本申请实施例提供的测试用例的生成装置，如图5所示，还包括：

第一创建模块504，用于在树形结构的思维导图中，创建各逻辑事务节点及其各下级节点；

第二创建模块505，用于在树形结构的思维导图中，创建各非逻辑事务节点及其下级节点。

进一步地，上述第一创建模块504，具体用于在各逻辑事务节点下创建输入节点、输出节点和实体节点；在输入节点下，对该逻辑事务相关操作进行拆解，分别生成该输入节点的下级节点，并根据所述相关操作输入和输出的关系，在输入节点的下级节点中，分别标识出输入DET以及输出DET；以及将该逻辑事务的所涉及的实体类型及描述信息写入实体节点中。

进一步地，上述第二创建模块505，具体用于按照预先设定的测试用例前缀标识+测试用例优先级+测试用例类型+测试用例名称的节点生成规则，创建非逻辑事务节点；根据该非逻辑事务节点对应的测试用例的各个步骤，在非逻辑事务节点下分别生成与各个测试步骤对应的下级节点，各下级节点的标识中包含对应测试步骤的执行顺序和测试步骤的内容。

进一步地，上述第一测试用例生成模块502，具体用于按照设定的规则，提取非逻辑事务节点中的测试用例的名称、优先级和类型的信息；生成与提取的名称、类型和优先级对应的测试用例；根据非逻辑事务节点的各下级节点的标识中记录的测试步骤的执行顺序和测试步骤内容，生成该测试用例的各测试步骤。

进一步地，上述第二测试用例生成模块503，具体用于遍历所扫描的逻辑事务节点中的各个输入DET；当输入DET的父级节点为除了输入DET和输出DET之外的节点时，将该输入DET的所有父节点分别生成测试用例树结构；当输入DET仅有一个子节点，且该子节点为输出DET时，将所述输入DET和输出DET分别作为输入条件和预期结果，生成单个测试用例；当多个输入DET和一个输出DET在同一个节点下，将多个输入DET作为输入条件，将输出DET作为预期结果，生成判定表用例；当一个输入DET的下级有多个输出DET，则按照每个输出DET，分别生成包含该输入DET作为数据条件，各输出DET作为预期结果的测试数据驱动模式的测试用例。

较佳地，本申请实施例提供的测试用例的生成装置，如图5所示，还包括：计算模块506，用于在第二测试用例生成模块503遍历所扫描的逻辑事务节点中的各个输入DET，生成包含输入条件和预期结果的测试用例之后，统计该逻辑事务节点中输入DET的数量、输出DET的数量以及实体节点中实体类型的数量，根据设定的功能点算法，计算出功能点指数并存储于实体节点中。

本申请实施例提供的测试用例的生成方法及装置，依次扫描思维导图中的各逻辑事务节点和非逻辑事务节点；对于所扫描的非逻辑事务节点，生成包含测试步骤的测试用例；对于所扫描的逻辑事务节点，根据该逻辑事务节点预先设置的输入DET和输出DET，生成包含输入条件和预期结果的测试用例。本申请利用可清晰地展现各逻辑事务需求架构的思维导图，对其进行解析，并根据各逻辑事务中输入和输出之间的关联关系，能够生成能够全面反映软件需求关系的测试用例，对于包含测试步骤形式的测试用例，可以通过思维导图转化生成，所生成的测试用例形式多样，满足了软件测试用例的需要，并且，由于采用同样方式对各逻辑事务进行处理得到相应的测试用例，避免了手工编写测试用例所带来的测试用例结构不统一、细节零碎等问题。

本申请实施例中，在对思维导图进行扫描生成测试用例之后，还可以根据思维导图中每个逻辑事务的输入DET、输出DET和实体类型的数量，对该逻辑事务测试的工作量和复杂程度进行衡量，以便更好地安排软件测试的进度，对测试工程师的工作量进行评估等。

显然，本领域的技术人员可以对本申请进行各种改动和变型而不脱离本申请的精神和范围。这样，倘若本申请的这些修改和变型属于本申请权利要求及其等同技术的范围之内，则本申请也意图包含这些改动和变型在内。

Claims

1.一种测试用例的生成方法，其特征在于，包括：

依次扫描思维导图中的各逻辑事务节点和非逻辑事务节点；

对于所扫描的逻辑事务节点，根据该逻辑事务节点预先设置的输入数据元素类型DET和输出DET，生成包含输入条件和预期结果的测试用例。

2.如权利要求1所述的方法，其特征在于，依次扫描思维导图中的各逻辑事务节点和非逻辑事务节点之前，还包括：

3.如权利要求2所述的方法，其特征在于，生成逻辑事务的各下级节点，包括：

在各逻辑事务节点下创建输入节点、输出节点和实体节点；

在输入节点下，对该逻辑事务相关操作进行拆解，分别生成该输入节点的下级节点，并根据所述相关操作输入和输出的关系，在输入节点的下级节点中，分别标识出输入DET以及输出DET；

将该逻辑事务的所涉及的实体类型及描述信息写入实体节点中。

4.如权利要求2所述的方法，其特征在于，在思维导图中创建非逻辑事务节点及其各下级节点，包括：

按照预先设定的测试用例前缀标识+测试用例优先级+测试用例类型+测试用例名称的节点生成规则，生成非逻辑事务节点；

根据该非逻辑事务节点对应的测试用例的各个步骤，在所述非逻辑事务节点下分别生成与各个测试步骤对应的下级节点，各下级节点的标识中包含对应测试步骤的执行顺序和测试步骤的内容。

5.如权利要求1-4任一项所述的方法，其特征在于，对于所扫描的非逻辑事务节点，生成包含测试步骤的测试用例，包括：

6.如权利要求1-4任一项所述的方法，其特征在于，对于所扫描的逻辑事务节点，生成包含输入条件和预期结果的测试用例，包括：

遍历所扫描的逻辑事务节点中的各个输入DET；

当输入DET的父级节点为除了输入DET和输出DET之外的节点时，将该输入DET的所有父节点分别生成测试用例树结构；

当输入DET仅有一个子节点，且该子节点为输出DET时，将所述输入DET和输出DET分别作为输入条件和预期结果，生成单个测试用例；

当多个输入DET和一个输出DET在同一个节点下，将多个输入DET作为输入条件，将输出DET作为预期结果，生成判定表用例；

当一个输入DET的下级有多个输出DET，则按照每个输出DET，分别生成包含该输入DET作为数据条件，各输出DET作为预期结果的测试数据驱动模式的测试用例。

7.如权利要求6所述的方法，其特征在于，遍历所扫描的逻辑事务节点中的各个输入DET，生成包含输入条件和预期结果的测试用例之后，还包括：

统计该逻辑事务节点中输入DET的数量、输出DET的数量以及实体节点中实体类型的数量，根据设定的功能点算法，计算出功能点指数并存储于所述实体节点中。

8.一种测试用例的生成装置，其特征在于，包括：

第二测试用例生成模块，用于对于所扫描的逻辑事务节点，根据该逻辑事务节点预先设置的输入数据元素类型DET和输出DET，生成包含输入条件和预期结果的测试用例。

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

第一创建模块，用于在树形结构的思维导图中，创建各逻辑事务节点及其各下级节点；

第二创建模块，用于在树形结构的思维导图中，创建各非逻辑事务节点及其下级节点。

10.如权利要求9所述的装置，其特征在于，所述第一创建模块，具体用于在各逻辑事务节点下创建输入节点、输出节点和实体节点；在输入节点下，对该逻辑事务相关操作进行拆解，分别生成该输入节点的下级节点，并根据所述相关操作输入和输出的关系，在输入节点的下级节点中，分别标识出输入DET以及输出DET；以及将该逻辑事务的所涉及的实体类型及描述信息写入实体节点中。