性能测试模型

性能测试模型（精选8篇）

性能测试模型 篇1

摘要：随着电信运营商应用系统的规模越来越大、用户越来越多, 如何准确地评估应用系统的性能带来了很大的挑战。本文就如何准确地针对电信运营商的应用系统, 设计负载测试策略进行了深入研究, 提出了基于TPS模型的性能测试, 并描述了基于TPS模型的性能测试实施流程。

关键词：性能测试,TPS,模型,负载策略

一、引言

随着用户越来越多地依赖于WEB应用系统, 如何对应用系统进行测试成为日益迫切的问题, 但由于WEB应用的复杂性和不可预测性, 使得性能测试难度较大。

二、基于TPS模型的性能测试实施过程

性能测试的实施需要经过需求分析、测试准备、测试执行和测试报告等几个重要阶段, 在此我们重要介绍需求分析的业务模型的建立, 准备阶段测试环境的准备, 测试执行阶段TPS模型使用。

2.1业务模型建立

用户对系统性能的关注往往集中在少数几个业务活动上, 对于已经上线商用的业务支撑系统, 采用系统日志分析法, 分析出用户最关注、最常用的业务功能。

2.1.1业务数据采集与预处理

按照固定模版采集近半年的业务数据, 粒度为15分钟。对业务数据的格式进行处理, 保证颗粒度、时间维度的正确。同时, 需要对业务进行简单的归类, 去除业务之间的包含关系。

2.1.2业务建模

首先, 按照15分钟的粒度, 对15分钟的所有业务量进行求和, 并按照业务量排序, 得出15分钟业务量的排序情况;为了忽略业务量变化对系统处理能力的影响, 我们选取15分钟业务量最大的前100的数据进行分析;其次, 我们按照业务类型对前100的数据合并, 并求和、取平均, 得到按照业务类型对应的业务量;接着, 我们按照业务量排序, 并计算每支业务的占比, 筛选出占比之和在80%-90%左右的业务类型;最后, 根据筛选的业务, 并对比例进行调整, 完成业务模型的建立。在筛选业务时, 需根据业务的重要性、重量级和使用频率进行灵活调整。

2.2制定测试目标

分析系统的最大处理能力, 使用最大的15分钟业务量/15/60s, 即生产系统的TPS, 再根据测试环境和生产环境的差异, 可得到目标TPS。同时, 也可分析得到每支业务的最大TPS, 判断每支业务是否达到了目标TPS。同时, 需要指定响应时间、资源消耗等指标值, 满足性能需求。

2.3测试环境的准备

测试环境的准备包括测试工具、被测系统和测试数据的准备, 在此, 主要介绍测试环境的准备工作。测试环境与生产环境的相似度越高越能正确的反映生产系统的性能情况, 但构建一套同等规模的测试环境会成本相当高, 搭建缩小版的测试环境应遵循以下原则: (1) 测试环境与生产环境系统架构相同, 可使用低配置或者减少机器台数的情况; (2) 测试环境和生产环境操作系统、各软件版本相同; (3) 测试环境与生产环境选择同一厂商同一系列机型; (4) 测试环境和生产环境的各软件参数类似。

2.4基于TPS模型测试执行

基于TPS的模型的负载配置方法, 是基于系统的目标TPS, 以及业务的办理时间, 反向推导并发用户数的一种压力负载配置策略, 使应用系统的测试结果符合业务模型的预期。TPS模型的基本计算步骤如下: (1) 设定目标TPS; (2) 依次对每一只业务进行如下步骤: (1) 选取一支业务, 单用户执行该业务100次, 获取该业务的响应时间, 即得到每支业务的基准响应时间ART1; (2) 根据基准响应时间ART1, 计算基准TPS1, TPS1=1/ART1; (3) 根据综合场景目标TPS以及该业务占比, 计算该业务应达到目标TPS2=TPS*占比; (4) 根据基准TPS1和目标TPS2, 计算虚拟用户数, 即Vuser1=TPS2/TPS1, 对Vuser1取整得到Vuser; (5) 根据Vuser和目标TPS2, 计算基准TPS12=TPS2/Vuser; (6) 根据TPS12, 计算基准响应时间ART2=1/TPS12; (7) 计算延迟时间delay Time=ART2-ART1; (3) 根据步骤2得到的并发用户数和延迟时间, 设置测试场景; (4) 测试后, 如测试结果某交易的平均响应时间与基准ART1的值相差较大, 则替换基准ART1值, 重复步骤2, 直至两者相差10%左右。

三、结束语

本文针对电信运营商的应用系统提出TPS模型, 该模型通过应用系统的目标TPS和业务模型计算虚拟用户数, 进而从前台发起相应的业务办理, 使测试结果更加符合生产系统的实际情况, 真实评估被测系统的性能情况, 使每支业务都能达到目标TPS。

参考文献

[1]浦云明.Web应用系统负载测试[J].计算机应用与软件, 2009 (11)

[2]段念, 软件性能测试过程详解与案例剖析[M].北京:清华大学出版社, 2012

性能测试模型 篇2

服务器软件：nginx/1.02.12

端口：80

一共测试了两次：

并发级别：10

完成请求：1000

完成时间：67.009 seconds

吞吐率：14.92/s 每秒相应14.92个请求

用户平均请求等待时间：670.088 毫秒

服务器平均请求等待时间 67.009 毫秒

每个请求处理时间的分布情况，50%的处理时间在552ms内，66%的处理时间在594ms内。Percentage of the requests served within a certain time(ms)

50%552

66%594

75%647

80%692

90%877

95%1018

98%3503

99%3596

100%3930

并发级别：100

完成请求：10000

完成时间：711.398 seconds

吞吐率：14.06/s 每秒相应14.92个请求

用户平均请求等待时间：7113.977 毫秒

服务器平均请求等待时间 71.140 毫秒

每个请求处理时间的分布情况，50%的处理时间在6011ms内，66%的处理时间在6454ms内。

Percentage of the requests served within a certain time(ms)

50%6011

66%6454

75%7220

80%7566

90%9422

95%12017

98%20382

99%28455

性能测试模型 篇3

关键词：灰系统,灰预测,GM(1,1)模型,过程控制,性能测试

1 引言

自灰色预测模型[1]提出以来,就一直有在过程控制中应用的研究报道[2,3,4,5]。在20世纪90年代,甚至有灰色预测控制器的新产品面世[6]。尽管曾有专家非常看好灰色预测控制器应用推广前景,但后来的发展证明:已开发的灰色预测控制器还是存在着应用缺陷,尚未具有取代传统PID调节器的实力。为了更好地认清灰色预测模型用于过程控制时的限制条件和应用问题,有必要展开对灰色预测模型的动态特性测试和性能分析。

一个典型的灰色预测控制系统如图1所示。这种基本的灰色预测控制方法可简述为:用灰色预测模型去预测被控量y而得到z,反馈控制器所依据将是新的偏差e=r-z。最常用的灰色预测模型是单变量一阶灰色预测模型GM1(,1)。在应用中需要设定的参数有,采样周期h、建模维数n和预测步长k。

文献[7]指出:“灰色预测方法有理论依据和实用价值。但是灰色预测方法也存在一定的局限性,仅适用于原始数据非负、符合或基本符合指数规律变化且变化速度不是很快的场合”。

文献[8]指出:“在灰色预测控制中,预测步长对控制性能的影响较为显著。以系统阶跃响应为例,当采用大的预测步长时,控制器输出较为保守,能防止系统产生较大的超调,但响应速度慢、上升时间长。当预测步长小时,控制器输出变化剧烈,系统响应速度加快,上升时间短,但超调增大”。

