Versions Compared

Old Version 43

changes.mady.by.user Raj Gumma

Saved on

compared with

New Version Current

changes.mady.by.user Kamel Idir

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Overview:

The E2E integration test consists of three main parts:

Table of Contents


Gliffy
size600
nameSDC-service-distribution Copy
pagePin1

Image Modified


Image RemovedImage Added


Deployment:

Test environment requirements for the test cases:

  • xNF simulator for test cases:  PNF Simulator with TLS & YANG support.
  • SO with Config-Assign and Configure steps implemented in workflows.
  • CDS Blueprint processor enhanced so that it can send mount, configure and un-mount rest request to SDNC.
  • SDNC enhanced with ODL flourine SR2 and also capable to import client and trusted certificate and private key at deployment time.

This environment can be set up by following the steps below.

  1. Repo : Yet to update
  2. RUN : Yet to update

Use Case preconditions:

    • xNF simulator.

High Level End-to-End feature integration Test cases :


#Test CaseDescriptionReferenceTester
1Create and distribute service which contains PNFVerify distribution and ingestion of PNF service csar to VID, AAI & SO.5G - PNF Onboarding Test Cases and Status : PNF-OB-5Andy Walshe
2Waiting for PNFReadyVerification if PNF PnP functionality within SO is waiting for PNFReady to be published by PRH.5G - PNF PnP -WaitingforPNFReady

Rahul Tyagi

Eric Moore

3

PNF registration accepted

Verification if PNF resource registration is done properly

5G : Configuration with NETCONF - E2E test case for Netconf over TLS

Rahul Tyagi

Eric Moore

4Send Configuration with NETCONF over TLSVerify the configuration is sent to the PNF with NETCONF5G : Configuration with NETCONF - Success Flow

Rahul Tyagi

Eric Moore



Detailed Description End-to-End Feature Integration Testcases :


Test Case ID

Netconf

NETCONF_CONFIGURATION_TLS_E2E

_03

Test Case Name

E2E test case for NETCONF over TLS

DescriptionEnsure that PNF_READY notification is received by SO from
simulated environment
PRH then SO sends CONFIG-ASSIGN, CONFIGURE request to SS-API, to configure the xNF
ReleaseDublin
Pre-conditions
  1. SO should be waiting for PNF_READY notification after registration process and fully configured as per registration process.
  2. Blueprint archive should be configured for correct blueprint.
  3. SDNC should be installed successfully with keystore preconfigured with certificates of PNF-SIM.
    Certificates for PNF simulator can be picked up from here. Copy these certs in /dockerdatanfs/sdnc/certs and
PNF simulator
  1. install sdnc.
  2. PNF-SIM should be running with TLS support.

      Install pnf simulator from here using ./simulator.sh start. It will start simulator in TLS/SSH mode at 6503/830 port. Send VES message by changing config/config.json.

Testing Steps


StepsExpected Result
  1. Send PNF_READY to SO(This step will trigger a run to SS-API, BP component, SDNC and PNF simulator)
  • Send SSH mount/connect request to SDNC/ODL using rest client.
    • Send GET request for configuration to get configuration, set in step 1
    2. SO sends CONFIG-ASSIGN request to CDS.
    3. SO receives the response from CDS for CONFIG-ASSIGN as success.
    4. SO sends CONFIG-DEPLOY  async request to CDS.
    5. CDS sends patch(includes mount, configure and unmount request) to SDNC.
    6. SDNC sends mount request to PNF-SIM using TLS connection.
    7. CDS send connection status to SDNC for PNF-SIM.
    8. SDNC sends configuration request to PNF-SIM.
    9. SDNC sends unmount request to PNF-SIM.
    10. Verify received configuration is correct on PNF-SIM (Manual verification).
    		Get response should give correct result for
    configure

    1. SO sends a request to perform action assignConfig

    Code Block
    languageyml
    blueprintName: String
blueprintVersion: Integer
action: String
pnf-name: String
pnf-ip: String

    2. SS-API forwards the request to BP, that will load the blueprint, execute the action specified, prepare the configlet, persist it and return a successful message to SO

    3. SO recognizes the success message and sends a request to perfom action deployConfig

    Code Block
    languageyml
    blueprintName: String
blueprintVersion: Integer
action: String
pnf-name: String
pnf-ip: String

    4. SS-API forwards the request to Blueprint Processor, that will load the blueprint, execute the action specified, retrieve the configlet from the persistence, connect to ODL, send the configlet(s) to the PNF and return a successful message to SO

    Conclusion (Pass /Fail)Testing
    configuration on PNF-SIM



    Conclusion (Pass /Fail)
    Testing Lab

    Test Case ID

    Netconf_TLS_E2E_04Test Case Name

    Successful flow

    DescriptionSteps assignConfig and deployConfig will conclude as expected, and the desired configuration will be applied to the PNF
    Release

    Dublin

    Pre-conditions

    Valid PNF
    Valid blueprint
    SO is primed and post PNF registration stage
    ODL instance is installed and available

    Testing Steps

    StepsExpected Result

    Status
    colourGreen
    titlePassed

    Testing Lab

    Ericsson Lab, Windriver Lab


    Information:


    Next Step(s):