Shulou(Shulou.com)06/02 Report--

Introduction to Tempest

Tempest is an open source project designed to provide integrated functional testing for OpenStack, including test cases for the basic components of OpenStack (nova,keystone,glance,neutron,cinder, etc.), as well as json,xml rest api format testing and cli testing. It is based on unittest2 and nose testing framework, flexible and easy to expand and maintain, which greatly improves the efficiency of OpenStack-related testing.

A list of functional changes in Rocky version

The latest version of Tempest is v19.0.0, which supports testing of Rocky,Queens,Pike and Ocata versions of OpenStack. In the newly released OpenStack Rocky version, its features are changed as follows:

Added v3-ext/os-endpoint-policy api to support testing associated with service endpoint and access permissions. Enable_service,disable_sevice,disable_log_reason,freeze_host and thaw_host api endpoint are added to V3 services_client. Tempest.lib.decorators.related_bug and tempest.lib.decorators. The parameter bug_type is added in skip_because to track the test bug. Add update flavor api. Added application credentials interface test for keystone. Projects_tags_client api is added to the Identity v3 library to test the project's tag functions, such as update_project_tag,list_project_tags,update_all_project_tag,check_project_tag_existence,delete_project_tag,delete_all_project_tags. Add update_service api to Compute library and change / os-services/disable,/os-services/disable-log-reason,/os-services/enable, / os-services/force-down to disable_sevice,disable_log_reason,enable_service,update_force_down. A new vnc_server_header configuration item has been added to Config, and the name of the vnc service can be displayed in the response header. Volume v3 api has been added to V3 api, and the default api for volume testing has been changed from V2 to V3. The Cinder command line option-- endpoint-type is changed to-- os-endpoint-type. The Config file configuration item allow_tenant_isolation is changed to use_dynamic_credentials. Tempest code structure

The Tempest project will be updated by community members from different companies: modify bug, improve functionality, add test cases for the latest features of OpenStack, and so on. Its approximate directory structure is as follows:

├── tempest

Test suite for ├── api # api.

├── compute # os nova related tests

├── identity # os keystone related tests

├── network # osnetwork related tests

├── image. # os glance related testing

├── volume # os cinder related tests

├── object_storage # os swift related tests

├── cmd # openstack command line tool test set.

├── common # some common utility classes and functions.

├── scenario # tests common openstack scenarios, including basic vm startup, etc.

Openstack api client implemented by ├── services # tempest itself.

Its code structure is shown in the figure:

Tempest testing process

Before preparing the Tempest test environment, you need to prepare the OpenStack (OS) environment to be tested.

Installation

Git clone git://git.openstack.org/openstack/tempest

Cd tempest

Pip install-r requirements.txt-c test-requirements

Python tempest/setup.py install

Initialization

Determine the test environment directory (/ opt) and execute it under / opt

Tempest init tempest-test

The tempest-test test folder is generated with the following structure:

├── etc

│ ├── tempest.conf

│ └── tempest.conf.sample

├── logs

└── tempest_lock

Modify the configuration file tempest-test/etc/tempest.conf

Tempest.conf is mainly divided into the following session, which match the OS environment you are testing.

[auth]: login information of admin users in os environment.

[identity]: mainly includes permission verification tests related to user/tenant.

[compute]: it mainly includes os compute api/cli related tests.

[image]: it mainly includes os image api/cli related tests.

[network]: it mainly includes os network api/cli related tests.

[volume]: mainly includes os cinder storage.

Perform a test

Tempest will find all the python source files under the directory that start with (T) test, and recursively look for subdirectories according to this rule. All function (test cases) that begin with (T) test in the python source files will be executed; it can specify files, modules, functions to test, or you can specify the type to test.

Perform all tests

Tempest run

Concurrent testing

Tempest run-parallel

Execute a function test case

Tempest run tempest.api.compute.servers.test_servers_negative.ServersNegativeTestJSON.test_reboot_non_existent_server

Execute a file test case

Tempest run tempest.api.compute.servers.test_servers_negative

Test result

There are four kinds of Tempest test results: test error (error), test failure (failure), skip (skip), and success (success).

Test error: it can be understood that there is something wrong with the test code or the configuration environment, which is wrong in the execution Times.

-- Test failure: it is understandable that the test code executed normally, but did not get the expected test results.

Skip: it can also be understood as test neglect, for example, a test only wants to run under window, so it will be skipped in linux, that is, ignored.

Success: the test code executes normally and the expected test results are obtained.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.