文献[9]指出:“灰色预测的GM1(,)1模型的预测精度与建模维数有关。仿真结果表明,对波动较大的工业过程来说,维数大并不一定对控制有利。因为,老信息太多往往会淹没新信息的特点,使预测对系统的波动反映迟缓.跟踪性变差。当然,若要突出其滤波作用,维数可取大点。综合考虑,建模维数一般取为n=5为宜”。

文献[1 0]指出:“当系统进入稳态后,GM1(,)1的输入序列各值将全部相等,白化方程的参数a=0,这将导致预测值失准,反而使本应处于稳态的系统趋于发散”。

还有,采样周期的选取将直接影响灰色预测的精度。采样周期过大时,灰色预测误差的急速增长有可能恶化控制系统的动态性能,甚至破坏系统的稳定性。

对于上述对灰色预测模型性能的评价观点,这里将不从理论方法的角度深入讨论他们是否成立,而想通过专门设计的性能测试试验来求证。为此,在以下展开的测试试验中特别设计了负信号、非指数规律信号和快变信号输入测试,预测步长对预测精度的影响测试,建模维数对预测精度的影响测试,对白化方程的参数a的观测试验,以及采样周期的选取对预测精度的影响测试项目。最后,综合分析了所得到的灰色预测模型用于过程控制的测试结果,归纳了灰色预测模型用于过程控制的限制条件和动态特性特点。

2 灰色预测模型性能测试试验设计

专为测试灰色预测模型性能的试验系统设计如图2所示。其中,测试信号发生模块可产生所需的负信号、非指数规律信号、指数规律信号和快变信号等信号(y(t)、y(t+kh));数据采集模块负责采集灰色预测模型所需的序列数据(y(t-(n-)1h)、y(t-(n-2)h)、……、y(t));灰色预测模型模块可对测试信号进行标准的灰色预测GM(1,1)运算并输出预测值z(t+kh)及模型参数值a,灰色预测模型自身的三个参数(采样周期h、建模维数n和预测步长k)是可以调整的;响应曲线绘制模块用来实现预测响应、预测误差及模型参数变化曲线的绘制和显示。

灰色预测特性测试信号采用以下四种:

(1)负信号(正弦信号)

测试用的负信号是利用正弦函数产生的,如式1所示。其中,角频率为ω。这是一种正负交替的周期信号。

(2)非指数规律信号

利用式2所示的函数产生测试用的非指数规律信号。为保证信号的非负性,加上了2这个静态偏置数。

(3)指数规律信号和快速变化信号

利用如式3所示指数函数产生测试用的指数规律信号和快速变化信号。用式3产生的信号,其动态变化规律是指数规律,其变化率在初始时刻最大,可用式4算出。当需要指数规律信号时,令时间常数T=1即可。当需要快速变化信号时,可通过调整时间常数T来调整变化率的大小,T越小,变化率越大。

3 灰色预测模型性能测试响应

采用上述的测试系统和测试信号,通过MATLAB编程方法可进行所需的灰色预测模型特性测试。所获得的试验响应结果和初步分析如下。

1)负信号测试试验

当选用式1产生的正弦波作测试信号时,灰色预测模型的试验响应如图3所示。图中展示有三条曲线,分别是输入信号的当前值y(t)、k步后的值y(t+kh)和灰色预测值z(t+kh)。遵从系统分析的单因素试验法则,取预测步长k=0。根据灰色预测原理及算法,既使取预测步长k=0,灰色预测值z(t+kh)表示的是对当前值的预测,它也是根据n步前的初值y(t-(n-1)h)推算出来的。因此,取k=0,照样能体现灰色预测模型特性,而且可避开灰色预测步长变化因素带来的影响。下述的试验项目中,除预测步长影响试验项目外,都采取了k=0的处理,这样就符合了单因素试验法则,使试验数据更有说服力。由图3可见,在正弦波的过零处,输入信号的当前值曲线y(t)和k步后的值曲线y(t+kh)重合在一起,但灰色预测模型的输出曲线z(t+kh)出现了异常的尖脉冲。这部分证实了灰色预测模型不能用于负输入数据的说法。但是,更确切地说,应当是灰色预测模型不适于用于具有从正到负的过零变化的输入数据。

2)非指数规律信号试验

当测试信号是式2描述的非负的非指数规律信号时,灰色预测模型的试验响应如图4所示。可见预测曲线和实际曲线重合,这说明对于非指数规律信号,灰色预测模型能很好地跟踪和预测。所以,那种认为灰色预测模型仅适用于符合指数规律变化信号的观点是不能确立的。但是,当把图4所示响应时系统所用的采样周期值增大10倍后,就得到了如图5所示的响应。这时,灰色预测模型对当前值的预测就有了明显的偏差。可以注意到,在正弦波的波峰和波谷处的预测误差明显偏大。这又说明灰色预测模型对于不符合指数规律变化的信号,相比指数规律变化的信号,其预测误差可能会大许多。

当测试信号是式3描述的信号时,分别取T=1秒、T=05.秒、T=0.3333秒,据式4可得到等差变化的信号最大变化率:1、2、3(1/秒)。进行试验后可得如图6所示的灰色预测模型的响应。可见,灰色预测模型的预测误差和输入信号的变化率成正比,输入变化越快,预测误差越大。不过,这个误差受采样周期选值的影响很大。见图7和图8。当T=05.秒时,选较小的采样周期h=0.0 5秒时,预测误差还不明显。但是,选采样周期h=0.1秒时,在最大变化率信号处(初始时刻)的预测误差就太大了(注意图中那条严重上翘的曲线)。所以,可以推断,在采样周期不变的前提下,灰色预测模型所能适用的输入信号的变化率有一个上限。当输入信号

3)快速变化信号试验

为便于研究预测模型参数对预测精度的影响,不妨定义灰色预测模型的预测误差ε(t)如式5所示。

的变化率超过这个上限后,就会产生不能容忍的预测误差。

4)趋于不变信号试验

当输入信号趋于稳态,不再变化时,灰色预测模型的响应有可能出现发散振荡的不稳定状况,如图9所示。理论分析表明[10]:当输入信号趋于稳态时,灰色预测模型的参数a将收敛于0,而灰色预测模型输出的计算式中有项,于是可能出现被零除的数值不稳定情况。事实上,在图9所示动态过程中,还可观察到参数a的收敛过程,见图10。其收敛值约为1.1e-016。这个试验证实了灰色预测模型不能处理输入信号趋于不变的工况。而在过程控制中,使被控量趋于不变恰恰是控制的主要目标。特别是在用有限位长的单片机实现灰色预测模型计算时,小于一个量化单位的数值就被圆整为零,所以在灰色预测模型在实际中应用时更容易发生被零除的事故。

5)预测步长影响试验

在建模维数和采样周期不变的前提下,分别令预测步长为等差递进的三个数值来进行试验,可得到如图11所示的预测误差响应曲线。很明显,预测误差随预测步长的增大而增大,并且增大的速度不是等差的,而是越来越快。

6)建模维数影响试验

在预测步长和采样周期不变的前提下,分别令建模维数为等差递进的三个数值来进行试验,可得到如图1 2所示的预测误差响应曲线。很明显,预测误差随建模维数的增大而增大,并且增大的速度基本上是按算术级数的。

7)采样周期影响试验

