ceph自动化测试用例编写

1.1  应用需求

由于官方对于teuthology和ceph-qa-suite没有任何的文档介绍。在这篇文档中将介绍ceph-qa-suite中case的测试内容以及如何简单修改增加case。

1.2  相关模块

整个自动化环境需要依赖如下三份python代码,关注最多的就是ceph-qa-suite和ceph/qa。

Teuthology:用来调度case ,选择机器,安装ceph等基础环境以及管理整个测试过程。

ceph-qa-suite:为集群增加配置,设置拓扑,以及测试case的设计。

ceph/qa/:自动化测试最终调用的shell脚本。

1.3  代码目录

目前搭建了两个可以进行推送测试任务的服务器。如果要登录机器上增加用例或推送任务,希望大家配置172.16.101.* /16的小网网段或者使用自己的16位掩码小网ip。(自动化测试都是100网段,防止与自动化的冲突)

目前搭建了两个teuthology的服务器,172.16.100.7 和172.16.100.4 (同时支持Jewel版本)。不测试B02的话,建议大家使用172.16.100.7的服务器。

ceph-qa-suite yaml文件所在目录:增加yaml文件在 /repo/ceph-qa-suite_基线版本,其中版本为需要测试的基线版本,hammer版本为空,jewel版本就为/repo/ceph-qa-suite_jewel

ceph-qa-suitetask所在目录:增加tasks文件在 teuthworker用户的src/ceph-qa-suite_基线版本下,hammer和master版本为ceph-qa-suite_master, jewel版本为ceph-qa-suite_jewel。

qa目录: /root/ceph/qa 但是测试用的qa是从172.16.100.9上git下来的,在这里修改代码以后需要push到[email protected]:/git/ceph.git远端自己搭建的git服务器上,注意push到自己需要测试的分支上。

2  简单用例编写

2.1  配置yaml文件

Yaml文件类似于对集群的配置,我们可以单独写一个yaml文件,也可以写多个yaml文件组合在一起。在yaml文件中, 我们必须指明如下几点:

(1)roles:

该项配置的目的是指明需要搭建的集群的拓扑。Mon数据,osd数据,以及客户端节点。例如:

- [mon.0, osd.0, osd.1, client.0]  //指明搭建一个单节点,一个mon,两个osd,该节点自身作为client0的集群

也可以用另一种方式写:

roles:

- - mon.a

-osd.0

-osd.1

-osd.2

-client.0

- - osd.3

-osd.4

-osd.5                   //两节点的集群,每个节点三个osd。总共一个monitor

另外,tasks为给case增加测试内容:

(2)tasks:

在该配置下面主要为了增加测试case,我们可以在该下面指明需要执行的任务,一般情况下,首先就是安装ceph ,然后再并行的进行多个测试脚本。

例如:

tasks:

- install:             //安装ceph

- ceph:             //搭建集群以及增加相应配置

log-whitelist:

-wrongly marked me down

-objects unfound and apparently lost

conf:

osd:

osd debug reject backfill probability: .3

osd max backfills: 1

osd scrub min interval: 60

osd scrub max interval: 120

- thrashosds:            //进行对osd的异常操作

timeout: 1200

chance_pgnum_grow: 1

chance_pgpnum_fix: 1

(3)overrides:

在overrides下,可以增加高优先级的ceph配置,但overrides部分不是必须要增加。例如:

overrides:

ceph:

conf:

mon:

debug mon: 20

debug ms: 1

debug paxos: 20

mon warn on legacy crush tunables: false

mon min osdmap epochs: 3

osd:

debug filestore: 20

debug journal: 20

debug ms: 1

debug osd: 20

log-whitelist:

-osd_map_cache_size

- slow request

如上的配置中mon ,和osd即为在ceph.conf中对集群的配置。log-whitelist的目的是过滤掉在log中你希望过滤的警告和错误。因为teuthology在测试过程中,如果log中出现了ceph集群的警告或者错误信息,这个测试case就认为失败,然后执行下一个测试case。

2.2  使用方法

见用例篇

2.3  参数介绍

-      install:  //安装ceph

-      ceph:  //给ceph增加配置信息,同时也可以过滤一些警告或error,例如:

-      exec: //在特定某个客户端执行具体命令,可以在exec下写希望执行的命令

-      thrashosd:      // 启动一个线程进行随机down osd,out osd ,revive osd,修改primary_affinity,,reweight_osd,修改pg_num,测试backfill等等

-      mon_thrash: //启动线程进行kill mon,等待quorum,revive mon,等待 quorum ,如此循环…

