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

Contents

Overview of ONAP Testing Requirements

TODO

Beijing Release Testing

OOF Beijing Release CSIT Functional Test Cases

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

Resources

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

Id

Description

Pre-conditions

Test Steps

Expected Results

A: Tests Related to Health Checks

A.1: OOF Component Health Checks via GET methods

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

A.1a

Perform healthcheck for the OOF components using Healthcheck API

  •   OSDF (OF Manager) 
  •   HAS (TODO: expand individual containers of HAS)

OSDF and HAS application components (<list components>) should be up and running

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

API – healthcheck

Method - GET

Endpoint: http://<host>:<port>/healthcheck OR https://<host>:<port>/healthcheck

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

A.2: (Robot Driven?) Health Checks for Dependencies (Real Components; test cases also useful for integration testing)

Testing whether dependencies (external components such as Policy, A&AI, Multi Cloud, etc., and all OOF containers) are responding to health checks.

A.2a

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

  • OSDF (OF Manager) 
  • HAS (TODO: expand individual containers of HAS)
  • Policy
  • Multi Cloud
  • A&AI (clarify)
  • DMaaP (clarify)
  • MUSIC

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

Services should be up and running.

API – healthcheck

Method - GET

Endpoint: http://<host>:<port>/healthcheck OR https://<host>:<port>/healthcheck

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:









  • No labels