在预测步长和建模维数不变的前提下,分别令采样周期为等差递进的三个数值来进行试验,可得到如图13所示的预测误差响应曲线。可见,预测误差随采样周期的增大而增大,并且增大的速度基本上是等差的。但是,从图4、图5、图7和图8所示的试验结果看,预测误差随采样周期的线性变化关系还不一定总是成立。在非指数规律信号输入时,或是在快变信号输入时,采样周期的增大也存在一个上限,超过了这个上限值,预测误差就可能急速增长。因此,更全面的推论或许可表述为:在预测步长和建模维数及采样周期的设定初值相对于输入信号的变化规律和频带宽度都较为适合的前提下,预测误差随采样周期的正比例变化;若其他参数无限制,则存在一个采样周期的安全设置的上限值。

4 结束语

综上所述,针对过程控制应用背景,灰色预测模型有如下七种特性:1)不适用于从正到负或从负到零的过零变化输入数据序列;2)对于不符合指数规律变化的信号也能适用,但相比指数规律变化信号的预测误差可能会大许多;3)在采样周期不变的前提下,所能适用的输入信号的变化率有一个上限,否则可能产生较大的预测误差;4)当输入信号趋于稳态时,灰色预测模型的参数将a收敛于0,于是可能出现被零除的数值不稳定情况;5)预测误差将随预测步长的增大而快速增大;6)预测误差将随建模维数的增大而线性增大;7)在其他参数较适合的前提下,预测误差随采样周期的增大而线性增大,否则存在一个安全上限值。

以上观点是依据实验研究方法得出的。若从理论角度论证,还有待研究。部分论述结果见文献[11]。

参考文献

[1]邓聚龙.灰色预测与决策[M].武汉:华中工学院出版社,1986.

[2]黄春岑,于向军,吕震中.基于灰色预测PID球磨机负荷控制[J].自动化仪表,2007,28(3):62-64.

[3]胡兆庆,毛承雄,陆继明.基于灰色预测的发电机励磁控制系统[J].电力系统及其自动化学报,2002,14(1):30-33.

[4]程启明,闵乐聪,李芹,王志萍.火电厂钢球磨煤机负荷的灰色PID控制系统研究[J].热能动力工程,2009,24(5):630-634.

[5]付建强,周志锋.灰色预测PID在水压控制系统中的应用[J].电子科技,2006,(10):45-47.

[6]李学文.新型工业过程自动控制调节器--灰色预测控制器[J].中国仪器仪表,1994,(5):28.

[7]吉培荣,胡翔勇,熊冬青.对灰色预测模型的分析与评价[J].水电能源科学,1999,17(2):42-44

[8]周自强,陈绍炳,谭浩艺,章毅.过热汽温非线性灰色预测控制研究[J].浙江电力,2009,(1):1-4.

[9]毕效辉,姚琼荟.灰色预测在过程控制中的应用[J].西南工学院学报,1997,12(3):11-16.

[10]刘宪林,杨建,王明东.励磁控制系统灰色预测PID控制仿真研究[J].郑州大学学报(工学版),2006,27(2):70-72.

确定软件性能测试性能需求的方法 篇4

如何确定软件测试性能需求的正确性是整个性能测试工作的基本前提。若不能保证性能测试需求的正确性, 即使性能测试工具选择正确, 性能测试执行顺利, 也无法保证性能测试达到预期效果, 无法对系统性能进行有效评估, 发现不了实际情况中系统出现的弱点或瓶颈。下面从性能测试目的出发, 然后再对如何确定性能测试性能需求进行分析。

1性能测试的目的

“很多人都在使用系统时, 响应时间太慢了”“完成一笔交易要花多少时间”“系统能在无错的情况下承担多大及多长的时间的负载”“哪些因素降低交易响应时间”等, 这样直观的问题描述反映了测试需求, 也由此决定了测试目的。 软件性能测试目的包括以下几个方面。

1.1评估系统能力

根据已确定的环境下测试得到的负载和响应时间等指标数据, 来验证已部署的系统能否在A条件下具备B能力, 从而能准确评估系统能力。

1.2查找系统中的瓶颈或弱点

通过测试发现系统中导致系统性能大幅下降的原因, 找到系统的瓶颈或弱点, 但在测试过程中并没有可以参照的性能指标或者是需要达到的性能目标。

1.3系统性能调优

重复进行运行测试、结果分析, 验证调整系统的活动是否达到了预期性能调优目标, 从而改进性能。

1.4验证系统稳定性、可靠性

采用系统稳定运行情况下能够支持的最大用户数, 或者日常运行用户数, 持续执行一段时间测试, 验证系统稳定性、 可靠性。

2性能需求要求

2.1系统容量要求

系统容量一般包括并发用户数、系统用户数、同时在线用户数、数据量等。

如测试系统在1 000个系统在线用户、2.0GB业务数据下, 连续运行24小时过程中, 业务动作是否稳定、有无业务处理失败;测试系统在500个并发用户的负载下, 接收邮件、 发送邮件、保存邮件等业务动作是否可行及稳定。

2.2时间特性要求

时间特性分为呈现时间和系统响应时间。呈现时间是指数据在被客户端收到的响应数据后呈现页面所消耗的时间; 系统响应时间是指应用系统从请求发出开始到客户端收到数据所消耗的时间。如系统登陆的响应时间小于3秒, 搜索页面呈现的时间平均在1 ~ 3秒。

2.3资源利用率要求

操作系统、数据库以及中间件等资源使用情况。如WEB应用服务器的CPU使用率不超过75%, 网络带宽是否满载等。

因此, 性能测试需求必须要包含在多少负载下, 进行了什么业务, 持续了多长时间, 最终需要关注怎样的指标 (交易处理性能指标、服务器操作系统资源、数据库资源、中间件服务器资源) 。了解性能需求包含哪些要求, 通过这些要求如何确定性能测试的需求。下面将介绍一些常用的性能测试需求获取方法。

3性能测试需求分析

性能测试和其他类型的测试一样, 都需要先进行测试需求分析, 进行相应的测试设计工作, 否则测试工作就没有目标。那么性能测试需求从哪里来?怎么判断出用户提出的性能测试需求是否过于理想化?

答案也和其他类型测试一样, 性能测试需求从需求文档、 各种招标文档中来, 从和项目组人员、客户交流的信息中获取。对于无法和用户直接沟通的测试人员来说, 建议先从需求、招标等文档中获得一些明确的信息点 (包括用户情况和系统运行环境情况、各个系统的运行场景) , 通过这些信息点挖掘出隐含的性能测试需求。挖掘的角度可以按照性能测试侧重的角度分析, 如:系统的用户访问量、系统的处理能力 (响应时间) 、系统的数据量、网络要求等方面。下面介绍一些理论知识及经验方法。

(1) 测试需求分析原理

80/20原理测试强度估算

80/20原理:每个工作日中80%的业务在20%的时间内完成。

举例:每年业务量集中在8个月, 每个月20个工作日, 每个工作日8小时, 即每天80% 的业务在1.6个小时内完成。 2015年全年处理业务约100万笔, 其中15%的业务处理中每笔业务需对应用服务器提交7次请求;其中70%的业务处理中每笔业务需对应用服务器提交5次请求;其余15%的业务处理中每笔业务需对应用服务器提交3次请求。根据以往统计结果显示, 每年的业务增量为15%。考虑到今后3年业务发展的需要, 测试需按现有业务量的两倍进行。

每年总的请求数为:

每天请求数为:1000/ (20x8) =6.25万次/天