-      radosbench:   //在节点上运行radosbench增加业务

-      admin_socket: //从指定路径获取脚本进行测试

-      rados: // 启动线程进行所有rados 部分读,写,删除,快照,回滚,拷贝等操作,并且可以指定各项测试的权重。实际运行的是 ceph/src/test/osd/TestRados.cc。也可以指定操作次数和object大小,是否使用纠删码,以及配置纠删码的erasure_code_profile

-      workunit: //获取ceph/qa/workunits 整个目录,并运行指定的shell脚本。大部分脚本最终运行的是ceph/src/test/*.cc测试文件

-      mon_clock_skew_check: //进行时钟不同步测试

上面是最常用的在yaml文件中配置的task接口。当然,我们也可以指定某个具体的函数,例如:

ceph_manager.create_pool:

args: [‘toremove‘]

kwargs:

pg_num: 4096

在yaml文件中配置如上信息即为创建一个名为toremove,pg_num为4096的pool。其他的接口都可以在/ceph_qa_suite/tasks目录下的.py文件中查看。

tasks部分为最重要的配置,在下面介绍一下yaml文件中tasks可以配置的参数。

2.4  配置文件增加

测试过程中经常会需要改变一下ceph.conf中的配置信息。目前有两种方式更改这些配置信息。

1、  在原有的tasks列下修改或增加,例如:

如图,可以在osd下增加osd的配置,当然也可以使用global,mon等增加其他的配置。图中的log-whitelist也是非常重要的。因为teuthology在测试过程中只要ceph的log里出现了error或者warning就会出错导致测试失败,所以我们可以在log-whitelist里增加相应的字段过滤认为不影响测试的error或者warning。

2、  使用overrides增加配置

另外一种方式是使用overrides的配置,给集群增加优先级更高的配置。例如:

个人建议使用这种方式增加配置,因为我们可以自己新建一个yaml文件,在该文件中写入overrides配置选项,测试过程中再把该文件列入yaml文件列表就可以了。这种方式可以在不修改基础测试用例代码的前提下增加配置,非常灵活。

2.5  测试task

在yaml文件里,实际每个tasks下的配置项都对应一个python文件,每个python文件的命名比较与yaml文件下的配置项名相同,才会被调用。对应在tasks目录下已经存在的python文件,可以直接在yaml文件里调用。如果需要新增测试task,可以在tasks目录下增加python文件。例如:

如上就是一个简单的python文件,最基础的就是需要定义一个名为task的函数。执行过程中teuthology代码会来调用。其中的参数config为调用该tasks时写入的参数。而在ctx中可以获取到所有需要的接口,包括获取整个测试case的配置,测试目录,调用创建pool的接口等等。

其中的remote函数调用的是teuthology代码里的接口,作用是远程登录到某一个client上,执行相应的命令。上例中remote远程登录到client上创建一个pool,同时运行radosbench,之后等待进程退出的同时运行下一个tasks。

这里要注意的是不仅仅是以python文件名的tasks接口可以被调用,ceph_manager里提供了另外一种调用方式。

这样,我们可以直接在yaml文件中执行一个具体任务进行测试,比如可以在tasks下使用ceph_manager.kill_osd,ceph_manager_create_pool等。其中也可以改使用args和kwargs指定相应的config。

总之,tasks是ceph-qa-suite里最重要的部分,其中使用最多的就是rados.py,thrash_osd.py,mon_thrash.py等。

-rados: 进行所有读,写,快照,回滚,纠删码,克隆等基本内部单元测试。实际会调用ceph/src/test下面的osd/TestRados.cc。

-thrash_osd:随机对osd进行down,out,reweight,改变pg数,使用ceph-objectstore-tool进行数据导入导出等一系统测试。

-mon_thrash:多次将mon进行down up测试,同时会伴随着其他各种操作。甚至会用到9个等更多个mon进行测试。

2.6  单元测试用例增加

tasks里的workunits配置项是非常有用的,可以直接从自己搭建的git服务器中获取到ceph/qa/下的shell脚本,之后在所选的client上执行对应的shell测试脚本。

如上就是直接在client.0的任务机上运行ceph/qa/workunits/rados/test.sh的测试脚本。shell测试脚本一般分两种类型:

1、  命令行的测试

