CN103412853B - 一种针对文档转换器的测试用例自动生成方法 - Google Patents

Abstract

本发明涉及一种针对文档转换器的测试用例自动生成方法，包括：步骤1，根据测试对象的产品需求得到形式化的测试需求，并基于形式化的测试需求划分测试功能点；步骤2，对形式化的测试需求中的类对象进行动态实例化处理，并向类对象写入测试数据，得到包含测试数据的类对象集合，再将类对象集合序列化，生成基于相应测试功能点的XML片段；步骤3，把基于测试功能点的XML片段写入对应的底层XML实例文档集合，生成测试用例文档。本发明的测试用例自动生成方法脱离了对办公软件界面的依赖，避免办公软件对标准的支持不够所产生的测试盲点问题，生成测试用例所用时间短，效率高。

Description

一种针对文档转换器的测试用例自动生成方法

技术领域

本发明涉及转换器测试技术领域，特别是涉及一种针对文档转换器的测试用例自动生成方法。

背景技术

文档格式标准是实现信息资源共享和开放文档格式的基础。虽然文档格式逐步走向开放，但是目前办公文档业界多种标准共存，而作为国际标准的OOXML由一家公司制定并拥有解释权，从技术文档和应用角度仍有诸多的专利和版权限制，很难做到完全公开，并且要在短期内实现多种文档格式标准的信息共享和互操作是不现实的。为了实现办公文档在中国国家标准UOF和国际标准OOXML之间的双向转换，对UOF/OOXML文档转换器进行测试是很必要的。转换器人工测试过程存在一些明显的但又难以解决的问题，总结如下：

1）办公文档的功能点数量繁多、种类复杂，致使测试用例的设计工作复杂繁琐，耗时耗力，测试用例设计人员需要做大量非创造性的重复工作。

2）测试用例的设计完全依靠测试设计人员对于Scope的理解以及对办公软件的熟悉程度和使用经验，人工设计的测试用例覆盖率无法度量，难以保证测试的完备性。

3）集成测试用例设计采用增量集成策略，以一级功能点为粒度单位，依次在测试用例中增加新的功能点，最后形成非常复杂的、集成度很高的测试用例，这种一级功能点平行组合的方式存在着不严谨和覆盖率低的问题，难以保证集成测试的质量。

4）由于办公软件对UOF2.0标准的支持还处在发展阶段，所以目前利用办公软件界面测试转换器的方案存在一定的测试盲点，文档格式标准中的一些功能点无法通过办公软件界面设计测试用例。

针对人工测试的缺点，目前对于文档转换器测试技术的探索和研究，主要有以下几种方法：

一、通过办公软件界面截图，使用模式识别技术，对比源文档和目标文档图像相似度。这种方法仅对比显示效果，无法对比功能点属性，从而无法保证对比结果的准确性，同时有一定的技术难度。

二、基于办公软件界面的捕获和回放，录制测试脚本，自动生成测试用例。这种方法测试成本较高，需要增加额外的测试脚本维护工作，同时没有解决测试盲点的问题。

三、通过分析文档格式标准的定义，使用XMLSpy等XML编辑器编写XML代码，生成测试用例。这种方法虽然解决了测试盲点问题，但是工作量大，效率低，要求测试人员具有较高的专业水平。

因此，本发明提出了一种设计测试用例自动生成方法，以现有的UOF2.0文档格式标准和转换器需求规格说明相关文档为依据，生成满足文档格式标准的电子表格测试用例。

发明内容

本发明所要解决的技术问题是提供一种测试用例自动生成方法，用于解决现有文档转换器测试技术存在盲点、覆盖率低和重复工作量大等问题。

本发明解决上述技术问题的技术方案如下：一种针对文档转换器的测试用例自动生成方法，包括：

步骤1，根据测试对象的产品需求得到形式化的测试需求，并基于形式化的测试需求划分测试功能点；

