摘要： LTP套件是由 Linux Test Project 所开发的一套系统测试套件。它基于系统资源的利用率统计开发了一个测试的组合,为系统提供足够的压力。本文主要讲解LTP的软件组织，应用，安装方法和使用介绍。
1.LTP简介
LTP套件是由 Linux Test Project 所开发的一套系统测试套件。它基于系统资源的利用率统计开发了一个测试的组合,为系统提供足够的压力。
通过压力测试来判断系统的稳定性和可靠性。
压力测试是一种破坏性的测试,即系统在非正常的、超负荷的条件下的运行情况 。用来评估在超越最大负载的情况下系统将如何运行,是系统在正常的情况下对某种负载强度的承受能力的考验 。
这是他的英文官方介绍：
The Linux Test Project is a joint project with SGI, IBM, OSDL, and Bull with agoal to deliver test suites to the open source community that validate thereliability, robustness, and stability of Linux. The Linux Test Project is acollection of tools for testing the Linux kernel and related features. Our goalis to improve the Linux kernel by bringing test automation to the kernel testingeffort. Interested open source contributors are encouraged to join the project.
使用LTP测试套件对Linux操作系统进行超长时间的测试,重点在于Linux用户环境相关的工作负荷。而并不是致力于证明缺陷。
压力测试的设计
重点:
1测试选择。
2评价系统资源利用率。
3分析内核代码覆盖率。
4评价最终压力测试
1.1 测试选择--包括达成两方面目的的测试：
- 测试应该可以得到 CPU（s）、内存、I/O 和网络等主要内核区域的高水平的资源利用率。
- 测试应该充分地覆盖内核代码，以帮助支持自其结果中生成的稳定性声明。
1.2评价系统资源利用率
所选择的测试的组合必须给系统的资源带来足够的压力。Linux 内核的四个主要方面可以影响系统的 响应和执行时间：
- CPU：用于在机器的 CPU（s）上处理数据的时间。
- Memory：用于自真实存储器中读写数据的时间。
- I/O：用于自磁盘存储器读写数据的时间。
- Networking：用于自网络读写数据的时间。
系统资源利用率评价阶段通常需要多次尝试才能得到合适的测试组合，并得到期望水平的利用率。当确定测试组合时，过度利用总是一个至关重要的问题。例如，如果选择的组合过于受 I/O 所限，可能会 导致 CPU 的测试结果不好，反之亦然。方法的这一部分主要是大量的试验和出错，直到所有资源达到期望水平。
当选定一个组合后，测试必须长时间运行以准确评价资源的利用率。测试运行的时间长短取决于每个测试的长度。假如多个测试同时运行，则时间必须足够长以使得这些测试中最长的那个可以完成。在这个评价过程中，sar 工具也应该在运行。在评价运行的结论中，您应该收集并评价所有四种资源的利用率水平。
1.3.分析内核代码覆盖率
获得足够的内核覆盖率是系统压力测试的另一个职责。尽管所选的测试组合充分地利用了四种主要资源，它也有可能只是执行了内核的一小部分。因而，应该对覆盖率进行分析以确保组合可以成为一个系统压力测试，而不是一个系统负载生成器。
1.4.最终评价
之所以要执行方法中的这最后一步，是为了对系统压力测试进行核实。在一个被认为是稳定的内核上执行压力测试； 通常，发行版本中的内核可以满足这一要求，但不总是如此。要长时间地执行压力测试，同时运行sar 工具，原因有以下两点：
-长时间运行有助于发现组合中的所有问题，否则，在短时间的“取样测试（sniff test）”中这些问题可能会被忽略。
-sar 生成的数据构成以后测试运行中进行比较的基线。
长时间运行结束后，现在可以基于收集的所有数据来决定这个测试组合是否是系统压力测试的合适候选者。
2.软件架构与组织
源安装包目录列表:
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 : 这个脚本是获取硬件、软件、环境信息。
3.安装方法
3.1获得源码
git clone ：https://github.com/linux-test-project/ltp.git
3.2进行内核配置
Using KDUMP test automation suite---------------------------------For more information on how to use the kdump test automation suite please referto file testcases/kdump/README.Using NUMA test automation suite---------------------------------For more information on how to use the 'numa' test automation suite please referto file testcases/kernel/numa/README.---------------------------------Enable CODE COVERAGE for your Kernel:---------------------------------1) Apply kernel-gcov patch(s) against the corresponding Kernel. They are available here:http://ltp.cvs.sourceforge.net/viewvc/ltp/utils/analysis/gcov-kernel/linux-2.*.*-gcov.patch?view=log,2) Also enable the following options in your .config file before building the kernelCONFIG_GCOV_PROFILE=yCONFIG_GCOV_ALL=yCONFIG_GCOV_PROC=mCONFIG_GCOV_HAMMER=y---------------------------------Enabling Kernel Configuration to test Containers/Namespaces---------------------------------CONFIG_NAMESPACES=yCONFIG_UTS_NS=yCONFIG_IPC_NS=yCONFIG_USER_NS=yCONFIG_PID_NS=yCONFIG_NET_NS=yCONFIG_VETH=yCONFIG_MACVLAN=yThe IPC namespaces do not automatically enable IPC, so you mayalso want to have:CONFIG_SYSVIPC=yCONFIG_SYSVIPC_SYSCTL=yCONFIG_POSIX_MQUEUE=y
如果我们要测试内核相关的特性，我们需要进行相关的配置，上面只是简要介绍了一些例子，具体的内核配置请参考LTP软件源代码中的README：https://github.com/linux-test-project/ltp
3.3软件安装方法
请参考源代码目录下的INSTALL：
1）编译相关的软件准备：
为了编译ltp，必须安装make 3.80+，为了编译和使用ltp-scanner（pan目录下的一个应用），必须要有bison/yacc（只需要一个）和flex, 同时，由于我们从git下来的源码中是不包含configure的，我们需要安装autoconf-2.61+和automake-1.1。
2）产生配置文件
$:make autotools
3)编译LTP（切换到root用户）
注意：ltp中不能安装目录中不能包含特殊字符（逗号，冒号和空格等）
进入源代码目录，依次运行：
$ make all
$ make \
SKIP_IDCHECK=[0|1] \
install
解释： Specify SKIP_IDCHECK=1 if and when you don't want to modify /etc/{group,pa sswd}
102 on the target system's sysroot.
4）检测是否安装成功
安装成功的目录默认在opt/ltp目录下，测试工作就在这个目录下进行：
$./runltplite
如果能够正确运行并且产生输出，就说明软件安装成功。
4.软件使用
4.1LTP 测试方法
测试方法有两个阶段:
阶段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 日志数据。
4.2测试前的配置
实际运行当中，您还需要配置一些必要的服务才可以正确的运行LTP的测试套件，以ltprunall.sh为例，它是不需要配置其他服务就可以运行的，但是对于ltpstress.sh，是需要配置一些相关服务之后才可以正确运行的，需要您配置的服务如下：
配置rsh和rlogin服务，使用户能以root身份不需密码验证直接登录本机。
4.3具体测试方法
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:指定测试的持续时间
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: 指定测试时间
3）用户自定义测试:
想要有选择的自定义测试项目,可以如下方法操作
创建命令文件,这个命令文件包括两部分: 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
关于自定义测试，一方面我们可以自己来写测试文件；另外一个方面，我们可以利用软件本身提供的自定义测试文件，比如：run/test下的mm文件，就是进行内存测试：
1 #DESCRIPTION:Memory Mgmt tests 2 mm01 mmap001 -m 10000 3 # 40 Mb mmap() test. 4 # Creates a 10000 page mmap, touches all of the map, sync's it, and 5 # munmap()s it. 6 mm02 mmap001 7 # simple mmap() test. 8 #mm03 mmap001 -i 0 -I 1 -m 100 9 # repetitive mmapping test. 10 # Creates a one page map repetitively for one minute. 11 12 mtest01 mtest01 -p80 13 mtest01w mtest01 -p80 -w 14 15 #test for race conditions 16 mtest05 mmstress 17 mtest06 mmap1 -x 0.05 18 mtest06_2 mmap2 -x 0.002 -a -p 19 mtest06_3 mmap3 -x 0.002 -p 20 # Remains diabled till the infinite loop problem is solved
5.实例进行内存测试
进入/opt/ltp目录之下：
$:./runltp -p -l self.log -f mm -t 24h
结果分析：
在result和outputs目录下，有相关的测试结果输出，显示哪些测试成功，那些测试失败。
本文链接：http://blog.csdn.net/trochiluses/article/details/10061513
外部参考：
【1】软件本身的README&&INSTALL
【2】http://tech110.blog.51cto.com/438717/737865
