CN108469998A - 一种通用型软件自动化测试框架系统 - Google Patents

Abstract

本发明公开了一种通用型软件自动化测试框架系统，包括：运行调度层，设置系统运行的调度方案；运行方案层，为运行调度层提供备选运行方案；数据分组层，针对不同测试策略、颗粒度以及测试强度将各种场景进行组合，形成各种自定义形式的测试分类；场景层，完成特定的业务流程或操作，以及预定义可参数化场景，用于实例化场景的调用；数据集层，作为场景层复杂数据的输入与输出，由不同结构的数据类封装整合而成；数据类层，定义数据集中不同结构数据类型的结构属性；数据记录层，为记录型结构的数据类提供实际的记录型数据。本发明适应不同应用类型和环境，实现协同工作和迭代进化，大大降低编码量，大幅度提高了编码开发与维护的灵活度和适应性。

Description

一种通用型软件自动化测试框架系统

技术领域

本发明涉及软件测试领域，具体涉及一种通用型软件自动化测试框架系统。

背景技术

早期的脚本录制方式的自动化测试技术，测试人员无需掌握很好的编码技术，就能够比较方便快速地形成测试脚本，但是因为脚本由机器生成，可读性很差，二次定制和后期维护的成本极其高昂，完全无法适应变化多端的软件形式，很早就被淘汰了。

结构化的分层次自动化测试技术，虽然初步实现了编码的分层，在一定程度上将处理与数据进行了解耦，但是编码的技术要求比较高，编码效率较低，编码质量无法保证，并且其设计是针对特定的应用项目，编码复用率也无法提高，这将导致测试工作只能由少数技术能力较强的技术人员参与，无法形成有效的测试分工；技术复杂度的提升，使得测试工作对于业务洞察能力相应降低；编码周期较长，很难跟上开发交付的节奏；缺少一致化的编码标准，突出了个性，阻碍了工程化发展；需求与设计的频繁变更，将涉及到控制流程的改变，测试编码的迭代变更通常成本高昂，并且可靠性无法保证。

针对具体项目进行设计的自动化测试编码，很难实现在一个统一的设计框架下，同时容纳多个项目的自动化编码的编制工作与运行，这让同一个公司的不同项目需要在分隔开的基础上各自构建自己的代码体系，产生大量的重复性工作，资源无法共享，标准无法统一，编码效率低下，管理流程通常都处于比较混乱的状态。

上述问题限制了自动化测试的可应用范围，随着软件开发从传统的全生命周期向敏捷化过渡，整个测试行业包括自动化测试技术手段面临严峻考验，总体表现堪忧，尤其当软件开发进一步延伸到运维环节，在新的Devops管理流程中，自动化测试技术手段的不足，严重限制了Devops的有效实施，成为整个开发-测试-交付-运维等诸多环节中最窄的一个瓶颈。

在整个软件设计开发的历史中，测试工作或者说软件的质量保证工作，是伴随着软件开发发展到一定程度上而逐步开始成型的。包括软件工程的提出，也是将陈述的重点放到设计开发的各个环节中，早期的软件工程对测试工作提及较少。到了敏捷时代和devops时代，这些新方法论的提出和管理模型的设计，测试都不是首先出场的角色，甚至在这些方法论中以及很多模型中，测试的角色都是缺位的，具体的实践中通常会采用生命周期模型来补足测试的管理流程。由于这些嫁接过来的测试流程存在先天的不适应性，导致无论手工测试还是自动化测试工作的开展，都远不如生命周期模型中的表现。

在测试方法论上，还没有提出来一个能够适应当前敏捷和devops这样快节奏交付的新理念，在技术上，与日新月异的开发技术相比较，测试技术的发展要缓慢而保守得多，缺少有价值的创新点，直接的后果就是交付质量的下降和测试行业的萎缩。并不是软件质量变得不重要，而是目前的趋势，测试工作日益融合在开发设计的环节中，并由所谓的开发测试角色来承担，形成的矛盾就是技术实现与业务洞察的剧烈冲突。

综上所述，测试的工作要想跟上当前软件发展的现状，需要在测试方法论和测试技术两方面都有所突破和创新，走开发测试这条路仅仅是临时的变通，并不是真正的解决问题之道。

手工测试仍然有不可取代的地位，但是越来越多的领域将采用自动化的手段适应快速交付和反复迭代的要求，其面临的挑战就是如何充分提炼自动化测试活动中不变的部分与异变的部分，并采取有效的技术手段加以分隔。

新的自动化技术需要满足分工合作的要求，让技术归技术，业务归业务，不同类型的人员都能在其中发挥各自的特长，并让测试工作为开发提供业务洞察；新的自动化技术需要兼顾手工测试，使得手工测试的成果能够被自动化技术有效继承，避免重复性工作；新的技术需要具有前瞻性，即能够满足当前的测试工作要求，也要为未来新的测试方法论提供技术支持。

发明内容

本发明设计思想中最核心的目标就是从自动化测试活动中提炼出不变的部分与异变的部分，并采取有效的技术手段加以横向的分隔与纵向的分层，这样的设计目标带来的好处包括：满足分工合作的要求，并让测试工作为开发提供业务洞察；兼顾手工测试，使得手工测试的成果能够被自动化技术有效继承，避免重复性工作；能够满足当前的测试工作要求，也要为未来新的测试方法论提供技术支持。