步骤2，对形式化的测试需求中的类对象进行动态实例化处理，并向类对象写入测试数据，得到包含测试数据的类对象集合，再将类对象集合序列化，生成基于相应测试功能点的XML片段；

步骤3，把基于测试功能点的XML片段写入对应的底层XML实例文档集合，生成测试用例文档。

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

进一步，所述步骤1中根据测试对象的产品需求得到形式化的测试需求具体包括：设计UML组件与UOF2.0标准的XSD组件之间的映射规则，通过建模工具为UOF2.0标准建立UML类模型，并将类模型中的各个组件和组件之间的静态关系用类代码来实现，建立类模型对应的UOF类库，得到形式化的测试需求。

进一步，UML组件与UOF2.0标准的XSD组件之间的映射规则在命名规范、数据类型、顺序关系和多样性约束上遵循标准XSD组件中的定义。

进一步，所述步骤1中基于形式化的测试需求划分测试功能点具体包括：以形式化的测试需求为依据，按照转换的优先级整理和划分测试功能点；定义独立功能点切片和独立功能点簇，统一测试功能点划分粒度，实现办公文档功能点的量化。

进一步，所述步骤2具体包括：通过人工录入或外部数据源导入的方法加载测试数据，利用.NetFramework中的反射技术，从UOF类库中动态实例化类对象，得到载入测试数据的类对象集合，再通过.NetFramework中的序列化技术，将类对象集合序列化，得到对应的XML片段。

进一步，所述步骤3具体包括：对空文档做预处理，得到其底层XML实例文档集合，通过DOM和XPath技术将XML片段写入对应的底层XML实例文档中，验证写入后的文档是否符合UOF2.0标准，处理完成的底层XML实例文档集合通过ZIP压缩打包，转换为文档转换器所识别的测试用例文档，并将其输出到测试用例库。

本发明的有益效果是：

一、根据对测试需求的形式化定义来划分测试功能点，能提供覆盖UOF2.0标准的测试功能点列表，实现测试用例覆盖率的度量，降低测试遗漏和冗余的风险。

二、根据测试功能点和输入的测试数据，自动生成相应的测试用例（转换器源文档），该测试用例能够通过UOF2.0标准XMLSchema的格式验证。

三、提供了测试用例自动生成方法，使测试用例设计人员可以把更多的时间和精力放在测试数据的设计上，而不是花费大量时间研究如何通过商业办公软件把测试数据写入测试用例文档。

四、实现了参数化的数据驱动测试用例自动生成，测试数据存储在外部文件或数据库中，与测试用例文档分离，可以方便的修改或重用，可以动态地读取测试数据，生成测试用例文档，快速高效地实现多次迭代。

五、测试用例自动生成方法脱离了对办公软件界面的依赖，避免办公软件对标准的支持不够所产生的测试盲点问题。

综合来说，本发明的测试用例自动生成方法可以实现电子表格文档的测试用例自动生成，降低测试用例设计工作量，提高测试工作效率，保证测试用例覆盖率，同时消除对办公软件的依赖所产生的测试盲点。

附图说明

图1为本发明所述针对文档转换器的测试用例自动生成方法的流程示意图；

图2为本发明实施例中UML模型、UOF文档标准及实例文档间的层次化关系示意图；

图3为本发明实施例中加载测试数据的流程示意图；

图4为本发明实施例中动态实例化类对象的流程示意图；

图5为本发明实施例中文档层操作的流程示意图。

具体实施方式

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

实施例一

如图1所示，实施例一给出了一种针对文档转换器的测试用例自动生成方法，包括：

步骤1，根据测试对象的产品需求得到形式化的测试需求，并基于形式化的测试需求划分测试功能点；

步骤2，对形式化的测试需求中的类对象进行动态实例化处理，并向类对象写入测试数据，得到包含测试数据的类对象集合，再将类对象集合序列化，生成基于相应测试功能点的XML片段；

步骤3，把基于测试功能点的XML片段写入对应的底层XML实例文档集合，生成测试用例文档。

