Functional Tests. Contractor shall include Functional Tests on the Project Schedule; shall prepare test plans and procedures for same; shall obtain Owner approval of same; and shall perform and successfully complete each of the Functional Tests as described in the Scope of Work.
Functional Tests. TVA will perform IP Product testing by issuing Test Interruptions to all IP5 participants (Reliability Only Fleet). The Reliability Only Fleet will be tested as illustrated in the following schedule: LPC T&C Rolling (7/27/18) Functional Test Schedule TVA Fiscal Year 2016 2017 2018 2019 2020 2021, etc. Fleet Test Schedule Test Interruptions will occur during the Summer Period or Winter Period Test Interruptions will occur during the Summer Period or Winter Period Test Interruptions will occur during the Summer Period or Winter Period Additional Tests by Request Customers with <100% Performance Factor in latest fleet test may request retest for protected demand reinstatement (at TVA’s discretion) Customers with <100% Performance Factor in latest fleet test may request retest for protected demand reinstatement (at TVA’s discretion) Customers with <100% Performance Factor in latest fleet test may request retest for protected demand reinstatement (at TVA’s discretion)
Functional Tests. The following table describes several functional features which allow checking the proper behaviour of different modules and activities carried out by the Trust Management Framework. It should be noted that all the tests described in Table 2-2 are not related to the integration of the Trust Management Framework with other 5GZORRO modules. Therefore, the following tests are internal to the TMF. Table 2-2: Trust Management Framework functional tests Name Description Passed (Yes/No/Partially) Trust Parameters Verify whether the dictionary received as parameter complies with the format of the described trust information model Yes Start data collection Verify that The Trust Management Framework is able to create a new pipeline in Xxxxx Yes Receive information from a topic Verify that The Trust Management Framework can retrieve trust information from a particular stakeholder to compute a trust score. Yes Send information to a topic Verify that The Trust Management Framework is able to push information to a Xxxxx topic and also to the Data Storage in order to keep track of a trust relationship. Yes
Functional Tests. The functional tests carried out on this module are mainly related to the correct verification of the implemented proof of concept. Table 2-3: Trusted execution environment security management functional tests Name Description Passed (Yes/No/Partially) Create docker image Create docker image on top of SCONE cross-compiler docker images Yes Setup trusted node Setup a node with SGX-enabled capabilities Yes Instantiate LAS Setup LAS service alongside the enclave Yes Upload SCONE session Upload SCONE session to CAS with the secrets that intended to run on the docker container Yes Instantiate docker container Instantiate docker container in the trusted node Yes Retrieve secrets Retrieve secrets from the docker container that are passed by CAS once LAS attests its authenticity Yes Validate docker container security Check if the secrets that should be passed by CAS were not in the container environment and the running code was encrypted Yes
Functional Tests. Our software tests refer to the successful deployment of the various containers needed for the module and the successful data sharing communication between them. Table 2-4: Intra-domain functional tests Name Description Passed (Yes/No/Partially) Zeek service Successfully deployed. Links with Filebeat (to be considered). YES Kibana service Successfully deployed. Links with Elasticsearch. YES Elastisearch service Successfully deployed. YES Filebeat service Successfully deployed. Links with Elasticsearch and Kibana. YES
Functional Tests. The functional tests (see Table 2-6) carried out on this module are mainly related to the verification of the correct functioning of the implemented methods. Table 2-6: Inter-domain security functional tests Name Description Passed (Yes/No/Partially) Module setup The module can be automatically installed and configured. Yes Client addition A new client is connected to the VPN, obtaining a client IP in the VPN. Yes Client removal A client is disconnected, removing its IP from the known list. Yes Connection establishment The automated connection establishment between two VMs running in different subnets is tested. Yes Connection deletion In the current design we use the public key to search for the client to be removed. Yes
Functional Tests. The functional tests to validate ISSM-WFM API with respect to the Workflow 3-6 reported in D2.3 are presented in Table 3-1. The tests have been performed using mock-up APIs for all involved components. The ISSM-WFM APIs have also been tested for the workflows involving actual the actual components, such as NSSO, and Data Lake, as described in Subsection 5.2. Table 3-1: ISSM-WFM functional tests Name Description Passed (Yes/No/Partially) Create flow Create a new business flow Yes Execute flow Execute a new business flow Yes Get progress Get progress of a business flow using web hook Yes Delete flow Remove a business flow from ISSM-WFM Yes Continuous progress Observe a progress of a flow with GUI Yes
Functional Tests. This section reports the set of main functional tests performed during the implementation of the VRM Resource Manager modules. In particular, Table 4-1 and Table 4-2 describe the test set for the RDT module (as part of the Resource Manager) and the MDA, respectively. Table 4-1: Resource Definition Translator functional tests Name Description Passed (Yes/No/Partially) Descriptors Translation Translation of descriptors for VNF, PNF and NS from ETSI SOL-006 to TMF 633 and 634 Yes RSOC invocation Invocation of the RSOC to store the translated services/resources Yes Table 4-2: Monitoring Data Aggregator functional tests Name Description Passed (Yes/No/Partially) Receiving a monitoring spec The module receives, from Vertical Slicer, a configuration containing the metrics to monitor, the duration of the monitoring stage, and the unique identifiers associated with the operator and business flow ID. Yes Collecting values of the monitored metrics The module collects metric values, from OSM, within the step received from the monitoring spec. Yes Pushing data into a Xxxxx topic The module, after signing the collected data, that is, performing the hashing and encryption operations, pushes it into a Xxxxx topic. Yes
Functional Tests. The set of functional tests conducted so far on the NSSO are reported in Table 4-3. Table 4-3: Network Slice and Service Orchestrator functional tests Name Description Passed (Yes/No/Partially) Service instantiation A simple service instantiation is requested from the ISSM. The NSSO provisions a network slice with one network service relying on the local domain functionality. Yes Configuration of monitoring metrics The NSSO requests the configuration of the metrics to the MDA Yes
Functional Tests. In this section are presented the functional tests that have been performed to the e-Licensing Manager components. These tests are further demonstrated in Section 5.3.1, where a set of screenshots of the ELM behaviour are depicted. Table 4-4: E-Licensing manager functional tests Name Description Passed (Yes/No/Partially) Test_osm_interface Test for the communication between the xXXX and the MANO. It includes: • Login • Get_descriptors • Get_instance_status • Describe_instances • Create_subscription • Remove_subscription Yes Test_registration_POP Test for the registration of a POP in the XXXX. Yes Test_registration_POP_error Registration test of non-existent POP in the marketplace Yes Test_registration_PO Test for the registration of a PO in the ELMC Yes Test_watcher Test for the watcher creation/deletion/update Yes Test_mysql Test for the internal database creation and connection. Yes Test_domain Test for the deployment in non-existing domain. Yes Test_NSSO_interface Integration test with the NSSO Yes
