测试用例复用在电子采购交易平台中的应用

杨 军 卢彩霞 黄 辰 王 婷

（北京中电普华信息技术有限公司 北京 100085）

1 引言

本文主要介绍在用户软件需求说明和系统设计说明书的基础上对测试需求的提取，以及由此引申出测试用例的生成，并且描述了测试需求和测试用例在电子采购交易平台系统中的分析过程。阐述了测试用例复用的设计原则及过程，并且将其应用在电子采购交易平台的过程，最终达到改善软件测试环境，提高软件测试效率的目的。

2 软件测试中的测试用例

2.1 测试需求

在介绍测试用例定义之前，我们先介绍一下软件测试需求的概念，软件测试需求是对软件产品测试范围的定义，表明测试软件产品是要测什么。软件测试需求必须是可观测、可测评的行为。目的是希望通过从原始需求（原始需求可以是用户需求说明书或是系统设计说明书）提炼出测试的要点，再针对每一个测试要点编写对应的测试用例。

软件测试需求定义就是编写一组需求分类、归档依据、需求描述、测试要点、重要性、测试需求状态的组合，实现从原始需求到测试要点的提炼过程。

我们可以把测试需求表示为一个八元组合

Test Requirements=｛Tq_ID，Qd，Qc，Ab，Oq，Tp，Imp，Qs｝

分别表示：｛需求标识，需求名称，需求分类，归档依据，原始需求，测试要点、重要性、需求状态｝；

1）需求标识Tq_ID：作为测试需求的唯一ID；

2）需求名称Qd：简要表述需求的某项特性；

3）需求分类Qc：分为流程类、功能类和其他；

4）归档依据Ab：与项目区域的类别相关，即所属模块；

5）原始需求Oq：对原始需求的描述；

6）测试要点Tp：根据原始需求提炼出的测试点；

7）重要性Imp：分为核心、重要、一般和可选四种，表示测试需求对最终用户的相对重要程度。通过与业务/系统分析人员/开发团队成员相互交换意见，最终确定测试需求的重要性；

8）需求状态Qs：新增、变更、删除；新增代表本次版本新增的测试需求，变更代表本次版本原始需求发生变更导致测试需求发生变更的，删除代表本次版本原始需求发生变更不在本次测试范围内的，只是设置一个标志位，实际未删除；

软件测试需求来源于用户业务需求说明书、功能需求说明书和系统设计说明书，我们可以直接将一个原始用户需求对应到一个测试需求或是多个测试需求，一个测试需求可以对应一个测试用例，或是拆分成多个测试用例。用公式可以表示如下：

Oq=＞Tq（一对一），或者 Oq1=＞（Tq11、Tq12、Tq13……Tq1N）（一对多）

Tq=＞Tc（一对一），或者Tq11=＞（Tc111、Tc112、Tc113……Tc11N）（一对多）；

从而推导出三者之间的关系：

Oq=＞Tq=＞Tc（一对一）；

OqM=＞（Tq11、Tq12、Tq13……Tq1N，Tp21、Tp22、Tp23……Tp2N，……，TpM1、TpM2、TpM3……TpMN）=＞（Tc111、Tc112、Tc113……Tc11X，Tc121、Tc122、Tc123……Tc12X，……，TcMN1、Tc-MN2、TcMN3……TcMNX）（一对多）；（Oq表示原始需求，Tq代表测试需求，Tc表示测试用例，M代表第几个原始需求，N代表一个原始需求对应的测试需求个数，X代表一个测试需求对应的测试用例个数）。

由此可知原始需求、测试需求和测试用例之间的对应关系，下面我们将紧接着对软件测试用例进行介绍。

2.2 测试用例

软件测试用例定义就是编写一组用例分类，测试要点，前提条件，输入，执行步骤，预期结果的集合，实现对某个特定目标或是需求的测试。

我们可以把测试用例表示为一个十元组合：

Test Case=｛TC_ID，Td，Tc，TQ_ID，Pre，In，Es，Er，Cs，Fr｝

分别表示：｛用例标识、用例名称、用例分类、需求标识、前提条件、输入数据、执行步骤、预期结果、用例状态及正反向｝

1）用例标识TC_ID：作为测试用例的唯一ID；2）用例名称Td：简述测试用例测试的目的；3）用例分类Tc：分为流程类、功能类和其他；4）需求标识TQ_ID：当前测试用例对应的测试需求，通过此标识关联对应的测试要点；

5）前提条件Pre：说明执行测试用例必须的前提条件，例如测试开始之前必须完成的一些操作步骤或者数据准备；