为了实现上述目标，本发明所采用的技术方案是提供一种通用型软件自动化测试框架系统，该系统对各项测试活动进行充分的数据化，并将数据划分成多个有效分层，包括：

运行调度层，作为系统的最高层，用于设置系统运行的调度方案；

运行方案层，作为中间过渡层，为所述运行调度层提供备选的运行方案，用于组织不同类型的数据分组，供所述运行调度层进行操作；

数据分组层，针对不同测试策略、颗粒度以及测试强度将各种场景进行组合，形成各种自定义形式的测试分类；

场景层，完成特定的业务流程或操作；预定义可参数化场景，用于实例化场景的调用；

数据集层，作为场景层复杂数据的输入与输出，由不同结构的数据类封装整合而成，每个数据类在数据集层中具有严格的顺序关系；

数据类层，定义数据集中不同结构数据类型的结构属性，包括控件型、记录型以及文件型三种不同结构数据类型；

数据记录层，为数据类层中记录型结构的数据类提供实际的记录型数据，为场景层中的内置函数提供记录型数据的输入以及用于测试结果校验时有关记录型期待结果的比对。

优选地，所述运行调度层设置的调度方案，主要要素包括调度运行的应用系统、运行的预定义方案、运行时用到的记录分类与记录分级以及运行的优先级；

同一个运行的应用系统允许有多个运行的预定义方案，用于不同的测试目的；

调度运行的记录分类与记录分级用来设置测试的颗粒度和覆盖范围；

运行优先级用来定义运行时的先后顺序，按照优先级序号从小到大依次运行，相同的优先级允许并行运行，相同优先级全部执行完毕，再开始下一个优先级的执行。

优选地，所述运行方案层提供的每个运行方案对应于具体的应用系统，包含多个数据分组，不同的数据分组具有不同的分组序号，在运行方案执行的过程中，数据分组按照分组序号依次执行，相同分组序号的数据分组允许并发执行，当相同分组序号的数据分组全部执行完毕后，才开始下一个分组序号的数据分组的执行。

优选地，所述数据分组层中的数据分组对应于具体的应用系统，形成的测试分类的定义主要包括：场景、运行级别、运行顺序号，其中，场景通过运行级别进行分组，通过运行顺序号进行排序，在执行测试的过程中，按照运行顺序号依次执行，相同运行级别允许并发执行。

优选地，所述场景层中的场景对应于具体的应用系统，场景分为两种类型，一种是普通场景，用来执行测试；另一种是参数化场景，由普通场景进行调用实现其实例化；

场景按照测试目标的不同由数据分组进行组织，同一个场景可以包含在多个数据分组中；

场景的定义主要包含操作步骤、操作序列、参数类型、参数、引用的数据集以及保存结果标识；

一个面向具体应用的业务场景，由一系列串行式的操作步骤组成，由操作步骤序号来决定执行顺序，组成场景的各步骤不允许有相同的操作步骤序号，每个操作步骤中包含一个操作序列，按照定义的先后顺序执行；

操作序列中具体的操作为一个独立的函数，包括两种函数类型，一种是内置函数，引用时需要在函数名字前加一个前导符；一种是预定义函数，不需要添加前导符；不同的操作需要用特殊符号进行分隔。

优选地，所述预定义函数为参数化场景，由内置函数定义而来；场景执行的时候，需要为内置函数提供输入与输出的参数，这些参数的引用、参数类型定义及参数值调用格式需要做出明确的规定；

参数直接在内置函数中进行引用，内置函数的参数值与不同预定义函数的参数值之间进行分组，第一个分组固定为内置函数参数值分组，第二个分组为第一个预定义函数参数值分组，第三个分组为第二个预定义函数参数值分组。

优选地，所述内置函数或预定义函数需要引用数据集作为复杂结构数据的输入与输出，数据集直接在内置函数中进行引用，数据集的调用格式分为两部分，第一部分固定为内置函数的数据集分组，第二部分为不同预定义函数的数据集分组，其中每个预定义函数按照其在操作序列出现的顺序再进行分组，不同分组需要进行分隔。

优选地，所述数据集对应于具体的应用系统，为排序的数据类的集合，由操作步骤中的内置函数引用，分为两种类型，一种为输入数据集，为所述场景层提供数据输入，另一种为期望数据集，定义应用系统在执行测试场景时期望输出的数据结果，用于与应用系统实际运行时的结果做比对。

优选地，所述数据类层对应于具体的应用系统和数据集，一个或者多个不同结构的数据类封装整合成一个数据集，数据集中的不同结构数据类型具体包括：

控件型，用于定义应用系统界面上的空间属性；

记录型，用于定义内置函数记录型输入输出数据的结构属性；

文件型，用于定义输入输出文件的名称及存储路径。

在上述技术方案中，所述数据记录层采用记录作为数据组织形式，每条记录对应具体的应用系统、数据集和数据类，并且包含记录分类与记录分级用于所述运行调度层的控制处理；所有数据均采用字符串类型存储，实际应用时，根据数据记录层对应字段的属性定义进行数据类型的转换。

本发明提供的一种通用型软件自动化测试框架系统，能够适应不同应用类型和环境，能够实现协同工作和迭代进化，通过多个层次的抽象解耦，不但大大降低了编码量，并且在保证质量的前提下，编码的开发与维护都获得相比以往更大的灵活度和适应性。

本发明具体包括以下优点：

(1)对于编码技术掌握比较好的人，可以承担有关内置函数、预定义函数的设计，因为屏蔽了控制细节，这部分编码都是相互独立的小程序，编码质量可以得到保障，编码效率能够大大提高；