这里，所述测试对象的产品需求包括UOF2.0标准文档、转换范围文档和标准差异文档。

另外，所述步骤1中根据测试对象的产品需求得到形式化的测试需求具体包括：设计UML组件与UOF2.0标准的XSD组件之间的映射规则，通过建模工具为UOF2.0标准建立UML类模型，并将类模型中的各个组件和组件之间的静态关系用类代码来实现，建立类模型对应的UOF类库，得到形式化的测试需求。其中，UML组件与UOF2.0标准的XSD组件之间的映射规则在命名规范、数据类型、顺序关系和多样性约束上遵循标准XSD组件中的定义。

所述步骤1中基于形式化的测试需求划分测试功能点具体包括：以形式化的测试需求为依据，按照转换的优先级整理和划分测试功能点；定义独立功能点切片和独立功能点簇的概念，统一测试功能点划分粒度。

所述步骤2具体包括：通过人工录入或外部数据源导入的方法加载测试数据，利用.NetFramework中的反射技术，从UOF类库中动态实例化类对象，得到载入测试数据的类对象集合，再通过.NetFramework中的序列化技术，将类对象集合序列化，得到对应的XML片段。

所述步骤3具体包括：对空文档做预处理，得到其底层XML实例文档集合，通过DOM和XPath技术将XML片段写入对应的底层XML实例文档中，验证写入后的文档是否符合UOF2.0标准，处理完成的底层XML实例文档集合通过ZIP压缩打包，转换为文档转换器所识别的测试用例文档，并将其输出到测试用例库。

上述针对文档转换器的测试用例自动生成方法，在具体实施中主要包括以下技术要点：

一、测试功能点定义及划分

测试功能点（TestPoint,TP）是进行测试用例生成和测试用例功能点组合覆盖及统计的基本单位。功能点的明确划分是进行测试用例自动生成和度量功能点覆盖率的基础。所以首先通过对文档格式标准的XMLSchema定义和实例文档XML结构进行形式化描述，得到形式化的测试需求，定义了独立功能点切片和独立功能点簇的概念，统一了测试功能点划分粒度，以实现办公文档功能点的量化，也为测试用例自动生成提供了依据。

【定义1】XMLSchema定义为一个六元组

S=(E,A,P,N,V,r)

式中：E为element标签标识的元素集合；A为attribute标签标识的属性集合；P为E中的元素到其直接后继节点的映射；N为E中的元素到A的映射，即其属性；V表示的是简单数据类型的集合，复杂的数据类型可以由简单的数据类型构成；r为树根元素类型。

【定义2】XML文档树状结构定义为一个六元组

T=(ver,lab,ele,att,par,root)

式中：S表示定义1中的六元组，T为满足S的XML树，表示为ver为节点的有限集合；lab为节点到标签的函数映射，即ver→E∪A∪{str}_v的映射，其中str表示文本节点，lab(v)返回节点v的标签；ele为元素节点的子元素节点和文本节点序列，即E→{str}∪v^*的映射；att为元素节点的子属性节点集合，即ver→A的映射；par为节点到其双亲节点的映射；lab(root)=r，表示XML树状结构根节点。

【定义3】节点等价：当且仅当下列条件成立时，v₁等价于v₂，记为v₁≡v₂。

$v_1\⋐\mathrm{ver},$ $v_2\⋐\mathrm{ver},$ lab(v₁)=lab(v₂)

如果则ele(v₁)=ele(v₂)，且att(v₁)=att(v₂)。

如果 $[\mathrm{lab}\left(v_1\right)\∪\mathrm{lab}\left(v_2\right)]\⋐A\∪\left\{\mathrm{str}\right\},$ 则par(v₁)=par(v₂)。

如果不满足上述条件，v₁不等价于v₂，记为

【定义4】功能点路径：如果T的树形结构上存在节点序列(v₀,v₁,…,v_n)，其中v₀₌root,i∈[1,n]满足以下条件：