每秒请求数为: (62500x80%) / (8x20%x3600) =8.68次/秒

即服务器处理请求的能力应达到9次/秒。

(2) 需求分析方法

任务分布图方法

使用任务分布图方法应关注两点:

第一, 有哪些交易任务;

第二, 在一天的某些特定时刻系统都有哪些主要操作。

交易混合图方法

使用交易混合图方法应关注三点:

第一, 系统日常业务主要有哪些操作, 高峰期主要有哪些操作;

第二, 数据库操作有多少;

第三, 如果任务失败, 商业风险有多少。

用户概况图方法

使用用户概况图方法应关注两点:

第一, 哪些任务是每个用户都要执行的;

第二, 针对每个用户, 不同任务的比例如何, 根据不同的部门用户进行模拟角色的负载压力。

4结语

性能需求分析是整个性能测试工作开展的基础, 一个准确、良好的系统性能需求能够制定出性能测试策略、内容以及环境的搭建和测试工具的选用, 以保证测试达到预期效果或者发现系统瓶颈。通过对系统功能模块进行调研与分析, 再根据需求测试分析原理和需求分析方法, 最终能得到准确有效的性能需求分析。

摘要：性能需求分析是整个性能测试工作开展的基础, 如果不清楚性能需求, 就无法进行后面的性能测试。测试需求分析阶段是通过对系统功能模块进行调研与分析, 根据需求测试分析原理和需求分析方法, 最终确认明确的性能需求。

关键词：软件性能测试,性能需求,任务分布图方法,用户概况图方法

参考文献

[1]柳纯录, 黄子河, 陈渌萍.软件评测师教程[M].北京:清华大学出版社, 2005.

软件性能测试研究 篇5

根据测试的目的和内容的不同, 性能测试主要包括以下方面:

(1) 负载测试:确定在各种工作负载下系统的性能, 目标是测试当负载逐渐增加时, 系统各项性能指标的变化情况。

(2) 强度测试:确定在系统资源特别低的条件下软件系统运行情况。

(3) 容量测试:在用户可接受的响应范围内, 确定系统可处理同时在线的最大用户数。

(4) 压力测试:通过确定一个系统的瓶颈或者最大使用极限的测试。

(5) 疲劳强度测试:以系统稳定运行情况下能够支持的最大并发用户数或者日常运行用户数, 持续执行一段时间业务, 通过综合分析交易执行指标和资源监控指标来确定系统处理最大工作强度性能的过程。

(6) 大数据量测试:大数据量测试侧重点在于数据的量上, 包括独立的数据量测试和综合数据量测试。独立的数据量测试针对某些系统存储、传输、统计、查询等业务进行大数据量测试, 而综合数据量测试一般和压力性能测试、负载性能测试、疲劳性能测试相结合。

2 软件性能测试流程

2.1 测试方案设计

在软件性能测试的初始阶段, 首先应对业务模型和系统架构进行调研, 收集测试需求, 然后生成性能测试计划。业务调研和系统调研, 需要性能测试团队提前了解被测试项目的业务功能和系统架构。其间, 开发部门应协助提供被测系统相关的文档和说明, 如系统总体介绍、系统规格书、用户使用手册、网络拓扑结构图和系统配置说明、关键服务器及应用部署与配置等文档。通过和业务部门协商明确本次测试针对哪些业务行为, 制定此次测试的目标, 细化测试的关注点和性能指标要求。通过以上内容制定详细的测试方案, 并制定详细测试计划和各阶段目标。

2.2 测试环境的搭建

测试环境的搭建分为软硬测试系统的环境搭建和测试相关的数据准备工作。环境搭建包括被测试系统的硬件环境建立和软件应用系统建立及基础数据环境建立。保障被测试系统的业务可用性和功能的正确性, 包括测试系统 (如被测试项目的操作系统、中间件、数据库、压力测试控制台、压力测试发起工具等) 的环境搭建、软件的安装;测试环境的网络环境建立 (如开放防火墙和网关等) ;最后进行测试环境可用性验证。测试数据准备包括测试应用系统基础数据准备, 即需要按性能测试规模要求, 准备足够的、一定规模的基础数据, 通常采用全量恢复生产数据的方式以达到和生产环境数据一致性的要求。

2.3 测试场景开发

测试场景开发指测试程序 (脚本) 的开发。测试程序 (脚本) 的开发是对被测系统的用户业务行为进行模拟、录制、编程、参数化、脚本定制和调式等一系列工作, 以使测试程序 (脚本) 可以真实模拟实际生产中的业务交易行为, 并通过对程序中参数的配置实现对并发数、思考时间等属性的准确控制。

2.4 测试执行

测试执行是在测试方案的制定、测试环境准备、测试场景开发工作正确完成的基础上进行的。

2.5 测试报告和分析

性能测试报告和结果分析是在测试执行完成以后, 对性能数据进行采集结果收集工作和针对性能测试过程中暴露的问题进行分析的阶段。性能测试报告是对性能测试过程中的监控结果以及报表进行汇总, 按照一定的模板整理出的一份结论性文档。开发团队和性能测试团队应依据对性能测试实施过程中监控和记录的数据和表格, 分析系统中存在的性能问题和程序缺陷。并有针对性的在报告中阐述问题、分析原因、提出解决或优化方案。

2.6 回归测试

回归测试是开发部门在性能测试报告的基础上针对软件的性能或者效率缺陷进行优化或者修复, 为了验证优化的效果而进行的再测试。

3 软件性能测试工具LoadRunner

作为软件质量控制中的重要一环, 性能测试已经越来越受到软件开发商和用户的重视, 成为软件测试的重中之重。性能测试通常在系统测试阶段执行, 常常与强度测试结合起来, 一般需要使用测试工具。一个优秀的软件测试工具, 不仅可以辅助测试工作, 满足科学测试的基本要求;而且可以自动化测试过程, 节约大量的时间、成本、人员和资源, 提高软件产品的质量。目前市场上主要使用的测试工具有微软公司的WAS (Web Application Stress Tool) 、Compuware公司的QALoad、RadView公司的WebRunner、HP (Mercury) 公司的LoadRunner。下面以LoadRunner为例, 介绍软件测试工具的工作流程。

LoadRunner是一种预测系统行为和性能的负载测试工具。通过模拟上千万用户实施并发负载及实时性能检测来确认和查找问题, 能够对整个企业架构进行测试。通过使用LoadRunner, 企业能够最大限度的缩短测试时间, 优化性能和加速应用系统的发布周期。LoadRunner能支持广泛的协议和技术, 功能比较强大, 可以为特殊环境提供特殊的解决方案。LoadRunner由下面三部分组成:Virtual User Generator用来录制脚本、编辑脚本;Controller用来布置测试场景、执行测试场景;Analysis用来对测试结果进行分析。

用LoadRunner进行负载测试的流程通常由五个阶段组成:计划、脚本创建、场景定义、场景执行、监视执行和结果分析。

(1) 计划负载测试:定义性能测试要求, 例如并发用户的数量、典型业务流程和所响应时间;根据软件项目相关需求, 定义相关测试的细节, 撰写性能测试报告。

(2) 创建Vuser脚本:将最终用户活动捕获到自动脚本中;LoadRunner的脚本是C语言代码, LoadRunner有自己的一整套函数接口, 可以供外部调用。脚本可分INIT、ACTION、END三部分, 其中:INIT部分可以理解为初始部分, ACTION可以理解为事务部分, 也是测试的主体, END是退出结束。

