User Tools

Site Tools


Project: OPNFV - Base system functionality testing (Functest)

  • Project Name: Functest
  • Project Repository: functest
  • Project Category: Integration & Testing
  • Project IRC chan: #opnfv-testperf

Project description

Project “OPNFV – Base system functionality testing” will provide comprehensive testing methodology, test suites and test cases to test and verify OPNFV Platform functionality that covers the VIM and NFVI components.

This project uses a "top-down" approach that will start with chosen ETSI NFV use-case/s and open source VNFs for the functional testing. The approach taken will be to

  • break down the use-case into simple operations and functions required.
  • specify necessary network topologies
  • develop necessary test traffic
    • Ideally VNFs will be Open Source however proprietary VNFs may also be used as needed.

This project will develop test suites that cover detailed functional test cases, test methodologies and platform configurations which will be documented and maintained in a repository for use by other OPNFV testing projects and the community in general. Developing test suites will also help lay the foundation for a test automation framework that in future can be used by the continuation integration (CI) project (Octopus). We envisage that certain VNF deployment use-cases could be automatically tested as an optional step of the CI process.

The project targets testing of the OPNFV platform in a hosted test-bed environment (i.e. using the OPNFV test labs world wide). It will leverage output of the "BGS" project.

The key objectives are:

  • Define tooling for tests
  • Define test suites (SLA)
  • Installation and configuration of the tools
  • Automate test with CI

A dedicated page for all the testing projects (Functest, Yardstick, Pharos, …) is available here.


“OPNFV – Base system functionality testing” will deliver a functional testing framework along with a set of test suites and test cases to test and verify the functionality OPNFV platform. The testing framework (tools, test-cases, etc.) are also intended to be used by the CI framework for the purpose of qualifying the OPNFV platform on bare metal servers. In this context, OPNFV Tester will use open source VNF components. Functional testing includes

  • Testing the basic VIM functionality that includes tenant, user CRUD operations, VNF Image CRUD operations etc.
  • Testing the VIM functionality to support VNF operations (create, modify, grow, shrink, destroy)
  • Testing the VIM functionality to support basic VNF network connectivity
  • Testing the inter working between the VIM and the SDN controller.
  • Testing the NFVI functionality as a black box to ensure that it meets the VIM requirements.

The project requires the following components:

  • OPNFV Lab setup with complete access to a set of Bare metal servers for Controller and Compute nodes (as defined by BGS project (OPNFV stack) and Pharos project (hardware)); associated switches and routers.
  • OPNFV platform software bundle from the repository that includes several upstream software components.
  • OPNFV "Bootstart Get Started!" software bundles that includes the installer


Functional tests shall be

  • independent from the installer (Fuel, Foreman/Puppet, Juju,..)
  • automated and integrated in CI

Functest versus Release


Testcase Availability Comment
vPing Arno basic hello world example.
ODL Arno Using robotframework, 3 pending errors due to ODL bug in Arno.
Tempest Arno Smoke suite considered. Still troubleshooting to be done.
Rally Arno based on default Rally scenario. Still troubleshooting to be done.
vIMS Brahmaputra candidate testcase using Cloudify for VNF management. pre-study
ONOS Brahmaputra candidate using teston tool
SFC Brahmaputra candidate
BGPVPN Brahmaputra candidate
Policy Brahmaputra candidate
vPE ? pre-study
vPE perfo ? pre-study
vEPC ?
vCDN ?

Study on VNF deployment



Short story on Functest versus the other test projects and the installers

First of all we try to be as agnostic as possible.

we see OPNFV as a black box.

We automatically run functest-{installer}-master after a successful fresh installation of {installer} In functest (and in yardstick) we have internal test cases and companion test projects the functest companion projects dealing with functional testing are

  • doctor
  • copper
  • ovno
  • policyTest
  • promise
  • sdnvpn

companion project means that we wil onboard them in Functest CI process. After a fresh install, functest will be started (a docker file) running several tests one after the others (e.g. including companion tests in the near future. each test may need specific env, so functest can install tooling and triggers scripts to setup env we will also create a filtering mechanism to run tests only when possible (assuming that by default it is always possible) but no need to run odl suite towards an OPNFV including onos

In functest we developed the code for our internal tests (scripts, tests, integration of upstream test suites,…)

The companion projects are in charge of their scripts, their code, their scenario… we mutualize the CI env (running on target CI production labs), the tooling (some projects need for instance to run upstream ODL suite, functest install once robot and mininet for all of them, Rally may test module used by feature project (eg; congress/copper)), the reporting, the documentation

Then jenkins functest-{installer} job will produce results that will be pushed in the Test collection DB before Release B we will look carefully to the jobs (success criteria for Functest for B-Release is 4 successfull run on CI of the onboarded projects)

  • if errors in integration or internal cases ⇒ we will blame ourselves
  • if erros in companion projects ⇒ we will report the issues to the member of the feature projects

So you can see that we did not do specific stuff for 1 installer. We have some adaptations of course in our scripts (e.g. to retrieve the credentials - not the same way on the different installers) but we do not create a plugin for a given installers, we have a docker file. Functest (as yardstick) docker file could even be almost used towards any OPNFV-like solution (some adaptations on the env setup)


Dealing with Branches

Best practice ⇒ Cherry Pick from Master to Stable useful patches as described in Stable Branch

If you forgot that (it may happen and we experienced that for SR1) as Master and stable may be considered as the same, you may have to merge Master on Stable…and then winter is coming…so a procedure that works:

 * git clone ssh://<Your_ID_assuming_you_have_the_merge_rights> functest-clean
 * git checkout stable/arno
 * git merge master
 * git push origin HEAD:refs/for/stable/arno.

Key Project Facts

This URL is not allowed for scraping
  • Additional Contributors
    • Frank Brockners (
    • Sajeev Manikkoth (
    • Sean Chen (
    • Rajeev Seth (
    • Kevin Riley (
    • Justin Hart (
    • Ryota Mibu (

Want to Join: know more on Functest

Tester Journey

opnfv_functional_testing.txt · Last modified: 2016/03/01 08:48 by Ryota Mibu