如果lab(v_i)∈E则v_i∈ele(v_i-1)，v_i是v_i-1的直接后继元素节点

如果lab(v_i)∈A则v_i∈att(v_i-1)，v_i是v_i-1的直接后继属性节点

如果lab(v_i)∈{str}，则v_i=v_n，v_i是文本节点，且是路径的最后一个节点

那么，表达式lab(v₀)/lab(v₁)/…/lab(v_n)称为T上的路径表达式，记为p；Src(p)=v₀表示此路径的根节点（源点），Dest(p)=v_n表示路径的叶子节点（终点）；P={lab(v₀),lab(v₁),…,lab(v_n)}称T上的路径节点集；Depth(p)=|P|=n+1表示路径的深度，即路径节点集的元素个数。

【定义5】独立功能点切片（IndependentFunctionSlicing,IFS）是实现文档转换器格式标准中最小粒度功能点的XML片段，它是XML树状结构中所有节点和节点之间的关联关系（即XML树形结构中的边）构成的集合的一个子集，可以用二元组来表示：IFS=(n,e)，其中n是有限节点的集合，e是有限边的集合，其中e_i,j∈e表示有序节点对<n_i,n_j>之间的直接关联关系。IFS中的任意两个节点不允许来自于同一个XMLSchema元素，即 每个IFS与一个路径表达式相对应。

【定义6】独立功能点簇（IndependentFunctionCluster,IFC）是实现单个测试功能点所涉及到的独立功能点切片有机组合，每个IFC有且仅有一个主IFS，记为IFS_main；还包括n个次要IFS(n≥0)，记为IFS_sub。假设IFS_m的路径表达式p_m为参考路径；对于IFS_m，从其路径表达式p_n的叶子节点Dest(p_n)往上层追溯，直到某个祖先节点属于参考路径节点集p_m时停止，中间经过的节点的个数称为IFS_n到IFS_m的距离，记为Dis(p_m,p_n)。有如下定义：

如果Dis(p_m,p_n)≤1，则IFS_n与IFS_m互为Family（同族）；

如果1＜Dis(p_m,p_n)≤Depth(p_n)，则IFS_n与IFS_m互为Clan（同宗）；

如果Dis(p_m,p_n)＞Depth(p_n)，则IFS_n与IFS_m互为Alien（异族）。

独立功能点簇是上文定义的测试功能点的一种表示形式，是独立功能点切片的有机组合，其簇状结构在转换器测试质量指标量化的相关定义中较常用。

二、文档格式标准建模

UOF标准包含了若干个XSD格式的规范性描述文件，这些文件之间存在着许多复杂的联系或引用关系，直接用程序操作XSD定义来生成符合标准要求的办公文档底层XML代码可以实现，但是这种方法繁琐复杂，效率低，需要对每个功能点进行相应的处理，实现复杂度与转换器开发的复杂度相当，因此不采用直接通过XSD生成测试用例的方案，而是对XSD建立UML模型，间接实现对XSD的操作。

如图2所示，UML模型是概念层的抽象模型，XMLSchema是逻辑层的文档格式定义，XML实例文档是满足XMLSchema定义的物理层的具体实现。为了使最终生成的XML实例文档能够通过UOF文档格式标准的验证，在设计UML类模型与XSD组件的映射规则的时候要从命名规范、数据类型、顺序关系和多样性约束等各个方面遵循标准XSD文档中的定义，尽量减少模型映射中的弱化影响。

下面列出了概念层UML与逻辑层的文档格式标准之间的映射规则：

1）命名空间的映射

单独的XSD文档映射为UML中的一个包，包名和XSD命名空间的对应关系。不同XSD文档之间的import和include映射为实体类中命名空间的引用，使用.Net中的using关键字来实现。

2）全局元素的映射

