OpenStack自动化功能测试.docx

OpenStack自动化功能测试一、OpenStack测试概要随着，云计算在国内外的迅猛发展，OpenStack业已成为这方面的既定事实标准，而众多企业在基于OpenStack开发云产品时，自然地，对测试方面的需求和质量提出了更高的要求。目前，OpenStack社区已有近百个项目、数千名开发人员、数千万行代码和数百家公司参与其中。如何确保如此众多且水平不同、目的不同的开发人员，按照某种规则贡献智慧、提交代码，促进OpenStack开源社区有序、稳定健康发展。为此，社区在CI（持续集成）中提出了一种规则，——Gate，即门禁系统之意。凡开发人员提交代码（站在门外），均务必测试成功后（门禁系统验证身份通过），代码才会进入到Git仓库中（站在门内）。OpenStack测试，是一个涉及层面非常广泛和多技术交叉应用的领域。根据不同层面，即纬度的划分主要有：单元测试——>功能测试（也称为集成测试）——>系统测试（如验收测试、性能测试）等。根据特定的测试对象和目标，又可以分为存储测试、虚拟机网络测试、故障HA测试等。如下图所示。在测试方面，OpenStack社区做得非常完善，针对不同的测试层面，设计并实现了相应的测试工具或项目。具体如，使用Python PEP8等测试代码编写是否符合规范，Nose等框架用于单元测试、Tempest用于功能/集成测试、Rally用于性能测试、Shaker用于虚拟机网络测试、DevStack用于部署测试等，除此外，还有各种环境兼容性测试，如Python2.7和Python3.4、Centos系和Debian系等环境测试。二、OpenStack功能测试设计与实现以上，是对OpenStack测试的概要介绍，是一个面。这里，针对一个点进行详细阐述，即使用Tempest自动化测试OpenStack的功能，具体包括测试Keystone、Glance、Cinder、Nova、Neutron和Swift等项目功能。由于Tempest大部分功能社区已经开发实现，所以在企业的研发测试环境下，用户可以按照自己的需求进行扩展使用等。目前，Tempest已广泛应用于CI持续集成、OpenStack社区互操作性测试认证等领域。1.在Docker中运行Tempest“工欲善其事，必先利其器”。首先，需要安装并配置好Tempest测试环境，由于Docker具有轻量、环境隔离、一次打包处处运行的优秀特性，故此，这里选择将Tempest安装部署在Docker容器中。举个简单例子，当测试A环境的OpenStack时，需要构建好一个诸如Tempest在内的测试平台；当测试B环境的OpenStack时，又需要构建好一个同样的测试平台；同时，因不同环境的反复配置容易导致测试环境配置错误。综上，选择Docker运行是一种更好的方式。Tempest测试的实现是基于Python的unittest2和nose框架。通过对Openstack后端发起一系列API请求，并且对后端的响应进行验证。Tempest使用config配置文件来描述整个测试环境，包括Nova 、Keystone、Glance、Neutron等OpenStack相关服务。并同时支持 JSON、XML 两种 REST API 格式类型的测试， 以及 CLI 测试。Tempest的优点Tempest可以自动寻找，执行测试：自动查找当前目录下所有以[Tt]est开头的Python源文件，并且按此规则递归查找子目录；所有以[Tt]est开头的Python源文件里所有以[Tt]est开头的function和class，以及继承自unittest.TestCase的class(不需要以[Tt]est开头)都会被执行。Tempest可以指定文件、模块、函数进行测试。Tempest可以指定类型进行测试。Tempest可扩展性强，可以方便的在tempest中添加其他测试用例，可以整合其他类型测试例如压力测试、场景测试等。Tempest是通过nose驱动的，python语言编写，使用testtools和testresources等几个测试工具库Tempest.test.BaseTestCase,BaseTestCase声明config属性,读取配置文件Tempest.test.TestCase声明很多工具函数，供调用。每个测试可以分别测试JSON格式和XML格式当然，它的缺点是需要手动配置tempest.conf环境描述文件，工作量大，容易出错。Tempest 代码主要结构，如下所示。其中，api和scenario部分的测试用例是我们关注的重点。tempest/├── etc/ ? ? ? ?<--tempest相关配置文件目录├── tempest/ ? ? ? <--各个组件测试用例 ? ?├── api ?