这种测试相当于是把所有要执行的命令组合在一个shell脚本里,其中当然也会写一些需要用到的函数,之后自动会在某个任务机上直接执行。如果需要增加这部分测试用例,只需要写好自己的shell脚本,将他放到ceph/qa/workunits目录下(这部分代码存放在自动化环境的一个git服务器上,需要提交到该git服务器上),然后在自己的yaml文件中在workunit配置项中指定自己写的shell脚本就Ok了。之后只需要切换到teuthology用户下使用teuthology-suite测试该yaml文件。

2、  对应的代码测试

另外一种测试是在shell脚本里运行某一命令,但该命令最终会调用到ceph/src/test/目录下的某个.cc测试文件。上面的rados/test.sh就是其中的一种。如果需要增加这部分单元测试用例,首先需要写一个测试模块的.cc测试代码,并且在test/Makefile-client.am里同样的增加。之后的步骤就和上面的一样了。

2.7  使用限制

1、  teuthology上所有的任务机都是ubuntu14.04.3的版本,所以无法测试到与cas相关的情况

2、  teuthology中做不到网络异常相关的测试例,所有任务机都是一个网卡,而且管理这些任务机是通过ssh远程登录的方式自动管理,如果网络异常就无法测试

3、  无法进行增删主机的测试,因为每个测试case的拓扑状况都是由teuthology代码管理和搭建,并且在测试前就限制住。但是teuthology会分别测试到相同用例,不同副本等不同环境配置的情况

4、  无法进行大业务量,大存储量的测试。因为任务机使用的都是虚拟机,每个虚拟机的硬盘只有60G,一旦数据量大就会把硬盘写满导致测试失败

3  应用实例

3.1  增加单个用例

现在已有的tasks 任务接口可以实现大多数的测试。所以我们可以调用这些接口,只增加yaml配置文件进行测试。例如:

如上我们需要在ceph-qa-suites目录下新建一个自己的目录,例如test(目的是不修改原有的用例)。在test目录下创建一个yaml文件,写入自己的需要的roles,以及测试任务tasks(overrides看自己需要)。以下几点需要特别注意:

(1)       yaml文件的编写格式。roles中每使用一次两个“- -”就代表一个新的任务节点,上例中就代表测试使用两个任务节点,一个mon,每个节点三个osd。其中第一个节点为client.0(后续在tasks中会用到)。

(2)       tasks中必须首先先install和ceph,目的是安装ceph,搭建集群。后续的每一个 “–”都代表一个任务,任务之间都是顺序执行,但是一般会在python代码里让任务之间能达到多线程并行的执行。

(3)       所有的yaml文件里都必须使用空格,不能使用Tab键。否则会导致读取失败

(4)       每个“:”后必须有空格,并且每个需要运行的任务或命令前都必须加“-”。配置文件前不需要增加。

增加完配置以后,就可以切换到teuthology用户下,su  - teuthology,直接运行新加的case

teuthology-suite--filter ‘test.yaml‘ --suite-dir /repo/ceph-qa-suite  --machine-type net --distro ubuntu --ownertest --suite test

3.2  增加组合用例

ceph-qa-suites上原有的测试用例基本都是组合用例。例如:

看过之前相关teuthology的介绍应该知道目录前面的%的意思。测试该目录下的case时可以直接指定这个目录,不必指定某个yaml文件。可以按照类似于如下目录结构进行创建:

这种方式的好处:

(1)       可以简单设计不同的副本模式测试相同的任务,覆盖创建更广

(2)       设计不同的文件类型进行测试

(3)       改变配置文件进行相同的测试,比较配置文件的影响

(4)       测试不同的case

3.3  增加新任务用例

如上面2.5所述,在ceph-qa-suites下的tasks目录下增加一个python文件,增加import模块和tasks函数。在tasks函数中写入你希望的整个测试过程以及如何判断测试失败的情况。就好比增加一个2.5上的python文件。然后同样需要在suites目录下创建test目录并且新建一个yaml文件,

在yaml文件中的tasks项配置新的任务接口就可以使用teuthology-suite命令运行了,运行方式见使用手册(一)。

时间: 2024-10-01 06:38:52

ceph自动化测试用例编写的相关文章

自动化测试用例编写

测试用例名同测试用例的编号,例如用例名统一以case+编号的形式开头: 每个测试用例粒度必须尽可能小,短小简单的测试用例易于调试.如果测试用例不得不长而复杂,则把它分成两个或更多的私有方法,并单独调用这些方法.尽量把重复任务放入一个方法中,这样它可以被多个测试用例调用: 所有的测试用例必须作为一个独立的测试用例运行,每个独立的测试用例负责自己的初始化和清理任务: 测试用例需要记录操作步骤: 测试用例执行出错要截图,从日志查看错误能一目了然: 测试用例要有合适的验证点,符合测试用例的期待结果: 测