当录制完一个基本的用户脚本后, 在正式使用前我们还需要完善测试脚本, 增强脚本的灵活性。一般情况下, 我们通过以下几种方法来完善测试脚本。插入事务、插入结合点、插入注解、参数化输入。

(3) 定义场景:使用LoadRunner Controller设置测试环境;录制好脚本之后, 就可以把脚本加入到场景里面去了, 这里首先介绍一下LR的场景类型, LR有2种大的场景类型。

①Manual Scenario:该项要完全手动的设置场景, 这项下面还可以设置为每一个脚本分配要运行的虚拟用户的百分比, 可在Controller的Scenario菜单下设置。

②Goal—Oriented Scenario:如果你的测试计划是要达到某个性能指标, 比如:每秒多少点击, 每秒多少transactions, 能到达多少VU, 某个Transaction在某个范围VU (500-1000) 内的反应时间等等, 那么就可以使用面向目标的场景。

(4) 设置场景:

Design:设计测试场景的静态部分, 设置模拟用户生成器、模拟用户数量、 模拟用户组等。

Run:设计测试的动态部分, 主要指添加性能计数器, 在脚本运行的过程中可以通过这些计数器反馈的数据。

建立了测试场景后, 我们可以对Edit_Schedule进行设置, 设置测试开始执行的时间, 对于手动设计的测试还可以设定它的持续时间, 以及何时起用或禁止调用模拟用户。

(5) 运行场景:通过LoadRunner Controller驱动、管理和监控负载测试。

设置完毕后, 点击“开始方案”运行场景。在运行过程中, 可以监视各个服务器的运行情况 (DataBase Server、Web Server等) 。监视场景通过添加性能计数器来实现, 下列数据需要特别关注:

①Memory:Available Mbytes物理内存的可用数 (单位 Mbytes) 至少要有10% 的物理内存值。

②Processor:Processor Time CPU 使用率。这是查看处理器饱和状况的最佳计数器。显示所有 CPU 的线程处理时间。如果一个或多个处理器的该数值持续超过 90%, 则表示此测试的负载对于目前的硬件过于沉重。为多处理器服务器添加该计数器的 0 到 x 个实例。

③Processor Queue Length:是指处理列队中的线程数, 小于2。处理器瓶颈时会导致该值持续大于 2。

④Context Switches/sec:如果切换次数到5000*CPU个数和10000*CPU个数中, 说明它忙于切换线程。

⑤Network Interface:Bytes Total/sec 为发送和接收字节的速率, 包括帧字符在内。判断网络连接速度是否是瓶颈, 可以用该计数器的值和目前网络的带宽比较。

(6) 分析结果:使用LoadRunner Analysis创建图和报告并评估性能。

LR的报表分析功能也异常强大, 有各种各样的报表, 甚至可以将单个报表组合, 也可以导出到Excel文件和Html文件。

摘要：随着当今软件开发技术的发展与成熟, 越来越多复杂的软件系统应用于人们生活的各个领域, 软件系统运行时的性能表现已经成为衡量软件产品质量的一个重要标准。研究了软件系统性能测试的整体的流程, 并结合自动化测试工具LoadRunner, 对软件性能测试的相关信息进行了探讨和分析。

关键词：软件测试,性能测试,LoadRunner

参考文献

[1]朱少民.全程软件测试[M].北京:电子工业出版社, 2007.

[2]古乐, 史九林.软件测试技术概论[M].北京:清华大学出版社, 2003.

[3]LydiaAsh.The Web Testing Companion[M].北京:机械工业出版社, 2003.

[4]柳纯录, 黄子河, 陈渌萍.软件评测师教程[M].北京:清华大学出版社, 2006.

如何进行有效的性能测试 篇6

测试的信息系统用于大连市劳动和社会保障业务的信息管理, 采用B/S三层架构。劳动和社会保障业务的经办人员通过这套系统进行参保单位、参保个人档案的建立、参保信息的建立、人员参保关系的调转、五险 (养老、医疗、失业、工伤、生育) 的申报、收缴和支付、采暖费的征缴和支付、就业管理、退休人员社会化管理、财务管理及各种查询统计。该系统的特点是数据量大 (超过100万人的参保信息和每月缴费、支付情况) 、并发用户多、计算复杂、功能点多 (2000多个) , 因此, 判断新开发的应用系统是否存在性能瓶颈, 以便采取相应的预防措施来降低系统上线后的性能风险至关重要。

本次性能测试性能测试工具是Loadrunner V8.0, 目的是评估应用系统主要功能点在模拟环境中, 验证单用户响应时间是否满足要求;验证在最大并发用户同时操作情况下系统响应时间是否买足最差响应时间的要求;检控在最大并发用户同时操作并持续一段时间的加压后系统的负载能力 (事务处理速度、CPU使用率、内存使用率等) 的变化情况;如果条件允许的情况下, 在预计的数据容量中, 系统能够容忍的最大用户数。同时使用EM作为辅助监控工具。为了能够做好性能测试, 我们做了以下工作:

1做好管理计划, 确保工作能够有序的进行

由于本系统包含的功能点多, 那么, 如何在有限的时间能完成测试任务, 必须先在项目管理上下功夫, 我们为测试工作做了如下准备:

1.1制定测试方案

测试方案的内容包括:

(1) 测试目标计划:定义本应用系统测试计划的人月、规模数、日程、交付成果;

(2) 测试生产性与质量目标计划:定义测试功能点的选取标准、应用服务器性能指标、数据库服务器性能指标;

(3) 测试体制结构:测试人员、组织结构

(4) 测试培训计划:对参加测试的人员培训测试工具的使用方法。

(5) 测试环境配备计划:部署测试服务器, 测试环境与生产环境的配置对照表

(6) 组间协调计划:开发组如何配合测试组, 指导业务, 协助准备测试数据。

(7) 测试大纲:系统名称 (同时设计了四个混合场景测试) 、功能模块、测试类型、测试方法、优先级、对应用例。

(8) 测试过程。包括单体测试和混合场景测试。

①单体测试:

首先, 使用单用户对功能点进行操作, 验证单用户响应时间是否满足要求。如果满足要求, 再使用Loadrunner录制、调试压力测试脚本。调试好脚本后, 执行脚本, 对系统加压, 记录系统各项指标并进行分析, 同时使用EM对ORACLE数据库进行监控, 记录阻塞事务和执行时间长的SQL, 做成测试报告。

②混合场景测试:

混合场景测试的目的是模拟日常业务办理的业务压力和使用场景组合来测试系统的性能是否满足日常业务办理时, 各子系统同时应用, 多用户同时办理, 各种业务同时发生的复杂压力情况下的要求。

采取的测试策略:模拟日常业务办理的情况, 在各子系统中抽出使用次数多, 并发用户数多, 及使用数据量大的业务点, 按照业务办理的时间段分别组织成不同场景, 利用多客户端, 使用LoadRunner进行多用户并发和持续加压, 对应用服务器和数据库服务器造成一定压力, 监控应用服务器和数据库服务器的各项性能指标 (CPU占用率, 内存分页率, 平均负载和磁盘流量等) 的变化情况, 判断服务器及应用程序是否能满足性能要求, 及是否存在性能瓶颈。

1.2制定需求确认计划

在有限的时间内, 不可能对2000多个功能点逐一测试, 因此要找到容易出现问题的功能点进行测试, 于是, 我们制定了需求确认计划来根据实际的业务量情况确定抽取的功能点和测试指标的标准。

需求确认计划的内容包括:功能模块、使用频度、单用户响应时间、最差响应时间、涉及的最大数据量、最大并发用户数。

