LTP(LinuxTest Project)测试工具

LTP(LinuxTest Project)是SGI、IBM、OSDL和Bull合做的项目,目的是为开源社区提供一个测试套件,用来验证Linux系统可靠性、健壮性和稳定性。LTP测试套件是测试Linux内核和内核相关特性的工具的集合。该工具的目的是经过把测试自动化引入到Linux内核测试,提升Linux的内核质量。LTP提供了验证linux系统稳定性的标准,设计标准的压力场景,经过对linux系统进行压力测试,对系统的功能、性能进行分析,并以此肯定linux系统的可靠性、健壮性和稳定性。php

压力测试是一种破坏性的测试,即系统在非正常的、超负荷的条件下的运行状况 。用来评估在超越最大负载的状况下系统将如何运行,是系统在正常的状况下对某种负载强度的承受能力的考验。linux

使用LTP测试套件对Linux操做系统进行超长时间的测试,重点在于Linux用户环境相关的工做负荷。而并非致力于证实缺陷。ios

压力测试的设计   数组

重点:   1. 测试选择。缓存

              2. 评价系统资源利用率。安全

              3. 分析内核代码覆盖率。网络

              4. 评价最终压力测试数据结构

一、测试选择--包括达成两方面目的的测试:多线程

  - 测试应该能够获得 CPU(s)、内存、I/O 和网络等主要内核区域的高水平的资源利用率。函数

  - 测试应该充分地覆盖内核代码,以帮助支持自其结果中生成的稳定性声明。

二、评价系统资源利用率

  所选择的测试的组合必须给系统的资源带来足够的压力。Linux 内核的四个主要方面能够影响系统的 响应和执行时间:

  - CPU:用于在机器的 CPU(s)上处理数据的时间。

  - Memory:用于自真实存储器中读写数据的时间。

  - I/O:用于自磁盘存储器读写数据的时间。

  - Networking:用于自网络读写数据的时间。

  系统资源利用率评价阶段一般须要屡次尝试才能获得合适的测试组合,并获得指望水平的利用率。当肯定测试组合时,过分利用老是一个相当重要的问题。例如,若是选择的组合过于受 I/O 所限,可能会致使 CPU 的测试结果很差,反之亦然。方法的这一部分主要是大量的试验和出错,直到全部资源达到指望水平。

  当选定一个组合后,测试必须长时间运行以准确评价资源的利用率。测试运行的时间长短取决于每一个测试的长度。假如多个测试同时运行,则时间必须足够长以使得这些测试中最长的那个能够完成。在这个评价过程当中,sar工具也应该在运行。在评价运行的结论中,您应该收集并评价全部四种资源的利用率水平。

三、分析内核代码覆盖率

  得到足够的内核覆盖率是系统压力测试的另外一个职责。尽管所选的测试组合充分地利用了四种主要资源,它也有可能只是执行了内核的一小部分。于是,应该对覆盖率进行分析以确保组合能够成为一个系统压力测试,而不是一个系统负载生成器。

四、之因此要执行方法中的这最后一步,是为了对系统压力测试进行核实。在一个被认为是稳定的内核上执行压力测试; 一般,发行版本中的内核能够知足这一要求,但不老是如此。要长时间地执行压力测试,同时运行sar工具,缘由有如下两点:

  -长时间运行有助于发现组合中的全部问题,不然,在短期的“取样测试(sniff test)”中这些问题可能会被忽略。

  -sar 生成的数据构成之后测试运行中进行比较的基线。

  长时间运行结束后,如今能够基于收集的全部数据来决定这个测试组合是不是系统压力测试的合适候选者。

LTP 测试方法

测试方法有两个阶段:

             阶段1:初始测试

             阶段2:压力测试

初始测试 --- 是开始测试的必要条件。初始测试包括LTP测试套件在硬件和操做系统上成功运转,这些硬件和操做系统将用于可靠性运转。LTP测试套件包附带的驱动程序脚本runalltests.sh用于验证内核。这个脚本串行地运行一组成包的测试,并报告所有结果。也能够选择同时并行地运行几个实例。在执行runltp脚本的时候,能够指定参数添加须要测试的项目(在/testscripts内),初始测试的测试脚本是runalltests.sh或runltp(runltp默认执行的内容与runalltests相同),默认地,这个脚本执行:

- 文件系统压力测试。

- 硬盘 I/O 测试。

- 内存管理压力测试。

- IPC 压力测试。

- SCHED 测试。

- 命令功能的验证测试。

- 系统调用功能的验证测试。

压力测试 --- 能够验证产品在系统高使用率时的健壮性。做为runalltests.sh的补充,特别设计了一个名为ltpstress.sh的测试场景,在使用网络与内存管理的同时并行地运行大范围的内核组件,并在测试系统上生成高压力负荷。

