| A | B | C | D | E | F | G | H | I | J | K | L | M | N | O | P | Q | R | S | T | U | V | W | X | Y | Z | AA | AB | |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
1 | Testcase ID | Jira Ticket | Name | Description | Status | Target Test Date/ Timeline | Purpose | Assigned Engineer | Jenkins Job Name (Physical POD) | Jenkins Job Name (BBSim) | Notes | |||||||||||||||||
2 | ExampleTest | This is meant to be a long description of the test. This may include pre/post conditions or this can be fleshed out in another form. The idea is to first capture a high level list of required test caes. | Declared | End of December | ||||||||||||||||||||||||
3 | FUNCTIONAL (FEATURE) TESTS | |||||||||||||||||||||||||||
4 | VOL-1954 | clean-start-1 | The following helm charts should be able to be installed in the order specified and the system should start up without error or container restarts: onf/onos onf/voltha onf/voltha-adapters-simulated onf/voltha-adapters-open-olt onf/voltha-adapters-open-onu Starting in this case includes all components should have working connections and a device should be able to be created, enabled, EAP authenticate, DHCP address assignment and pass HISA traffic. | Implemented | End of December | stabilization | Kailash/Andy | NOTES: images are built locally and tests. on Jenkins EC2 [kind-voltha] | ||||||||||||||||||||
5 | VOL-2008 | clean-start-2 | The following helm charts should be able to be installed in the order specified and the system should start up without error or container restarts: onf/voltha onf/voltha-adapters-simulated onf/voltha-adapters-open-olt onf/voltha-adapters-open-onu onf/onos Starting in this case includes all components should have working connections and a device should be able to be created, enabled, EAP authenticate, DHCP address assignment and pass HISA traffic. | Declared | End of December | stabilization | Gerald | |||||||||||||||||||||
6 | VOL-2008 | clean-start-3 | The following helm charts should be able to be installed in the order specified and the system should start up without error or container restarts: onf/voltha-adapters-simulated onf/voltha-adapters-open-olt onf/voltha-adapters-open-onu onf/voltha onf/onos Starting in this case includes all components should have working connections and a device should be able to be created, enabled, EAP authenticate, DHCP address assignment and pass HISA traffic. | Declared | End of December | stabilization | ||||||||||||||||||||||
7 | SanityTest in Voltha_PODTests.robot => https://github.com/opencord/voltha-system-tests/blob/master/tests/functional/Voltha_PODTests.robot | VOL-1953 | Sanity test on physical POD | Jenkins job to deploy a physical pod every night and the following verifications are being performed. Sanity test is executed where a device should be able to be created, enabled, EAP authenticate, DHCP address assignment and pass HISA traffic. (Default BandwidthProfile/ Default Tech Profile) | Implemented | End of December | stabilization | Suchitra | https://jenkins.opencord.org/view/VOLTHA-2.X-Tests/job/build_flex-ocp-cord_Default_voltha_master/ https://jenkins.opencord.org/view/VOLTHA-2.X-Tests/job/build_flex-ocp-cord_Default_voltha_master_test/ | POD has one OLT and one ONU. | ||||||||||||||||||
8 | DisableDeleteONUandOLT in Voltha_PODTests.robot | VOL-2354 | Functional Test - Disable and Delete OLT + ONUS | On deployed POD, and device should be create and enabled. After the device is verified enabled the following operations should happen successfully: 1. Disable and verify disabled the ONUs 2. Disable and verify disabled the OLTs 3. Delete the ONUs and OLTs 4. Verify the device list is empty. | Implemented | End of February | stabilization | Hemalatha Thangavelu | ||||||||||||||||||||
9 | DisableDeleteONUandOLT in Voltha_PODTests.robot | VOL-2355 | Functional Test - Disable ONUs and OLTs, but only delete OLTs | On deployed POD, and device should be create and enabled. After the device is verified enabled the following operations should happen successfully: 1. Disable and verify disabled the ONUs 2. Disable and verify disabled the OLTs 3. Delete the OLTs 4. Verify the device list is empty. | Implemented | End of February | stabilization | Hemalatha Thangavelu | ||||||||||||||||||||
10 | DeleteOLT in Voltha_PODTests.robot | Functional Test - Disable and delete OLT | On deployed POD, and device should be create and enabled. After the device is verified enabled the following operations should happen successfully: 1. Disable and verify disabled the OLTs 2. Delete the OLTs 3. Verify the device list is empty. All OLTs and ONUs should be gone | Implemented | End of February | stabilization | Suchitra | |||||||||||||||||||||
11 | Functional Tests - Redfish API Tests | On deployed POD, device should be created and enabled. Redfish should be deployed on the OLT. Redfish importer should be deployed and running. Tests will exercise a variety of Importer functionality, including adding and removing devices from the importer, listing devices, etc. | Implemented | End of February | new-feature | Maddie/Scott | ||||||||||||||||||||||
12 | Functional Tests - VOLTHA FCAPS Tests (non redfish based) | On deployed POD, device should be created and enabled. 1. Capture events from voltha.events kafka channel 2. Ensure the captured events include performance metrics within expected bounds. | Implemented | End of April | new-feature | Scott | ||||||||||||||||||||||
13 | Functional tests - ONOS fcaps Tests | Placeholder | ||||||||||||||||||||||||||
14 | Functional tests - In-band tests | Placeholder | ||||||||||||||||||||||||||
15 | Functional tests - ISSU tests | Placeholder | ||||||||||||||||||||||||||
16 | Functional tests - Multiple OLTs (can be coupled with GPON OLT) | Placeholder | ||||||||||||||||||||||||||
17 | AT&T workflow based Tests | |||||||||||||||||||||||||||
18 | test1 in Voltha_PODTests.robot => https://github.com/opencord/voltha-system-tests/blob/master/tests/functional/Voltha_PODTests.robot | VOL-1954 | Functional Tests (1TCONT/4 GEM) - successful end-end test (AT&T Workflow Sanity Test) | On a deployed POD, test by pushing 1TCONT/4GEM ports technology profile into ETCD. Make sure that a device can be created, enabled, authenticated, DHCP address assignment and pass traffic. This test is in effect a sanity test for AT&T's workfllow. This test has a dependency on BAL 3.2 for correct operation. | Implemented | End of December | stabilization | Suchitra | https://jenkins.opencord.org/view/VOLTHA-2.X-Tests/job/build_flex-ocp-cord_1T4GEM_voltha_master/ https://jenkins.opencord.org/view/VOLTHA-2.X-Tests/job/build_flex-ocp-cord_1T4GEM_voltha_master_test/ | Currently tests with one OLT and ONU. Job can be used with default profile as well. Test is completed but testing for DHCP related issues on physical POD | ||||||||||||||||||
19 | EnableDisableONU in Voltha_PODTests.robot | VOL-2049 | Functional Test - Enable/Disable ONU (generic, but done with AT&T's subscriber flows) | Functional pod should be brought up with eapol/dhcp and pings working. Then we should disable the ONU and check that pings are not working, enable ONU and verify that pings work fine again. | Implemented | End of December | stabilization | Suchitra | ||||||||||||||||||||
20 | ATT_EnableDisableONU in Voltha_PODTests.robot | VOL-2284 | Functional Test - Enable/Disable ONU (ATT workflow) | Functional pod should be brought up with eapol/dhcp and pings working. Then we should disable the ONU and check that pings are not working. -- disable ONU and perform volt-remove-subscriber. check that pings fail (this can happen before the previous step too) enable ONU do authentication check Perform volt-add-subscriber-access call again Redo DHCP check verify that pings pass - this test should ideally be done with AT&T 1TCONT/4GEM tech profile | Implemented | End of December | stabilization | Torsten | ||||||||||||||||||||
21 | SubAddDelete in Voltha_PODTests.robot | VOL-2050 | Functional Test - Add/remove Subscriber (generic, but done with AT&T's subscriber flows) | Functional pod should be brought up with eapol/dhcp and pings working. Then we should remove the subscriber and check that pings are not working. Then readd the subscriber, and pings should work again. Repeat 5 times. Removing/readding a particular subscriber should have no effect on any other subscriber. This test has a dependency on BAL 3.2 for correct operation. | Implemented | End of February | stabilization | Suchitra | ||||||||||||||||||||
22 | DeleteOLT in Voltha_PODTests.robot | VOL-2051 | Functional Test - Admin Disable/Delete the OLT (generic, but done with AT&T's workflow) | Functional pod should be brought up with eapol/dhcp and pings working. Then disable/delete the OLT which should cause the OLT to reboot. Then pre-provision the OLT again. OLT should discover the ONUs again, Then redo auth/dhcp and ping and things should work. Disabling/deleting an OLT should have no effect on other OLTs/ONUs - this may require launching multiple BBSims or multiple physical OLTs. | Implemented | End of February | stabilization | Suchitra | ||||||||||||||||||||
23 | VOL-2052 | Functional Test - Bandwdith Profiles -1 (AT&T's workflow) | Different ONUs/subscribers should be activated with different bandwidth profiles. There should always be a Default bandwidth profile. Verify the bandwidth profile is met and not exceeded beyond 5% using iperf. This test should be done with AT&T's subscriber flows and AT&T's 1TCONT/4GEM tech-profile | Implemented | End of April | stabilization | Gayathri | |||||||||||||||||||||
24 | VOL-2053 | Functional Test - Bandwidth Profiles -2 (generic but done with AT&T's subscriber flows) | Changing a bandwidth profile. On a working pod with verified bandwidth performance for a subscriber, delete the subscriber, re-add the subscriber by assigning a different bandiwdth profile (either higher or lower), and verify the new bandwidth in the dataplane. Other subscribers on other ONUs should be unaffected. This test has a dependency on BAL 3.1 for correct operation. | WIP | End of April | stabilization | Hema | |||||||||||||||||||||
25 | VOL-2054 | Functional Test - Technology Profile with pbit verification (AT&T Workflow) | With AT&T's tech profile (1 TCONT and 4 GEMs) - send traffic with differnet pbits and ensure that they get through the PON -- they will be going through differnt GEM ports according to the pbit mapping specified in the tech profile -- try to get per GEM port traffic counts | Implemented | End of April | stabilization | Suraj | |||||||||||||||||||||
26 | Funtional Test -- Changing a Tech Profile | With an assigned tech profile on a working pod, remove tech profile and all ONUs using it, change the techprofile and test the changes. This functionality does not currently exist and this test case is more of a place holder | Declared | End of April | new-feature | |||||||||||||||||||||||
27 | Functional Test - Different Technology Profiles (AT&T workflow) | Ensure that different tech profiles can be configured for subscribers on different PONs - for example 1 pon for residential service and a second pon for business service. Different service-types will have different tech profiles (Ask Michael Gasser for TP for business service) | Declared | End of April | new-feature | |||||||||||||||||||||||
28 | TT workflow based Tests | |||||||||||||||||||||||||||
29 | Functional Test - Triple Play Services with Multi T-Cont for 1 subscriber (Sanity test for Turk Telekom workflow) | An ONU/subscriber should have HSI, VOIP and IPTV (VOD&Multicast) services each with different bandwidth profiles. This should use Turk Telekom's Technology profile definition -- in other words separate TCONTS for separate services and single GEM port per subscriber. Test that traffic sent with different vlans for HSIA, VoIP and VoD reach the NNI port on the OLT with the expected pbits and VLAN ids. Test that one multicast stream reaches the RG. This test is in effect a sanity test for Turk Telekom workflow. | Implemented | End of March | new-feature | Done as part of VOLTHA-2.6 | ||||||||||||||||||||||
30 | Functional Test - Bandwidth Profiles with Multi Tcont, Single Subscriber (Turk Telekom workflow) | An ONU/subscriber should have triple play services that are activated with different bandwidth profiles. Verify the bandwidth profile is met and not exceeded beyond 5% using iperf. This test should also verify multicast bandwidth | Declared | End of May | new-feature | |||||||||||||||||||||||
31 | Functional Test - Bandwdith Profiles, Multi TCont, Multiple Subscribers (Turk Telekom workflow) | Different ONUs/subscribers should be activated with different bandwidth profiles with more than one services. Verify the bandwidth profile is met and not exceeded beyond 5% using iperf. This test should also verify multicast bandiwidth | Declared | End of May | new-feature | |||||||||||||||||||||||
32 | Functional Test - Enable/Disable ONU (generic, but done with TT's triple play services) | Functional pod should be brought up with TT's triple play service flows and pings working. Then we should disable the ONU and check that pings are not working, enable ONU and verify that pings work fine again. Also multicast service should resume | Declared | End of May | new-feature | |||||||||||||||||||||||
33 | Functional Test - Add/remove Subscriber (generic, but done with TT's service flows) | Functional pod should be brought up with TT's triple play service flows and pings working. Then we should remove the subscriber and check that pings are not working. Then readd the subscriber, and pings should work again. Repeat 5 times. Removing/readding a particular subscriber should have no effect on any other subscriber. This test has a dependency on BAL 3.2 for correct operation. Multicast should also work | Declared | End of May | new-feature | |||||||||||||||||||||||
34 | Functional Test - Admin Disable/Delete the OLT (generic, but done with TT's service flows) | Functional pod should be brought up with TT's tripleplay service working. Then disable/delete the OLT which should cause the OLT to reboot. Then pre-provision the OLT again. OLT should discover the ONUs again, Then re-add the TT triple-play service flows and things should work. So should multicast. Disabling/deleting an OLT should have no effect on other OLTs/ONUs - this may require launching multiple BBSims or multiple physical OLTs. | Declared | End of May | new-feature | |||||||||||||||||||||||
35 | Functional Test - Multicast with single multicast group (Turk Telekom workflow) | Single IP TV Group - Group 1 - 225.22.0.2 Three ONUs - ONU1 and ONU2 on PON0 and ONU3 on PON1 All three ONUs subscribe to group1 and are able to receive traffic At ONOS IGMP flow1 is created pointing to the group1. Group1 created in ONOS with three buckets At BAL Two pon ports (PON0 and PON1) have registered to the group1 ONU2 leaves the group1 At ONOS, one bucket should be cleared referencing ONU2 UNI On BAL the group1 should still exist and two PON ports should still be registed to the group1 ONU3 leaves the group At ONOS, one more bucket should be cleared referencing ONU3 UNI On BAL the group1 should still exist but PON1 should be unregistered from the group1 ONU1 leaves the group1 At ONOS the IGMP flow1 should be deleted, followed by group1 delete. On BAL the IGMP flow1 is deleted and group1 will be deleted. | Declared | End of May | new-feature | The below command can be used on the BAL to verify the group information on BAL echo "a/g object=group id=3" | ./example_user_appl | ||||||||||||||||||||||
36 | Functional Test - Multicast with multiple multicast groups (Turk Telekom workflow) - 1 | Three IP TV Groups - Group1 225.22.0.2, Group2 224.8.7.6, Group3 226.94.1.1 ONU1 subscribed to Group1, ONU2 to Group2 and ONU3 to Group3 - traffic is fine. At ONOS IGMP flow1 created pointing to the group1, IGMP flow2 is created pointing to group2 and IGMP flow3 is created pointing to group3. Group1 created in ONOS with one buckets. Group2 is created with one buckets. Group3 is created with one bucket At BAL three groups 1,2 and.3 are created with PON1 is registering to Group1, PON0 registering to Group2 and PON1 to Group3. ONU2 leaves the group2 At ONOS, IGMP flow2 and Group2 should be deleted. On BAL the flow2 and group2 is deleted. ONU3 leaves the group3 At ONOS, flow3 and group3 should be deleted. On BAL the flow3 and group3 should get deleted. ONU1 leaves the group1 At ONOS, flow1and group1 should be deleted. On BAL the flow3 and group3 should get deleted. | Declared | End of May | new-feature | The below command can be used on the BAL to verify the group information on BAL echo "a/g object=group id=3" | ./example_user_appl | ||||||||||||||||||||||
37 | Functional Test - Multicast with multiple multicast groups (Turk Telekom workflow) - 2 | Two IP TV Groups - Group1 225.22.0.2 and Group2 224.8.7.6 ONU1 subscribed to Group1, ONU2 to Group2 and ONU3 to Group2 - traffic is fine. At ONOS IGMP flow1 created pointing to the group1 and IGMP flow2 is created pointing to group2. Group1 created in ONOS with one buckets. Group2 is created with two buckets At BAL Two pon ports have registered to the group2 and one pon port is registed to group1 on the BAL ONU2 leaves the group2 At ONOS, one bucket should be cleared for group2 corresponding to ONU2 UNI port On BAL the group should still exist and but only one PON port should still be registed to the group now ONU3 leaves the group2 At ONOS, group2 should get deleted and also the IGMP flow2 pointing to the group should get deleted On BAL the flow2 and group2 should get deleted. ONU1 leaves the group1 At ONOS the IGMP flow1 should be deleted, followed by group1 delete On BAL the IGMP flow1 is deleted and group1 will be deleted. | Declared | End of May | new-feature | The below command can be used on the BAL to verify the group information on BAL echo "a/g object=group id=3" | ./example_user_appl | ||||||||||||||||||||||
38 | DT workflow based Tests | |||||||||||||||||||||||||||
39 | VOL-2483 | Functional Test - FTTH service -1 (Sanity test for Deutsche Telekom FTTH workflow) | Subscribers should have FTTH service each with different bandwidth profiles. This should use Deutsche Telekom's Technology profile definition -- in other words 1TCONT/8 GEM. Test that traffic sent with same vlan from different RGs reach the NNI port on the OLT with the expected double tagged vlan ids. Test that inner vlans from the RG are not changed. This test is in effect a sanity test for Deutsche Telekom workflow. | Implemented | End of March | new-feature | ||||||||||||||||||||||
40 | VOL-2545 | Functional Test - FTTH service -2 (DT workflow) | In a simple variation of the sanity test for the DT workflow, the RGs should send different VLANs. Rest of the parameters are the same as the sanity test. Test that vlans received at the NNI port of the OLT are the expected values, especially the inner vlans which should be preserved and match the different values sent by the difffernt RGs | Declared | End of March | new-feature | ||||||||||||||||||||||
41 | VOL-2548 | Functional Test - Bandwidth Profiles (DT workflow) | Different ONUs/subscribers should be activated with different bandwidth profiles for FTTH service. Verify the bandwidth profile is met and not exceeded beyond 5% using iperf. | Declared | End of April | new-feature | ||||||||||||||||||||||
42 | VOL-2549 | Functional Test - Bandwidth Profiles -2 (generic but done with DT's subscriber flows) | Changing a bandwidth profile. On a working pod with verified bandwidth performance for a subscriber, delete the subscriber, re-add the subscriber by assigning a different bandiwdth profile (either higher or lower), and verify the new bandwidth in the dataplane. Other subscribers on other ONUs should be unaffected. This test has a dependency on BAL 3.1 for correct operation. | Declared | End of April | new-feature | ||||||||||||||||||||||
43 | VOL-2546 | Functional Test - Enable/Disable ONU (generic, but done with DT's subscriber flows) | Functional pod should be brought up with DT's FTTH service flows and pings working. Then we should disable the ONU and check that pings are not working, enable ONU and verify that pings work fine again. | Implemented | End of March | new-feature | ||||||||||||||||||||||
44 | VOL-2547 | Functional Test - Add/remove Subscriber (generic, but done with DT's subscriber flows) | Functional pod should be brought up with DT's FTTH service flows and pings working. Then we should remove the subscriber and check that pings are not working. Then readd the subscriber, and pings should work again. Repeat 5 times. Removing/readding a particular subscriber should have no effect on any other subscriber. This test has a dependency on BAL 3.2 for correct operation. | Implemented | End of April | new-feature | This is actually a non-test because with the DT workflow the removal of a subscriber is always deletion of the ONT from vOLTHA -- move to low priority ecause if flows don't get deleted then onu gets deleted so don't really care | |||||||||||||||||||||
45 | VOL-2550 | Functional Test - Admin Disable/Delete the OLT (generic, but done with DT's workflow) | Functional pod should be brought up with DT's FTTH service working. Then disable/delete the OLT which should cause the OLT to reboot. Then pre-provision the OLT again. OLT should discover the ONUs again, Then re-add the DT FTTH service flows and things should work. Disabling/deleting an OLT should have no effect on other OLTs/ONUs - this may require launching multiple BBSims or multiple physical OLTs. | Implemented | End of May | new-feature | This needs a re-visit by DT A4 vOLTHA team | |||||||||||||||||||||
46 | VOL-2551 | Functional Test - Technology Profile with pbit verification (DT Workflow) | With DT's tech profile (1 TCONT and 8 GEMs) - send traffic with differnet pbits and ensure that they get through the PON -- they will be going through differnt GEM ports according to the pbit mapping specified in the tech profile -- try to get per GEM port traffic counts | Declared | End of May | new-feature | ||||||||||||||||||||||
47 | Functional Tests - DT FTTB workflow | Placeholder | ||||||||||||||||||||||||||
48 | VOL-2557 | Disable/Enable OLT PON port (low priority) | Disable OLT PON Send dhclinet -> no IP received Enable OLT PON Send dhclinet -> IP received using dhclient instead of EAP because that is a common step in all workflows (DT, ATT, TT) | Declared | End of May | new-feature | ||||||||||||||||||||||
49 | DisableEnableOLT | VOL-2410 | Disable/Enable tests on OLT (not done for DT workflow but has not specific DT elements in it) | After a POD has been brought up with a successful EAPOL/DHCP and pings working on the ONUs. Automation of the following functional scenario Disable the OLT and verify it is disabled properly. Check the ONU status also changed accordingly. Verify that pings fail Enable the OLT back and check ONU, OLT status are back to "ACTIVE" Verify that pings work fine again. | Implemented | stabilization | Hemalatha Thangavelu | |||||||||||||||||||||
50 | SubsRemoveDHCP in Voltha_PODTests.robot | VOL-2182 | Functional Tests - Authentication failure scenarios | Test with the specified configuration on the POD. Validate sure that when EAP fails correspondingly DHCP fails. Retry authentication to succeed and validate that DHCP succeeds and corresponding end-end traffic flow is successful. | Implemented | End of December | stabilization | Suraj Gour | Merged | |||||||||||||||||||
51 | DisableONU_AuthCheck in Voltha_PODTests.robot | VOL-2506 | Check EAP authentication failure when ONU is in disabled state | Disable ONU Send EAP auth request, it must fail Enable ONU Send EAP auth request, it must pass | Declared | End of February | stabilization | Suraj | ||||||||||||||||||||
52 | ||||||||||||||||||||||||||||
53 | Ideally each of the following tests should be attempted with all 3 workflows | FUNCTIONAL (FAILURE/RESTART) TESTS | ||||||||||||||||||||||||||
54 | RadiusRestart in Voltha_FailureScenarios.robot | VOL-2023 | Functional Test -- Restart Radius server and check for the authentication | Functional POD should be brought up with the EAPOL/DHCP and pings working. Then Restart the Radius server, then add new ONU and check for the authentication, It should be successful. | Implemented | End of December | stabilization | Hemalatha Thangavelu | Merged | |||||||||||||||||||
55 | OpenOLT in Voltha_FailureScenarios.robot | VOL-1958 | reconnect-1 | Once VOLTHA is operational (working) then any container should be able to be killed/scaled to 0/crash and be automatically restarted by k8s. Once container is restarted the system should reconnect and continue to function properly. The "demise" of any single container should not cause (domino) the demise of another container. | Implemented | End of February | stabilization | Gayathri | Merged | |||||||||||||||||||
56 | reconnect-2 | Once VOLTHA is operational (working) then network connectivity between components should be allowed to be disrupted (link down) without causing any container to crash/restart. Upon re-establishment of connectivity (link up) the components should reestblish connectivity and the system should function properly, without the halt/restart of any container. | Declared | End of December | stabilization | How is this tested or simulated? | ||||||||||||||||||||||
57 | rwcore-restart in Voltha_FailureScenarios.robot | VOL-1960 | rw-core-crash | Once VOLTHA is operational (working) if the rw-core crashes then any in-flight requests should return an error and the rw-core will be restarted from kubernetes and must pickup the data from ETCD and the connection to/from other components. | Implemented | End of December | stabilization | David/Suchitra | ||||||||||||||||||||
58 | FailureTest in K8S_SystemTest.robot | VOL-1961 | etcd-crash | Once VOLTHA is operational (working) if etcd crashes (becomes unavailable) the r/w and r/o cores should return error messages to all in-flight and pending requests. The error message should be focused on the operator (not the troubleshooter), but should container an error number that can be used by the troubleshooter to identify the cause is a data store unavailable. i.e. not helpful to tell the operator "data store unavailable" because they just want to add a subscriber. | Implemented | End of December | stabilization | Hung Wei | ||||||||||||||||||||
59 | ONUAdapCrash in Voltha_FailureScenarios.robot | VOL-1959 | onu-adapter-crash | Once VOLTHA is operational (working) and an attached RG is passing data traffic, if the ONU adapter crashes, when a new instance is restarted it should sync up with its expected state and not force connected RGs through a re-auth/re-address scenario. | Implemented | End of December | stabilization | Suraj Gour | In Progress | |||||||||||||||||||
60 | VOL-1956 | Failure scenarios: OLT Reboot | On a deployed physical POD where the subscriber is authenticated, DHCP address assigned and pings are successful. Reboot the OLT and validate that the OLT comes back into ACTIVE state, ONU comes back into active and right `state`. Validate by re-authenticating the RG, DHCP and pings successfully. | Implemented | End of April | stabilization | Suchitra | |||||||||||||||||||||
61 | RebootONU in Voltha_FailureScenarios.robot | VOL-1957 | Failure scenarios: ONU Reboot | On a deployed physical POD where the subscriber is authenticated, DHCP address assigned and pings are successful. Reboot the ONU and validate that the ONU comes back into active and right `state`. Validate by re-authenticating the RG, DHCP and pings successfully. | Implemented | End of April | stabilization | Gayathri | In-Progress | |||||||||||||||||||
62 | ofagentRestart in Voltha_FailureScenarios.robot | VOL-2409 | Failure Scenario: Restart ofagent after VOLTHA is operational | Restart ofagent container and verify that no other container is crashing and also perform sanity checks(flows,dhcp/ping) | Implemented | End of March | stabilization | Gayathri | Merged | |||||||||||||||||||
63 | RebootONU in Voltha_FailureScenarios.robot | VOL-2431 | Failure Scenario: Multiple ONUs: Reboot any ONU and check the functionality for all the ONUs | After a POD has been brought up with a successful EAPOL/DHCP and pings working on the ONUs. Automation of the following functional scenario Reboot any ONU and verify that pings fail for that particular ONU Verify that the other ONUs are still functional or pings work well Validate that the rebooted ONU comes back into active and right `state` Validate the auth+dhcp+ping for the rebooted ONU | Implemented | End of March | stabilization | Gayathri | Merged | |||||||||||||||||||
64 | Revisit missing restart/reconcile scenarios | |||||||||||||||||||||||||||
65 | VOL-2089 | Functional Test - PON Port Discovery - Failure Scenario | Precondition: One or more PON MAC devices (i.e. chips) are in failed state. Scenario: - During the initialization of the openolt agent, the state of all PON MAC devices are probed and stored. Some of them cannot be probed and OLT throws disconnected and failure indications asynchronously. Expected Result: - Voltha becomes aware of the ports that are inaccessible due to PON MAC device failure and isolates them in its resource management. - OLT state will be down only if all pon ports are inaccessible. - OLT state remains up if at least one set of ports (connected to the remaining healthy chip) is accessible. | Declared | End of February | stabilization | ||||||||||||||||||||||
66 | ERROR SCENARIOS TESTS | |||||||||||||||||||||||||||
67 | LogicalDeviceCheck in Voltha_ErrorScenarios.robot | VOL-2416 | Test Logical device creation | Automation of the following scenario. Create the OLT device - Admin should be preprovisioned Enable the device - should be in Enabled, Active state Logical device also should be created => "voltctl logicaldevice list" Check logical device ports => "voltctl logicaldevice ports <logical device id>" Check logical device flows => "voltctl logicaldevice flows <logical device id>" | End of February | stabilization | Gayathri | |||||||||||||||||||||
68 | LogicalDeviceCheck in Voltha_ErrorScenarios.robot | VOL-2417 | Test Logical device deletion | Automation of the following scenario. Disable the OLT device - should be disabled Delete the OLT - OLT and associated ONU's also should be removed successfully Logical device also should be deleted => "voltctl logicaldevice list" is empty | Implemented | End of February | stabilization | Suraj | Merged | |||||||||||||||||||
69 | DeleteBeforeDisableCheck in Voltha_ErrorScenarios.robot | VOL-2411 | Error Scenario: Delete OLT / ONU directly before disabling them | After a POD has been brought up successfully Automation of the following Error scenario. Delete the ONU directly before disabling it Should not be able to delete and it should throw the error message like "expected-admin-state:DISABLED" Delete the OLT directly before disabling it Should not be able to delete and it should throw the error message like "expected-admin-state:DISABLED" | Implemented | End of February | stabilization | Suraj | Merged | |||||||||||||||||||
70 | DisableInvalidDevice in Voltha_ErrorScenarios.robot | VOL-2412 | Error Scenario: Disable different device id which is not in the device list | Automation of the following Error scenario. 1. Disable the different OLT/ONU device ID which is not there in the device list 2. Should not allow to disable and it should throw the Error message with NOTFOUND indication. | Implemented | End of February | stabilization | Gayathri | ||||||||||||||||||||
71 | VOL-2413 | Error Scenario: Enable different device id which is not pre-provisioned | Automation of the following Error scenario. 1. Enable the different device ID which is not pre-provisioned. 2. Should not allow to enable (should not display the device id) and it should throw the Error message with NOTFOUND indication. | Implemented | End of February | stabilization | Gayathri | |||||||||||||||||||||
72 | DisablePreprovisionedOLTCheck in Voltha_ErrorScenarios.robot | VOL-2414 | Error Scenario: Disable the pre-provisioned OLT before enabling it | Automation of the following Error scenario. Create an OLT device, state should be Pre-provisioned. Try to disable the created Device => It should through the error message with "invalid-admin-state:PREPROVISIONED" indication. Enable the created device => should be enabled and associated ONUs also should be active. | Implemented | End of February | stabilization | Suraj | Merged | |||||||||||||||||||
73 | DisableDelete_LogicalDevice in Voltha_ErrorScenarios.robot | VOL-2418 | Error Scenario: Disable and Delete the logical device directly | Automation of the following scenario. Create the OLT device - Admin should be preprovisioned Enable the device - should be in Enabled, Active state Logical device also should be created => "voltctl logicaldevice list" Disable the logical device direclty ==> "voltctl logicaldevice disable <logicaldevice id>" Should not be possible and throw the error message Delete logical device directly ==> "voltctl logicaldevice delete <logicaldevice id>" Should not be possible and throw the error message | Implemented | End of February | stabilization | Hemalatha Thangavelu | ||||||||||||||||||||
74 | AddSameOLT in Voltha_ErrorScenarios.robot | VOL-2405 | Error Scenario: Adding the same OLT before enabling the OLT | Automation of the following scenario: Add an OLT in an up and running physical pod Make sure that the device is in PRE-PROVISION state Add the same OLT with the same IP address Error message should be thrown | Implemented | End of February | stabilization | Gayathri | Merged | |||||||||||||||||||
75 | VOL-2406 | Error Scenario: Adding the same OLT after enabling the device | Automation of the following scenario: Add an OLT in an up and running physical pod Make sure that the device is in PRE-PROVISION state Enable the OLT and make sure the OLT is in ENABLED state and ONU is added Add the same OLT with the same IP address Error message should be thrown | Implemented | End of February | stabilization | Hemalatha Thangavelu | Merged | ||||||||||||||||||||
76 | LogicalDeviceCheck in Voltha_ErrorScenarios.robot | VOL-2416 | Test Logical device creation | Automation of the following scenario. Create the OLT device - Admin should be preprovisioned Enable the device - should be in Enabled, Active state Logical device also should be created => "voltctl logicaldevice list" Check logical device ports => "voltctl logicaldevice ports <logical device id>" Check logical device flows => "voltctl logicaldevice flows <logical device id>" | End of February | stabilization | Gayathri | |||||||||||||||||||||
77 | LogicalDeviceCheck in Voltha_ErrorScenarios.robot | VOL-2417 | Test Logical device deletion | Automation of the following scenario. Disable the OLT device - should be disabled Delete the OLT - OLT and associated ONU's also should be removed successfully Logical device also should be deleted => "voltctl logicaldevice list" is empty | Implemented | End of February | stabilization | Suraj | Merged | |||||||||||||||||||
78 | ||||||||||||||||||||||||||||
79 | SCALE TESTS | |||||||||||||||||||||||||||
80 | Activate Devices OLT/ONU in Voltha_ScaleFunctionalTests.robot | VOL-1821 | Preprovisioning with 16 ONUs | This test preprovisions an OLT simulator with given IP address and TCP port and then enables both it and a number of ONU simulators with predefined IP/port information. It then verifies that all the physical and logical devices are ACTIVE and REACHEABLE (BBSim) | Implemented | End of December | stabilization | Gilles | periodic-voltha-scale-test | |||||||||||||||||||
81 | (ONU Discovery and Validate Device's Ports and Flows ) in Voltha_ScaleFunctionalTests.robot | VOL-1822 | Olt, Onu Discovery with 16 ONUs | This test covers both Onu Discovery and Olt Discovery It aims to verify the integrity of all port fields under each discrete device, including Logical Device. It also insures that the peers fields contains device Id entries for the corresponding Olt or Onu device. The extent of the flow validation is limited to checking whether number of Flows is > 0 (BBSim) | Implemented | End of December | stabilization | Gilles | periodic-voltha-scale-test | |||||||||||||||||||
82 | { Verify AAA-Users Authentication and Verify Total Number Of Eapol Flows} in Voltha_ScaleFunctionalTests.robot | VOL-1823 | Radius Authentication with 16 ONUs | This test attempts to perform a Radius Authentication from the RG in the case of the 'ponsim' simtype. It uses the wpa_supplicant app to authenticate using EAPOL. We then verify the generated log file confirming all the authentication steps In the case where the simtype is 'bbsim' we simply verify that all ONUs have authenticated. We do this by executing the 'aaa-users command on onos (BBSim) | Implemented | End of February | stabilization | Debasish | Tests on one OLT/ONU. WIP for multiple ONUs | |||||||||||||||||||
83 | {Allocate DHCP To All ONU Devices and Validate Total Number Of DHCP Allocations} in Voltha_ScaleFunctionalTests.robot | VOL-1824 | DHCP with 16 ONUs | DHCP with 16 ONUs (BBSim) | Implemented | End of February | stabilization | Debasish | Tests on one OLT/ONU. WIP for multiple ONUs | |||||||||||||||||||
84 | ||||||||||||||||||||||||||||
85 | PERFORMANCE TESTS | |||||||||||||||||||||||||||
86 | ||||||||||||||||||||||||||||
87 | SOAK TESTS | |||||||||||||||||||||||||||
88 | ||||||||||||||||||||||||||||
89 | ||||||||||||||||||||||||||||
90 | ||||||||||||||||||||||||||||
91 | ||||||||||||||||||||||||||||
92 | ||||||||||||||||||||||||||||
93 | ||||||||||||||||||||||||||||
94 | ||||||||||||||||||||||||||||
95 | ||||||||||||||||||||||||||||
96 | ||||||||||||||||||||||||||||
97 | ||||||||||||||||||||||||||||
98 | ||||||||||||||||||||||||||||
99 | ||||||||||||||||||||||||||||
100 |