Table of Contents |
|
...
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
Anchor | ||||
---|---|---|---|---|
|
...
Used
Expand |
---|
The following abbreviations are used in the functional test case description below since there is may be substantial repetition and along with clarification notes associated with some terms
|
Anchor | ||||
---|---|---|---|---|
|
Id | Description | Pre-conditions | Test Steps | Expected Results | ||||||||||
A: Health Checks | A.1: for OOF-OSDF Component Health ChecksComponents and Dependencies (Policy and OOF-HAS API) | |||||||||||||
A.1a1 | Perform healthcheck health check for the OOF-OSDF components using Healthcheck Health Check API
| OSDF application component (OSDF application server) should be up and running[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 | : OOF-OSDF Dependencies Health ChecksCHECK-REQ-OR-OPTIONAL | A.2a | Perform healthcheck for the following external components and OOF components using Healthcheck Health Check API:
| [Policy Emulator] 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 Fetch Data from Emulators (valid and invalid data | sets, via GET and POST) | ||||||||||||
B.1 | : Check Requests covering Valid and Invalid DataPost Valid Retrieve data from HAS-API emulator (or HAS-API container) | 2 | Retrieve data from mock emulators for the following components or links via emulators:
| 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 |
| [OOF-HAS API – container or emulator]EMULATORS-OR-SERVICES-ARE-UP | TODO: Payloads and Endpoint API – specific to each component Method - POST in most cases; GET in some cases Endpoint: http://<host>:<port>/<specific-API> Notes: 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
...
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:
- Provide an end point for SO to make homing requests
- Ensure authentication and validate the incoming request payload based on a model (Python Schematics model based on the SO-OOF API)
- 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)
- Send response to SO that the request is accepted and is in processing (or send an error response)
- Create a "template" (request payload) for OOF-HAS and submit the request to OOF-HAS
- 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)
- 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
Appendix C: Resources and Links
- https://wiki.onap.org/display/DW/Creating+a+CSIT+Test
Policy Team's CSIT Functional Test Cases used as a basis for OOF-OSDF test cases