(2)对于业务把握比较好的，可以承担场景设计和测试数据的构建与维护，这不需要掌握编码技术，因此能够将精力放到业务洞察的环节上，也可为开发提供及时的测试数据；

(3)测试执行可以由各种类型的测试人员来启动不同类型的测试调度；

(4)管理人员与终端用户也可以执行他们感兴趣的测试调度，因为有效的分层使得测试执行工作变得简单易懂。甚至在应用系统上线之后，也可以执行相应的监测调度，观察系统的运行状态，增加测试覆盖，持续检测系统的潜在缺陷；

(5)动态的操作已经实现静态化，后期的维护工作，其实已经不再是编码了，而是一系列操作代码的组合。附加在测试数据的各种封装与属性的定义，要求对于测试数据必须采用工程化的管理模式，这就让测试数据的质量、可用性和灵活度大大提高；

(6)运行测试调度可以针对同一个运行方案，随时调整不同的记录分类与记录分级，以便改变不同的测试颗粒度和覆盖范围；

(7)本发明在保证编码质量的前提下，编码的开发与维护获得相比以往更大的灵活度和适应性。

附图说明

图1为本发明提供的一种通用型软件自动化测试框架系统的控制流程图；

图2为本发明提供的一种通用型软件自动化测试框架系统的场景控制流程图；

图3为本发明提供的一种通用型软件自动化测试框架系统的场景的操作步骤控制流程图。

具体实施方式

本发明提出了一种通用型软件自动化测试框架系统，在此基础上，通过嵌入不同的对象以及信息捕捉工具，比如selenium等，实现具有操作系统和应用环境无关性的通用型软件自动化测试框架。充分提炼自动化测试活动中不变的部分与异变的部分，并采取有效的技术手段加以横向的分隔与纵向的分层；满足分工合作的要求，并让测试工作为开发提供业务洞察；兼顾手工测试，使得手工测试的成果能够被自动化技术有效继承，避免重复性工作；能够满足当前的测试工作要求，以及为未来新的测试方法论提供技术支持。

下面结合说明书附图和具体实施方式对本发明做出详细的说明。

本发明提供了一种通用型软件自动化测试框架系统，对各项测试活动进行数据化，并将数据再划分成多个有效分层，从而在高内聚、低耦合的基础上，将处理的细节进行封装屏蔽，让更高的层次获得更便捷而自由的操纵空间。所划分的数据分层包括：

运行调度层10，该层次作为系统的最高层，用于设置系统运行的调度方案。

该层次的使用者既可以是普通的测试执行人员，也可以是普通的用户，因为预定义的运行方案都有比较明确的测试目的性，把握这个目的性所需要的更多是业务方面的知识背景，而不是更细节的技术控制流程。

其中，调度方案主要要素包括调度运行的应用系统、运行的预定义方案、运行时用到的记录分类与记录分级以及运行的优先级；同一个运行的应用系统允许有多个运行的预定义方案，用于不同的测试目的；调度运行的记录分类与记录分级(记录分类与分级在数据记录层70中进行定义)用来设置测试的颗粒度和测试的覆盖范围，在具体的项目中，相关的含义都将能够进行明确的定义，如何将具体执行的数据进行有效的分类与分级管理，其实就需要发展一种完善的对数据进行工程化管理的流程。系统经过充分的抽象，实现了从调度方案到操作数据的层层递进，实现了测试活动的全角色、全过程参与，实现了编码测试到交付监控的有机结合。所有层次的工作成果都通过运行调度层10中不同调度方案的执行来体现。

运行优先级用来定义运行时的先后顺序，按照优先级序号从小到大依次运行，相同的优先级允许并行运行，需要注意的是，只有相同优先级全部执行完毕，才能开始下一个优先级的执行。

运行方案层20，作为中间过渡层，为运行调度层10提供备选的运行方案，每个运行方案都对应于具体的应用系统，用于灵活地组织不同类型的数据分组，供运行调度层10进行操作。

每个运行方案允许包含多个数据分组，不同的数据分组之间具有不同的分组序号，在运行方案执行的过程中，数据分组的执行按照分组序号依次进行，分组序号允许相同，在这种情形下，这些具有相同分组序号的数据分组将允许并发的执行，以便提高执行效率，需要注意的是，只有相同分组序号的数据分组全部执行完毕后，才能开始下一个分组序号的数据分组的执行。

数据分组层30，针对不同测试策略、颗粒度以及测试强度将各种场景进行组合，形成各种自定义形式的测试分类。

数据分组定义中主要包含场景、运行级别和运行顺序号，其中，场景通过运行级别进行分组，通过运行顺序号进行排序，在执行测试的过程中，按照运行顺序号依次执行，相同运行级别允许并发执行。

场景的详细情形在场景层40中进行定义，一个数据分组包含多个场景，场景的运行逻辑通常有比较严格的顺序控制，运行顺序号规定了不同场景运行时的顺序关系，相同的运行顺序号允许并行运行，不同的运行顺序号，依照排序依次运行。需要注意的是，只有相同运行顺序号的场景全部执行完毕，才能开始下一个运行顺序号场景的执行。

数据分组层30中的数据分组对应于具体的应用系统，但不归属于特定的运行方案，用于将场景组合起来，类同于传统的测试分类，同一个数据分组可以同时隶属于不同的运行方案。传统的测试理论中，测试类型包括单元测试(UT)、功能测试(ST)、系统集成测试(SIT)以及验收测试(UAT)等等，这些固定类型的测试分别应用在不同阶段和场合，实现不同的测试目标。