测试组根据需求计划确认的使用频度、涉及数据量和最大并发用户数作为抽取压力测试功能点的依据。本应用系统共有2013个功能点, 本次性能测试根据需求确认计划, 抽取了183个功能点, 覆盖率为9%。

需求确认计划确认的单用户响应时间、最差响应时间作为测试指标是否满足要求的标准。

1.3编写测试用例

(1) 制定测试用例标准

(2) 编写测试用例:使用脚本、数据量、并发用户数、功能执行步骤、最差响应时间、实际响应时间、事务处理速度。

具体指标根据需求确认计划确定。

1.4测试数据的准备

测试数据的准备必须由开发人员协助解决。由测试人员根据测试用例编写测试脚本。对于测试脚本中需要的测试数据, 测试人员与开发人员沟通, 由开发人员协助准备测试数据。

以上工作的每一个产出物都组织技术骨干进行评审。而后, 我们按照评审后的结果进行测试。

2准备测试环境

我们为性能测试准备了如下测试环境:

3测试人员按照方案中制定的测试过程, 依据测试用例进行测试

3.1单体测试

采用压力测试和并发测试进行性能验证。

3.1.1压力测试

(1) 用户加载方式:每2-5秒加载1个用户。

(2) 测试持续时间:20-30分钟。

(3) 用户结束方式:每1秒结束1个用户。

3.1.2并发测试

对于业务不可复制的功能, 进行并发测试。

3.1.3测试监控情况

(1) 虚拟用户运行情况

(2) 平均事务响应时间

(3) 事务摘要

(4) 应用服务器

(5) 数据库服务器

由以上监控结果可以看出, 本次测试采用一次性并发测试, 并发用户数为200, 整个测试过程持续2分钟28秒;每秒点击次数平均为127.517, 报盘操作 (68.657秒) 的响应时间大于半分钟, 事务通过率为100%, 应用服务器的CPU占用率为0.106%, 数据库服务器的CPU占用率为94.833%。另外, 还对此功能分别进行了50用户、100用户一次性并发测试, 监控发现操作同样对数据库服务器CPU占用率的影响较大, 分别达到89.256%和90.773%, 因此此功能点不满足性能测试的要求, 需要进一步调优。

3.2混合场景测试

3.2.1场景组织

把每天工作时间划分为四个时间段:8:10-10:00, 10:00-11: 30, 13:00-15:00, 15:00-17:00。按照这四个时间段经常办理的业务来组织场景。以下是每个场景的功能点的具体分配:

3.2.2测试过程: (场景一)

(1) 9:30-10:20:执行社保征缴子系统“全险种明细查询”功能, 120用户, 每5秒增加1个用户, 持续加压30分钟, 每5秒减少1个用户。

(2) 10:20-10:50:执行社保征缴子系统“人员参保信息新建复核”功能, 120用户, 每5秒增加1个用户, 持续加压10分钟, 每5秒减少1个用户。

(3) 10:00-10:10:执行社保征缴子系统“按单位生成应缴帐”功能, 120用户, 一次性并发。

(4) 10:20-11:00:执行事保征缴子系统“职工档案浏览”功能, 5用户, 每5秒增加1个用户, 持续加压30分钟, 每5秒减少1个用户。

(5) 9:30-9:35:执行医疗待遇子系统“医疗费用明细”功能, 1用户, 单用户操作1次。

(6) 9:40-10:00:执行医疗待遇子系统“基本医疗保险费支出情况”功能, 1用户, 单用户操作1次。

(7) 10:10-10:45:执行医疗待遇子系统“个人综合信息查询”功能, 30用户, 每5秒增加1个用户, 持续加压30分钟, 每5秒减少1个用户。

(8) 10:00-10:10:执行工伤待遇子系统“工伤待遇登记”功能, 3用户, 一次性并发。

(9) 10:10-10:20:执行财务接口子系统“生成日记账”功能, 20用户, 一次性并发。

(10) 10:30-11:10:执行基本档案子系统“个人基本信息查询”功能, 20用户, 每5秒增加1个用户, 持续加压30分钟, 每5秒减少1个用户。

混合场景测试与单体测试的主要区别在于场景的组织和测试过程, 监控结果基本与单体测试相同, 只是记录混合场景中每一个事务 (功能点) 的响应时间, 这里就不再一一列举了。

通过监控结果可以看出:本次混合场景测试, 整个执行时间为1小时50分钟, 用户最高并发数达到290, 有1个小时保持在120个并发用户以上。应用服务器受影响较小, 各项指标一直保持在较低水平, 不存在性能瓶颈。数据库服务器CPU占用率最高达到100%, 平均值最高达到91.752%, 有1小时左右保持在90%左右, 超过警告阀值, 接近严重阀值, 存在性能风险, 需要采取措施进行改进, 其他指标保持稳定, 无性能风险。事务总数为35357个, 失败事务数仅为6个, 事务通过率为99.98%, 应不影响系统正常使用。工伤待遇登记和生成日记帐两个功能点的平均响应时间较长, 需要改进。

形成测试报告, 给出测试总结和优化建议。开发人员再根据测试结果, 综合考虑测试环境和生产环境之间的差别, 对系统进行调优, 再进行回归测试。

4结束语

通过这次测试, 我们总结出以下几个关键的要点:

(1) 要对每个功能点的使用频度、单用户响应时间、最差响应时间、涉及的最大数据量、最大并发用户数进行充分调研, 了解真实的使用情况, 先从业务发生角度找出瓶颈可能存在的功能点, 再使用技术手段对这些功能点进行测试分析, 使得整个测试工作有组织、有顺序、有针对性、有实效性。

(2) 单体测试的并发用户数以及测试指标阀值要根据实际业务情况来确定, 我们的确定方法是在实际业务量上再增加10%的并发量, 以便测试结果能够最真实、最充分的体现实际运行情况。

(3) 混合场景测试至关重要。混合场景要进行合理的场景组织, 模拟在各子系统同时应用, 多用户同时办理, 各种业务同时发生的复杂压力。通过选取各子系统中使用次数多, 并发用户数多, 及使用数据量大的业务点, 按照业务办理的时间段分别组织成不同场景, 利用多客户端, 使用LoadRunner进行多用户并发和持续加压, 对应用服务器和数据库服务器造成一定压力, 监控应用服务器和数据库服务器的各项性能指标 (CPU占用率, 内存分页率, 平均负载和磁盘流量等) 的变化情况, 判断服务器及应用程序是否能满足性能要求, 及是否存在性能瓶颈。

(4) 测试环境与生产环境要尽量保持一致。如果实在有困难, 也要列出对比情况, 供测试人员根据测试结果进行具体的分析, 以便得出可靠的结论。

参考文献

[1]李伟华, 周兴社.实时并发软件的测试软件开发[N].西北工业大学学报, 1995年03期.

[2]刘帆.一种基于LoadRunner的系统性能测试方案[J].船舶电子工程, 2012年07期.

竹炭纤维性能研究与测试 篇7

1 竹炭纤维的开发[1]

竹炭在纺织中的应用途径基本上有3种∶

其一, 在纺丝过程中将超细甚至是纳米竹炭粉末加入到纺丝流体中制成竹炭纤维。一般选用粘胶基材, 因为纤维素的透气性比合成纤维树脂切片的要高很多, 适合开发新一代保健性功能纤维。

