CN103810196A - 基于业务模型进行数据库性能测试的方法 - Google Patents

Abstract

提供一种基于业务模型进行数据库性能测试的方法。该方法包括：基于业务建立所述业务的业务模型；根据所述业务模型配置与所述业务模型对应的测试信息，将配置好的测试信息保存在文件中形成测试文件；依据所述业务模型和对所述测试文件进行读取所获得的所述配置信息，测试与目标业务相关联的数据库的性能；以及将所述数据库的性能的结果作为测试结果输出。

Description

基于业务模型进行数据库性能测试的方法

技术领域

本申请涉及数据库测试，尤其涉及一种基于业务模型进行数据库性能测试的方法。

背景技术

随着数据业务的不断发展，数据库性能在很大程度上成了一个企业效率的体现。而对数据库性能的了解，我们只能通过一些测试软件来完成。

目前数据库性能测试的软件存在着两个方面的问题，一是、不能根据特定的业务进行量身的定制。二是、不能全面复杂的测试数据的性能。现有的技术中一种是只有固定的事务模型进行测试的软件，它可以测试一些特定的业务功能，例如订单下发，而像一些比较特别的业务就不能很好的进行测试。而另外有一种就只能简单的数据库查询、添加等测试，并不能达到好的效果。

比如我们经常使用通用的测试工具如tpcc，sysbench，业务模型相对比较简单。tpcc模拟的是银行用户转账模型，而我们的应用系统模型跟tpcc用户转账模型相差较大，如果采用tpcc来测试我们的数据库，由于本身的模型的差别较大，测试的结果精确度不够，可信度不高。而sysbench本身的结果更加简单，只能配置简单的sql进行测试，数据库各个表和字段无法按照真实的业务进行模拟，表和表之间的关系也没有办法表示，测试的结果相差也是很大。

目前能够真实模拟业务的方式就是在线运行真实的应用，通过真实应用测试数据的压力，而完全从业务角度进行测试，需要使用大量的应用服务器进行测试，线上数据库和应用服务器的比例是1:50左右，想模拟真实的业务测试具体数据库的瓶颈需要使用大量的测试资源，灵活性也受到限制，并不能测试到最后数据库的瓶颈。

发明内容

针对上述缺陷，本申请提供一种数据库性能测试的方法，解决在满足业务要求的情况下优化当前数据库性能测试的问题。

本申请的基于业务模型进行数据库性能测试的方法，包括：基于业务建立所述业务的业务模型；根据所述业务模型配置与所述业务模型对应的测试信息，将配置好的测试信息保存在文件中形成测试文件；依据所述业务模型和对所述测试文件进行读取所获得的所述配置信息，测试与目标业务相关联的数据库的性能；以及将所述数据库的性能的结果作为测试结果输出。

根据本申请的实施例，在该方法中，所述配置与所述业务模型对应的测试信息还包括：配置连接数据库信息，配置创建表和定义字段信息，以及配置建立业务模型信息。

根据本申请的实施例，在该方法中，所述配置连接数据库信息还包括：配置连接不同类型的数据库，通过变更数据库的类型信息，在不同类型的数据库之间切换。

根据本申请的实施例，在该方法中，所述配置创建表和定义字段信息，还包括：根据被测试数据库中的表创建业务表；配置创建的业务表的表名和字段；定义所述字段，包括定义字段名称、字段类型、字段描述，并且，采用“；”区分字段；所述字段名称与数据库中表的字段名称一致；以及各个创建的业务表中的字段类型为随机生成的不同的数据类型，字段的数值则根据业务规则来随机生成。

根据本申请的实施例，在该方法中，所述业务模型建立还包括：把业务模型中所使用到的关系数据抽象成一个公用的集合，所述业务表中的数据从这个公用集合中取得，保证表和表之间的关系。

根据本申请的实施例，在该方法中，所述配置创建表和定义字段信息，还包括：对创建的业务表和字段的顺序进行定制，创建的业务表中的信息跟目标业务的信息保持一致，并对各个业务表的字段长度、取值范围进行配置。