ltpstress.sh也是LTP测试套件的一部分。这个脚本并行地运行类似的测试用例,串行地运行不一样的测试用例,这样作是为了不因为同时访问同一资源或者互相干扰而引发的间歇性故障。测试内容同runltp,不一样点在于runltp能够指定测试项进行组合测试,而runalltests.sh则会所有执行。默认地,这个脚本执行:

- NFS 压力测试。

- 内存管理压力测试。

- 文件系统压力测试。

- 数学(浮点)测试。

- 多线程压力测试。

- 硬盘 I/O 测试。

- IPC (pipeio, semaphore) 测试。

- 系统调用功能的验证测试。

- 网络压力测试。

LTP工做组在设计Linux 内核压力测试脚本 ltpstress.sh 时使用了这一设计方法,为给系统提供足够的压力,LTP工做组对这个组合测试进行了分析,以肯定 Linux 内核的哪些部分在测试执行中获得了使用。而后,修改了组合测试,在保持指望的高强度系统压力的同时提升代码覆盖率的百分比。最终获得的压力测试涵盖了Linux 内核的足够多部分,有助于稳定性声明,而且有系统使用状况和内核代码覆盖状况的数据来支持它。

有两个开放源代码工具能够帮助进行 Linux 内核的代码覆盖率分析:

  - gcov:一个由 LTP 维护的开放源代码工具。这个工具分析内核代码的覆盖率,并报告哪些行、函数和分支被覆盖以及它们被访问了多少次。

  - lcov:另外一个由 IBM 开发,由 LTP 维护的开放源代码工具。 这个工具由一组构建于基于文本的 gcov 输出之上的 Perl 脚本构成,以实现基于 HTML 的输出。输出包括覆盖率百分比、图表以及概述页,能够快速浏览覆盖率数据。能够自LTP主页找到这两个工具。

lcov 工具会生成一棵完整的HTML 树,其中包含有内核中代码的每一行以及关于每一行执行了多少次的数据(若是有的话)。这个工具会量化覆盖率数据并生成关于内核中每一部分和文件覆盖率的百分比数字。

内核的代码覆盖率分析只是在ltpstress.sh的设计和开发过程当中用到,目的是保证ltpstress.sh的可用性,咱们在实际测试的时候就不须要再作内核的代码覆盖率分析了。

系统监控

LTP 测试套件附带的 top 工具是通过修改的,用做系统监控工具。使用 top 能够实时地观察处理器的行为。改进的 top 工具具备附加的功能,能够将 top 结果的快照保存到文件中,并给出结果文件的平均总结,包括 CPU、内存和交换空间利用率等信息。

在咱们的测试中,sar工具每 10 秒钟截取一次系统利用率的快照,并保存到结果文件。

测试以前全部选定的测试系统的硬件配置尽量相同。去掉额外的硬件以减小潜在的硬件故障。在映像安装过程当中选择最低的安全选项。预留至少 2GB 的硬盘空间以保存 top 数据文件和 LTP 日志文件。

在测试期间系统不要受到干扰。偶尔访问一下系统以确认测试仍在进行是能够接受的。确认的手段包括使用 ps 命令、检查 top 数据和检查 LTP 日志数据。

源安装包目录列表:

doc:该目录是说明文件和帮助文档的所在地,这个目录中对LTP的内容和每一个工具都有详细的说明。

testscripts:该目录中存储的是可执行的测试脚本,不一样方面的测试脚本的集合。

testcases:该目录存储了全部LTP测试套件中所使用的测试用例的源码。

runtest:该目录中的每一个文件都是要执行的测试用例的命令集合,每一个文件针对测试的不一样方面。

(用于连接testscripts内的测试脚本和testcases测试项目)

include:LTP测试套件的头文件目录,定义了LTP自身的数据结构和函数结构。

lib:LTP测试套件运行时自身须要的库文件,定义了LTP自身的各类函数。

bin:存放LTP测试的一些辅助脚本。

results:测试结果默认存储目录。

output:测试日志默认存储目录。

share:脚本使用说明目录。

pan:该目录存储的是LTP测试套件的测试驱动程序pan。

pan工做原理:LTP测试套件有一个专门的测试驱动程序pan,具体的测试用例的执行都是由pan来调用执行,它能够跟踪孤儿进程和抓取测试的输出信息。它的工做方式是这样的:

从一个测试命令文件中读取要测试的条目和要执行的命令行,而后等待该项测试的结束,并记录详细的测试输出。默认状态下pan会随机的选择一个命令行来运行,能够指定在同一时间要执行测试的次数。

pan会记录测试产生的详细的格式复杂的输出,但它不进行数据的整理和统计,数据整理统计的工做由scanner来完成,scanner是一个测试结果分析工具,它会理解pan的输出格式,并输出成一个表格的

