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 21 Next »

Table of Contents
 Click here to expand...

Test Planning for OOF Optimization Service Design Framework (OOF-OSDF)

The test structure for Adapted from Policy Team's CSIT Functional Test Cases created by Pamela Dragosh

Abbreviations Used

 Click here to expand...

The following abbreviations are used in the functional test case description below since there may be substantial repetition along with clarification notes associated with some terms

  1. CHECK-REQ-OR-OPTIONAL

    1. Check if the test is required or optional. For instance, health checks for dependencies is likely optional because this will be captured in the tests for request/response

  2. EMULATORS-OR-SERVICES-ARE-UP

    1. Emulator or service should be up and running

    2. Emulator or service configuration file should be available and loaded

    3. Notes: For OOF internal components (e.g. OOF-OSDF connecting to OOF-HAS API), real services may be used when convenient

  3. 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. Notes: (a) Verify whether the external components also have standardized on "true" as the value
  4. 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/should be used, and whether mutual TLS is required when using OOM/K8S, and
      (b) verify if the health check is required for dependencies (it will help in quickly debugging but will add extra logic in our testing)
  5. SIMPLE-GET-POST-TO-EMULATORS

    1. API: specific to each component

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

    3. Method - POST in most cases; GET in some cases

    4. Notes: (a) check whether https can/should be used, and whether mutual TLS is required when using OOM/K8S

OOF-OSDF Beijing Release CSIT Functional Test Cases 

Id

Description

Pre-conditions

Test Steps

Expected Results

A: Health Checks for OOF-OSDF Components and Dependencies (Policy and OOF-HAS API)

A.1

Perform health check for the OOF-OSDF components using Health Check API

  •   OSDF Manager

[OSDF Manager]
EMULATORS-OR-SERVICES-ARE-UP

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

SIMPLE-GET-HEALTH-CHECK-API

HTTP-200-TRUE

A.2

CHECK-REQ-OR-OPTIONAL
Perform health check for the following external components and OOF components using Health Check API:

  • Policy (external component)
  • OOF-HAS API (OOF component)

[Policy Emulator]
[OOF-HAS API – container or emulator] EMULATORS-OR-SERVICES-ARE-UP


SIMPLE-GET-HEALTH-CHECK-API

HTTP-200-TRUE


B: Fetch Data from Emulators (valid and invalid data, via GET and POST)

B.1

Post Valid Retrieve data from HAS-API emulator (or HAS-API container)

  • OSDF → HAS (POST with valid and invalid templates)
  • OSDF → HAS (GET status/solution)
  • OSDF → Policy (POST to query policy)

[OOF-HAS API – container or emulator] EMULATORS-OR-SERVICES-ARE-UP

TODO: Payloads and Endpoint

Should receive expected data:

TODO: Payloads











C: Run Complete Requests for Different Applications

C.1









Test Planning for OOF Homing and Allocation Service (OOF-HAS)


Appendix A: Overview of ONAP Testing Requirements

TODO

Appendix B: Overview of OOF Scope

TODO

Overview of OOF-OSDF Scope

General Description

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

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 to the call-back URL specified in the request from SO in the format defined by SO-OOF API (or send an error response)

Overview of OOF-HAS Scope

General Description

TODO

Technical Description for OOF-HAS Functionality 

TODO

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

  2. Policy Team's CSIT Functional Test Cases used as a basis for OOF-OSDF test cases



  • No labels