全局声明的元素在实例文档中一般作为根元素出现。全局元素v映射为一个UML类，类名为lab(v)，构造型为<<XMLRoot>>。由于XSD中没有可见性约束，因此映射成UML类的访问类型为公有。将全局元素的子元素映射为类的私有字段，然后使用属性对该字段进行封装，通过属性的set和get访问器实现对字段的读写操作。

3）内置类型的映射

XMLSchema的数据类型分为内置类型和自定义类型。内置类型包括内置基元类型和内置派生类型。定义一个UML包XSDDatatypes，包括XMLSchema中的37中内置数据类型，其中一些类型可以直接引用.Net中的数据类型，无法完全对应的则需要定义新类。

4）自定义类型的映射

自定义类型包括simpleType和complexType，是XMLSchema中最基本的组件。simpleType直接转换为UML类，其stereotype为自定义构造型<<simpleType>>。简单类型的定义方式通常是对现有简单类型或内置类型的限制派生，并使用约束面对现有类型进行约束，这种定义方式映射为UML类图中的Constraint。将simpleType对应的UML类模型转换成代码时，使用属性对私有字段进行封装，UMLConstraint转换为属性的set访问器中的限制条件，实现限制继承。

复杂类型也映射为一个UML类，由自定义构造型<<complexType>>修饰，其子元素和子属性转换为UML类模型的属性，其中子属性的stereotype为自定义构造型<<XmlAttribute>>。

5）type组件的映射

XSD中使用type标签指定元素或属性的数据类型，如果元素或属性的类型为自定义类型，则映射为UML中的聚合关系（Aggregation）。自定义类型为被聚合的类，以此表示两个类之间存在整体和局部的关系，而且此关系是单向的。

6）extention组件的映射

XSD中的extension组件映射为UML类模型中的泛化关系。将extension组件的base属性所指明的类型指定为父类，子类继承父类所有属性和子元素。

7）ref属性的映射

ref属性在XSD中作为已有元素或属性的引用出现，映射为UML类模型中的关联关系。

8）多重性转换规则

XSD中的minOccurs和maxOccurs节点映射为UML中的多重性约束，表示类属性可能出现的次数。例如“maxOccurs=unbounded”映射为多重性描述[1..*](此处minOccurs的默认值为1)。子属性节点use的取值“required”映射为UML多重性描述[1..1]，“optional”映射为UML多重性描述[0..1]。

9）其他映射规则

对于XSD和UML无法完全对应的部分，设计相应的构造型，例如：XSD中的约束面enumeration，在UML类模型中没有对应的组件，但是.Net平台提供了枚举类型，因此定义构造型<<enumeration>>，将XSD中的枚举约束面转换为以此为构造型的类。另外还有一些XMLSchema组件可以在设计实体类的时候做特殊处理，例如XMLSchema中的default节点修饰的属性值映射为UML类字段的初始值；fixed节点修饰的属性值设为UML类字段的初始值，同时关闭字段对应属性的set访问器，将属性设为只读。

三、测试用例自动生成系统架构

电子表格、字处理和演示文稿三部分的测试用例自动生成方法通用，本实施例将其归纳为文档转换器测试用例自动生成，其实现架构分为三个层面：模型层、对象层和实例文档层。

1)模型层实现方案

首先根据映射规则，在EA中建立了DesignModel。通过EA的代码生成（CodeGenerate）功能，初步生成了用于构造UOF类库的.CS文件。由于EA代码转换功能仍有一定的局限性，生成的类文件并不能直接在对象层使用，还需要对类文件进行序列化预处理（需要在类文件中加入序列化标记、在类属性中实现XSD约束面等）。类文件之间命名空间的引用以XSD文件中的import和include为依据。将这些类文件封装成动态链接类库UOFClassLibrary.dll。

2)对象层实现方案

测试用例自动生成系统的主体阶段主要是对象层的操作。对象层作为文档格式标准模型与实例文档之间的桥梁，通过反射技术和序列化技术实现了动态实例化的类对象与文档底层XML之间的转换，是本课题的核心技术模块。