其二, 在涤纶、丙纶、腈纶、粘胶纤维等表面涂上超细竹炭添加剂。这是超细纳米技术和纺织工程相结合的产品, 是将天然植物添加剂移植到化纤中的一个新亮点。

其三, 将竹炭粉末分散到水溶性、热塑性树脂中, 将组合后的树脂涂抹在梭织物、针织物等基布之上。对于涂布量需求较少的被覆膜, 可采用点状被覆。反之, 宜采用全面被覆方式。

在此重点介绍由第1种途径开发的竹炭改性涤纶纤维。即指将竹炭超微颗粒与聚酯通过共混纺丝而制成的竹炭涤纶纤维, 并对这种具有多微孔结构及超强吸附、抗静电、抗菌、防霉、发射负离子等特殊功能的涤纶纤维[2]进行测试。

2 性能测试[3,4]

对竹炭改性涤纶纤维性能的研究是为其产品开发服务的, 本试验选用与其可纺性, 服用性能等有关的指标进行测试研究, 并且与纯涤纶纤维进行性能指标的对比, 见表1。

注:A, B为竹炭改性涤纶纤维, C为纯涤纶纤维

2.1 纤维回潮率的测试

试验仪器:Y802A型八吊篮烘箱:

试验结果与分析:竹炭涤纶纤维与纯涤纶纤维的回潮性能比较见表2。

从竹炭改性涤纶纤维和涤纶纤维的回潮率测试中可以看出, 前者由于竹炭颗粒的存在, 较好地改善了纤维的回潮率, 且随着竹炭在纤维中含量的增加, 纤维的回潮率也随着增加。这是由于竹炭改性涤纶纤维的竹炭颗粒有吸附的功能, 因此使得竹炭改性涤纶纤维比一般的涤纶纤维吸湿性能更好, 用其制作的服装穿着舒适, 适合于制作夏季及贴身穿着的服装、运动服装等, 具有良好的服用性能。

2.2 纤维比电阻性的测试

试验仪器:YG321型纤维比电阻仪;

试验结果:竹炭涤纶纤维与纯涤纶纤维的比电阻性能比较见表3。

由上表可以看出, 竹炭改性涤纶纤维的表面质量比电阻明显低于普通纯涤纶纤维, 这意味着竹炭改性涤纶纤维具有良好的抗静电能力。这是由于竹炭改性涤纶纤维具有良好的吸湿性的原故, 使得其抗静电性能好。用其制作的服装穿着时比较舒服, 不会因静电而有吸附在身上的贴身感, 不易粘着灰尘。这也表明它具有良好的服用性能。

2.3 摩擦性能的测试

试验仪器:Y151型纤维摩擦系数测定仪;

试验结果与分析:竹炭涤纶纤维与纯涤纶纤维的摩擦性能比较见表4。

从上表的测试结果可以看出, 竹炭改性涤纶纤维的摩擦系数较小, 纤维比较光滑, 纤维的动、静态摩擦系数相差不大。涤纶纤维采用熔体纺丝, 截面呈圆形, 表面很平整, 使纤维相对滑动时接触面积不大, 摩擦系数高。竹炭改性涤纶纤维是将高温炭化技术烧制的竹炭, 利用纳米技术微粉化, 再通过熔融纺丝程序把竹炭次纳米级微粉均匀地融入化学纤维中, 这使得其表面具有一定的粗糙, 表面积相对有所增大, 从而其摩擦系数得以减小。

由实验得出的数据可以看出, 橡胶辊的动、静摩擦系数, 竹炭纤维与涤纶纤维相比都有减小, 是因为含竹炭量的多少对纤维摩擦性能的影响不是很显著。

2.4 纤维强力的测试

试验仪器:YG004E型电子单纤维强力仪;

试验结果与分析:竹炭涤纶纤维与纯涤沦纤维的耐酸碱性能比较见表5。

注:A1, B1, 为竹炭涤纶改性纤维是A, B在18%的HCl溶液中浸泡2h, 温度30℃。A2, B2, 为竹炭涤纶改性纤维是A, B在0.5%的Na OH溶液中浸泡2h, 温度30℃。

3 结语

由实验数据可得:竹炭改性涤纶纤维经浓度为18%的HCl处理后与未处理前相比, 其强力、强度、伸长率都没有太大变化, 而经浓度为0.5%的Na OH处理后, 其拉伸强度、强力有所明显的减小。由此, 可得酸对竹炭改性纤维的力学性能没有大的影响, 强碱对其强度有很大的损害。这说明在织物的后面加工过程中, 应注意不能用强碱性的物质对其加工。竹炭纤维所具有的耐酸不耐碱性, 决定了其纱线和织物也具有这种性能, 这让我们注意织物的印染后整理中采用适当的处理工艺。

参考文献

[1]李旭明.竹炭纤维的开发与应用[J].针织工业2007, (10) :21-22.

[2]林力.台湾大力开发竹炭纤维[N].中国绿色时报, 2005-9-29 (07) .

[3]姚穆, 周锦芳.纺织材料学[M].北京∶中国纺织出版社, 1988.

陶瓷地砖防滑性能测试研究 篇8

目前我国建筑装饰的档次不断提高,豪华高档的公共建筑酒店、写字楼、商厦,以至高档公寓等的地面,大都是采用陶瓷地砖做饰面,在美化了环境的同时,却也带来了日益突出的地面滑倒的安全隐患问题。例如居室里特别是厨房、卫生间地砖摩擦系数如选用不当,会造成使用者跌伤事故;在广场路面的地砖摩擦系数选用不当,会造成机动车刹车失效,伤及无辜路人;在商场、餐厅地砖的摩擦系数选用不当,致使消费者“失足”后把经营者告上法庭的事件亦有所闻,多挂几个“小心路滑”的警示牌也不能从根本上解决问题。如何选用既美观又防滑安全的地砖,参考的依据是什么?人们都希望从陶瓷地砖的产品标识中找到摩擦系数的答案。本来GB/T4100,1～5-1999系列产品标准要求在产品说明书中应标明按附录A试验测出的摩擦系数,但由于试验方法的可操作性存在问题以及国内陶瓷砖摩擦系数专用检测设备的开发滞后,以致此规定在实际中一直未有执行。

本研究将采用倾斜平台法测试各类陶瓷地砖的防滑性能,建立测试数据库,参照发达国家的评价准则进行陶瓷地砖防滑性能的评价和安全风险预测。课题的研究,对于指导陶瓷地砖的合理选用,促使企业提高产品的防滑性能,保护公众的人身安全有着非常重要的意义。

1 陶瓷地砖防滑性能测试方法

1.1 动滑快法

使用一个自行走装置在待测陶瓷砖表面上水平来回移动,陶瓷砖表面需紧密铺砌形成一个平展的测试区,测试长度为1m。自行走装置拖动一个由200g重块垂直正压在φ9mm橡胶摩擦块上所组成的摩擦组件,摩擦组件与陶瓷砖水平面滑动接触,用于测试干或湿状态下陶瓷砖表面的滑动摩擦系数。

1.2 静滑块法

用一块75×75×3橡胶板(硬度值IRD90±1)粘在一块200×200×20胶合板的底面,在胶合板上面垂直加载一个4500g重块,组成一个滑块组件。通过拉力计拖滑块组件与被测陶瓷砖水平表面产生相对运动趋势。测出在干和湿的条件下陶瓷砖的静摩擦系数值。

1.3 倾斜平台法

