一．OpenStack持续测试概述
众所周知，OpenStack作为一个特大型软件开发项目，有着数千人的开发人员，每天要处理千计提交的代码，几千条Gerrit评论和投票，催生出数万个测试环境，还有数百次源代码的合并，十几个顶级项目，大量的文档，跨大洲大洋的协同开发。
因此，为了确保这些工作的实现，OpenStack构建了一套完善的CI（持续集成）-CT（持续测试）-CD（持续交付）基础设施平台和流程体系。如下图所示
图来自docs：http://docs.openstack.org/infra/manual/developers.html
CI方法已经在 OpenStack 项目中得到了大规模的实现，统一来管理所有不同的子项目的CI过程。
为了实现这些，OpenStack项目使用了下面这些组件：
- Gerrit：代码审查和git资源库管理器。
- Zuul、Git：代码库控制系统。
- Jenkins：持续集成服务器。
- Nodepool：部署在OpenStack云上的智能的Jenkins衍生工具。
- Github：用于存放Gerrit上被Merge的代码
- 其他
持续测试（CT）作为软件持续集成（CI）中的重要组成部分，为软件项目的成功提供了保证软件质量持续改进的重要手段。OpenStack当然也不列外，其持续测试系统如下所示：
- Selenium：用于自动化测试Dashboard UI
- Tempest：用于自动化测试OpenStack API
- Rally：用于自动化测试OpenStack性能
- Unit Tests：用于每个项目的单元测试
- 其他
备注：
这里我们关注的是OpenStack 项目中的Neutron CT部分。因此，这与理解其他项目是一致的。
二．Neutron中的持续测试
图来自wiki：https://wiki.openstack.org/wiki/Network/Testing
1.Mock & Mox单元测试
SmallTestingGuide：
http://wiki.openstack.org/SmallTestingGuide
Unit Tests：
http://docs.openstack.org/developer/neutron/devref/development.environment.html#testing-neutron
openstack单元测试组件一览：
http://blog.csdn.net/halcyonbaby/article/details/30344441
从总结性角度而言，单元测试追求的是速度、隔离以及可移植性。对于速度，需要测试代码不和数据库、文件系统交互，也不能和网络进行通信。另外，单元测试的粒度要足够小，确保一旦测试失败，能够很容易迅速的找到问题的根源；可移植性是指测试代码不依赖于特定的硬件资源，能够让任何开发者去运行。
OpenStack中单元测试的代码位于每个项目源码树的Project_name/tests/目录下，使用了oslo.test公共测试库提供的基础框架。通常单元测试的代码需要专注在对核心实现逻辑的测试上，如果需要测试的代码引入了其他的依赖，比如依赖于某个特定的环境，我们在编写单元测试代码的过程中，花费时间最多的可能就是如何处理这些依赖，否则，即便测试失败，也很难定位出问题所在。
在单元测试中，引入了一种Test Double（理解为模拟某个事物）的理念来替代测试中的每一个依赖。有多种类型的Test Double，比如Mock对象、Fake对象等。Mock和Fake都是Python中用于实现单元测试的模块库实现隔离，比如将相应的操作进行隔离，通过替换测试内容中的Class、Function等对象。专注在Function的核心实现逻辑的测试上，比如把DB操作、I/O、网络相关操所如socket、ssh等隔离掉。
在测试运行过程中，当执行到这些操作时，并不会深入到方法的内部去执行，而是直接返回我们事先假设的一些值。
如下，在neutron/tests/functional/services/l3_router/test_l3_dvr_router_plugin.py测试模块中。便事先设置好了我们假设的subnet_cidr、ext_net值。
Shell| 123456789101112131415161718 | def _test_remove_router_interface_leaves_snat_intact(self, by_subnet): with self.subnet() as subnet1, self.subnet(cidr='20.0.0.0/24') as subnet2: kwargs = {'arg_list': (external_net.EXTERNAL,), external_net.EXTERNAL: True} with self.network(**kwargs) as ext_net, self.subnet(network=ext_net, cidr='30.0.0.0/24'): router = self._create_router() self.l3_plugin.add_router_interface( self.context, router['id'], {'subnet_id': subnet1['subnet']['id']}) self.l3_plugin.add_router_interface( self.context, router['id'], {'subnet_id': subnet2['subnet']['id']}) self.l3_plugin._update_router_gw_info( self.context, router['id'], {'network_id': ext_net['network']['id']}) |
Mock、Mox 都是OpenStack中常见的实现隔离很好的单元测试模块，理解它们能够更快的做UT的编码。这种测试通常直接导入特定的代码功能，并运行它们以确保它们的返回值是有效的，比如通过调用期望函数等。Neutron项目的测试类别，如下图所示：
1）通过Mock带隔离的测试，包括单元测试，还有针对API和example的功能测试（在Mock环境中针对一个个具体的API和example做测试）。Neutron中的单元测试路径为neutron/tests/unit。
2）不带隔离的真实环境测试，比如功能测试（尽量在真实环境中辅以少量的mock串起来测试，neutron中的代码位于：$neutron/tests/functional, 运行时添加OS_SUDO_TESTING=True）和集成测试（在真实环境中将多个API串起来测试，即tempest项目)。
Mock单元测试，也就是经常说的最小测试，它强调隔离，也就是说我们只将精力集中在我们要测试的方法内，如果该方法调用了其他方法，都可以通过Mock方式来模拟返回一些假设的值。
代码隔离有如下几种方法：
1）一种是依赖注入，如下例子，想要测试FamilyTree类的话，应集中精力测试FamilyTree本身是否有错，至于它所依赖的Person_Gateway可以做一个假的FakePersonGateway注入进去。
| 1234567 | class FamilyTree(object): def __init__(self, person_gateway): self._person_gateway = person_gateway person_gateway = FakePersonGateway() # ... tree = FamilyTree(person_gateway) |
2）另外一种是利用Python的Monkey Patching的特性，在运行时可以动态替换命名空间，用FakePersonGateway替换掉命名空间mylibrary.dataaccess.PersonGateway。
Shell| 1234567 | class FamilyTree(object): def __init__(self): self._person_gateway = mylibrary.dataaccess.PersonGateway() mylibrary.dataaccess.PersonGateway = FakePersonGateway # ... tree = FamilyTree() |
3）另外一种方式是使用Mox模块来实现单元测试。Mox模块是python实现单元测试的一个框架，如下面的列子所示，如果测试方法中调用了get_instance_type_by_name方法，则可以使用mox模块来模拟这个方法的输出。
Shell| 1 | inst_type = instance_types. get_instance_type_by_name(flavor_name, context) |
现在可以使用Mox模块将其替换，返回不同的值：
Shell| 1234567 | self.mox.StubOutWithMock(flavor_dynamic.instance_types, 'get_instance_type_by_name')flavor_dynamic.instance_types.get_instance_type_by_name( mox.IgnoreArg(), mox.IgnoreArg()).AndReturn(None) flavor_dynamic.instance_types.get_instance_type_by_name( mox.IgnoreArg(), mox.IgnoreArg()).AndReturn("{'a'='1'")self.mox.ReplayAll()self.mox.VerifyAll() |
我们除了可以对一个个方法使用Mox实现Mock对象；还可以使用Mock模块来实现，对一个类的所有方法进行模拟。
Shell| 123 | self.utils_exec_p = mock.patch('neutron.agent.linux.utils.execute')self.utils_exec = self.utils_exec_p.start()self.addCleanup(self.utils_exec_p.stop) |
列如，在测试方法中用到了self.router_info_inst，我们可以将它用Mock替换。
Shell| 1 | self.router_info_inst = mock.Mock() |
4）Fake对象，即创建大量的假对象。
所以在考虑单元测试代码时，可以考虑以下两点作为标准：
1）是否使用了VerifyAll()，这意味着是否所有隔离方法的返回值都被单元测试所覆盖；
2）测试覆盖率，可通过工具查看，这意味着是否覆盖了每个方法的语句分支（条件分支覆盖测试）；
备注：
1)-4)部分，整理自《深入浅出Neutron OpenStack网络技术》10.1。
2.Tempest集成测试
除了上面的单元测试，还有针对和Keystone交互的集成测试，位于neutron/tests/tempest目录，单元测试、功能测试和集成测试的区别在于集成测试采用的是真实环境。
在Neutron项目中，Tempest涉及到的服务还是相对较少的，主要是identity和network。从中可以看出的一个显著趋势是，Neutron中的Tempest更趋向于Keystone V3版本发展，如下图所示：
当开发人员提交了一项代码到Gerrit中后评审的整个流程，如下图所示。
图来自：http://www.joinfu.com/2014/01/understanding-the-openstack-ci-system/
Neutron CI系统会创建一个虚拟机，并使用devstack在虚拟机上部署OpenStack环境，打上提交评审的patch后运行一系列的测试（如单元测试、功能测试、upgrade、PEP8测试等），最后向开发者反馈测试结果。
与之前所述测试不同的是，集成测试采用的是真实环境调用真实的Rest API进行测试，不涉及Mock对象。目前，对于Neutron项目，主要是验证一些基本的网络场景，通过一个Network启动一个实例然后访问这个实例的浮动IP，测试覆盖率非常低。当然，今后将针对这些Core API（Port、Network、Subnet）和Extension API（LB、VPN）做更多的场景和集成测试。比如：
- 跨Router的云主机连通性测试；
- 公共和共享网络的测试；
- 对一个Port设置Security Group的测试；
- 跨Router上移动Floating ip时的连通性测试；
- 其他；
再次强调，功能测试（functional）和集成测试（tempest）是有区别的。前者的测试粒度要比单元测试大一些，单元测试关注于方法层面，功能测试关注于功能层面，仍会涉及到Mock对象等；而集成测试所测试的对象是模块间的接口，其目的是找出模块接口之间（函数接口之间的数据传递是否准确无误或引起异常崩溃等），包括整体系统结构的问题。其测试的依据来自于系统的架构设计。不涉及到Mock对象等。
3.如何执行单元测试
执行单元测试的途径有两种，Tox或者项目源码树根目录下的run_tests.sh脚本。
Tox是一个标准的Python虚拟环境管理器和命令行测试工具。可以用于检查软件包能否在不同的Python版本或解释器下正常安装；在不同的环境中运行测试代码；作为持续集成的组成部分，减少测试工作所需要的时间。
1）run_tests.sh脚本
run_tests.sh脚本封装了testr测试框架的用法。可以使用bash run_tests.sh –h命令来获取有效帮助，如果仅想对某个模块或功能做测试的话，可以运行相应的测试子集：
| 1 | bash ./run_tests.sh neutron.tests.functional.services |
#对功能测试的services模块做测试
当然，也可以指定对模块中的某个类或方法做测试，如下：
Shell| 1 | bash ./run_tests.sh l3_router.test_l3_dvr_router_plugin:L3DvrTestCase |
#对test_l3_dvr_router_plugin模块中的L3DvrTestCase类做测试
Shell| 1 | bash ./run_tests.sh test_l3_dvr_router_plugin:L3DvrTestCase.test_get_router_ids |
#对L3DvrTestCase类中的test_get_router_ids方法做测试
默认情况下，执行测试之后，会在控制台输出大量的测试信息，非常不方便查看结果。这时，我们在执行测试的时候添加一个--nologcapture参数就行。比如，这里我们可以打印print或log日志，加上后面2个参数：
Shell| 1 | bash ./run_tests.sh test_l3_dvr_router_plugin:L3DvrTestCase --nocapture --nologcapture |
可以把test内容输出到指定文件：
Shell| 1 | bash ./run_tests.sh test_l3_dvr_router_plugin:L3DvrTestCase --nocapture > test.log 2>&1 |
备注：请尽可能在虚拟的环境中运行脚本。
2）Tox工具
官网资料：
http://tox.readthedocs.org/en/latest/
Openstac工程的持续集成实践1—tox：
http://blog.csdn.net/agileclipse/article/details/19044667
Tox是OpenStack持续集成中非常重要的一个通用的虚拟环境管理和测试命令行工具，每个项目源码树的根目录下都有一个Tox配置文件tox.ini，比如Neutron项目的tox.ini部分。
Shell| 123456789101112131415161718 | [tox]envlist = docs,py34,py27,pep8 #测试的Python版本或环境 minversion = 2.0skipsdist = True [testenv]setenv = VIRTUAL_ENV={envdir}passenv = TRACE_FAILONLYusedevelop = Trueinstall_command = constraints: {[testenv:common-constraints]install_command} pip install -U {opts} {packages}deps = -r{toxinidir}/requirements.txt #要安装的依赖关系 -r{toxinidir}/test-requirements.txtwhitelist_externals = shcommands = #测试时要执行的命令 dsvm-functional: {toxinidir}/tools/deploy_rootwrap.sh {toxinidir} {envdir}/etc {envdir}/bin ostestr --regex '{posargs}' |
如下，我们执行下面的两个tox命令。
Shell| 12 | # tox –e pep8# tox –e py27 |
第一次执行时，会自动安装一些依赖的软件包，如果自动安装失败，我们可以根据提示信息手动执行安装。如果我们只希望执行特定的单元测试代码，不喜欢浪费时间去等待所有单元测试的执行，可以加参数指定，比如为了执行neutron/tests/api/admin/ test_routers_dvr.py文件：
Shell| 1 | # tox –e py27 -- test_routers_dvr.py |
小结
通过以上的分析和理解，我们能够懂得OpenStack的整个持续测试流程和单元测试运行机制，以及每个项目中（这里以Neutron为例）的Mock & Mox单元测试、Tempest集成测试、功能测试，和如何更有效的执行Unit Tests。至于如何为OpenStack中的项目编写单元测试，可按需参考其他资料，比如这篇资料Neutron集成ONOS源码分析中的networking_onos/tests部分。
作者简介：
徐超：任职于九州云信息科技有限公司（上海），从事OpenStack相关工作。个人倾向于研究CI-CT-CD-CD。
推荐资料
Neutron/TempestAPITests
https://wiki.openstack.org/wiki/Neutron/TempestAPITests
Neutron/InTreeTests
https://wiki.openstack.org/wiki/Neutron/InTreeTests
NeutronThirdPartyTesting
http://git.openstack.org/cgit/openstack/neutron/tree/doc/source/policies/thirdparty-ci.rst
Network/Testing
https://wiki.openstack.org/wiki/Network/Testing
OpenStack Project Infrastructure
http://docs.openstack.org/infra/system-config/
OpenStack Developer and Community Infrastructure Documentation
http://docs.openstack.org/infra/
OpenStack git repository browser
https://git.openstack.org/cgit/openstack-infra