在新的测试理念中，数据分组能够继承但不局限于传统的测试分类，一个数据分组既可以直接一一对应传统的测试分类，也可以将这些测试重新打散、混合、再分类，也可以是这些粗线条的测试分类的一种细化，能够针对不同测试策略、颗粒度以及测试强度进行自定义形式的测试分类。具体地，数据分组的设计主要是面向业务逻辑的，而传统的测试分类更多面向技术实现，两者设计的出发点有着本质的不同。

场景层40，每个场景对应于具体的应用系统，完成特定的业务流程或操作，也可用于预定义可参数化场景，类似于封装的类，用于实例化场景的调用。

在传统意义上，场景类同于测试用例，场景对应于具体的应用系统，场景分为两种类型，一种是普通意义上的场景，能够用来执行测试，另一种为参数化场景，由其普通场景进行调用实现其实例化，场景按照测试目标的不同由数据分组进行组织，同一个场景可以包含在多个数据分组中；

场景的定义主要包含操作步骤、操作序列、参数类型、参数、引用的数据集以及保存结果标识；

一个面向具体应用的业务场景，由一系列串行式的操作步骤组成，由步骤序号来决定执行顺序，组成场景的各步骤不允许有相同的操作步骤序号，每个操作步骤中包含一个操作序列，按照定义的先后顺序执行；

操作序列中具体的操作为一个独立的函数，包括两种函数类型,一种是内置函数，引用时需要在函数名字前加一个前导符“&”，一种是预定义函数，不需要添加前导符；不同的操作需要用特殊符号“#”进行分隔；

内置函数是采用java语言实现的一个元操作，实现诸如点击按钮，为一个字段输入数据等操作，内置函数之间是非耦合非状态的，没有复杂的控制流，这相对来说保证了编码的简便性，以良好可控的质量用来执行一个元操作，比如点击按钮，为一个输入字段输入数据，在不同控件间进行跳转等等。这些元操作可以由系统提供基本操作集合，也可以根据项目的特点要求进行后期定制。这些相互独立的函数不涉及复杂的控制流，属于轻量级开发，因此编码简单，质量稳定，可以快速定制。

预定义函数也就是预定义的参数化场景，这些参数化的场景能够在设计具体的场景中直接被看作一个封装好的操作，与内置函数一起引用。预定义函数提炼具有共性的操作序列并进行封装，能够大大简化场景的构建工作，并使得维护工作也大大简化。

预定义函数能够进行两级分类定义和管理，也就是全局级和应用系统级，一个应用系统能够引用本应用系统级和全局级的预定义函数，不允许引用其它应用系统的预定义函数，预定义函数也不能嵌套定义。

参数类型、参数及数据集为内置函数和预定义函数提供输入与输出的数据。

保存结果标识用来定义是否将本步骤各操作序列的执行结果保存在输出报告中。

一个场景步骤中操作序列由内置函数或预定义函数组成，其中预定义函数为参数化场景，也是由内置函数定义而来。场景执行的时候，需要为内置函数提供输入与输出的参数，这些参数的引用、参数类型定义及参数值调用格式需要做出明确的规定。

参数直接在内置函数中进行引用，引用的格式形如：&P1，&P2，....&Pn，其中前导符“&”表明该位置为引用一个参数或数据集，而不是实际数据，P代表这是一个参数，P后面的数字表示参数的序号。比如&JS(&P1)，含义就是内置函数JS引用第一个参数。

参数的类型定义写法形如：&S,&D,&I,其中&后面的字母代表参数数据类型，以逗号分隔，其定义的顺序与参数的顺序一致。比如上述的例子，说明参数P1、P2、P3的参数类型分别为：S、D、I。合法的参数类型：C:CHAR；S:STRING；D:DATE；T:TIME；A:DATETIME；I:INT；F:FLOAT；B:BOOLEAN。

参数值的调用格式定义分为两部分，由于在场景步骤中，定义操作序列时引用了预定义函数，而预定义函数的参数引用与参数类型在参数化场景中已经做了定义，因此在实例化的场景步骤中不会重复定义，但是在提供具体参数值的时候，需要为这些预定义函数和内置函数进行明确的界定，因此规定，内置函数的参数值与不同预定义函数的参数值之间进行分组，分组采用“#”进行分隔，每一个分组内部采用“，”将不同参数值进行分隔。第一个分组固定为内置函数参数值分组，第二个分组为第一个预定义函数参数值分组，第三个分组为第二个预定义函数参数值分组，依次类推。比如：111,AAA#222,BBB#333,CCC，则111,AAA分别为内置函数P1、P2的值；222,BBB分别为第一个预定义函数中P1、P2的值；333,CCC分别为第二个预定义函数中P1、P2的值。即使内置函数或者预定义函数没有参数，对应的分隔符“#”也仍然不能省略。

一个场景步骤中操作序列的内置函数或预定义函数需要引用数据集作为复杂数据的输入与输出。

数据集直接在内置函数中进行引用，引用的格式形如：&D1，&D2，....&Dn，其中前导符“&”表明该位置为引用一个参数或数据集，而不是实际数据，D代表这是一个数据集，D后面的数字表示数据集的序号。比如&JS(&D1)，就是内置函数JS引用第一个数据集。