根据本申请的实施例，在该方法中，所述配置建立业务模型信息，还包括：根据目标业务复杂度和/或目标业务执行逻辑，来配置所建立的业务模型的执行的方式。

根据本申请的实施例，在该方法中，所述配置建立业务模型信息，还包括：在配置好的测试文件中添加事务模型。

根据本申请的实施例，在该方法中，所述配置测试文件，还包括：测试文件中设定有不同的标签；以及对测试文件中不同的标签进行配置，定义每个标签中的信息，从而能对不同的信息加以标识，以便测试数据库性能时对测试文件的读取。

根据本申请的实施例，在该方法中，所述测试文件进行读取，还包括：根据读取的测试文件中标签的标识，解析出用于测试所述与目标业务相关联的数据库的性能的指令，模拟所述实际业务的流程以执行处理。

根据本申请的实施例，在该方法中，所述模拟所述实际业务的流程执行处理，还包括：读取出的所述业务模型中的各个事务的信息，并使用结构体链表保存；以及依据各个事务的信息，执行解析出的指令。

根据本申请的实施例，在该方法中，所述业务模型建立之前，还包括：对各种数据库进行抽象，对数据库表中字段类型及字段长度进行统一。

与现有技术相比，根据本申请的技术方案，其优点之一是可以根据具体业务定制业务模型进行测试，可以对程序执行方式进行配置，更好的模拟了实际的业务。不但能保证结果的正确性，还能保证测试的真实性。其另一优点是设备利用率高，可以用很少的设备模拟大量的应用服务器，可以节约大量的测试资源，灵活性更好。

基于本申请的方案，其对当前的数据库容量有更好的测试，从而估计结果最优，根据实际的业务场景，在测试结果的帮助下，能选择更好的硬件或进行更好的性能调优，更合理的利用资源。

附图说明

为了更清楚地说明本申请实施例的技术方案，下面将对实施例描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1是本申请基于业务模型的数据库性能测试的一具体实施方式的功能架构图；

图2是本申请基于业务模型的数据库性能测试方法的一具体实施方式的流程图；

图3是本申请基于业务模型的数据库性能测试方法的一具体实施方式中配置测试文件的流程图；以及

图4是本申请基于业务模型的数据库性能测试方法的一具体实施方式的读取测试文件执行测试的流程图。

具体实施方式

为使本申请的目的、技术方案和优点更加清楚，下面将结合本申请具体实施例及相应的附图对本申请技术方案进行清楚、完整地描述，显然，所描述的实施例仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。

本申请依据实际的业务建立业务模型，通过模拟真实的用户操作以及还原实际业务流程，来达到更全面的测试出数据库性能的目的。可以根据不同的业务来定制不同的业务模型，节约更多的资源，配置操作通用性、移植性高。

图1描述了基于业务模型的数据库性能测试方法的功能框架，其示意性地示出了本申请所述方法的三个主要的处理组成部分，其包括配置测试文件模块110，读取测试文件执行测试模块120，输出测试结果模块130。

在配置测试文件模块110中，完成对测试信息进行配置，其完成测试信息的配置后，将测试信息保存在测试文件中，这里，测试文件可以选择使用xml文件。读取测试文件执行测试模块120获取所述xml文件并进行解析，执行模拟业务操作过程的指令，进行测试处理。完成测试处理获得的测试结果传送到输出测试结果模块130，以将所述数据库性能的测试结果输出。

图2的流程更具体地体现本申请一具体实施方式的整体流程以及对应上述输入配置、读取执行和输出模块的具体处理方式。

在配置测试文件模块110中，建立目标业务对应的业务模型200。对数据库抽象和事务的抽象及关系数据库中各个表数据之间的关系抽象。业务模型通常在测试之前要确定，此后就可按正常的业务模型配置，配置信息根据业务主要流程定制和配置。

数据库的抽象

测试工具目前支持两种最主流的数据Oracle和MySQL(实际工作需要)，而目前许多测试工具只能测试Oracle或者只能测试MySQL。利用本申请的测试方法，配置连接数据库信息，这两者都能很好的支持（无需考虑数据库类型）。

