This is an archive of the ONOS 1.4 wiki. For the current ONOS wiki, look here.

Test Plan - Functional

Last Update: 

Test Suite Description:

The main goal of the functionality test is to verify if the ONOS package is working correctly. Functionality test focuses on testing the intent framework which allows us to build different scenarios in the network topology that ONOS should be able to handle. A test run covers from network discovery to rerouting flows by changing the network topology during the test. We verify the results by analyzing ONOS state before and after each scenarios as well as confirming hosts reachability.

Test Topology:

Intent Functionality Test Suite


 This test ensures the functionality of intent framework application. The script focuses on the northbound with high level verification included in the CLI application.

Test Overview 

 This test uses a topology shown in the figure below emulated via Mininet. The topology has 7 switches, each end switch consist of multiple hosts that has different configuration. The remaining core switches are used to test rerouting by bringing links up and down. The test combines single and multi node testing using OF 1.0 and 1.3 OVS. Test configuration will vary in the values inside params file.

Test Strategy

The test heavily depends on connectivity of the devices under test. High level verification such as verifying states are done multiple times before and after events. Connectivity and state verification determines the passing criteria of each test case.

Test assumption

  • A test bench that has onos package deployed

  • Requires at least a single node cluster

  • Mininet topology included in the test dependency folder should run without errors

  • Stable ONOS build ( v1.3 and up )

  • VLAN module installed

NOTE: Please read READme file in the test folder for more information about dependencies

Test SuiteTest CasesPassing CriteriaRoad Map
Intent Functionality (FUNCintent)Host intent
  • Intents can be installed between network nodes
  • Connectivity between hosts when intents are installed
  • Intent state is in INSTALLED state for each active instances
  • All devices that are being used are in ACTIVE state
  • Each active device is assigned to one master controller
  • Network topology from Mininet is equivalent to ONOS view for each active instances
  • Flows should be in its appropriate state before and after an event such as intent installation, rerouting flows etc.
  • System state is consistent to all active ONOS instance
  • Connectivity is preserved in rerouting flows when particular links are down
  • Every match action given when adding intents should correctly stored in each of intents status
  • Network nodes ( switch and host ) information are consistent such as MAC, IPs, IDs, Ports.
  • All steps and verification should pass with different types of host: Dual stack, IPV4, VLAN etc.
  • Completely remove or purge all intents that have been installed
 Point intentNow
 Multi-to-single point intentNow
 Single-to-multi point intentNow

Test Principle

  • Test will only use all the functionality related to intents and other sub system in the CLI application

  • There will be repetitive verification before and after an event

  • Use of dependency python files to extend the test script functions for code reusability

  • The test can be extended for more low-level verification

  • Testing disregards performance of any application or subsystem used and focused entirely on the functionality of the system

  • Passing criteria of each cases should always include device connectivity
  • No labels

1 Comment

  1. Good enough to study and work