Client Control files
主要内容
- jobs 例子
- 扩展测试
- 流程控制
- 系统信息抓取
- 分析器
- 创建文件系统
- job执行期间重启
- 并行运行多个测试
control file定义了一次test job 关键信息,它定义了一次测试的方方面面.control文件是一个python脚本,它驱动这个测试.
job例子
可以添加一个job对象用来驱动测试和一些服务支持.一个job例子可以是这样:
job.run_test('kernbench')
参数只有测试的名字(kernbench).autotest有很多测试用例,每个测试都有一个简单的control文件(tests/
$ client/autotest-local <control_file_name>
在control文件中同样可以指定测试参数
job.run_test('kernbench', iterations=2, threads=5)
- 第一个参数是测试名称;
- 第二个参数是执行次数和线程数,大多数你可以执行它的默认参数.
还可以指定一个tag参数,用来给测试结果目录命名:
job.run_test('kernbench', iterations=2, threads=5, tag='mine')
测试时会创建结果目录"kernbench.mine"来替代之前的"kernbench".这个功能非常重要,当你执行了多次测试,可以用来区分测试结果.
扩展测试
当开发一个测试时,为了让它能正常的下载和执行时,需要符合扩展测试的要求.
流程控制
真正掌握一门语言用于脚本控制是学会它的控制结构和错误检查机制.这里给出一个kernbench运行不同threads的例子.
for t in [8, 16, 32]:
job.run_test('kernbench', iterations=2, threads=t, tag='%d' % t)
系统信息抓取
每次重启和测试时,autotest都会生成一个目录用来保存系统的信息.比如/proc/meminfo文件内容,"uname-a"的输出信息.可以在测试结果目录找那个查看.
sysinfo/(每次重启前的数据),
job.add_sysinfo_file("/proc/vmstat")
可以设置每次重启后,收集/proc/vmstat的信息.可以通过on_every_test参数实现:
job.add_sysinfo_file("/proc/vmstat", on_ervey_test=True)
另外一种方式:
job.add_sysinfo_command("lspci -v", logfile="lspci.txt")
这样每次重启都可以执行lspci -v,并把信息导入到lspci.txt. logfile的参数是可选的.如果不指定它,就会默认以lspci_ -v作为名字.这个方法,同样是每次reboot都会 执行.
使用分析器
你可以启用一个或多个分析器.下面是添加和移除的例子: job.profilers.add('oprofile') job.run_test('sleeptest') job.profilers.delete('oprofile')
多个测试使用方式:
job.profilers.add('oprofile')
job.run_test('kernbench')
job.run_test('dbench')
job.profilers.delete('oprofile')
它会为每个测试生成独立的分析结果,以免不影响性能结果.分析结果会在测试结果目录下的
创建文件系统
autotest内建支持创建文件系统.用来支持在不同文件系统中进行fsx测试:
# uncomment this line, and replace the device with something sensible
# for you ...
# fs = job.filesystem('/dev/hda2', job.tmpdir)
for fstype in ('ext2', 'ext3'):
fs.mkfs(fstype)
fs.mount()
try:
job.run_test('fsx', job.tmpdir, tag=fstype)
finally:
fs.unmount()
同样支持为不同的文件系统添加不同的挂载参数:
fs = job.filesystem('/dev/sda3', job.tmpdir)
iters=10
for fstype, mountopts, tag in (('ext2', '', 'ext2'),
('ext3', '-o data=writeback', 'ext3writeback'),
('ext3', '-o data=ordered', 'ext3ordered'),
('ext3', '-o data=journal', 'ext3journal')):
fs.mkfs(fstype)
fs.mount(args=mountopts)
try:
job.run_test('fsx', job.tmpdir, tag=tag)
job.run_test('iozone', job.tmpdir, iterations=iters, tag=tag)
job.run_test('dbench', iterations=iters, dir=job.tmpdir, tag=tag)
job.run_test('tiobench', dir=job.tmpdir, tag=tag)
finally:
fs.umount()
job测试中重启
当一个job需要重启时,比如导入一个新的内核.这样就会导致control脚本执行中断.这样就需要分布执行的模块.
def step_init():
job.next_step([step_test])
testkernel = job.kernel('2.6.18')
testkernel.config('http://mbligj.org/congig/opteron2')
testkernel.build()
testkernel.boot() #does autotest by default
def step_test():
job.run_test('kernbench', iterations=2, threads=5)
job.run_test('dbench', iterations=5)
通过指定step_init表明控制脚本已一种分布模式执行.在执行中断时(如reboot)会保存测试环境.
一个重要的提示是分布执行引擎并不意味支持这个测试过程的分步执行.只能支持再控制文件级别中实现.因为在测试程序执行时一些返回值.实现自动测试过程中中断测试 不太现实.如果出现超时,会杀死子线程. 因此,代码插入到control文件中是正确的:
def step_init():
job.next_step([step_test])
testkernel = job.kernel('testkernel.rpm')
testkernel.install()
testkernel.boot()
def step_test()
job.run_test('ltp')
相关代码插入到测试模块中,是不行的.
class Kerneltest(test.test):
def execute(self):
testkernel = job.kernel('testkernel.rpm')
testkernel.boot()
直接的,当使用分布引擎时,控制文件不是简单的执行一次.而是循环执行,直到测试完成.在一个独立的情况下,当一个控制文件存在,在重启之后会自动启动执行.在托管环境中管理服务器将执行相同的作用. 当面对分步执行时,循环会变得更加困难.
def step_init():
step_test(1)
def step_test(iteration):
if (iteration < 5):
job.next_step([step_test, iteration + 1])
print "boot: %d" % iteration
job.run_test('kernbench', tag="%s" % i)
job.reboot()
并行运行
job对象同样提供一个并行运行多个测试的方法. 该方法采用可变数量的参数,分别代表不同的任务并行运行。 每个参数应该是一个列表,其中该列表中的第一项是一个函数的调用和所有其余元素都将被传递给函数被调用时的参数。
def first_task():
job.run_test('kernbench')
def second_task():
job.run_test('dbench')
job.parallel([first_task], [second_task])
控制文件会同时执行kernbench和dbench.代码还可以如此写:
job.parallel([job.run_test, 'kernbench', [job.run_test, 'dbench'])
如果你想这样更复杂的东西在你的任务中,而不是要求单一的功能,那么你就必须定义自己的函数来做到这一点,如在第一个例子。
并行任务执行在自己的地址空间,你不比担心.但是毕竟是运行在同一台物理机中.仍然需要主要避免访问同一资源,如相同的文件.
Top^
上一篇Autotest:Autotest-Local>>> 下一篇Autotest:Autotest-Control file specification>>>