...
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] Server and authentication details should be configured at $OOF_HOME/config/feature-healthcheck.properties | SIMPLE-GET-HEALTH-CHECK-API | HTTP-200-TRUE |
A.2 |
|
|
|
NOTE: Per comment and discussion with Ramki, removing this cell TODO: Retain this cell till and then remove it. |
B: Fetch Data from Emulators (valid and invalid data, via GET and POST) | ||||
B.1 | Retrieve response corresponding to "valid request" from HAS-API emulator
| [OOF-HAS API – container or emulator]EMULATORS-OR-SERVICES-ARE-UP | SIMPLE-GET-POST-TO-EMULATORS-OR-SERVICES TODO: Payload for OSDF-HAS request (based on SO-OOF/HAS Request Example below in section on payloads; dr_patel_an to add the payload; Shankaranarayanan Puzhavakath Narayanan to review) TODO: Endpoint and ports | Should receive a "request accepted" type response, following which we query status and the status should be a valid one (translating, translated, solving, solved, solution not found, etc.) |
| B.2 | Retrieve response corresponding to "valid policy query" from Policy emulator
| [Policy] | SIMPLE-GET-POST-TO-EMULATORS-OR-SERVICES TODO: Payloads and Endpoint | Should receive response for valid policy query TODO: Payloads |
| B.3 | CHECK-REQ-OR-OPTIONAL Moved to another cell |
|
|
NOTE: Per comment and discussion with Ramki, removed tests for "malformed" requests (open to adding them later on as needed). Moved the remaining one to a separate cell. TODO: Retain this cell till and then remove it. |
| B.4 | Retrieve response corresponding to a decision from Conductor (i.e. "done" with either a solution found or no solution found): OSDF → HAS (GET; solution found OR no solution found). Since we cannot guarantee whether a solution can be found (it is dependendent on dynamic state of the cloud instance), it may be better to merge it to a "solution found OR no solution found" – i.e. Conductor is done processing and gave a decision | [Policy Emulator] [OOF-HAS API – container or emulator] EMULATORS-OR-SERVICES-ARE-UP | SIMPLE-GET-POST-TO-EMULATORS-OR-SERVICES TODO: Payloads and Endpoint | TODO: Check format of response and valid status messages |
C: Run Complete Requests for Different Applications | ||||
| C.1 | SO → OSDF → HAS (well formatted request) | [Policy Emulator] | SIMPLE-GET-POST-TO-EMULATORS-OR-SERVICES TODO: Payloads, Endpoint, and Call-Back URL | Should receive a valid Conductor reponse TODO: Payloads |
| C.2 |
| [OOF-HAS API – container or emulator] EMULATORS-OR-SERVICES-ARE-UP |
|
NOTE: Per comment and discussion with Ramki, removing this cell TODO: Retain this cell till and then remove it. |
| C.3 | SO → OSDF → HAS → OSDF → Call Back URL A valid request sent from SO to OSDF, which results in a valid template sent from OSDF to HAS. OSDF will then poll HAS till a decision is made (i.e. "done" with either a solution found or no solution found; it is probably difficult to ensure a solution is guaranteed – it is great if a solution is found, and it is OK for testing purposes even if there if no solution in some cases) | [Policy Emulator] EMULATORS-OR-SERVICES-ARE-UP | [Policy Emulator] [OOF-HAS API – container or emulator] EMULATORS-OR-SERVICES-ARE-UP | Should receive a "done" type Conductor reponse (either successful in finding a solution or failed to find a solution, but Conductor made a decision either way) TODO: Payloads |
Example Request/Response Payloads for OOF-OSDF Functional Test Cases
...
- OOF-HAS: handling the internal “R’” interface, which in invoked by OSDF
Id | Description | Pre-conditions | Test Steps | Expected Results |
N.1 | Name: OOF-HAS Healthcheck Interface (R’). Perform healthcheck for OOF-HAS using Healthcheck REST API | 1. OOF-HAS docker image is up and running 2. OOF-HAS configuration is performed 3. MUSIC (real ONAP) docker image is up and running 4. Music is prepopulated with Healthcheck row | Robot Framework is sending a REST call to OOF-HAS API – healthcheck Method - GET Endpoint: http://$(hostname ):8091/v1/plans/healthcheck | OOF-HAS should respond with HTTP 200 and body containing "true" |
| N.2 | Name: OOF-HAS Wrong Version Interface (R’). Perform sanity sending a plan with wrong Version | 1. OOF-HAS docker image is up and running 2. OOF-HAS configuration is performed 3. MUSIC (real ONAP) docker image is up and running 4. Music is prepopulated with Healthcheck row | Robot Framework is sending a REST call to OOF-HAS API – to Post a Plan Method - POST Endpoint: http://$(hostname ):8091/v1/plans | OOF-HAS should respond with HTTP 200 and body containing "the error reason" |
| N.3 | Name: OOF-HAS Missing Demand Section Interface (R’). Perform Sanity sending a plan with missing Demand Section | 1. OOF-HAS docker image is up and running 2. OOF-HAS configuration is performed 3. MUSIC (real ONAP) docker image is up and running 4. Music is prepopulated with Healthcheck row | Robot Framework is sending a REST call to OOF-HAS API – to Post a Plan Method - POST Endpoint: http://$(hostname ):8091/v1/plans | OOF-HAS should respond with HTTP 200 and body containing "the error reason" |
| N.4 | Name: OOF-HAS Wrong Constraint Interface (R’). Perform sanity sending a plan with wrong Constraints | 1. OOF-HAS docker image is up and running 2. OOF-HAS configuration is performed 3. MUSIC (real ONAP) docker image is up and running 4. A&AI simulator docker image is up and running and it is populated in such a way that OOF cache can be built | Robot Framework is sending a REST call to OOF-HAS API – to Post a Plan Method - POST Endpoint: http://$(hostname ):8091/v1/plans | OOF-HAS should respond with HTTP 200 and body containing "the error reason" |
| N.5 | Name: OOF-HAS Correct plan no result Interface (R’). Send a correct plan requiring vCPE Optimization request for a set of Candidates and constraints that cannot be satisfied | 1. OOF-HAS docker image is up and running 2. OOF-HAS configuration is performed 3. MUSIC (real ONAP) docker image is up and running 4. A&AI simulator docker image is up and running and it is populated in such a way that OOF cache can be built and that a set of recommendations can be returned | Robot Framework is sending a REST call to OOF-HAS API – to Post a Plan Method - POST Endpoint: http://$(hostname ):8091/v1/plans | OOF-HAS should respond with HTTP 200 and body containing the plan acceptance (i.e. the plan is in “template” status and a unique identifier) |
Robot Framework is sending a REST call to OOF-HAS API – to GET a final recommendations Method - GET Endpoint: http://$(hostname ):8091/v1/plans/<planId> | OOF-HAS should respond with HTTP 200 and body containing NO recommendations (i.e. the plan is in “done” status and no resources are returned back) | |||
| N.6 | Name: Correct Plan with recommendations Interface (R’). Send a plan requiring vCPE Optimization request for a set of Candidates | 1. OOF-HAS docker image is up and running 2. OOF-HAS configuration is performed 3. MUSIC (real ONAP) docker image is up and running 4. A&AI simulator docker image is up and running and it is populated in such a way that OOF cache can be built and that a set of recommendations can be returned | Robot Framework is sending a REST call to OOF-HAS API – to Post a Plan Method - POST Endpoint: http://$(hostname ):8091/v1/plans | OOF-HAS should respond with HTTP 200 and body containing the plan acceptance (i.e. the plan is in “template” status and a unique identifier) |
Robot Framework is sending a REST call to OOF-HAS API – to GET a final recommendations Method - GET Endpoint: http://$(hostname ):8091/v1/plans/<planId> | OOF-HAS should respond with HTTP 200 and body containing the plan recommendations (i.e. the plan is in “done” status and a set of optimized vCPEs is returned to the caller ) | |||
Appendix A: Overview of ONAP Testing Requirements
...