首先测试人员将设计好的n组（n>=1）测试数据通过外部数据源（文本文件、xml文件或数据库文件）导入系统，每一组测试数据对应生成一个独立功能点簇XML文档。如图3所示，将一组测试数据存入字典集合Dictionary<Key,Value>。其中Key存储string类型的IFCName，Value存储object类型的IFCValue。在动态实例化类对象的过程中，将使用此键值对中的数据为对象赋值。对n组测试数据循环调用此过程，得到n个实例化的类对象。

图4为测试用例自动生成系统在对象层通过反射技术动态实例化类对象的主流程图。从配置文件中读取需要测试的IFC所包含的所有IFS的路径表达式，将属性为Clan和Alien的路径表达式与属性为Main和Family的路径表达式分开保存在动态数组ArrayList中，然后以主路径为中心对不同属性的IFS进行分情况处理。首先调用分词函数getPathSegment()对主路径表达式进行分词，结果存储到一个字符串数组。然后利用反射技术，分别创建主路径根节点和叶子节点的实例。

在创建叶子节点实例的同时，将键值对Dictionary<IFCName,IFCValue>中保存的测试数据写入叶子节点对象。

为了实现UOF标准XMLSchema和类模型转换强类型的特点，减少模型转换的弱化效应，在测试数据写入叶子节点对象时将字符串类型的测试数据转换成类模型中对应的属性类型。

如果存在属性为Clan的IFS，即到主路径距离大于1的路径，首先调用getJoint()方法，找到pathClan与pathMain的分支节点，通过上述一系列反射获取对象的方法，获取pathClan在分支节点处的已载入测试数据的对象。

根据路径表达式字符串数组，动态创建叶子节点的上一层对象objMiddle，使用SetValue()将叶子节点挂载到objMiddle；递归调用getMiddleObject()方法，往上回溯直到遇到根节点；在回溯的过程中，如果此层的中间层对象是某个分支节点的父节点，则将上一步准备好的分支节点对象挂载到这个父节点对象上；同时需要处理属性为Family的IFS，回溯每一层中间层对象时，获取其属性集合，如果键值对Dictionary<IFCName,IFCValue>中存在某个属性，则为此属性赋值，完成之后从字典中删除该组键值对，以减小下次查找的样本空间，提高查找效率。回溯结束后返回objMiddle，将其挂载到根节点对象。

进行多个IFC组合，生成集成测试用例时，首先获取所有的IFSmain的路径表达式，找出路径最深的一条作为新的主路径，重新确定其他各个路径与新主路径之间的距离，根据距离值确定路径的属性，然后按照与上述单功能点相同的处理方式对多个IFC组合后的XML进行处理，读取功能点组合覆盖算法输出的测试数据，获得载入测试数据的类对象。

完成上述步骤之后，将最终的对象通过XMLSerializer序列化生成XML片段。

3)文档层实现方案

文档层的操作对象是XML实例文档及其上层以uos为后缀的、以ZIP压缩打包规范压缩过的XML实例文档集合，文档层的主要目的是把通过对象层输出的XML片段写入XML实例文档，验证载入测试数据后的底层XML文档是否符合UOF2.0标准，将通过XMLSchema验证的XML实例文档集合压缩为ZIP格式的文件，并修改后缀为uos，输出到测试用例库。文档层操作流程如图5所示。

UOF2.0格式的办公文档是多文件形式，解压缩后的文件夹包括uof.xml,content.xml,styles.xml,hyperlinks.xml等多个实例文档，不同类型的IFC要写入的实例文档和在文档中的位置有所不同，因此不同类型的功能点写入实例文档的处理方式也是不一样的。定义了接口IFileProvider，提供的服务是获取种子文件；定义了接口IIFCProcessor，提供的服务是将IFC写入实例文档。在系统实现时用接口来创建对象，不同类型的功能点处理类仅需实现这两个接口，即可向系统提供服务。这种方法有效地实现了程序的解耦合，同时增强了程序的可扩展性。

实施例二

