Scribd Logo
Upload

Welcome to Scribd!

  • Group 1 Test Scenarios Document PDF

    Uploaded by

    Kushagra
    15 views6 pages

    Original Title

    Group 1 Test Scenarios Document .pdf

    Copyright

    © © All Rights Reserved

    Available Formats

    PDF, TXT or read online from Scribd

    Did you find this document useful?

    Is this content inappropriate?

    Report this Document

    Copyright:

    © All Rights Reserved
    Download as PDF, TXT or read online from Scribd
    Flag for inappropriate content
    15 views6 pages

    Group 1 Test Scenarios Document PDF

    Uploaded by

    Kushagra

    Copyright:

    © All Rights Reserved
    Download as PDF, TXT or read online from Scribd
    Flag for inappropriate content
    of 6

    Test Scenarios Document

    By
    Group 1

    Avinash Kumar 20172057


    Gaurav Mahajan 20172045
    Pratyush Madhukar 20172095
    Juhi Gupta 20172031
    Kushagra Gupta 20172079
    Harshit Sharma 20172018
    Rajat Agarwal 20172065
    Parul Jain 20172107
    Nikita Agrawal 20172093
    Kaushik L V 20172138
    Table of Contents

    Table of Contents 2

    Test Scenarios 2
    Functional: 2
    Non Functional: 3
    Platform Bootstrap Check 3
    Application Deployment Check 3
    Various workflows running simultaneously in workflow engine 4
    Local decision making at gateways based on thresholds 4
    Minimal delays in notifications 4
    Data encryption 4
    Isolation of application data 4
    Communication between gateway and load balancer 4
    Communication between load balancer and intermediate server 4
    Communication between intermediate server and central server 4
    Communication of each component (Gateway, Intermediate Server, Central
    Server) with the Central Repository 5
    Verifying correct resource availability (jars) across the components 5
    Dynamic V.M instantiation: 5
    Fault tolerance of Docker: 5
    Fault tolerance of V.M: 5
    Load Balancing: 5
    1. Test Scenarios
    1.1. Functional:
    1.1.1. Platform should support multiple application and multiple instances of
    same application.
    1.1.2. Platform should allow application developer to specify logic through
    workflow, java function, rules, python scripts etc.
    1.1.3. Platform should allow deployer to distribute application functionality
    across the topology.
    1.1.4. Platform should enable seamless reliable communication throughout the
    application topology.
    1.1.5. Platform should ensure the isolation of a particular application’s data from
    another.
    1.1.6. Platform should provide analytics of available sensor data and generate
    corresponding reports.
    1.1.7. Platform should provide Logging services to log all the actions of the
    application.
    1.1.8. Platform should provide database APIs to the application developer who
    can execute simple SQL queries.
    1.1.9. Platform should provide error handling and troubleshooting services.
    1.1.10. Platform should provide simple UI so that the application developer can
    upload the artifacts and see the current running instances of the
    application. Same interface may be used to application logs.
    1.1.11. Platform should provide means to specify CRON jobs.
    1.1.12. Platform should provide default actions such as sending SMS, sending
    emails etc.
    1.2. Non Functional:
    1.2.1. Platform Bootstrap Check

    Test whether the Platform is up and running and waiting for requests of
    deployment of new applications. Also test whether different components of the
    platform are up and running.

    1.2.2. Application Deployment Check

    Test whether the application is deployed across the platform as per


    topology specified by the deployer.

    1.2.3. Various workflows running simultaneously in workflow engine

    Workflow engine should run multiple application workflows


    simultaneously.

    1.2.4. Local decision making at gateways based on thresholds

    Sensitive application logic must be executed at the gateway itself and this
    is ensured by the workflow engine.

    1.2.5. Minimal delays in notifications

    Ensure that sensitive alerts are sent in time to the end user.

    1.2.6. Data encryption

    Ensure the usage of state-of-the-art encryption techniques to protect


    application data.

    1.2.7. Isolation of application data

    Ensure access to data is governed by authentication and authorization.

    1.2.8. Communication between gateway and load balancer

    Messages between the gateway and intermediate server is redirected via


    Load balancer. So, test whether the communication channel between the
    gateway and load balancer is configured correctly.
    1.2.9. Communication between load balancer and intermediate server

    The message intercepted by load balancer will be guided to the


    appropriate intermediate server by the load balancer. So, test whether the
    communication channel between the load balancer and connected intermediate
    servers is configured correctly.

    1.2.10. Communication between intermediate server and central server

    Communication between the intermediate server and central server


    components running inside isolated docker instances should also be consistent
    and reliable. So, test whether the communication channel between the
    intermediate server and corresponding docker instances is configured correctly.

    1.2.11. Communication of each component (Gateway, Intermediate Server,


    Central Server) with the Central Repository

    Verify whether the communication of FTP server with all the platform
    components is configured correctly.

    1.2.12. Verifying correct resource availability (jars) across the components

    Application developer specifies which application logic to run based on


    events & thresholds. Verify that appropriate jars are available to the
    corresponding component.

    1.2.13. Dynamic V.M instantiation:

    Autoscaling of V.M based on number of docker instance currently running on


    particular V.M instance . If resources used by docker instance exceeds system
    capabilities new V.M instance needs to be spawn in another physical system

    1.2.14. Fault tolerance of Docker:

    System should ensure new docker instance is spawned when any one of
    instance is down.
    1.2.15. Fault tolerance of V.M:

    System should ensure new V.M instance is spawned when any one of instance
    is down.

    1.2.16. Load Balancing:

    System should be able to distribute requests on multiple docker instances


    running on different VMs.

    You might also like