对不同数据库的表字段类型中存在的差异的地方，测试程序可以进行兼容性处理，比如Oracle表示字符类型是varchar2,而在MySQL中是varchar,测试程序统一使用的字符类型String表示，比如Oracle和MySQL中日期类型及默认值是不同的，在程序中统一的使用Date表示日期类型，同时用户可以根据数据库类型配置具体日期的默认值，比如c1#Date{systimestamp}表示是字段c1是日期类型，同时使用systimestamp作为它的默认值(Oracle中日期的默认值)，c2#Date{now()}表示字段c2是日期类型，它的默认值是now(MySQL日期的默认值)，这样，尽可能抽象和统一配置，简化了配置测试文件的成本。对长度不同的字段，本方法的处理方式是取实际业务表中的每个字段的平均长度，简化配置的复杂度，同时更好的模拟了真实场景。因而，业务模型无需考虑数据库类型，字段类型也尽可能的统一，从一种数据库切换到另外一种数据，配置测试文件基本上不需要太大的改动（配置信息基本上无需修改），如平滑的从Oracle切换成MySQL。

对事务的抽象

从数据库相关的业务来说，事务密集型的业务主要就是由一系列的相关事务组成，并且事务之间有一定的逻辑顺序，每一步操作都跟上一步事务操作整整相连，同时也直接影响到下一步的操作，在本申请的配置完成后得到的测试文件中，保留了业务相关最重要的一部分，就是事务的相关性，每个事务用一个结构体来表示，由很多的结构体组成了一个队列，必须保证在上一个事务完成之前才能运行本事务，本事务操作成功以后调用下一个事务处理，这样，将业务逻辑抽象成有序的几个事务。举例说，在交易中首先需要确认商品是否有库存，这个就涉及到一个事务操作，在确认存在库存的情况下，用户才可以下订单创建一笔交易，在创建一笔交易成功的情况下，用户才可以使用银行卡进行支付，每个过程都包含一些若干事务的处理。在建立业务模型时，就可以根据这些处理过程进行灵活事务配置，保证业务处理真实性。

业务有由很多个关联事务组成，事务之间是顺序执行的，同时上一个事务执行结果，直接影响到后一个事务是否执行。本申请专利申请的方案中，事务当中详细的语句也是可以配置的。例如：一个业务包含T1,T2,T3三个事务，现在流程是T1->T2->T3，如果业务模型可以发生变化，比如把T2这个事务拆分成T2-1，T2-2，当前业务的流程变成T1->T2-1->T2-2->T3，配置也是很灵活的，把配置文件中T2替换成T2-1和T2-2就可以了；如果业务流程发生变化，顺序上有所调整，配置文件修改下事务顺序也就可以了；如果事务中具体的sql语句执行有所改变，具体调整事务中的sql语句即可。

对关系数据库中各个表数据之间的关系抽象

在关系数据库模型中，最重要的就是各个表之间的关联关系，在真实的业务场景中，也存在这样的情况，比如上面提到的例子，你在创建交易过程，默认交易记录里面插入一条交易信息，标明“谁”、“什么时候”、“购买了一件什么样的物品”，对应的这个物品信息肯定是在库存库中的（否则创建这种交易毫无意义），而交易记录与库存信息是存在联系的，在建立业务模型时，通过把这些关系的数据抽象成一个公用的集合，来保证各个表之间的联系，即表关系的抽象处理。每个表的数据都是从公共的集合中提取的，保证了所有表的某些属性保持一致，保留了关系数据库中最重要的表和表之间的关系。公共的集合在建立业务模型过程中得到的，从业务表的数据集和业务模型特点，我们都可以得到这个共享集合。如：每个表的数据都从共享的集合提取数据，也就是表和共享的集合产生了关系，共享的集合在每个表之间搭了一座桥。想把表A和表B关联起来，最重要的就是在表A和表B中间搭建一座桥，这个共享的集合就是这么一座桥梁。

