简介:
LTP套件是由 Linux Test Project 所开发的一套系统测试套件。它基于系统资源的利用率统计开发了一个测试的组合,为系统提供足够的压力。
通过压力测试来判断系统的稳定性和可靠性。
压力测试是一种破坏性的测试,即系统在非正常的、超负荷的条件下的运行情况 。用来评估在超越最大负载的情况下系统将如何运行,是系统在正常的情况下对某种负载强度的承受能力的考验 。
使用LTP测试套件对Linux操作系统进行超长时间的测试,重点在于Linux用户环境相关的工作负荷。而并不是致力于证明缺陷。
压力测试的设计
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 日志数据。
测试运行
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中，方便查看。
