Have questions? Stuck? Please check our FAQ for some common questions and answers.

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 20 Next »

System Test Setup Overview

Created by: Last Modified by: Last Update: 

Components in this Setup:

  • Jenkins CI system (Optional - if you need to have automated build job set up; else, all the test cases can be driven from TestStation.);
  • Wiki (Atlassian Confluence), or other publishing services (Optional - if you don't need to publish test results);
  • Gerrit Repo - gerrit.onosproject.org; this is the git repository for both onos and OnosSystemTest;
  • TestStation - runs "OnosSystemTest/TestON"; optionally onos Bench and Mininet. Required: "OC" environment variables are configure in the host to run test scripts.
  • ONOS cells - each cell is a node running ONOS - the number of cells needed depending on your test cases;
  • SDN network - this is either a Mininet-emulated network, or physical network.

Example Test Setup Procedure:

This procedure assume TestStation is running OnosSystemTest, onos bench, and Mininet; Host[1~7] are running onos cell OC[1-7].

  1. Setting up on TestStation ONOS test bench according to the "getting started" guide in "ONOS for Newcomers";
  2. Install Mininet on TestStation - http://mininet.org/download/
  3. Clone "OnosSystemtest" to TestStation:  "git clone https://gerrit.onosproject.org/OnosSystemTest";
  4. Configure environment variables on the TestStation with OC[1-7], OCN, OCI to assigned the correct IPs per your environment; Important: these env variables are used by TestON in the init step to create (ssh) handles to all the component systems; they have to be set according to the specific test suites in order for the test to run.
  5. Run the sample case from OnosSystemTest/TestON/bin: "./cli.py run SAMPstartTemplate" (This case requires to have 3 onos cells).


TestON Scripting General Guidelines:

 Due to the many components required for system tests, it is possible that one tester's environment can be drastically different from another's.  In ONLAB, we have a production test environment to run the current published test suites. In time, we expect the community to contribute to improving the test suites, or creating new test suites that will also be run on this env. We set up a set of test development guideline to achieve the following objectives:

  1. Portability:

    • testers should be able to clone the tests; set up system environment variables accordingly; and run the tests without test script modifications;

    • contributors should be able to commit changes and new test suites to be run on ONLAB production testbed.

  2. Stability:

    • robust - i.e. minimize script-causing test failures;

    • In depth onos application state verification.

  3. Clarity:

    • tests should produce useful onos failure information for further debug;

    • reports should provide a glance of onos health from each suite

    • Standardize driver & tests documentation.

       

  • No labels