数据库中各个表相关联的属性都在一个集合（模型）中，各个表引用的数据都从这个集合中取，这个集合把各个表关联起来了。在程序一开始的测试过程中，各个表是相互独立的，无法与其他的表关联起来，无法找到共同点。通过把共同的属性保存在一个共享的集合中，把各个表关联起来，保证了关系数据库中最基本的特点。举个列子，一般我们去注册一个网站需要填写很多的信息，比如姓名，手机号码，邮箱，收货地址等。假设这些信息都是存放在不同的表中。如何知道这些信息关联到那一个人，此时可以通过一个用户编号来关联起来，比如在姓名表中加入用户的编号，手机号码表，邮箱，收货地址表中加上同一个编号，通过用户的编号，我们可以知道某一个用户相关的所有信息，在这个里面，用户的编号就是那个共享集合元素。各个表都跟共享集合有关系，可以认为各个表间接的有这种关系。每次程序运行过程当中，共享的元素开始需要初始化一次，后面使用的时候会直接从这个集合中去获取。

通过有顺序的执行事务，保证事务执行的有序性，保留了业务最重要的特性；通过把表之间关系的抽象成一个共用的集合，来保证各个表之间数据的一致性，保留了关系数据库最重要的一部分，从而保证了本申请测试方法能够真实的模拟实际业务。

在配置测试文件模块110中，实施对测试文件进行配置的配置步骤210，完成对测试信息进行配置。这里，测试文件可以选择使用xml文件。配置测试文件的过程如图3所示。其中，测试信息包括，连接数据库信息，创建表和定义字段信息，建立业务模型信息。

其中，xml文件中的各个层次的标签，方便进行配置，同时添加一个标签基本上对之前配置没有影响，很好的符合了设计模式中的对添加开发，对修改封闭的原则。读取xml文件也很方便，通过对应的几个接口来做就可以，相当的方便和快捷。

并且，xml富标签功能，使得测试工具可以非常灵活的进行配置，固定的信息配置，比如用户名和密码，数据库schema及端口等，可以通过固定的标签进行配置，对于一些存在可变的信息，比如不确定的字段数目和变化的表的数目，也提供灵活的配置功能。对于表的字段，通过一个有规则的宽字符来表示，每个字段和字段之间以“#”分割，字符串的长度是不受限制的，因此理论上表的字段也是没有限制的，同时在测试工具中，使用了队列来表示字段，理论上长度也是不受限制的，对于表名配置，通过多个相同的表标签来配置，因为xml本身标签长度是可以动态调整的，表数量也是可以动态配置，同样在测试过程中，表是用一个链表，长度也是无限制的，可以动态配置的。

配置步骤210优选为先配置连接数据库信息310，再配置创建表和定义字段信息320，最后配置建立业务模型信息330，完成配置测试信息后，将测试信息保存在测试文件中。

下面将具体介绍配置测试文件的过程，如图3所示。

在配置连接数据库信息310时，对数据库类型，数据库用户名，数据库密码，数据库集合标识schema，数据库ip，数据库端口这几个部分进行配置。

比如，在支持MySQL和Oracle两类不同的数据库时，数据库类型可以选择MySQL或者Oracle，这里，schema在Oracle代表的是Oracle中实例名SID，在上述配置连接数据库信息310以“db标签”做为标识时，则为例如：

数据库的配置信息除了数据库类型不一致以外（Oracle或MySQL）其他的保持一致。虽然在数据库内部比如Oracle和MySQL内部不同，但从配置过程来看两者几乎没有区别，则由本申请的测试方法的配置手段，很好地抽象了此点，封装了复杂度，实现测试方法能在不同数据库中转换。

在配置创建表和定义字段信息320时，对数据库的表名、表的字段名、表的字段类型以及字段描述进行定义和赋值。

在目前主流的数据库中，主要的数据类型包括:整型，字符串，时间类型，枚举类型（甚至支持MySQL中本身不支持的按照一定规则自动增加的数字序列Sequence），这些类型数据库都是支持的，同时，按照一些应用的特点，可以生成随机的整型数据，随机的字符串数据，更好的模拟应用上各个数据分布较随机的特性。字段的数值可以根据这些规则来生成，较好的保持了业务上的特点，更准确代表了业务整体的流程。

