本文来自云技术社区线上分享。

Hi，大家好今天很荣幸，给大家分享“企业环境下的OpenStack自动化功能测试”，更准确的来说是API功能测试。分享内容如有不妥，恳请指正，同时本人尽力确保内容清晰易懂。言归正传，咱们进入正题。

一、OpenStack测试概要

随着，云计算在国内外的迅猛发展，OpenStack业已成为这方面的既定事实标准，而众多企业在基于OpenStack开发云产品时，自然地，对测试方面的需求和质量提出了更高的要求。

目前，OpenStack社区已有近百个项目、数千名开发人员、数千万行代码和数百家公司参与其中。如何确保如此众多且水平不同、目的不同的开发人员，按照某种规则贡献智慧、提交代码，促进OpenStack开源社区有序、稳定健康发展。为此，社区在CI（持续集成）中提出了一种规则，——Gate，即门禁系统之意。凡开发人员提交代码（站在门外），均务必测试成功后（门禁系统验证身份通过），代码才会进入到Git仓库中（站在门内）。

OpenStack测试，是一个涉及层面非常广泛和多技术交叉应用的领域。根据不同层面，即纬度的划分主要有：单元测试——功能测试（也称为集成测试）——系统测试（如验收测试、性能测试）等。根据特定的测试对象和目标，又可以分为存储测试、虚拟机网络测试、故障HA测试等。如下图所示。

在测试方面，OpenStack社区做得非常完善，针对不同的测试层面，设计并实现了相应的测试工具或项目。具体如，使用PythonPEP8等测试代码编写是否符合规范，Nose等框架用于单元测试、Tempest用于功能/集成测试、Rally用于性能测试、Shaker用于虚拟机网络测试、DevStack用于部署测试等，除此外，还有各种环境兼容性测试，如和、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两种RESTAPI格式类型的测试，以及CLI测试。

Tempest的优点

Tempest可以自动寻找，执行测试：自动查找当前目录下所有以[Tt]est开头的Python源文件，并且按此规则递归查找子目录；所有以[Tt]est开头的Python源文件里所有以[Tt]est开头的function和class，以及继承自的class(不需要以[Tt]est开头)都会被执行。

Tempest可以指定文件、模块、函数进行测试。

Tempest可以指定类型进行测试。

Tempest可扩展性强，可以方便的在tempest中添加其他测试用例，可以整合其他类型测试例如压力测试、场景测试等。

Tempest是通过nose驱动的，python语言编写，使用testtools和testresources等几个测试工具库

,BaseTestCase声明config属性,读取配置文件

声明很多工具函数，供调用。每个测试可以分别测试JSON格式和XML格式

当然，它的缺点是需要手动配置环境描述文件，工作量大，容易出错。

tempest/

测试用例和RESTAPI交互流程，如下图所示。

1）安装Docker和Tempest

catdockerfile

执行镜像构建命令

dockerimages|greptempest

以后台运行方式启动Tempest镜像

dockerps|greptempest

进入到Tempest容器中，进行操作