数据集属于复杂数据，数据集本身没有类型，不需要进行类型定义，预定义函数引用数据集无需提供具体的数据集名称。

内置函数引用数据集类同于参数值的调用规则，具体来说，数据集的调用格式分为两部分，第一部分固定为内置函数的数据集分组，第二部分为不同预定义函数的数据集分组，其中每个预定义函数也要按照其在操作序列出现的顺序再进行分组，不同分组需要采用“#”进行分隔，每一个分组内部采用“，”将不同数据集进行分隔。除了第一个分组固定为内置函数数据集分组外，第二个分组为第一个预定义函数数据集分组，第三个分组为第二个预定义函数数据集分组，依次类推。比如：DS1,DS2#DS3,DS4#DS5,DS6，则DS1,DS2分别为内置函数中D1、D2的值；DS3,DS4分别为第一个预定义函数中D1、D2的值；DS5，DS6分别为第二个预定义函数中D1、D2的值。即使内置函数或者预定义函数没有数据集，对应的分隔符“#”也仍然不能省略。

场景按照测试的不同类别由数据分组进行组织，同一个场景可以包含在多个数据分组中。

一个场景包含多个操作步骤，不同操作步骤有严格的执行顺序，一个场景不允许有相同的操作步骤序号，每个操作步骤中又包含一个操作序列，按照定义的先后顺序执行。

无论是实例化场景还是参数化场景，其操作序列所需要引用的参数类型都只在场景的步骤1进行定义，实例化场景的参数值与数据集也只在场景步骤1提供，也就是说参数的定义与参数值和数据集的导入都是在场景级别进行的。需要注意的是参数化场景不提供实例化的参数值和数据集。

数据集层50，数据集对应于具体的应用系统，作为场景层40复杂数据的输入与输出，由不同结构的数据类封装整合而成，每个数据类在数据集层中具有严格的顺序关系。

一个数据集的定义是一个排序的数据类的序列，一个数据集可以由不同场景引用，并不专属于特定的场景，数据集层50主要定义的内容包括数据类和序号，这里的序号标识了数据类在数据集中的排序，序号不允许重复。

数据集类别分为两种，一种为输入数据集，另一种为期望数据集，输入数据集用来定义测试执行过程中需要输入的数据，而期望数据集则定义了应用系统在执行测试场景时期望输出的数据结果，用于与应用系统实际运行时的结果做比对。通常期望的结果包括两种类型，一种为记录型，另一种为文件类型，相关更细节的描述在数据类层60中定义。

数据类层60，定义数据集中不同结构数据类型的结构属性，数据类层60对应于具体的应用系统和数据集，一个或者多个不同结构的数据类封装整合成一个数据集，数据集中的不同结构数据类型具体包括控件型、记录型以及文件型三种不同结构数据类型。

数据类对应于具体的应用系统和数据集，数据集将一系列不同种类的数据进行统一绑定，用于特定目的的测试活动，这些绑定的数据具有一定的内在的逻辑关联，使其成为统一的整体。一个数据集内的数据类原则上不要与其它数据集的数据类相混淆，避免出现逻辑的混乱，导致后期维护的困惑。

数据类定义中将数据分为三种类型，这三种类型包括：控件型、记录型和文件型。

控件型，用于定义应用系统界面上的空间属性，包含各种需要识别的UI控件类型，比如编辑框、复选框、单选框、按钮等等，主要用于定位操作对象，每个需要识别的控件都在这里定义，控件的基本属性包括控件类型、控件描述、识别标识和识别方法等等；

记录型，包含多个字段，类似于传统数据库表中的记录，主要为内置函数提供输入或输出记录型数据结构定义。类似于数据库表，在这里进行相关各字段属性的定义，主要包括字段名称、字段类型、数据长度等等；

文件型，为输入或输出文件型数据提供文件的存储路径及文件名。

数据记录层70，为数据类层60中记录型结构的数据类提供实际的记录型数据，为场景层40中的内置函数提供记录型数据的输入以及用于测试结果校验时有关记录型期待结果的比对。

数据记录层70采用记录作为数据组织形式，每条记录对应具体的应用系统、数据集和数据类，并且包含记录分类与记录分级用于所述运行调度层的控制处理；所有数据均采用字符串类型存储，实际应用时，根据数据记录层对应字段的属性定义进行数据类型的转换。数据类层60中定义的记录类型只有结构定义，不包含具体的数据，实际的数据需要在数据记录层70中定义。

为统一管理，所有记录型的数据，都保存在一个实体数据库表中，以记录为单位进行管理。由于不同字段的数据类型具有多样性，在存储的环节一律采用字符串的形式保存，每个字段实际的字段类型在数据类层60中进行定义，并在运行的时候进行数据类型的转换。

每条数据记录都归属于一个具体的数据类，一个记录的实际存储数据字段分别形如TF1，TF2，…TFn,相当于字段1，字段2，…字段n,其字段顺序与在数据类层中定义的数据字段结构顺序一一对应。

对应于运行调度层的记录级别和记录类别，每条数据记录包含记录级别和记录类别，用来控制测试的颗粒度和覆盖范围。

同一个数据类中的数据记录需要进行分组，每个记录分组在执行一个测试场景的时候需要依次进行循环，比如说一个数据类中的记录有n个分组，那么一个场景引用这个数据类所归属数据集时，意味着这个场景需要循环执行所有步骤n次，每次依次提取下一组数据记录。

