Versions Compared

Key

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

...

Anchor
OOF Beijing Release Functional Test Cases
OOF Beijing Release Functional Test Cases
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

HTTP-200-TRUE


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

B.1: Check Requests covering Valid and Invalid Data

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.

Acknowledgments

Adapted from Policy Team's CSIT Functional Test Cases created by Pamela Dragosh

Appendix A: Overview of ONAP Testing Requirements

...