Tempest的确很好地指引了我们这种亲密接触OpenStack的吃瓜群众，不光是因为完整提供了一套测试框架，还有就是Test Case的设计方式

    @attr(type=['negative', 'gate'])
    def test_resize_server_using_overlimit_ram(self):
        flavor_name = data_utils.r[......]
Read more

首先是瞄到了一个用例

    @test.attr(type=['negative', 'gate'])
    def test_show_host_detail_with_non_admin_user(self):
        hostname = self._get_host_name()

        self.assertRaises(exceptions.Unauthoriz[......]
Read more

目前主要还是基于H版的OpenStack，因此Tempest也是H版，对比了下最新社区Tempest，已经有很多实现的改进，连最基础的create_server的方法也优化了，特别是传入的networks，还会先通过方法tenant_network来获取，而目前使用的H版的Tempest默认依旧无网卡创建，除了重写方法外，如果不做任何修改，很多用例都没办法直接通过，加上在用的OpenStack也做[……]

Read more

刚刚开始看openstack或者tempest的人，会发现都是装饰器，所以要抱着激情的态度来迎合它，而不是抵触，相信多看个几次就会慢慢习惯了

还是先看前面老是提起的flavor这个case

@attr(type='smoke')
def test_list_flavors(self):
    # List of all flavors should contain the expected flav[......]
Read more

Tempest里进行接口测试，有API HTTP的，也有Command Line的，这里简单看下API层面HTTP RESTful的调用流程

这里随便看一个tempest里的test case，比如还是test_flavors.py里

@attr(type='smoke')
def test_list_flavors(self):
    # List of all flavors should co[......]
Read more

昨天在测试一个简单nova接口的时候，只要是有继承base.py里的BaseComputeTest类，create_test_server函数这个case就会被默认执行，而假如测试的OpenStack环境不支持不带网卡创建虚拟机，就会报错，还是这个函数

@classmethod
def create_test_server(cls, **kwargs):
    """Wrapper utility[......]
Read more

对于OpenStack里API接口的测试，由于按需一直在变，云网络接口相对较少，一直放在持续集成测试中，而云主机部分接口实在太多，涉及到的模块也多，而主机部分大多生命周期操作以及验证都还涉及到多个物理节点，因此目前仅仅在一整个OpenStack环境通过整体功能回归验证其正确性，而对于接口层验证目前还是比较老，供提交代码之后来触发的接口测试，而对于新增功能接口，都没有实时添加进去，更甚之由于更新频率[……]

Read more