形式来总结那些测试passed或failed。

LTP测试套件经过执行测试脚本runalltests.sh(或runltp或runltplite.sh)或/testscripts内的测试脚本调用驱动程序pan执行/testcases内的测试项目。

文件列表:

IDcheck.sh:检查系统是否缺乏执行LTP测试套件所需的用户和用户组,若是缺乏则为LTP测试套件建立所需的用户和用户组。

runltplite.sh:这个脚本用来测试LTP安装,也可用来对测试套件的子项目进行测试。

ver_linux:这个脚本是获取硬件、软件、环境信息。

安装: ltp-full-20110915.bz2

下载地址:http://ltp.sourceforge.net/

1> tar xvjf ltp-XXXXXXXX.bz2

2> cd ltp

3> ./configure

4> make all

5> make install

##不指定安装路径的话,将会默认安装到/opt/ltp目录

LTP的实际运行

实际运行当中,您还须要配置一些必要的服务才能够正确的运行LTP的测试套件,以ltprunall.sh为例,它是不须要配置其余服务就能够运行的,可是对于ltpstress.sh,是须要配置一些相关服务以后才能够正确运行的,须要您配置的服务以下:

配置rsh和rlogin服务,使用户能以root身份不需密码验证直接登陆本机。

测试运行

1. 初始测试

./runltp -p -l /tmp/resultlog.20111207 -d /tmp -o /tmp/ltpscreen.20111207 -t 24h

或者:./runalltests.sh                   

          -p:人为指定日志格式,保证日志为可读格式                      

          -l:记录测试日志的文件

          -d:指定临时存储目录,默认为/tmp

          -o:直接打印测试输出到/tmp/ltpscreen.20111207

          -t:指定测试的持续时间

          -t 60s = 60 seconds

          -t 45m = 45 minutes

          -t 24h = 24 hours

          -t 2d  = 2 days

2. 压力测试

在使用testscripts/ltpstress.sh脚本以前须要对系统进行配置

-rsh必须配置完毕并在运行。

-内核支持NFS,而且安装NFS软件,经过网络测试。

-"sar"或"top"工具须要被安装,执行ltpstress时须要添加"sar"或"top"工具。 # yum install sysstat

./ltpstress.sh -d /tmp/sardata -l /tmp/ltpstress.log -I /tmp/iofile -i 5 -m 128 -t 24 -S

-d:指定sar或top记录文件,默认/tmp/ltpstress.data

-l:记录测试结果到/tmp/ltpstress.log (小写L)

-I:记录"iostat"结果到iofile,默认是/tmp/ltpstress.iostat (大写i)

-i:指定sar或top快照时间间隔,默认为10秒

-m:指定最小的内存使用,默认为: RAM + 1/2 swap

                -n:不对网络进行压力测试

                -S:用sar捕捉数据

                -T:利用LTP修改过的top工具捕捉数据

                -t:指定测试时间   

测试结果分析

默认状况下,测试结果放在/tmp

ltpstress.log ---- 记录相关日志信息,主要是测试是否经过(pass or fail)

ltpstress.data ---- sar工具记录的日子文件,包括cpu,memory,i/o等

ltpstress.611.output1 ---- 对应stress.part1,测试命令的一些输出信息  

ltpstress.611.output2 ---- 对应stress.part2,测试命令的一些输出信息

ltpstress.611.output3 ---- 对应stress.part3,测试命令的一些输出信息

cpu 平均使用率:#sar -u -f ltpstress.data

memory 平均使用率:#sar -r -f ltpstress.data

分析:

     ltpstress.log 将全部FAIL过滤出来,获得完整的全部FAIL的testcases。

方法以下:用sort把FAIL的项排序,再用uniq排除重复项输出到一个文件就能够了:

     grep FAIL ltpstress.log | sort | uniq >failcase.txt

至此,获得的failcase.txt为全部FAIL的testcases名字。要注意分析case失败的缘由是什么.

并下结论:是配置的问题,仍是稳定性的问题(有失败也有成功)。并将结论加注在failcase.txt中,方便查看。

用户自定义测试:

想要有选择的自定义测试项目,能够以下方法操做

建立命令文件,这个命令文件包括两部分: tag和test case

tag即为标签项,起到一个说明的目的,方便咱们知道是干什么的.

test case即为要测试的项目,此部分为/opt/ltp/testcases/bin/下的命令加上相关的选项

例如:

#Tag         Test case

#------------------------------------

mtest01         mtest01 -p 10

mmstress      mmstress -x 100

fork01        fork01

chdir01         symlink01 -T chdir01

#------------------------------------

假如此文件名定义为self.sh

则可运行:

