...
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:
...
Overview of OOF-HAS Scope
TODO
Technical Description for OOF-HAS Functionality
TODO
Beijing Release Testing
| Anchor | ||||
|---|---|---|---|---|
|
Acknowledgment: adapted from Policy Team's CSIT Functional Test Cases created by Pamela Dragosh
Resources
...
| Anchor | ||||
|---|---|---|---|---|
|
...
Beijing Release Functional Test Cases
...
The following abbreviations are used for items in the functional test case description below since there is substantial repetition and notes associated with some terms.
- HTTP-200-TRUE
Component (or all components) should return health status as “true” (HTTP response code of 200, response content containing the string "true")
- SIMPLE-GET-HEALTH-CHECK-API
- API: healthcheck
- HTTP Request Method: GET
- HTTP Endpoint: http://<host>:<port>/healthcheck
- Notes: (a) check whether https can be used, and (b) check whether mutual TLS is required when using OOM/K8S
...
Id | Description | Pre-conditions | Test Steps | Expected Results |
A: Tests Related to Health Checks | ||||
A.1: OOF-OSDF Component Health Checks via GET methods | ||||
A.1a | Perform healthcheck for the OOF-OSDF components using Healthcheck API
| 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: Health Checks for Dependencies Test whether dependencies (external components) such as Policyresponding to health checks. | ||||
| A.2a | Perform healthcheck for the following external components and OOF components using Healthcheck API
| 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:
| 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:
| 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. | ||||