Tempest的确很好地指引了我们这种亲密接触OpenStack的吃瓜群众，不光是因为完整提供了一套测试框架，还有就是Test Case的设计方式
@attr(type=['negative', 'gate'])
def test_resize_server_using_overlimit_ram(self):
flavor_name = data_utils.r[......]
分类：Tempest
Unittest里反向测试以及又一个莫名其妙的Case
首先是瞄到了一个用例
@test.attr(type=['negative', 'gate'])
def test_show_host_detail_with_non_admin_user(self):
hostname = self._get_host_name()
self.assertRaises(exceptions.Unauthoriz[......]
费解的service_available.neutron配置以及传递network参数
目前主要还是基于H版的OpenStack，因此Tempest也是H版，对比了下最新社区Tempest，已经有很多实现的改进，连最基础的create_server的方法也优化了，特别是传入的networks，还会先通过方法tenant_network来获取，而目前使用的H版的Tempest默认依旧无网卡创建，除了重写方法外，如果不做任何修改，很多用例都没办法直接通过，加上在用的OpenStack也做[……]
Tempest测试类型解析：满屏装饰器
刚刚开始看openstack或者tempest的人，会发现都是装饰器，所以要抱着激情的态度来迎合它，而不是抵触，相信多看个几次就会慢慢习惯了
还是先看前面老是提起的flavor这个case
@attr(type='smoke')
def test_list_flavors(self):
# List of all flavors should contain the expected flav[......]
Tempest框架RESTful流程：HTTP接口组装终极无脑版
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[......]
Tempest里create_test_server方法的调用问题
昨天在测试一个简单nova接口的时候，只要是有继承base.py里的BaseComputeTest类，create_test_server函数这个case就会被默认执行，而假如测试的OpenStack环境不支持不带网卡创建虚拟机，就会报错，还是这个函数
@classmethod
def create_test_server(cls, **kwargs):
"""Wrapper utility[......]
测试框架Tempest进阶：第一坑一头雾水
对于OpenStack里API接口的测试，由于按需一直在变，云网络接口相对较少，一直放在持续集成测试中，而云主机部分接口实在太多，涉及到的模块也多，而主机部分大多生命周期操作以及验证都还涉及到多个物理节点，因此目前仅仅在一整个OpenStack环境通过整体功能回归验证其正确性，而对于接口层验证目前还是比较老，供提交代码之后来触发的接口测试，而对于新增功能接口，都没有实时添加进去，更甚之由于更新频率[……]