MultiCloud Functional Testing planning

Owned by Bin Yang
Last updated: Feb 20, 2019
2 min read
Table of Contents
 Click here to expand...

We would need to have one CSIT per repo based on OOM:  Dev Testing_Enhancement for Dublin_V2.pptx

Recommending B1, and N4 as the initial candidates for OOM based CSIT. 

Abbreviations Used

The following abbreviations are used in the functional test case description below since there may be substantial repetition along with clarification notes associated with some terms:

 Click here to expand...

Abbreviations:

  1. CHECK-REQ-OR-OPTIONAL

    1. Check if the test is required or optional. For instance, health checks for dependencies is likely optional because this will be captured in the tests for request/response

  2. EMULATORS-OR-SERVICES-ARE-UP

    1. Emulator or service should be up and running

    2. Emulator or service configuration file should be available and loaded

  3. HTTP-200-TRUE

    1. Component (or all components) should return health status as “true” (HTTP response code of 200, response content containing the string "true")

    2. Notes: (a) Verify whether the external components also have standardized on "true" as the value
  4. SIMPLE-GET-HEALTH-CHECK-API
    1. API: healthcheck
    2. HTTP Request Method: GET
    3. HTTP Endpoint: http://<host>:<port>/api/<multicloud component namespace>/v0/swagger.json
    4. Notes: (a) check whether https can/should be used, and whether mutual TLS is required when using OOM/K8S, and
      (b) verify if the health check is required for dependencies (it will help in quickly debugging but will add extra logic in our testing)
  5. SIMPLE-GET-POST-TO-EMULATORS-OR-SERVICES

    1. API: specific to each component

    2. Endpoint: http://<host>:<port>/<specific-API>

    3. Method - POST in most cases; GET in some cases

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

MultiCloud Dublin Release CSIT Functional Test Cases 

Id

Description

Pre-conditions

Test Steps

Expected Results

A: Health Checks for MultiCloud Components and Dependencies

A.1

Perform health check for the MultiCloud components using Health Check API

  • MultiCloud Broker (multicloud)
  • MultiCloud Plugin for Ocata (multicloud-ocata)
  • MultiCloud Plugin for Pike (multicloud-pike)
  • MultiCloud Plugin for Wind River (multicloud-titaniumcloud)
  • MultiCloud Plugin for StarlingX (multicloud-starlingx)
  • MultiCloud Plugin for VIO (multicloud-vio)
  • MultiCloud Plugin for Azure (multicloud-azure)
  • MultiCloud Plugin for k8s (multicloud-k8s)

EMULATORS-OR-SERVICES-ARE-UP


SIMPLE-GET-HEALTH-CHECK-API

HTTP-200-TRUE






B: Configuration

B.1















C: Run Time

C.1













Example Request/Response Payloads for MultiCloud Functional Test Cases

MultiCloud HealthCheck Request Example 
export MC_EP_IP=127.0.0.1
export MC_EP_PORT=9005
curl -v -s -H "Content-Type: application/json" -X GET http://$MC_EP_IP:$MC_EP_PORT/api/multicloud-titaniumcloud/v1/swagger.json
MulitCloud HealthCheck Response Example 
> GET /api/multicloud-titaniumcloud/v1/swagger.json HTTP/1.1
> Host: 127.0.0.1:9005
> User-Agent: curl/7.50.1
> Accept: */*
> Content-Type: application/json
>
< HTTP/1.1 200 OK
< Vary: Cookie
< X-Frame-Options: SAMEORIGIN
< Content-Type: application/json
< Allow: GET, HEAD, OPTIONS
* no chunk, no close, no size. Assume close to signal end