以一名测试者穿着肖氏硬度为73±5的特制橡胶鞋,在以每秒倾斜1°的恒角速度旋转的平台(600mm～2000mm)上行走,直至测试者显示出不安全的迹象时,测出旋转平台与水平面之间倾角,以确定被测陶瓷砖的动态临界摩擦角(夹角正切值=动摩擦系数)。用此方法制造的专用检测设备需占较大空间,检测所得的摩擦系数值可因测试者而异存在一定差别。但此方法模拟陶瓷地砖实际使用原形,对斜坡路面的陶瓷地砖摩擦系数阻力测试有实际意义。

用倾斜平台法测定地面材料摩擦系数是一种在欧美和澳洲得到认可和广泛使用的方法。在法国、德国和意大利等国家,规定了不同功能建筑物地面必须达到的防滑等级,这些防滑等级是根据倾斜平台法测定的摩擦系数来划分的,陶瓷地砖的CE认证要求制造商明示产品的摩擦系数和检测方法,虽然没有规定必须使用倾斜平台法,但是欧洲的客户通常只认可倾斜平台法的测试数据,特别是当产品可能用于市政工程时,制造商必须提供使用倾斜平台法测得数据。虽然用倾斜平台法进行陶瓷地砖防滑性能的测试和评价在国外得到广泛的认可和使用,但在国内还没有进行该方法的研究。对于陶瓷地砖,目前还没有国际统一测试方法和评价准则,我国推荐使用的方法为静滑块法。国外的研究文献表明,相比于静滑块法,倾斜平台法的试验结果能更好地评价陶瓷地砖的防滑性能。

2 倾斜平台法测试陶瓷地砖防滑性能

2.1 实验材料及设备

2.1.1 实验材料

测试鞋:符合BS EN ISO 20345有一个外鞋底在橡胶基部上,IRHD厚度72±2符合AS1683.15.1;

倾斜坡度:平坦抗扭地板,典型的600mm宽和2000mm长,斜度按纵向方向从0°调节到45°,测量角度指针固定在组合中允许误差0.5±0.2°;

润滑油:使用SAE viscosity class 10W30发动机润滑油用于测试,就保存在密封的容器以防止粘结;

校准板:三个校准确性板E,P和R,分别是10.7°,18.2°和26.8°的防滑能力;

测试板:测试板应大约1000×500mm.应由表面测试材料做成,每个都应像是从一个更大的薄片上切割下来,或是单独个体的集合,如个体砖,或是梯级前沿部分.步行表面材料应可自己支撑或制作成自己支撑的,包裹厚地板的水平底部,或固定在水平的、厚实、承重材料做成的基部上。用于测试的表面应是清楚可辨别或有记号。有方向侧面或粗糙表面的步行表面材料应放置移动方向符合最小防滑系数的方向。单独步行表面次表面,直角成形和没有方向表面和粗糙表面,应固定在短边平行测试仪器的旋转轴。(备注:砖,除了马赛克,可一个一个没有缝隙地拼凑起来)。测试上表面试验前应清洁干净,再安装完成以前,移除任何的生产杂质,污垢,萃取剂或粗糙边缘。测试覆盖应按如现实使用的覆盖表面一样的方式准备。

2.1.2 实验设施

型号为C03463的倾斜角滑度测试仪。

2.2 实验方法

实验要求考察了环境、人为、空气温度等因素,并且对这些因素进行分析。摩擦系数与表面粗糙度相关性分析,在采用测试区域的温度和鞋的温度,润滑剂和测试表面应23±5℃。测试开始前,100±1mL的润滑剂在测试表面完全的展开。鞋子的后鞋跟应用润滑剂湿润。测试人应身体垂直,脸朝下,以半个鞋长度的步伐前行。往前和往后移动,测试表面的倾斜度应从水平位置开始以1°/s的速率增加。倾斜角度的获得是安全步行的极限,该极限的获得就是不断重复在临界上下浮动的范围。覆盖测试的可接受角度应由从水平面开始的三次结果决定。每次试验的开始,在第二次和第三次测量以前,润滑剂应再一次在表面上展开。步行实验由两个人展开。每次踩测试板时都要先踩三块标准板(i=E,P,R)三次和决定αk,E,j,αk,P,j,αk,R,j的平均值进行相关性的分析。

3 实验结果与分析

3.1 实验结果

防滑性能检验结果见表1,防滑性能计算正确值Dj是为了每个测试人而计算的。根据测试接受角度值(αO1,αO2)的尺寸,计算的执行应符合以下四中情形中的一种:

个体结果,对于每个测试人(j),正确接受角度值(αj)的获得,是正确值Dj增加到可接受测试角度αoj,公式如下:αj=αoj+Dj。最后算可接受角度a1和a2应加在一起再平均,两个测试人获得的测试最后结果就是,正确值的可接受角度。

对于决定带有方向表面侧面或图案的地板表面的防滑特性,获得最低总值的可接受角度应适用于表1:

3.2 结果分析

测试研究结果表明:

(1)马赛克

由公式:

计算的,它的安全等级达到R10和R11,

(2)抛光砖、抛晶砖、楼梯地砖、仿古砖

结果都是根据计算的,它的安全等级普遍达到R9。

(3)耐磨砖

安全等级达到R9和R10,其计算公式则有

(4)广场砖

广场砖的安全等级达到R12,其计算公式为

由表1中的数据和试样图片可以看出不同样品数据差距的原因及影响因素有环境、人为、空气湿度等相关。比如抛光砖如果做实验之前没有用磨纱纸擦其表面的污渍和薄膜,那么润滑油涂在砖的表面会不均匀,从而出现错误数据。为什么是同种样品而它的数据却不同?原因是要看其样品的外表面,比如马赛克和耐磨砖来说,有表面凹凸不平,有表面光滑的;而耐磨砖表面也是有凹凸的,所以它们对鞋底摩擦系数会大点。

4 结论

解决“防滑”标准制定问题已经刻不容缓。在借鉴外国进行了长期研究的先进检测技术和标准的基础上,我国应当尽快制定自己的地面安全防滑性能技术标准,制定出适合我国特点的地面安全防滑检测体系,以促进我国研究、开发新的地面安全防滑处理的技术和产品,全面推进我国地面防滑安全水平。本研究采用的是倾斜平台法测试各类陶瓷地砖的防滑性能。倾斜平台法检测所得的摩擦系数值可因测试者而异存在一定差别,但此方法模拟陶瓷地砖实际使用原形,对斜坡路面的陶瓷地砖摩擦系数阻力测试有实际意义。从测试数据分析,无釉制品表面比有釉面的防滑性能要好;无釉制品中表面呈凹凸状,花纹状的表面的防滑性好;由于抛光砖表面平整,与鞋底接触面积大,所以防滑性能也好。在有釉制品中,釉面的材质、特性以及无釉砖的表面特性均应加以改善外,且应采用耐磨、防滑透明涂料加以解决。

摘要：陶瓷地砖地面防滑安全问题日渐突出,故对地砖进行防滑测试与研究,对于指导陶瓷地砖的合理选用,促使企业提高产品的防滑性能,保护公众的人身安全有着非常重要的意义。

关键词：陶瓷地砖,防滑性能,测试,摩擦系数

参考文献

[1]陈国本.浅议我国研究和制定地面防滑标准的迫切性[J].石材2008(1)33～35

[2]符冰群.陶瓷砖行业防滑标准滞后.中国房地产报,2006年12月25日第015版

[3]潘施.我国应推出石材地面防滑检侧标准,石材2004(7)

[4]陈国本.国外目前常用地面防滑性能的测试方法和仪器[J].石材2006(10)20～24