在上述配置创建表和定义字段信息320以“tablist标签”作为标识时，则为例如：

tablist标签:

tablist标签中的“table name”表示表名，其后的中间内容表示表的各个字段的信息。

字段主要由三部分组成：名称+类型+字段描述，各个字段之间以“；”分隔开，字段名称必须与数据库中表的字段名称是一样的，包括大小写部分。

字段类型主要包含StrRand,NumRand,Date,StrList,Func,如下:

StrRand表示随机的字符串其中{}中保存的是随机字符串的长度，如C2#StrRand{6}，表示C2是一个随机的字符串，它的长度为3。

NumRand表示随机的整形，其中{}中保存的是随机整数的起始值,如C4#NumRand{10,99}，表示C4是一个在10和99之间一个整数。

Date表示日期类型，如C9#Date{’systimestamp’}表示C9是一个日期，值为当前的系统时间。

StrList表示枚举值，它的类型只能是状态集合中的某一个，比如C10#StrList{’T’,’S’}表示C10只能是T和S状态中的某一个。

Func表示自定义的类型，它的值是自定义的，根据对应名称可以在找到具体的生成规则，在关系数据库中这个字段可以用来表示各个表关联，(脚本最开始是写死在程序中,后面想着把这个从程序中抽出来了)。如A1#Func{’acc1’}表示A1是一个自定义的类型，名称是acc1，后面会根据acc1这个名称去func列表里面查找对应的值。

依据本申请测试方法的配置手段，表和字段的顺序可以进行很细粒度的定制，为了模拟真实的业务，表信息跟真实的业务是保持高度一致的，各个表的字段长度，取值范围也是可以进行配置，保证能够模拟业务真实的压力。在具体测试时所使用的测试字段长度跟实际业务中的字段的平均长度一致，最大程度上保证实际业务中的表和字段与具体测试中的表和字段一致，以确保数据库性能测试的结果真实准确。

在配置建立业务模型信息330时，根据实际的具体业务来建立一个或多个事务模型进行模拟实际的业务流程。整个业务流程由一系列事务组成，而每个事务包含若干条sql语句，主要包含select for update，update，insert，delete等，每个具体的sql都可以跟业务上处理流程一致。业务整体的流程也是通过多个事务进行模拟，这样保证测试的真实性。例如在有大型活动上线时，数据库都有超过平常几倍到十倍以上的压力，模拟用户正常的业务请求，在业务模型中配置为多用户同时登录系统，循环多次查询数据库。

在配置建立业务模型信息330中，以“test标签”作为标识时，则为例如：

test标签

压测程序里面最重要的部分，包含了func，loop和transaction:

func

func这个在上面的已经提到，主要是生成具体值是自定义的(不具备通用性)。

分成两种，db生成和程序自己生成，当type为”program”的时候具体值是测试程序生成，否则表示通过查询db生成

程序生成：

<func name=”acc1”type=”program”>”2088111”#Random(1,100000000,9)#”0156”</func>表示名称为acc1的字段，它是与测试程序生成的，由三部分拼装而成:

2088111+随机生成的1到100000000整数(Random第三个参数表示不足9位前面补0)+0156

db生成:

<func name=”acc1”>select seq_test.nextval from dual</func>

表示这个acc1通过查询db的sequence得到，

loop

表示测试循环多少次，一般设置一个比较大的数即可。

transaction:

每个transaction里面可以有很多的select,update,insert,delete,所有的sql语句都需要写成绑定变量的形式，如:

<select tab=”i_tab”>select*from I_TAB where I1=:ACC1 for update wait3</select>

tab属性表示表名，标签里面内容表示具体的查询sql，其中绑定变量名称必须能够在对应表中(程序是通过绑定变量名去对应的字段名中查找的)。

特别说明:当是纯insert语句的时候，是可以不用把一个一个字段写出来，直接写成:<insert tab=”m_tab”/>程序根据自己表名去查找所有的字段。