./runltp -p -l self.log -f /opt/ltp/self.sh

若是未指定日志文件存储路径将会默认保存到/opt/ltp/results/self.log下

若是 -f 选项后的文件不指定绝对路径,将会默认的到目录/opt/ltp/runtest下去寻找

此例中假如self.sh文件在/opt/ltp/runtest目录下,只需-f self.sh便可,如不在将会提示在runtest目录下找不到文件self.sh 

 如:

./runltp -p -l self.log -f self.sh

INFO: creating /opt/ltp/results directory

cat:/opt/ltp/runtest/self.sh: 没有那个文件或目录

FATAL:unable to create command file

例如要单独测试runtest目录里的项目,以tracing为例,则可:

./runltp -p -l tracing.log -f tracing

结果以下:

#cat results/tracing.log

Test Start Time: Thu Dec  8 18:26:03 2011

-----------------------------------------

Testcase                       Result     Exit Value

--------                       ------     ----------

ftrace-stress-test             PASS       0    

-----------------------------------------------

Total Tests: 1

Total Failures: 0

Kernel Version: 2.6.18-194.el5

Machine Architecture: i686

Hostname: HA02

一样能够对文件进行修改,取消咱们不须要测试的部分,以下:

runtest中stress.part1,stress.part2,stress.part3。

如修改 stress.part1 中有这样一个测试 mem02,根据阅读testcases/kernel/mem/mem/mem02.c 源代码,可将他修改成 mem02 -m 15,意思是测试 15m 内存。一样的也能够在 stress.part1,stress.part2,stress.part3 中添加、删除一些测试,如咱们测试时就把

stress.part3 中关于 swap 交换分区的去掉

#swapoff01 swapoff01

#swapoff02 swapoff02

#swapon01 swapon01

#swapon02 swapon02

有个IBM的LTP测试,不过期间较老为2004年的,并且说的太简单,最重要的是它里面的图标数据是怎么来的,本人还不知道是怎么来的呢,望知道的朋友可以提出您的宝贵意见,本人将很是感谢,或者可以发帖出来与你们分享一下!!!

http://www.ibm.com/developerworks/cn/linux/l-rel/  能够看看!!!

能够参考资料:使用 gnuplot 在网页中显示数据

http://www.ibm.com/developerworks/cn/aix/library/au-gnuplot/#4.Installing Gnuplot|outline

下面附上top和sar的使用方法,方便参考!

"top"工具

使用方式:top [-] [d delay] [q] [c] [S] [s] [i] [n] [b]

说明:即时显示 process 的动态

-d    改变显示的更新速度,或是在交谈式指令列( interactive command)按d

-q    没有任何延迟的显示速度,若是使用者是有 superuser 的权限,则 top 将会以最高的优先序执行

-c    切换显示模式,共有两种模式,一是只显示执行档的名称,另外一种是显示完整的路径与名称

-S    累积模式,会将己完成或消失的子行程 ( dead child process ) 的 CPU time 累积起来

-s    安全模式,将交谈式指令取消, 避免潜在的危机。

-i    不显示任何闲置 (idle) 或无用 (zombie) 的行程

-n    更新的次数,完成后将会退出 top

-b    批次档模式,搭配 "n" 参数一块儿使用,能够用来将 top 的结果输出到档案内

 

"sar"工具

sar [options] [-A] [-o file] t [n]

说明:在命令行中,n 和t 两个参数组合起来定义采样间隔和次数,t为采样间隔,是必须有的参数,n为采样次数,是可选的,sar命令的选项不少,下面只列出经常使用选项:

-a    报告文件读写使用状况

-b    报告缓存的使用状况

-c    报告系统调用的使用状况

-d    报告磁盘的使用状况

-h    报告关于buffer使用的统计数据

-m    报告IPC消息队列和信号量的使用状况

-q    报告运行队列和交换队列的平均长度

-R    报告进程的活动状况

-r    报告没有使用的内存页面和硬盘块

-u    报告CPU的利用率

-v    报告进程、i节点、文件和锁表状态

-w    报告系统交换活动情况

本文出自 “宗军” 博客,请务必保留此出处http://tech110.blog.51cto.com/438717/737865

 

关于楼主,博文中提到的图片的生成方法。推荐读这篇文章:
Data visualization tools for Linux 
http://www.ibm.com/developerworks/linux/library/l-datavistools/

找到了gnuplot的中文事例!
gnuplot 让您的数据可视化
http://www.ibm.com/developerworks/cn/linux/l-gnuplot/

LTP:

http://ltp.sourceforge.net/documentation/how-to/ltp.php

参考自:https://blog.csdn.net/melody157398/article/details/24354415

更详细内容可参考:https://blog.csdn.net/kernel_learner/article/details/8238974