专注于软件性能测试与自动化测试的学习与应用

软件性能测试中的数据建模

上一篇 / 下一篇  2011-03-24 21:14:55 / 个人分类:软件性能测试

软件性能测试中的数据建模

1为什么要数据建模

在性能测试过程中,一般都需要二方面的数据,即系统初始化数据与测试数据。其中,初始化数据是程序(系统)能正常运行的前提条件。这些初始化数据有些是静态数据,如程序运行的配置文件,静态配置表等一般不会变化,对性能测试的结果不会有较大的影响。但是,有些不断变化的动态数据,尤其是随着时间的推移,表记录会不断增加时,会直接影响性能测试的结果。设想一下,系统运行在一个已有1000万用户号码表记录的数据库表和一个几乎为空表的数据库表条件下,进行插入、更新、查询与删除操作的响应时间显然是不同的。测试数据是指我们在性能测试过程中,要用到的关键参数数据。试想,在计费系统中,在本地用同一个主叫号码直拨同一个被叫号码的业务场景与不同的号码采取不同的拨打方式与接听不同的号码的业务场景的测试结果是不同的。很显然,只有在最接近真实环境与场景下的性能测试才会测试出最逼近系统上线后的真实性能表现。因此,为了获得这些最真实数据环境与场景,有效的途径是进行数据建模。这里的数据建模包括二个方面,一个是基础数据建模,另一个是指业务建模。基础数据建模是构造系统初始化数据的基础。业务建模是构造测试场景与测试参数数据的依据。

基础数据建模,为了便于理解,在本文中我个人把它定义为:为了保证软件性能测试结果无限逼近系统上线后在预期负载压力的真实场景下的系统性能结果,找出真实场景下会影响系统性能的各种库表(或共享内存)中的数据记录总量及记录的类型比例。从而为构建系统性能测试时的初始化数据提供依据。

业务数据建模,同样,在本文中我个人把它定义为:为了保证软件性能测试结果无限逼近系统上线后在预期负载压力的真实场景下的系统性能结果,找出系统承载的主要一些高频繁、大量IO以及其它的核心业务的相关执行路径以及使用这些业务的比例。根据找出的业务及比例,构造相应的测试场景。

 

2建模的方法

基础数据的建模相对来说,比较容易。如在线计费系统中,三户资料的构造数据,依据需求与设计文档的容量规划进行总量的确定,而且,根据现网的实际,库表中的用户状态会分成有效,未激合及处于充值期以及其它状态。因此,在构造初始化数据时,要依据状态的不同,构造与现网接近比例的三户初始化数据。同时要注意,一般的系统出现问题,都是系统运行了一段时间或较长时间才会暴露出来,这主要是因为系统运行一段时间后,系统保存了相关结果数据在相应的库表(内存)中,从而引起的相关性能问题。而这部分的数据往往是我们较易忽略的数据,且又可能影响性能测试结果的初始化数据。如在短信计费性能测试过程中,每一个短信计费请求,会通过查询与插入短信备份表来避免短信的重复计费与补款用,因此,在现网中,任何时刻都会保存一定时间段内的短信计费记录因此,短信性能测试中,短信备份表的初始化数据就不能忽略不计。

业务数据建模相对来说,稍微复杂一些。通常有三种方法。第一种方法也是最常见的方法,系统历史运营数据的分析,历史运营数据包括不仅包括系统日志,还包括各种输出结果文件。从系统的日志分析中,了解用户的活动,分析出用户最关注、最常用的业务功能,以及达到业务功能的操作路径,这种用户的操作路径即是构建业务模型的主要骨架。此外,根据每天不同时段用户使用业务的数据统计分析,可以得出系统的闲忙时段,以及闲忙时段的业务峰值。从而为性能测试构造高峰时段的负载峰值提供计算依据。同理,分析春节、十一等节假日的极端高峰业务数据,通过综合分析与估算,可以推断出与平常峰值之间的大约比例关系。根据各业务的日志或输出结果,统计可以得出各种业务的使用业务比例等相关数据。总之,是通过这些数据,借助于统计学与估算等相关合理的计算推断出:系统承载业务的主要业务流程以及主要业务流程之间各自的业务比例关系,各业务各自闲忙时段峰值,同一时段下各业务并存的综合场景下的各自峰值的负载关系。

第二种方法为:业务调研与2:8原则分析方法。这种建模方法一般适用于新建系统,且没有相关历史运营数据与同类参考系统。通过业务需求调研,了解相关业务发生频率,做出相关业务模型。根据2:8原则,分析与估算出各业务的峰值与各业务之间的比例关系。如:200万的用户规模,其中60%用户三天内要完成开户操作。此时可通过公式计算出200万用户开户业务时每小时的高峰交易量:(200*60%*80% / 3*8小时*20%

第三种方法:参照其它厂商同类业务系统的性能测试模型。这种方法,虽说是建模最捷径的建模方法,往往不可获得,而且不同厂商承载的业务量与细节可能不同,因此不能全部照搬。

一般来说,这三种建模方法不只是被孤立的单独使用,往往是其中间的2种或3种方法的综合运用。除此之外,行业经验模型在业务建模与数据建模中起到事半功倍效果。例如,如果存在系统现网的语音、数据、短信与增值业务的比例模型,完全不必从历史清单中去分析这个模型,直接拿来就行。你所关注的是每类业务中的细分比例,如语音,你要分拨打本地电话,长途,ip等细项的划分。如果知道在线用户数与并发用户数之间的比例关系经验模型,就可以根据在线用户总量直接估算出同时加载给系统最大的并发总量压力。


TAG: 性能测试 数据建模 业务建模

引用 删除 wang123456   /   2011-04-14 15:59:54
5
 

评分:0

我来说两句

cow

cow

个人主要专注于性能测试与自动化测试方向的学习与应用

日历

« 2024-04-25  
 123456
78910111213
14151617181920
21222324252627
282930    

数据统计

  • 访问量: 12850
  • 日志数: 13
  • 建立时间: 2011-03-08
  • 更新时间: 2011-06-12

RSS订阅

Open Toolbar