用java和junit编写app自动化测试用例

package myTest; import static org.junit.Assert.*; import io.appium.java_client.android.AndroidDriver; import org.junit.After; import org.junit.Before; import org.junit.Test; import org.openqa.selenium.By; import org.openqa.selenium.WebElement; import

用python和unittest编写app自动化测试用例

import unittest import webdriver import time class Test(unittest.TestCase): @classmethod def setUpClass(self): cap = {} cap['platformName'] = 'Android' cap['platformVersion'] = '4.4.2' cap['deviceName'] = '7N2SSE158P001892' cap['noReset'] = 'noReset'

三. 自动化测试用例设计

1.  主要内容:   2.  手工测试用例与自动化测试用例区别 目前自动化测试更多的时候是定位在冒烟测试和回归测试: 冒烟测试执行的是主体功能点的用例. 回归测试执行全部或部分的测试用例. 3.  测试类型 4.  异常 5.  WebDriver错误截图 get_screenshot_as_file()函数将截取当前页面的截图保存到指定的位置. 1 # coding = utf-8 2 from selenium import webdriver 3 4 driver = webdriver

网上看到的,关于测试用例编写粒度准则

一.界面规范1.是否整个软件的字段的字体.大小.颜色.排列一致2.是否整个软件的字段后都有冒号(如果有,是否都属于同一种字体) 二.用例编写粒度准则1.对于不作为一个完整业务流的操作,如增.删.改等,每个操作(比如增加)作为一个用例.2.对于完整的业务功能实现的操作,把实现一个业务功能的目的作为一个用例.3.对于紧密关联的业务功能,把关联的业务功能实现作为一个用例.4.对于异常情况下的操作,作为一个用例.5.对于在异常情况下的操作的数据处理,作为一个用例. 网上看到的,关于测试用例编写粒度准则,

测试用例编写规范

一.测试用例编写准备 从配置管理员处申请软件配置:<需求规格说明书>和<设计说明书>:根据需求规格说明书和设计说明书,详细理解用户的真正需求,并且对软件所实现的功能已经准确理解,然后着手制订测试用例. 二.测试用例制定的原则 测试用例要包括欲测试的功能.应输入的数据和预期的输出结果.测试数据应该选用少量.高效的测试数据进行尽可能完备的测试:基本目标是:设计一组发现某个错误或某类错误的测试数据,测试用例应覆盖方面: 1.    正确性测试:输入用户实际数据以验证系统是满足需求规格说明

测试用例编写思路

    测试用例的编写可不简单呢,写一份专业的测试用例,是所有测试工作者考虑的内容,其实用例的编写是可以通过一些思路来进行,不少比较成熟的公司为了提升用例的专业性,就会有自己的用例库,包括流程.关注点,以及自己定义的模板. 今天作为测试老鸟的我经过几年的经验沉淀总结出来的一套测试用例编写思路,该思路累计共有八步,经验过验证几乎所有功能性测试都可以依据该架构思路来进行,将最大限度提升用例设计的专业程度 第一步.UI体验测试 1.风格.样式.颜色是否协调 2. 界面布局是否整齐.协调(保证全部显示出

测试用例编写指南

l        用例的补充.1.        测试执行阶段产生新的测试思路或者发现的BUG,没有用例覆盖到的,在项目发布后一周内,把用例全部补充上.让每一个BUG都有对应的用例覆盖.由产品线负责人监督 l        公共用例库.2.       公共用例库的目录结构规划要合理,方便后面的项目更新进来,这个最好由产品线负责人先统一规划好.3.       项目发布后一周内,把用例更新到公共用例库,由产品线负责人监督4.       小需求发布后半个月内,更新到公共用例库(考虑到小需求变术太

自动化测试用例与手工测试用例应用的区别

手工测试用例是针对手工测试人员,自动化测试用 例是针对自动化测试框架,前者是手工测试用例人员应用手工方式进行用例解析,后者是应用脚本技术进行用例解析,两者最大的各自特点在于,前者具有较好的异 常处理能力,而且能够基于测试用例,制造各种不同的逻辑判断,而且人工测试步步跟踪,能够细致的定位问题.而后者是完全按照测试用例的方式测试,而且异常 处理能力不强,往往一个自动化测试用例运行完毕后,报一堆错误,对于测试人员来定位错误是一个难点,这样往往发现的问题很少.所以,根据其各自的特点,需 要将两者有很好的