同一个数据类中的数据记录的分组，如果每个分组有多条记录，那么一个场景的步骤引用这个数据类所归属数据集时，该步骤需要依次循环执行该分组的每条记录。比如说一个数据类中的某个分组包含m条记录，那么引用这个数据类所归属数据集的场景特定步骤，在执行该记录分组时，该场景步骤需要循环执行该步骤所有操作序列m次，每次依次提取该记录分组的下一个数据记录。

记录分组的定义目的，用来重复执行一个测试场景。一个测试场景需要用几套数据进行测试，那么就可以将每一套数据按顺序进行分类，每一次循环执行这个场景，依次提取一组数据。

记录序号唯一标识一个数据类的记录，如果同属于一个记录组的数据有多条记录的时候，那么引用这个数据类的场景步骤就需要进行循环执行，每循环一次提取当前记录组的下一个记录，比如当测试一个记录型控件对不同输入数据进行合法性校验时，这样的设定就比较方便，不会产生大量的测试场景。

记录分级和记录分类用来控制测试的颗粒度和覆盖范围，当测试的数据量比较大，执行的时间比较长时，如何在测试的覆盖率和测试成本之间进行平衡，就需要用到这两个字段，这两个字段在运行调度层10进行设置。

本发明提供的一种通用型软件自动化测试框架系统的功能一共分解成7个层次，需要采用一系列的复杂控制流程，从而将这些层次的逻辑关联表达出来。这些不同层次之间的控制采用了分层循环的方式，通过逐级演进，将运行控制从业务层次的粗线条的调度，一直深入到具体的技术实现和所操作的数据细节。

数据分层的关系体现的是数据之间静态的逻辑关系，相对应的，控制流表达数据之间动态的逻辑关系，下面给出一些流程图，表达的是概念性的逻辑控制图，与实际的设计在细节上有较大的不同，但是在描述数据分层之间动态逻辑方面基本一致，采用简化的控制流程图更便于用户理顺数据与控制之间的关系。

如图1所示，为本发明提供的一种通用型软件自动化测试框架系统的控制流程图，其中，最外层的循环是有关测试方案的循环。系统能够同时容纳多个地区/公司的多个应用系统，每个应用系统都能够预先定义多个运行方案，通过设置运行开关来决定是否运行该测试方案，每个应用系统可以同时打开多个方案的开关，不同应用系统可以打开各自的开关，这些打开开关的运行方案在开始启动测试系统时，能够按照设定的执行顺序依次执行。

接下来的循环层就是数据分组层，之所以称为数据分组是因为通过这个，强调整个测试是由数据驱动起来的，而数据分组就是对数据进行的最粗线条的分类，相当于我们对于测试类型进行的分类，比如UT/ST/SIT/UAT等等。但是需要注意的是，传统测试分类多数针对的是与业务相关的技术和流程，而这里的分类则直指业务的内涵，因此两者形相似，其真实的内在目的性有着本质的不同，也因此在此循环中，可以是针对不同的业务，甚至业务的不同侧面分别进行的测试。

再接下来的循环就是场景的循环。传统的用例强调了技术的操作，在本系统中，场景的设计目标是业务流程的实现而不只是技术的操作，但是两者能够保持相对的一致性和兼容性，因此传统的用例模式仍然可以在这里用场景的方式得到体现。每个数据分组都是由一系列的场景组成的，这些场景的总和构成了一个数据分组测试表达出来的业务空间。

场景的控制设计是整个系统的关键，如图2所示，为本发明提供的一种通用型软件自动化测试框架系统的场景控制流程图，一个场景由多个步骤的执行来实现。一个场景通常面向一个业务流，或者一个业务流的片段，测试这项业务的各个环节，需要从多个维度来进行，采用多组数据进行业务各分支处理的覆盖，因此，测试一个场景往往需要多组输入数据，这些分组测试数据需要从数据集层、数据类层、和记录层中获取，每一组记录需要完整执行一次该场景的各步骤，所有记录分组依次重复执行该场景，因此场景的最外部的循环就是记录分组的循环。

为减少频繁读取数据的操作，提高系统执行效率，每次执行一个场景前，都需要将当前记录分组所包含的所有数据记录一次性提取出来，并保存在系统定义封装的数据类的各数组内。

场景的内部第一级循环就是场景步骤的循环，场景步骤需要按照步骤的顺序依次执行，不允许并行执行，每步骤中各内置函数和预定义函数所引用的数据记录在场景执行前已经预先提取出来。

如图3所示，为本发明提供的一种通用型软件自动化测试框架系统的场景步骤控制流程图，在一个场景的具体执行步骤中，包含一个操作序列，这些操作序列相互之间是独立的、非耦合的、非状态的，是采用java类程序编制的小程序，我们称之为内置函数，每个操作完成特定的不可分割的元操作(meta-operation)或者元处理(meta-process)。需要注意的是，系统提供预定义函数，在执行的过程中，这些预定义函数也需要解析成为内置函数，也就是说，整个系统实现的具体功能是由这些内置函数来决定的，系统提供基本的内置函数集，一个项目按照自己的特点可以自行增加自己的内置函数。

在执行一个场景步骤的外层，需要套接一个当前记录组所有记录的循环，类似上面所提到，每个场景需要将每个记录组依次循环一次，对于每个场景的步骤而言，如果当前记录组存在多条记录，那么每条记录都需要针对当前的场景步骤进行循环。这样设计的一个方便的理解，比如在场景的一个步骤中需要检测一个字段，i.e.用户账号字段，需要针对不同输入数据类型进行合法性校验，采用这样的方式是很合适的。