根据实施例一的系统建模和实现方案，实施例二实现了一个基于WinForm和.NetFramework4.0的测试用例自动生成原型系统。

该原型系统允许测试用例设计人员选择需要生成测试用例的测试功能点，编辑测试用例相关信息，然后从系统界面手工录入或从外部数据源导入测试数据，生成测试用例并查看测试用例库情况。

该系统设计了导入测试数据的系统界面，测试数据列表列出了测试设计人员选择的独立功能点切片及其对应的测试数据；该系统允许测试设计人员手工录入测试数据，并将数据保存到文本文档；该系统允许测试设计人员从外部数据源导入测试数据，并可以对外部数据源数据进行修改。测试数据准备完毕之后，该系统还通过相应功能模块将测试数据读入系统对象层和文档层进行处理，生成测试用例文档，保存到测试用例库。

实施例二的测试用例还体现了测试用例自动生成方法对测试盲点的消除，其中阴影偏移量的坐标在目前中文办公软件界面上都无法实现，是一个测试盲点，而用测试用例自动生成的方法可以完全绕开测试盲点的限制，生成满足文档格式标准的测试用例。

表1列出了一级功能点“预定义图形”中的IFC分类，比较了人工设计测试用例的时间与测试用例自动生成的时间，其中人工测试用例设计时间假设了测试设计人员使用办公文档软件界面点击一个功能按钮的时间为5s，测试用例自动生成时间为原型系统显示的程序运行时间，从表1可明显看出本实施采用的文档转换器的测试用例的自动生成方法在效率上相对于人工设计测试用例有明显优势。

表1人工设计用例时间与自动化生成用例时间对比表

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

Claims (5)

1.一种针对文档转换器的测试用例自动生成方法，其特征在于，包括：

步骤1，根据测试对象的产品需求得到形式化的测试需求，并基于形式化的测试需求划分测试功能点；

步骤2，对形式化的测试需求中的类对象进行动态实例化处理，并向类对象写入测试数据，得到包含测试数据的类对象集合，再将类对象集合序列化，生成基于相应测试功能点的XML片段；

步骤3，把基于测试功能点的XML片段写入对应的底层XML实例文档集合，生成测试用例文档；

所述步骤2具体包括：通过人工录入或外部数据源导入的方法加载测试数据，利用.NetFramework中的反射技术，从UOF类库中动态实例化类对象，得到载入测试数据的类对象集合，再通过.NetFramework中的序列化技术，将类对象集合序列化，得到对应的XML片段。

2.根据权利要求1所述的测试用例自动生成方法，其特征在于，所述步骤1中根据测试对象的产品需求得到形式化的测试需求具体包括：设计UML组件与UOF2.0标准的XSD组件之间的映射规则，通过建模工具为UOF2.0标准建立UML类模型，并将类模型中的各个组件和组件之间的静态关系用类代码来实现，建立类模型对应的UOF类库，得到形式化的测试需求。

3.根据权利要求2所述的测试用例自动生成方法，其特征在于，UML组件与UOF2.0标准的XSD组件之间的映射规则在命名规范、数据类型、顺序关系和多样性约束上遵循标准XSD组件中的定义。

4.根据权利要求1所述的测试用例自动生成方法，其特征在于，所述步骤1中基于形式化的测试需求划分测试功能点具体包括：以形式化的测试需求为依据，按照转换的优先级整理和划分测试功能点；定义独立功能点切片和独立功能点簇，统一测试功能点划分粒度，实现办公文档功能点的量化。

5.根据权利要求1所述的测试用例自动生成方法，其特征在于，所述步骤3具体包括：对空文档做预处理，得到其底层XML实例文档集合，通过DOM和XPath技术将XML片段写入对应的底层XML实例文档中，验证写入后的文档是否符合UOF2.0标准，处理完成的底层XML实例文档集合通过ZIP压缩打包，转换为文档转换器所识别的测试用例文档，并将其输出到测试用例库。