transaction中的note其实没有任何的含义，仅仅就是一个注释，编号而已。

基于配置建立业务模型信息330，本申请的测试方法还支持添加事务，对于不同业务来说，事务的次数和每个事务具体内容是需要定制的，本申请的测试方法中，使用了xml来进行事务的配置，每个事务之间通过<transaction>标签分割，由于xml支持多级的标签，因此事务的配置可以非常灵活，测试过程中，如果需要添加一个事务，在配置文件中对应增加一个<transaction>标签，xml文件特性让事务配置有很高的灵活性。在程序的内部，也是通过事务链表来实现的，由链表来保存事务的信息，链表相对于数组来说，有更好的灵活性，数组相对来说有固定的长度，比如只能支持特定的事务数，而链表事务的数量是不受限制的。

这里，对于较复杂的事务处理，本申请的配置建立业务模型信息330还根据具体的业务来配置执行的方式，从而通过配置执行的方式来达到更好的处理。

比如多个逻辑分支的处理，执行A，B的操作或者A，C的操作；同时在一个事务内部，语句可以按照一定的概率执行，比如20%的情况下执行A操作，80%的情况执行B操作，这些操作都能正常很好地得到执行。A、B、C可以是执行处理的A语句、B语句、C语句，对应着相应的处理操作。

根据复杂的业务逻辑进行一定的逻辑判断来完成操作。比如，当A操作成功的时候，执行B操作，否则的话执行C操作，这些稍微有点的复杂的业务处理逻辑更真实反映了业务上的操作。

与业务相关的配置信息在上述配置之后全部保存到xml文件中，下面是一个示例：

接着，在读取测试文件执行测试模块120中，实施对配置完的测试文件即配置文件的读取和测试过程的执行的操作，即读取测试文件执行测试步骤220，以完成对获取的配置文件的读取、保存、执行处理。读取测试文件，比如通过对xml文件解析来完成。程序会根据配置文件中表和字段的配置信息，依次进行读取，读取完成以后，程序解析出各个表的字段类型。在支持通用的数据类型以外，还支持个性化的数据类型，比如一些订单编号信息，程序可以完全按照业务上的特性进行拼装，比如，在某类事务为订单服务过程中，订单编号由一些特定的规则组成:固定的字符串+日期+序列号，程序都可以方便的解析这些规则。

表和各个字段信息预处理完成以后，系统会读取各个事务的信息，按照顺序，存入到一个结构体链表中。事务当中包含了若干个sql语句，简单的业务就是顺序的依次执行，部分程序业务逻辑稍微有点复杂，程序可以进行一定的逻辑判断来完成操作。

解析测试文件的过程即对输入进行加工的过程（至此所有程序的预处理工作完成），通过解析配置文件，获取了数据库的连接信息；通过读取和解析表的配置信息，得到了整个业务涉及到的表和具体字段的信息，通过解析事务，得到各个事务处理的整体过程及执行sql的逻辑。这些准备及预处理工作完成，程序已经得到了执行的指令，根据用户配置的线程数的大小，程序开始开启多个线程，每个线程执行业务的指令。模拟这个现场的业务操作过程，再运行到指定的次数以后，程序运行完成。

如图4所示，从xml配置的测试文件中获取测试信息401，开启多线程测试403，最后输出测试结果405到输出测试结果模块130。

在进入输出测试结果步骤230中，程序得到执行的指令，根据用户配置的线程数的大小，程序开始开启多个线程，每个线程执行业务的指令。模拟整个的业务操作过程，类似一种仿真方式（对真实业务处理的模拟），在运行到指定的次数以后，程序运行完成，测试结果传送到输出测试结果模块130，输出事务响应时间，最大，最小的响应时间及平均响应时间。