在当前记录组记录循环的下一层循环，就是针对每一个元操作或元处理的循环，也就是依次执行对应的内置函数。这些内置函数需要引用具体的参数以及数据集，参数值从场景的步骤1定义中获取，数据集所涉及的数据在整个场景执行前已经预先从数据库中提取出来，并存放在内存的数据类中。

本发明提供的一种通用型软件自动化测试框架系统，通过将复杂的软件测试情景进行多次抽象分层，将业务表达与技术实现进行多层次解耦，形成一个普适性的具有统一控制结构的设计框架。在这个设计框架之下，所有的操作首先被分解成相互独立的元操作，并由统一的控制机制将这些元操作再组合成操作序列，构成完整的业务操作流程。

新的框架系统提供基础的元操作，满足一般通用性的操作要求。针对具体的项目要求，需要定制项目专用的元操作。元操作采用JAVA编码，是独立的、状态无关的低耦合度代码，不涉及系统级的控制，主要专注于事务性处理，因此是局部的设计，便于实现与后期维护，能够在进行变更的时候，将可能产生的副作用和对系统稳定性的影响降到最低。这是将易变性与可维护性进行的最佳平衡，既保证了对不同项目的适应性要求，也保证了响应的时间性要求，并且大大降低了编码的技术实现复杂度，毕竟都不希望测试编码的复杂度超过所测试代码的复杂度。

新的框架系统无论对静态的测试数据以及动态的操作序列，都将以数据的方式，也就是采用数据库方式进行管理维护，这是对控制进行数据化解耦的关键举措。维护数据远比维护编码更直观，更便捷；维护小的程序编码，屏蔽复杂的控制细节，也能够让编程人员更加关注操作与业务的实现，提高编码效率和编码质量。测试数据将进行分级、分类，便于控制测试的范围与颗粒度。进一步的，测试数据将以工程化的模式进行规范化管理，从而将测试工作从原始的个性化状态导入工程化管理的轨道。

新的测试框架将测试准备与测试运行的各个环节整合在一起，包括编码、数据管理、业务编排、执行调度等，不同类型的专家在此平台上能够协同工作，充分发挥不同角色的特长，这将形成新的测试管理模式。这样的系统也能将开发有效地纳入测试环节，测试得以与开发进程深度融合。开发的过程中通过持续地引入测试数据，实现尽早测试的目标，甚至开发者就可以参与到项目测试元操作的设计环节中，与测试进行良性互动，实现技术实现与业务洞察的并轨运行。

在新的测试框架中，不但为交付提供测试手段，也为交付后的运维提供持续测试的能力，并且简单灵活的运行方案及调度的设计，允许终端用户也能参与到持续测试与监护的活动中来。

软件系统架构设计的奥妙，就在于如何体现高内聚、低耦合、分层次的设计思想，该通用型软件自动化测试系统的设计，通过7个层次的划分，将测试活动的各项要素进行分解。

对于编码技术掌握比较好的人，可以承担有关内置函数、预定义函数的设计，因为屏蔽了控制细节，这部分编码都是相互独立的小程序，编码质量可以得到保障，编码效率能够大大提高。

对于业务把握比较好的，可以承担场景设计和测试数据的构建与维护，这不需要掌握编码技术，因此能够将精力放到业务洞察的环节上，也可为开发提供及时的测试数据。

测试执行可以由各种类型的相关者来启动不同类型的测试调度。比如说，在开发的过程中，测试人员就在为开发准备测试数据，并由开发者执行特定的测试调度，检验代码潜在的错误，将缺陷消灭在编码的过程中，而不是后续的测试环节里，这是测试对开发进程的最好支持。让测试做他们擅长的，而不是驱使他们勉为其难地辅助编码，让整个项目缺少了业务洞察的角色。

管理人员与终端用户也可以执行他们感兴趣的测试调度，因为有效的分层使得测试执行工作变得简单易懂。甚至在应用系统上线之后，也可以执行相应的监测调度，观察系统的运行状态，增加测试覆盖，持续检测系统的潜在缺陷。

这样一个系统并不是一个面向特定项目的自动化测试系统，它是一个各种格局经过仔细设计的搭建好的框架，尽可能用最小的代价、最快捷的方式，容纳所面对的不同项目类型。没有好的分层隔离，实现这样的目标是不可能的。

其实更重要的，该设计是与敏捷思想和devops的要求紧密相关的，进一步配套的管理流程就是对敏捷方法论中有关测试这个缺失环节的补充。

在这个系统中，动态的操作已经实现静态化数据管理，后期的维护工作，其实已经不再是编码了，而是一系列操作代码的组合。附加在不同层次测试数据的各种封装与属性的定义，要求对于测试数据必须采用工程化的管理模式，这就让测试数据的质量、可用性、灵活度大大提高。对数据进行工程化管理的探索，其实就是对测试工程化管理的探索，从前充满不确定性的测试工作，能够通过这样的设计进入工程化的轨道。

本发明不局限于上述最佳实施方式，任何人在本发明的启示下做出的结构变化，凡是与本发明具有相同或相近的技术方案，均落入本发明的保护范围之内。

Claims (10)

1.一种通用型软件自动化测试框架系统，其特征在于，该系统对各项测试活动进行充分的数据化，并将数据划分成多个有效分层，包括：

运行调度层，作为系统的最高层，用于设置系统运行的调度方案；

