Skip to end of metadata
Go to start of metadata

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

Compare with Current View Page History

« Previous Version 11 Next »


Table of Contents



 Click here to expand...

Overview of ONAP Testing Requirements

TODO

Overview of OOF Scope

TODO

Overview of OOF-OSDF Scope

General Description

 Click here to expand...

The OOF-OSDF is meant to provide an environment for creating policy-driven optimization applications in a declarative manner easily. It also provides an execution environment for these models to be interpreted and run.

Additionally, it supports external, custom optimizers such as the HAS application by providing various levels of functionality to the optimization applications. For example, the OSDF may fetch and translate policies for HAS, or it may fetch policies and data for another application.

Technical Description for OOF-OSDF Functionality related to OOF-HAS

 Click here to expand...

The OOF-OSDF is provides the following functionality to support OOF-HAS:

  1. Provide an end point for SO to make homing requests
  2. Ensure authentication and validate the incoming request payload based on a model (Python Schematics model based on the SO-OOF API)
  3. Fetch policies relevant to the SO's request (e.g. based on specific use case such as vCPE) and ensure that the policies are valid (well formed and contain required attributes)
  4. Send response to SO that the request is accepted and is in processing (or send an error response)
  5. Create a "template" (request payload) for OOF-HAS and submit the request to OOF-HAS
  6. Periodically poll OOF-HAS for request processing status and optimization solution (with a configurable timeout) and validate the response based on a model (Python Schematics model)
  7. Post the optimization solution in the format defined by SO-OOF API (or send an error response)

Overview of OOF-HAS Scope

TODO

Technical Description for OOF-HAS Functionality 

TODO

Release Specific Documentation

Beijing Release Testing

Abbreviations used in Beijing Release Functional Test Cases

 Click here to expand...

The following abbreviations are used in the functional test case description below since there is substantial repetition and notes associated with some terms.

  1. HTTP-200-TRUE

    1. Component (or all components) should return health status as “true” (HTTP response code of 200, response content containing the string "true")

  2. SIMPLE-GET-HEALTH-CHECK-API
    1. API: healthcheck
    2. HTTP Request Method: GET
    3. HTTP Endpoint: http://<host>:<port>/healthcheck 
    4. Notes: (a) check whether https can be used, and (b) check whether mutual TLS is required when using OOM/K8S

OOF-OSDF Beijing Release CSIT Functional Test Cases 

Acknowledgment: adapted from Policy Team's CSIT Functional Test Cases created by Pamela Dragosh

Id

Description

Pre-conditions

Test Steps

Expected Results

A: Health Checks

A.1: OOF-OSDF Component Health Checks

A.1a

Perform healthcheck for the OOF-OSDF components using Healthcheck API

  •   OSDF (OF Manager)

OSDF application component (OSDF application server) should be up and running

Server and authentication details should   be configured at $OOF_HOME/config/feature-healthcheck.properties

SIMPLE-GET-HEALTH-CHECK-API

HTTP-200-TRUE

A.2: OOF-OSDF Dependencies Health Checks

Test whether dependencies (external components) such as Policy, and other OOF components (e.g. HAS API) respond to health checks.

A.2a

Perform healthcheck for the following external components and OOF components using Healthcheck API

  • Policy
  • OOF-HAS API

Service configuration file(s) should be available and loaded.

Services should be up and running.

SIMPLE-GET-HEALTH-CHECK-API

All components should return health status as “true” (HTTP code 200, content as string "true")

Note 1: Verify whether the external components also have standardized on "true" as the value

Note 2: Verify if this step is required or optional (it will help in quickly debugging but will add extra logic in our testing)

B: Tests Related to Data from Emulators (valid and invalid data sets)

B.1: Checking Dependencies (Mostly external components) via Emulators

Testing whether dependencies (mostly external components such as Policy, A&AI, Multi Cloud, etc., and in some cases other OOF containers) are available and return expected data. The external components will be mock emulators, while internal components may be mock or real.

2

Retrieve data from mock emulators for the following components or links via emulators:

  • OSDF → HAS (POST template)
  • OSDF → HAS (GET status/solution)
  • OSDF → Policy
  • HAS → Multi Cloud
  • HAS → A&AI (clarify)
  • HAS → DMaaP (clarify)
  • HAS → MUSIC
  • Interactions among HAS internal components (when using separate Docker containers)

Emulator configuration file should be available and loaded.

Emulator services should be up and running.

For some internal component testing, emulators may be replaced by real systems when convenient

API – specific to each component

Method - POST in most cases; GET in some cases

Endpoint: http://<host>:<port>/<specific-API>

Notes:

  1. Split these into individual cells and expand

Should receive expected data

TODO: Expand individual cases as separate cells within this section


C: Tests Related to Data from Emulators (valid and invalid data sets)

B.2:







B.1: Checking Dependencies (Mostly external components) via Emulators

Testing whether dependencies (mostly external components such as Policy, A&AI, Multi Cloud, etc., and in some cases other OOF containers) are available and return expected data. The external components will be mock emulators, while internal components may be mock or real.


  1. https://wiki.onap.org/display/DW/Creating+a+CSIT+Test



  • No labels