本申请可以在由计算机执行的计算机可执行指令的一般上下文中描述，例如程序模块或单元。一般地，程序模块或单元可以包括执行特定任务或实现特定抽象数据类型的例程、程序、对象、组件、数据结构等等。一般来说，程序模块或单元可以由软件、硬件或两者的结合来实现。也可以在分布式计算环境中实践本申请，在这些分布式计算环境中，由通过通信网络而被连接的远程处理设备来执行任务。在分布式计算环境中，程序模块或单元可以位于包括存储设备在内的本地和远程计算机存储介质中。

最后，还需要说明的是，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、商品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、商品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、商品或者设备中还存在另外的相同要素。

本文中应用了具体个例对本申请的原理及实施方式进行了阐述，以上实施例的说明只是用于帮助理解本申请的方法及其主要思想；同时，对于本领域的一般技术人员，依据本申请的思想，在具体实施方式及应用范围上均会有改变之处，凡在本申请的精神和原则之内，所作的任何修改、等同替换、改进等，均应包括在本申请的权利要求范围之内。综上所述，本说明书内容不应理解为对本申请的限制。

Claims (12)

1.一种基于业务进行数据库性能测试的方法，所述方法包括：

基于业务建立所述业务的业务模型以模拟所述业务的流程，其中，所述业务包含一个或多个事务；

根据所述业务模型配置与所述业务模型对应的测试信息，将配置好的测试信息保存在文件中形成测试文件；

依据所述业务模型和对所述测试文件进行读取所获得的所述配置信息，测试与目标业务相关联的数据库的性能；以及

将所述数据库的性能的结果作为测试结果输出。

2.根据权利要求1所述的方法，其特征在于，根据所述业务模型配置与所述业务模型对应的测试信息还包括：

配置连接数据库信息，配置创建表和定义字段信息，以及配置建立业务模型信息。

3.根据权利要求2所述的方法，其特征在于，所述配置连接数据库信息还包括：

配置连接不同类型的数据库，通过变更数据库的类型信息，在不同类型的数据库之间切换。

4.根据权利要求2所述的方法，其特征在于，所述配置创建表和定义字段信息，还包括：

根据被测试数据库中的表创建业务表；

配置创建的业务表的表名和字段；

定义所述字段，包括定义字段名称、字段类型、字段描述，并且，采用“；”区分字段；

所述字段名称与数据库中表的字段名称一致；

各个创建的业务表中的字段类型为随机生成的不同的数据类型，字段的数值则根据业务规则来随机生成。

5.根据权利要求4所述的方法，其特征在于，所述业务模型建立还包括：

把业务模型中所使用到的关系数据抽象成一个公用的集合，所述业务表中的数据从这个公用集合中取得，保证表和表之间的关系。

6.根据权利要求4所述的方法，其特征在于，所述配置创建表和定义字段信息，还包括：

对创建的业务表和字段的顺序进行定制，创建的业务表中的信息跟目标业务的信息保持一致，并对各个业务表的字段长度、取值范围进行配置。

7.根据权利要求2所述的方法，其特征在于，所述配置建立业务模型信息，还包括：

根据目标业务复杂度和/或目标业务执行逻辑，来配置所建立的业务模型的执行的方式。

8.根据权利要求2或7所述的方法，其特征在于，所述配置建立业务模型信息，还包括：在配置好的测试文件中添加事务模型。

9.根据权利要求1所述的方法，其特征在于，所述配置测试文件，还包括：

测试文件中设定有不同的标签；

对测试文件中不同的标签进行配置，定义每个标签中的信息，从而能对不同的信息加以标识，以便测试数据库性能时对测试文件的读取。

10.根据权利要求1所述的方法，其特征在于，对所述测试文件进行读取，还包括：

根据读取的测试文件中标签的标识，解析出用于测试所述与目标业务相关联的数据库的性能的指令，模拟所述实际业务的流程以执行处理。

11.根据权利要求10所述的方法，其特征在于，所述模拟所述实际业务的流程执行处理，还包括：

读取出的所述业务模型中的各个事务的信息，并使用结构体链表保存；

依据各个事务的信息，执行解析出的指令。

12.根据权利要求1所述的方法，其特征在于，所述业务模型建立之前，还包括：

对各种数据库进行抽象，对数据库表中字段类型及字段长度进行统一。

Images