运行方案层，作为中间过渡层，为所述运行调度层提供备选的运行方案，用于组织不同类型的数据分组，供所述运行调度层进行操作；

数据分组层，针对不同测试策略、颗粒度以及测试强度将各种场景进行组合，形成各种自定义形式的测试分类；

场景层，完成特定的业务流程或操作；预定义可参数化场景，用于实例化场景的调用；

数据集层，作为场景层复杂数据的输入与输出，由不同结构的数据类封装整合而成，每个数据类在数据集层中具有严格的顺序关系；

数据类层，定义数据集中不同结构数据类型的结构属性，包括控件型、记录型以及文件型三种不同结构数据类型；

数据记录层，为数据类层中记录型结构的数据类提供实际的记录型数据，为场景层中的内置函数提供记录型数据的输入以及用于测试结果校验时有关记录型期待结果的比对。

2.如权利要求1所述的通用型软件自动化测试框架系统，其特征在于，所述运行调度层设置的调度方案，主要要素包括调度运行的应用系统、运行的预定义方案、运行时用到的记录分类与记录分级以及运行的优先级；

同一个运行的应用系统允许有多个运行的预定义方案，用于不同的测试目的；

调度运行的记录分类与记录分级用来设置测试的颗粒度和覆盖范围；

运行优先级用来定义运行时的先后顺序，按照优先级序号从小到大依次运行，相同的优先级允许并行运行，相同优先级全部执行完毕，再开始下一个优先级的执行。

3.如权利要求1所述的通用型软件自动化测试框架系统，其特征在于，所述运行方案层提供的每个运行方案对应于具体的应用系统，包含多个数据分组，不同的数据分组具有不同的分组序号，在运行方案执行的过程中，数据分组按照分组序号依次执行，相同分组序号的数据分组允许并发执行，当相同分组序号的数据分组全部执行完毕后，才开始下一个分组序号的数据分组的执行。

4.如权利要求1所述的通用型软件自动化测试框架系统，其特征在于，所述数据分组层中的数据分组对应于具体的应用系统，形成的测试分类的定义主要包括：场景、运行级别、运行顺序号，其中，场景通过运行级别进行分组，通过运行顺序号进行排序，在执行测试的过程中，按照运行顺序号依次执行，相同运行级别允许并发执行。

5.如权利要求1所述的通用型软件自动化测试框架系统，其特征在于，所述场景层中的场景对应于具体的应用系统，场景分为两种类型，一种是普通场景，用来执行测试；另一种是参数化场景，由普通场景进行调用实现其实例化；

场景按照测试目标的不同由数据分组进行组织，同一个场景可以包含在多个数据分组中；

场景的定义主要包含操作步骤、操作序列、参数类型、参数、引用的数据集以及保存结果标识；

一个面向具体应用的业务场景，由一系列串行式的操作步骤组成，由操作步骤序号来决定执行顺序，组成场景的各步骤不允许有相同的操作步骤序号，每个操作步骤中包含一个操作序列，按照定义的先后顺序执行；

操作序列中具体的操作为一个独立的函数，包括两种函数类型，一种是内置函数，引用时需要在函数名字前加一个前导符；一种是预定义函数，不需要添加前导符；不同的操作需要用特殊符号进行分隔。

6.如权利要求5所述的通用型软件自动化测试框架系统，其特征在于，所述预定义函数为参数化场景，由内置函数定义而来；场景执行的时候，需要为内置函数提供输入与输出的参数，这些参数的引用、参数类型定义及参数值调用格式需要做出明确的规定；

参数直接在内置函数中进行引用，内置函数的参数值与不同预定义函数的参数值之间进行分组，第一个分组固定为内置函数参数值分组，第二个分组为第一个预定义函数参数值分组，第三个分组为第二个预定义函数参数值分组。

7.如权利要求6所述的通用型软件自动化测试框架系统，其特征在于，所述内置函数或预定义函数需要引用数据集作为复杂结构数据的输入与输出，数据集直接在内置函数中进行引用，数据集的调用格式分为两部分，第一部分固定为内置函数的数据集分组，第二部分为不同预定义函数的数据集分组，其中每个预定义函数按照其在操作序列出现的顺序再进行分组，不同分组需要进行分隔。

8.如权利要求1所述的通用型软件自动化测试框架系统，其特征在于，所述数据集对应于具体的应用系统，为排序的数据类的集合，由操作步骤中的内置函数引用，分为两种类型，一种为输入数据集，为所述场景层提供数据输入，另一种为期望数据集，定义应用系统在执行测试场景时期望输出的数据结果，用于与应用系统实际运行时的结果做比对。

9.如权利要求1所述的通用型软件自动化测试框架系统，其特征在于，所述数据类层对应于具体的应用系统和数据集，一个或者多个不同结构的数据类封装整合成一个数据集，数据集中的不同结构数据类型具体包括：

控件型，用于定义应用系统界面上的控件属性；

记录型，用于定义内置函数记录型输入输出数据的结构属性；

文件型，用于定义输入输出文件的名称及存储路径。

10.如权利要求9所述的通用型软件自动化测试框架系统，其特征在于，所述数据记录层采用记录作为数据组织形式，每条记录对应具体的应用系统、数据集和数据类，并且包含记录分类与记录分级用于所述运行调度层的控制处理；所有数据均采用字符串类型存储，实际运行时，根据数据类层对应字段的属性定义进行数据类型的转换。