6）输入数据In：明确测试用例的数据输入或者测试数据的生成办法。输入数据可以在操作描述中说明，或者写在单独的案例数据表中，根据功能验证的要求的不同，可以输入正向数据、反向数据、边界数据等；

7）执行步骤Es：说明如何操作该测试步骤且步骤要求清晰无歧义。例如说明点击操作的时候，需要说明点击的对象是菜单、按钮，还是链接；

8）预期结果Er：说明从测试输入到执行该步骤应该产生的对应的输出，比如状态的迁移、计算结果、提示信息、页面的切换等

9）用例状态Cs：新增、变更、删除；新增代表本次版本新增的测试用例，变更代表本次版本原始需求发生变更导致测试用例发生变更的，删除代表本次版本原始需求发生变更不在本次测试范围内的，只是设置一个标志位，实际未删除；

10）正反向Fr：正向、反向；正向测试主要关注于系统能够正常工作，反向指系统不支持的输入或状态，这类用例是为了检查系统的容错能力和可靠性。

以上介绍了测试需求和测试用例的定义及相关要素，测试需求是测试用例编写的前提，而测试用例又是测试执行的前提，所以测试需求和测试用例在测试过程中至关重要，下面我们将以某一应用为例，介绍测试需求和测试用例的分析过程。

2.3 测试需求和测试用例分析过程

本章以电子采购交易平台系统中的一种采购方式为例，说明测试需求和测试用例的分析过程。测试需求来源于原始需求，对于简单的原始需求此处不做说明，本次只针对复杂的原始需求，流程存在多个分支或者子流程的，采用如下的分析过程：

1）根据原始需求描述对业务进行分析，对于复杂的业务流程可以借助思维导图或是流程图；

2）确定主流程、子流程或是分支流程；

3）根据原始需求制定出主流程、子流程或是分支流程的测试需求，在每个测试需求中提取测试要点；需要注意的是，有时候需求和设计的变更并没有完全体现在相关需求分析和设计文档中，所以在分析测试需求时，还应参照系统的用户操作界面，辅助资料、补遗文档中缺失或修改的系统功能；

4）编写测试需求时，按照以上定义的测试需求进行规范及标准化编写，保证应有的元素不能缺失，并且每个要素要求描述充分。

5）针对分解出的测试需求编写测试用例，依照本系统的特征，测试用例按类型分为流程类测试用例和功能类型测试用例；

6）编写测试用例时，按照以上定义的测试需求进行规范及标准化编写，遵循统一的规范格式并且包括全部应有的要素，保证测试用例可执行且有效，能够发现软件的缺陷。

7）在测试用例中，输入项中定义了案例数据表，案例数据表作为单独的一项，是考虑到在操作步骤不变的情况下，根据测试需求的不同变换不同的输入数据项，为自动化测试做准备。

以上是针对电子采购交易平台中的一种采购方式进行的分析过程。但是在软件测试过程中，测试用例会随着环境、产品、功能、业务的变化而失效，测试用例的设计不能仅局限于一个系统，而应具备通用性、独立性、标准性等特性，因此如何设计出可复用的测试用例是测试的关键技术。

3 软件测试用例的复用

3.1 软件测试复用

软件复用是指利用原有的软件相关知识、成果、经验进行软件开发的技术。软件复用的对象是指软件产品生产过程中的一切劳动成果，包括项目计划书、可行性报告、系统的需求分析、软件设计、测试，以及形成的相关文档等［1］。

软件复用有三个基本问题：一是必须要有可以复用的对象；二是所复用的对象必须是有用的，三是复用者需要知道如何去使用被复用的对象。通过软件复用，消除了包括分析、设计、编码、测试等在内的许多重复劳动，从而提高了软件开发的效率，同时，通过复用高质量的已有开发成果，避免了重新开发可能引入的错误，从而提高了软件质量［2］。了解了软件复用基本概念以后，下面主要针对软件测试领域的复用进行讨论，软件测试的复用包括测试过程的复用、测试方法的复用和测试用例的复用。基于我们所测试的电子采购交易平台系统的特点，我们主要针对测试用例的复用进行叙述，所谓测试用例复用是指对一个软件已执行的测试用例，将其不同程度地应用于该软件新阶段的测试中或其他软件的测试中。可复用的测试用例具有通用性、独立性、有效性、完整性和标准化的特点［3］。

Adhikari针对自动化测试脚本的可复用性，提出了编写自动化复用测试用例的四个原则［3，6］：

1）设计相互独立的测试用例

2）设计自包含的测试用例

3）设计基于出发点的测试用例

4）设计可全覆盖和无重复的测试用例。

