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
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:
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
The project requires the following components:
Functional tests shall be
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 | ? |
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
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. https://build.opnfv.org/ci/view/functest/job/functest-fuel-master/lastSuccessfulBuild/consoleText) 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)
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>@gerrit.opnfv.org:29418/functest functest-clean * git checkout stable/arno * git merge master * git push origin HEAD:refs/for/stable/arno.
Want to Join: know more on Functest