https://blog.csdn.net/melody157398/article/details/24354415
LTP--linux稳定性测试 linux性能测试 ltp压力测试 ---IBM 的 linux test project
今天考虑如何将这个变态的系统（说它变态，一点都不过，因为是debian和Ubantu 杂交的，设计者都是这么说的）的功能测试程序化，结果论坛上有人建议考虑 IBM 的 linux test project 下载下来，安装了十来分钟，最后运行时报错，安装不准确，糟糕的变量名等，奇怪呀，安装挺顺利的结果不能用，这系统，哎，就是特殊呀！
不管了，IBM 的 linux test project 也是一个好工具，把参考资料保存在这里。
http://tech110.blog.51cto.com/438717/737865
说明:在写这篇文章之前,本人也不曾了解LTP是干嘛的,直到参加一次技术沙龙才了解到它是用来对linux系统进行稳定性测试的一个开源工具,演讲人是世纪佳缘运维部门的技术老总!平时我们这些做运维朋友们都很少涉及到系统的测试,因为觉得linux本生就很稳定,因此就没有必要去做测试,但是系统是更新的,同样linux的内核是也在更新的,那新系统是否就适合我们的业务,是否就比就系统稳定可靠呢!!我想大部分人凭直觉认为新系统就比老系统好吧!特别是对那些业务量大,访问量较高的大型网站来说,稳定的系统是多么的重要!!!
@@@@-本人在网上也找了好久LTP的介绍,大都是雷同的,而且不知道COPY了多少遍,且时间已久,要想找到完整且好的非常的困难,从这点也可以看出,几乎很少有人做稳定性测试这方面的工作了!!
本人关于LTP的一些说明大都还是来自于网上,我想这个应该都是一样的!
=============================LTP介绍开始===================================
LTP--Linux Test Project
简介:
LTP套件是由 Linux Test Project 所开发的一套系统测试套件。它基于系统资源的利用率统计开发了一个测试的组合,为系统提供足够的压力。
通过压力测试来判断系统的稳定性和可靠性。
压力测试是一种破坏性的测试,即系统在非正常的、超负荷的条件下的运行情况 。用来评估在超越最大负载的情况下系统将如何运行,是系统在正常的情况下对某种负载强度的承受能力的考验 。
使用LTP测试套件对Linux操作系统进行超长时间的测试,重点在于Linux用户环境相关的工作负荷。而并不是致力于证明缺陷。
压力测试的设计
重点: 1测试选择。
2评价系统资源利用率。
3分析内核代码覆盖率。
4评价最终压力测试
1. 测试选择--包括达成两方面目的的测试：
- 测试应该可以得到 CPU（s）、内存、I/O 和网络等主要内核区域的高水平的资源利用率。
- 测试应该充分地覆盖内核代码，以帮助支持自其结果中生成的稳定性声明。
2. 评价系统资源利用率
所选择的测试的组合必须给系统的资源带来足够的压力。Linux 内核的四个主要方面可以影响系统的 响应和执行时间：
- CPU：用于在机器的 CPU（s）上处理数据的时间。
- Memory：用于自真实存储器中读写数据的时间。
- I/O：用于自磁盘存储器读写数据的时间。
- Networking：用于自网络读写数据的时间。
系统资源利用率评价阶段通常需要多次尝试才能得到合适的测试组合，并得到期望水平的利用率。当确定测试组合时，过度利用总是一个至关重要的问题。例如，如果选择的组合过于受 I/O 所限，可能会 导致 CPU 的测试结果不好，反之亦然。方法的这一部分主要是大量的试验和出错，直到所有资源达到期望水平。
当选定一个组合后，测试必须长时间运行以准确评价资源的利用率。测试运行的时间长短取决于每个测试的长度。假如多个测试同时运行，则时间必须足够长以使得这些测试中最长的那个可以完成。在这个评价过程中，sar 工具也应该在运行。在评价运行的结论中，您应该收集并评价所有四种资源的利用率水平。
3. 分析内核代码覆盖率
获得足够的内核覆盖率是系统压力测试的另一个职责。尽管所选的测试组合充分地利用了四种主要资源，它也有可能只是执行了内核的一小部分。因而，应该对覆盖率进行分析以确保组合可以成为一个系统压力测试，而不是一个系统负载生成器。
4. 之所以要执行方法中的这最后一步，是为了对系统压力测试进行核实。在一个被认为是稳定的内核上执行压力测试； 通常，发行版本中的内核可以满足这一要求，但不总是如此。要长时间地执行压力测试，同时运行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的设计和开发过程中用到，目的是保证lptsress.sh的可用性，我们在实际测试的时候就不需要再做内核的代码覆盖率分析了。
系统监控
LTP 测试套件附带的 top 工具是经过修改的，用作系统监控工具。使用 top 可以实时地观察处理器的行为。改进的 top 工具具有附加的功能，可以将 top 结果的快照保存到文件中，并给出结果文件的平均总结，包括 CPU、内存和交换空间利用率等信息。
在我们的测试中，sar工具每 10 秒钟截取一次系统利用率的快照，并保存到结果文件。
测试之前所有选定的测试系统的硬件配置尽可能相同。去掉额外的硬件以减少潜在的硬件故障。在映像安装过程中选择最低的安全选项。预留至少 2 GB 的硬盘空间以保存 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/ 可以看看!!!
此图挺好,本人就是不知道用什么工具来实现,期待ING!!!!!!!
可以参考资料:使用 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