1 / 28

Automatic Software Testing Tool for Computer Networks

Automatic Software Testing Tool for Computer Networks. ARD Presentation. Adi Shachar Yaniv Cohen Dudi Patimer. www.cs.bgu.ac.il/~adishach. Introduction.

meadow
Télécharger la présentation

Automatic Software Testing Tool for Computer Networks

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Automatic Software Testing Tool for Computer Networks ARD Presentation Adi Shachar Yaniv Cohen Dudi Patimer www.cs.bgu.ac.il/~adishach

  2. Introduction Access Layers' flagship product, Portnox, is a natural extension of existing security policies and methodologies, allowing network administrators to configure access parameters for physical network ports, and proceed to monitor, control, and manage LAN entities, including devices, switches, ports, access slots, and more. Portnox represents a new approach to LAN protection, providing complete online control of end-point access to the corporate network. Portnox allows networks administrators to determine which devices are allowed LAN access.

  3. Vision The tool will provide the ability for Access Layers testers to perform tests on their product easily and efficiently by changing settings and execute actions from a central computer over a group of end-stations. Moreover, the tool will enable them to perform tests that they could not perform before, such as simultaneously executing actions on group of end-stations or by a given schedule.

  4. The Problem Domain When Access Layers QA's testers execute tests on their software they need to change the settings of an end-stations and to perform different actions, for example: turning on/off the computer, changing the IP address, enable/disable Ethernet card, changes in the network settings of the end-station, login/logoff with users, etc. Nowadays, in order to execute the actions and the setting changes, they should execute all the necessary actions manually in the end-stations.

  5. Solution (1) Our project allows performing all the above actions automatically from a central station with simple GUI, and in addition to view the status of the end-stations at any step. Furthermore, our tool will be able to add and execute new scripts that were written by the testers on the end-stations, manage the scheduling of these actions, meaning to execute actions in chosen order, and to schedule the execution order of the end-stations.

  6. Solution (2) The tool will be composed of the following components: • Agents – this component will be placed on the end-stations; its responsibilities are to receive and execute commands on the end-station, and to send results and end-station state back to the ATS. • TSC (Test Set & Configuration) – it contains a set of actions that the user chooses to run and also configuration settings such as choosing the end-stations for the test and scheduling the execution of the tests.

  7. Solution (3) • ATS (Automatic Testing Server) - the main component of the project; its responsibilities are to: • Establish connection to the end-stations. • Remote executing commands/TSC on the end-stations, receiving results and end-stations state. • Create, modify and save TSC. • Define and validate the pre-conditions and the post-conditions for each action in the TSC. • Generate reports and logs.

  8. Solution (4) • Database – this component stores the following data: • Basic actions – definition of the pre-conditions, the post-condition and the commands/script for the execution for each basic action. The basic actions are depending on the operating system, meaning the scripts should use the commands of the operating system. • Logs – events that occur due to the use of the tool. • Additional actions – scripts that are written by the user, their pre-conditions and post-conditions. • TSC. • Executions results, which contains the state of the end-stations before and after execution of each action. • GUI – friendly and easy to use interface.

  9. End-Stations TSC Database ATS GUI High-Level Overview

  10. Functional Requirements (1) Establish Connection & Getting General Information • The ATS will be able to establish connection to Agents in the end stations by IP address or by physical address. • The Agent will be able to get general information from the end-station, such as information about the operating system, Ethernet card, state of the station, etc. • The ATS will be able to receive general information from the Agent.

  11. Functional Requirements (2) Assembling a TSC (1) • The user will be able to create a new TSC composed of the following components: • Basic actions (built-in actions). • Additional actions (scripts). • TSC. • The user will be able to configure the following settings in the TSC: • The end-stations which the user selected to run the TSC on. • The scheduling policy of the components in the test set. • The scheduling policy of the execution of tests between the end-stations that was selected (parallel, the order of the end-stations, the time gap between each pair of end stations, etc). • The number of times to run this TSC.

  12. Functional Requirements (3) Assembling a TSC (2) • The ATS will be able to generate a script from a TSC, which will include the pre-conditions and post-conditions scripts before and after each action in the test set, the scheduling policy and more. • The user will be able to save/load/modify/delete the TSC to the database.

  13. Functional Requirements (4) Creating Additional Actions • The user will be able to add actions to the system. • The additional actions will be composed of pre-conditions, post-conditions scripts and the script of the actions. • The user will be able to load scripts from file or to write/edit script using the editor in the ATS. • After additional action was added to the ATS, the user will be able to assemble TSC that contains this new action. • The user will be able to delete saved additional action.

  14. Functional Requirements (5) Executing TSC or Single Action • The ATS will check the state of the end-stations before executing the TSC/single action. • The user will be able to execute the TSC/single action on the selected end-stations. • The ATS will process the results and will act according to the results. • The user has the ability to view the state of each end-station at any step of the execution of the TSC.

  15. Functional Requirements (6) Generating Reports & Logs • The user will be able to get reports of the last execution or other executions that were saved on the database. • The ATS should log the results and other activities for debugging and monitoring the behavior of the system, moreover to overcome inconsistency in the database.

  16. Non-Functional Requirements (1) Speed, Capacity & Throughput • The ATS should be able to handle as much as possible end-stations. • The execution of TSC/single action should take at most as the timeout defined in the TSC/single action (the timeout defines the worst case). • Generating reports from the results will complete in less than 1 second. • All the GUI interactions, except actions that need communication, will complete in less than 1 second.

  17. Non-Functional Requirements (2) Reliability • The ATS will check the state of each end-station before executing TSC on them, and will notify the user if the state isn't appropriate to execute TSC. • The system relies on the end-stations while executing TSC, if one end-station fails on executing an action the Agent will inform the ATS about the failure. • The system will define timeout for each TSC. If an end-station disconnects during executing TSC, the system will detect it and send a message to the user.

  18. Non-Functional Requirements (3) Safety & Security • The system is an internal organization system. The data does not need to be encrypted. No cryptographic protocols will be used. Portability • The system will work on all of Microsoft Windows versions; the design will support extension to communicate and execute commands/actions on other operating systems in the future. • All the components in the system should be on the same LAN.

  19. Non-Functional Requirements (4) Usability • The system will be easy to use and the user will require several hours to learn how to operate the system. • The user will have to be familiar with the script languages being used in the system in order to create test descriptions via scripts.

  20. Major Use-Cases (1)

  21. Major Use-Cases (2)

  22. Major Use-Cases (3)

  23. Major Use-Cases (4)

  24. Major Use-Cases (5)

  25. Major Use-Cases (6)

  26. Major Use-Cases (7)

  27. Risks • Handling large number of end-stations, identifying and managing the results for each end-station.

  28. The End

More Related