egrep"^[^egrep"^[^!/bin/sh

将以上内容写入脚本文件中，并放在Tempest目录下。执行该脚本，会在tempestresult目录下分别输出和testcase_文件，前者用于存放tempest/api目录下各项目服务的测试用例，后者用于存放每个项目服务的测试用例统计数量。

打开testcase_文件，部分内容如下：

cattestcase_

3.Tempest代码调试

1.安装ipdb库

_servers__reboot_non_existent_server

4.运行Tempest测试

执行Tempest测试，既可以使用testr也可以使用nosetests、ostestr、run_脚本等命令，但社区推荐使用ostestr命令。这里以testr使用为例进行介绍。

这里以测试Keystonev2版本的testlisttenantsreturnsonlyauthorizedtenants测试用例为例。命令如下：

vimtempest/api/identity/v2/test_

该测试用例的主要内容是，检查用户是否只可以看见同租户下的其他用户；验证用户所使用的凭证和租户名；最后检查用户不能登录到名为“alt”用户的租户。主要是调用assertEqual、assertRaises等断言方法来判断程序的执行结果和预期值是否相符。

如下，是一些testr测试的相关命令

1）使用testr,查看命令帮助信息

/py27/bin/activate

直接运行测试

testrrun--parallel

测试结束后，查看失败的用例，并重新运行失败用例

testrfailing

批量运行api、scenario两个测试用例集

testrrun

或者，并行运行测试

/root/tempest/tempest/apitestrrun--parallel

运行单个测试用例

testrrun--parallel--concurrency=2

执行测试分析

testrlist-tests

执行Tempest的场景测试

./run_

只重新运行失败的测试用例

cd/tempest

将和自动化测试程序文件（比如，这里提供的用例程序tempest_）一并存放在Tempest目录下。代码如下：

pythontempest_

执行测试命令后，会在/home目录下生成一份HTML格式的测试报告，使用浏览器打开该文件，如下图所示。

需要说明的是，这里是针对Tempest中的identity项目（Keystone认证服务）v2版本目录下的用例进行测试。如若运行其他项目测试，可参考此方法。

测试报告查看

对于测试结果报告，可以通过邮件和浏览器等多种方式查看。比如，我们可以开发程序，自动将测试报告发送到相关人员的邮件中，或者自动发送到Web服务器中，这样当我们使用浏览器访问某个URL地址，就可方便的看到测试结果。围绕这一内容，还可以将其应用到日常的QA测试、CI/CD等研发测试环节，起到以点带面的效果。

三、人工智能AI对软件测试的影响

自从，阿尔法狗（AlphaGo）在人机大战中，以3:0的绝对优势战胜李世石之后，AI便火得一塌糊涂，仿佛一夜之间不谈AI，便已感觉是来自外星球。那么AI对软件测试的影响如何呢。

软件测试技术发展至今，可以说基于页面对象的模型测试（POM）是一种更接近于人工智能的测试方法。但人工智能AI明显还要更进一步，要求可以实现自动的构造测试场景和测试用例。它要求测试人员首先基于软件功能构造出各种模型（或者叫做行为），然后制定行为和行为之间的关系以及行为和系统整体的关系，之后自动测试系统就可以智能的根据当前的被测系统的状态（场景）以及预设的规则，选择下一步要执行的行为。

理论上这种测试方法可以尽可能的遍历被测试系统中各种可能经历的行为链，从而极大的提高测试覆盖率。由于它每次执行的路径并非固定不变，所以可以构造出完全不同的测试用例，我们也可以称之为智能的软件测试。

基于模型的人工智能测试，首先就是要把各种OpenStack操作定义成模型。这里我们拿虚拟机的各种操作举例。通常，虚拟机具有多种状态，如运行、暂停、重启、迁移、快照等等，此时，我们可以在状态和状态之间定义一些标准的操作。当把这些状态和操作画出来后，我们就可以得到虚拟机的状态迁移图（或者说是虚拟机场景）。如下图所示。

可以看到，上图中Running和Stopped的状态之间可以通过stop和start操作做成状态环。那么智能测试就可以根据预先设定的规则，让虚拟机在这个环里做有限的测试。这一个看起来好像很简单，但是要知道OpenStack里面还有很多其他资源的状态迁移图，而且很多资源之间是有相互依赖关系的，例如在其他服务正常运行可用的前提下，虚拟机各种操作才会顺利执行。而且用户在操作OpenStack的时候，也不会只做虚拟机状态的改变，通常还会和其他资源的行为混合操作。所以，当把所有资源的迁移图画完，就会发现整个OpenStack的场景和可选的行为之间的关系是非常复杂的。

最后，关于Tempest还有很多故事点和内容可以进行研究，如测试用例和配置文件之间的关系、如何按照自身需求扩展Tempest测试用例等。本次分享内容整理自《OpenStack最佳实践—测试与CI/CD》一书5.5.1小节，现已发售。

提问环节

比如说创一个虚拟机，有bug，也就是hostos上可能留有脏数据，DB中也可能，这些东西怎么清理？或者说如何保证环境是干净的。尤其是hostos上的干净？

就拿Tempest来说吧，当它创建一个VM后，如果没有异常或错误（也有可能是程序bug）发生，tempest会自动删除掉vm及其相关的资源

请问现在你们开发是用什么工具？调试又是如何做的？刚才只看到测试部分，谢谢！

每个开发人员使用的工具不同，比如说我吧，看代码一般会用eclipse+pydev，调试一般用ipdb等等。

请问你们修改的代码都会提交到社区吗？如果有部分提交不了社区，请问你们是怎么维护的？再下次OpenStack版本发布是怎么合并的？谢谢！版本怎么做的控制？

针对软件项目，我们一般使用持续集成Jenkins来统一管理，对于DB数据字段更新多的业务，可能还需要其他来完善。

安全性测试如何做的呢？

对于安全性测试，每个人或者每个团队对它的侧重点不一样，比如会有常见的SQL注入、渗透、前端页面的漏洞扫描

很想知道针对openstack存储性能方面有什么比较好的测试方法吗？

针对openstack存储性能方面的测试，可以参见《OpenStack最佳实践-测试与CI/CD》第5.6小节，比如在openstack+ceph集成的情况下，从下往上，有服务器本身的，也有Ceph集群、RBD块存储、虚拟机等

测试各个组件的用例应该是涵盖了各个组件的大部分功能吧？这些功能是必须在组件的配置文件中先全部配置的吧？

tempest支持主流项目的API功能测试，需要事先在文件中配置，目前来说，比较琐碎。

请问你们修改的代码都会提交到社区吗？如果有部分提交不了社区，请问你们是怎么维护的？再下次OpenStack版本发布是怎么合并的？谢谢！版本怎么做的控制？

如果，我们有fix的bug，由于各方面原因，无法进入到社区，但是在我们的产品中经验证通过，我们会打进产品中，对于版本的控制，内部使用gitlab

测试报告是否可以基于测试数据做智能分析和给出优化建议?

一个良好的测试报告，应该基于测试数据做出智能的分析和给出优化建议，测试的目的在于发现缺陷，并进行管控

我有200台不同厂家，不同型号的老旧pc服务器，如果用os来搞成一个大的集群，供测试或业务使用，是否可行？谈谈大体方案？

我有200台不同厂家，不同型号的老旧pc服务器，用于搭建OpenStack测试环境应该够了（没有特殊要求），但不太建议上生产系统。开发、测试、使用不用的OS环境即可，具体看自身对资源环境的隔离要求

OpenStack对硬件的最低配置要求？

OpenStack对硬件的最低配置要求，可以说下，我在大二时，在自己笔记本上的虚拟机（2Core、4GB内存）上搭建了一个all-in-one的OpenStack，也能部署成功，但基本没法用

对于生产环境上的云容灾，这是一个老生常谈的话题，不同的需求，可能有不同具体实现方案。比如ceph存储的，就会有多MON、多OSD。OpenStack服务的ＨＡ，可能有Haproxy、keepalived等。但我个人觉得，有效及时的监控和运维、预警，可能更为重要。

徐超的新书已经出版