在我们测试的电子采购交易平台系统中，最为关注的是手工测试用例，根据自动化复用测试用例的原则和特点，设计手工测试的可复用测试用例同样可以遵循以上的原则进行分析。

3.2 测试用例复用的设计

随着电子商务的快速增长，招标投标市场也呈现出快速发展的态势，各类电子采购交易平台由政府、企业、协会等不同主体大量建设，其中我们也承担了许多大型电子采购交易平台系统项目的建设，比如中广核、中国移动、大唐集团、三峡集团、新奥能源集团、国机集团等大型集团公司电子采购交易平台项目的建设，基于这些系统之间的共性，如平台、实现、功能、业务等相似性，总结出一套适合电子采购交易平台系统可以复用的测试用例。

在进行测试用例复用设计的时候，我们主要考虑以下几个要素：

首先考虑系统所属行业、软件实现的功能、业务场景，运行的平台及采用的编程语言，以此来判断此类软件相似程度是多少；

其次根据软件相似度、业务场景及功能实现的不同判断测试用例库中是否存在与之匹配的测试用例，针对被测系统，做一些输入、输出的改动，进而对测试用例进行不同程度的复用；

最后执行测试用例，通过执行复用的测试用例，检查被测软件是否通过测试。

3.3 测试用例复用的分析过程

软件测试用例的复用有三个基本的条件一是必须有可以复用的软件测试用例，二是复用的软件测试用例对将来软件测试是非常有用的，三是复用者应该知道如何去使用被复用的测试用例。正确地刻画、描述和管理可复用的测试用例是实现测试用例复用的关键技术［5］。

下面以电子采购交易平台系统为例进行分析，说明测试用例复用的分析过程。

1）对软件框架进行分析。本系统框架是基于SoGrid企业级构造云平台，包括了平台构造、框架构造和业务构造三部分，以SoGrid作为电子交易采购平台的应用支撑。SoGrid的框架构造提供了致力于敏捷软件开发、快速应用开发、平台无关的基础框架，可以进行JAVAEE企业级软件研发。在充分考虑了集成环境的复杂性的情况下，本系统的框架即能运行在国网统一的SG-UAP上，也能运行在公司自主产品SoTower上，软件在不同平台之间的可移植性为可复用测试用例的编写提供了一些可参考的依据。

2）对软件业务进行分析。通过对电子采购交易平台系统业务分析，整体业务流程梳理，从业务中抽取共性功能作为公共业务组件，同时，抽取的公共业务组件与电子采购交易平台业务没有强制的依赖关系，耦合度低，公共业务组件是否存在不影响整体业务流程。公共业务组可以跨越多个逻辑层和子系统，公共业务组件有明确的业务功能边界，功能独立，卸载后不会造成其他功能无法使用，从业务角度为电子采购交易平台提供了运行时和开发时的伸缩性。公共业务组件是独立的实体，影响测试用例是否具有独立性，而测试用例的独立性决定了测试用例的复用性的强弱。

3）对软件功能进行分析。电子采购交易平台系统核心采购模式包括公开招标、邀请招标、竞价采购、询价采购、竞争性谈判、单一来源和比选采购等，采购过程分为招投开评定五大环节，这在所有的电子采购项目中是共有的属性；在招标环节，招标方根据项目计划发布公告或是邀请函，在投标环节，供应商需参与标书购买，澄清交互，投标文件编制以及开标文件确认等业务；在开标环节，招标方负责对供应商的投标文件进行开启；在评标/评审环节，专家参与采购项目的初评、详评，评标报告/谈判报告的编制。在定标环节，根据评标结果产生中标候选人；在整个采购过程，纪检监察人员对采购的关键环节进行事中监察或事后监察。采购结束后，以中标结果作为签订合同的依据进行合同的签订，合同的履约，合同的变更等业务。纪检监察人员对合同的全过程也会进行事中监察或事后监察，系统实现企业供应链全过程管理，实现了上下协同、内外协同的物资采购管理模式。系统功能的全部实现，以及多个系统之间存在的共性，决定了是否能设计出全覆盖且可复用的测试用例。

4）对组织机构及用户权限进行分析。首先从业务需求判断采购方式是集中采购还是自行采购，采购方式的不同将决定该软件组织机构采用何种部署方式。其次对用户权限进行分析，首先用户的权限由系统赋予的角色所决定，而角色要由绑定的资源决定，而资源决定了此用户的操作和数据。比如招标项目经理具有招标、开标和定标的权限，供应商具有投标的权限、专家具有评标的权限等，而这些用户在相似的系统中应该具有相类似的权限控制。

5）对软件业务实现的依据进行分析。国家制定了《电子招投标系统技术规范》、《招投标法》、《招标投标法实施条例》等办法，目的就是为了规范招标投标活动，所有的招投标系统都要遵从这些办法及规范进行设计开发，所以这些标准化、规范化的办法及条例是设计开发的依据，也是设计可复用测试用例的依据和参考。

6）对软件输入进行分析。所有的电子采购交易平台都有五个部分组成，分别是招标、投标、开标、评标和定标，从这五个部分中整理出共性的属性作为输入项的父集，然后再针对每个不同行业的电子采购交易平台的个性特点，整理出输入域的子集。父集可以在所有的电子采购平台进行通用，子集根据不同的行业要求进行不同的应用。

最后根据以上分析和测试用例的定义要求，编写通用的、有效的、独立的、标准的、完整的可复用测试用例。考虑到可复用的目的，测试用例的设计要满足测试用例复用的特性。可复用测试用例设计完成以后组织专家进行评审，以确保测试用例是有效且正确的，对评审通过后的测试用例执行，经测试执行确认的可复用测试用例纳入到测试用例库中，供测试人员在以后的待测软件中查询使用。

本文虽然重点关注测试用例复用在电子采购交易平台中的复用，但是这种测试用例复用的方法在其他软件平台中同样适用。

3.4 测试用例复用的应用

本文的研究内容在采购领域进行了应用，电子采购交易平台系统在不同的行业的应用过程中（比如参与建设的能源行业、通信行业，机械装备、核电行业等），虽然行业有所不同，但是不同的行业对该类软件有共性需求。

首先对待测软件的运行环境、测试需求、业务功能等进行分析之后，发现待测软件与已测软件两者之间存在共性的需求。然后在原有测试用例库V1.0中检索与待测软件相同或是相似的测试用例，若与待测软件不匹配，对其进行修正使之更符合该软件的测试用例，若原有的测试用例库中未检索到与待测软件相同或是相似的测试用例，则按照可复用测试用例的设计原则进行设计，生成新的测试用例，对其进行评审，对评审通过后的测试用例执行，最后经验证确认的可复用测试用例入库到测试用例库V1.0之后，生成新版本的测试用例库V1.1以便后续继续复用，保证软件测试用例的收集和积累。在实际参与的几个系统中，同样应用了可复用测试用例，大大缩短了测试时间，提高了测试效率。

本文提出了基于复用的软件测试模型，主要表现在测试用例设计及测试用例的复用上，如图1所示。

图1 软件测试用例复用模型

下面以参与测试过的两个电子采购交易平台为例说明测试用例的复用。

首先针对已测试过的电子采购交易平台中的招标采购进行测试用例的设计，测试用例分析的过程根据以上3.3中提到的方法执行。招标采购是为用户提供招标采购的基本信息服务，包括了招标管理、投标管理、开标管理、评标管理和定标管理，这五部分是每一个电子采购平台共有的环节，但是每个系统由于业务的差异又有所不同，先从这五个主要部分中整理出共性的属性作为测试用例的父集，然后再针对电子采购平台特有的部分整理出个性的子集。经过评审的测试用例入库到用例库中，测试用例库分为两部分一部分是系统通用和共性的用例即为父集库，一部分是系统专用和特性用例库即为子集库。

然后再针对待测电子采购交易平台中的招标采购进行软件分析。因为每个电子采购交易平台通用的部分都是招投开评定五个部分，在测试用例库中这部分的用例有上千条，可以直接从原有的用例库中提取父集中的共有用例，在编写测试用例上节约很多的时间和资源。但是有所不同的是待测电子采购交易平台在招标管理前的准备阶段，是通过与其他系统的集成来获取采购计划，已测电子采购交易平台在招标管理前的准备阶段是通过在本系统直接新增采购计划，因此根据两个系统不同特征建立对应的子集加入到用例库中生成新的测试用例库。如果其他电子采购交易平台采用的是集成的方式，测试用例可以直接从前者的测试用例子集中提取，如果是采用新增的方式直接从后者的测试用例子集中提取执行。在不同的系统不断的应用过程中，子集中出现越来越多共性的属性的时候，子集可以升级为父集，作为通用用例来执行。

4 结语

本文研究的主要内容是测试需求和测试用例在实际应用中的分析过程，软件测试用例设计是软件测试的重要环节，设计出高效可复用的测试用例是更关键的技术，将设计出可复用测试用例的思路和方法应用到不同的电子采购交易平台中，从而达到改进测试方法，提高测试效率的目的。