![[Main Page]](/themes/Go4ITv2/images/logo.gif){kind=logo}
This document describes the TM-UI section of the Go4IT Package2 General Design Document, wich is made of the following sections:
- General Design of the Compiler.
- General Design of the SA.
- General Design of the PA.
- General Design of the CH.
- General Design of the TM.
- General Design of the TM-UI: This document.
- General Design of the TL.
- General Design of the CD-Gen
- General Design of the CD
- General Design of the RIPng ATS.
Introduction
This document intends to provide a preliminary introduction to the design of the Test Management User Interface (hereafter, TM-UI) entity within a TTCN-3 test system. The TM-UI is the user interface of the whole system. All the interactions which need the information or command from test user are done in this module including starting up the test system, executing test suite, etc. So this project aims to provide a basic, command line interface with test user. TM-UI provides to test user three kinds of functions:
- First, test user can manage test system such as starting, quitting, configuration, etc.
- Second, test user can manage the execution of TE such as starting test case, controlling test case, starting test case control, etc.
- Third, visualizing test log for test user.
Use Cases
This section contains a set of use cases that describe the external behavior of the TM-UI module. A use case is a description of a specific interaction that a user (or another module) may have with this module. Use cases are deceptively simple tools for describing the functionality of the software.
A use case is a simple, straightforward tool that can be used to completely describe all of the behavior of a piece of software. It contains a textual description of all of the ways that the intended users could work with the software through its interface. Use cases do not describe any internal workings of the software, nor do they explain how that software will be implemented. They simply show how the steps that the user follows to use the software to do his work. All of the ways that the users interact with the software can be described in this manner.
This section will contain multiple use cases, enough to define all of the interactions the actors will have with the module. In the following figure is shown a general overview of defined use cases and relationships between the different actors which are:
- TM: TCI-TM interface includes all operations needed to manage test execution, provides module parameters and external constants and provides test event logging. This entity is responsible for overall management of the test system. After the test system has been initialized, test execution starts within TM entity. This entity is responsible for the proper invocation of TTCN-3 modules, i.e. propagating module parameters and/or PIXIT information to the TE, if necessary.
- TL: Test Logging
- Go4IT user
Use Cases: test system management
UC-1: Starting the test system
Summary
- Test user starts the test system using TM-UI
Rationale
- TM-UI is the user interface of all test system. All user operation must be made through TM-UI, including start up.
Actors
- Test user, TM
Preconditions
- None
Basic Course of Events
- Step1: Test user opens TM-UI
- Step2: TM-UI sends to TM a "start system" operation message
- Step3: TM finishes the starting process and returns all the corresponding information (No matter success or fail, all the corresponding information should be returned)
- Step4: TM-UI displays information about the result for test user.
Alternative Paths
- In Step4, if an error message is sent to TM-UI, TM-UI should quit after Step4.
Postconditions
- Start up done
UC-2: Configuring the system
Summary
- User makes some system configuration by TM-UI
Rationale
- TM-UI is the user interface of all test system. All user operation must be made through TM-UI, including configuration operations.
Actors
- Test user, TM
Preconditions
- UC-1 has been done.
Basic Course of Events
- Step1: Test user inputs configuration command
- Step2: TM-UI sends the command to TM
- Step3: TM finishes the work and returns all the corresponding information (No matter success or fail, all the corresponding information should be returned)
- Step4: TM-UI displays information about the result for test user
Alternative Paths
- None
Postconditions
- Configuration done
UC-3: Quitting the test system
Summary
- Test user quits the test system
Rationale
- TM-UI is the user interface of all test system. All user operation must be made through TM-UI, including quit.
Actors
- Test user, TM
Preconditions
- UC-1 has been done.
Basic Course of Events
- Step1: Test user inputs quit command
- Step2: TM-UI sends the quit command to TM
- Step3: TM finishes the work and returns all the corresponding information (No matter success or fail, all the corresponding information should be returned)
- Step4: TM-UI displays information about the result for test user
- Step5: TM-UI ends its own session
Alternative Paths
- In Step3, if some operation is running and test user sends a quit command that should cause running operations do not finish properly, a message should be sent to TM-UI and TM-UI should warning test user about the possible results and request test user to choose between quitting right now or waiting for a while. If test user chooses to quit right now, the next steps should be done. If test user chooses to wait; the quit process should be stopped.
Postconditions
- Quit TM-UI
UC-4: Getting the help information
Summary
- Using help command to give test user a simple help for all commands and their format
Rationale
- Test user needs a convenient help and reminder for all the commands.
Actors
- Test user
Preconditions
- UC-1 has been done.
Basic Course of Events
- Step1: Test user inputs help command and the topic about which the information is being requested.
- Step2: TM-UI displays help information for test user
Alternative Paths
- None
Postconditions
- Help information has been displayed.
Use Cases: Test case management
UC-5: Executing test case
Summary
- Test user launches the execution of one test case
Rationale
- TM-UI is the user interface of all test system. All user operation must be made through TM-UI, including the execution of test cases.
Actors
- Test user, TM
Preconditions
- UC-1 has been done.
Basic Course of Events
- Step1: Test user inputs execute command and the specified test case
- Step2: TM-UI sends the command to TM
- Step3: TM finishes the work and returns all the corresponding information (No matter success or fail, all the corresponding information should be returned)
- Step4: TM-UI displays information about the result for test user
Alternative Paths
- None
Postconditions
- Test case execution done
UC-6: Executing test campaign
Summary
- Execute some test campaign
Rationale
- TM-UI is the user interface of all test system. All user operation must be made through TM-UI, including the execution of test campaign
Actors
- Test user
Preconditions
- None
Basic Course of Events
- Step1: Test user inputs execute test campaign command and the specified test case
- Step2: TM-UI sends the command to TM
- Step3: TM finishes the work and returns all the corresponding information (No matter success or fail, all the corresponding information should be returned)
- Step4: TM-UI displays information for test user
Alternative Paths
- None
Postconditions
- Execution done
UC-7: Requesting runtime parameter
Summary
- TM requests TM-UI for any runtime parameters using
Rationale
- The execution of test cases needs some runtime parameters that has to be requested to the test user.
Actors
- Test user, TM
Preconditions
- UC-7 has been done.
Basic Course of Events
- Step1: TM sends the “need runtime parameter” command and corresponding information to TM-UI
- Step2: TM-UI displays the information to test user and requests the parameter.
- Step3: Test user inputs the needed information.
- Step4: TM-UI returns the input information to TM
Alternative Paths
- In Step3: Test user does not enter the requested parameter and decides to end the execution of the running test.
Postconditions
- The requested parameter has been returned to TM.
UC-8: Stopping the execution
Summary
- Test user stops the execution of a test.
Rationale
- Because of some reason, test user may want to stop the execution Eof running test.
Actors
- Test user, TM
Preconditions
- UC-6 has been done.
Basic Course of Events
- Step1: Test user inputs stop command
- Step2: The possible result such as uncompleted result should be warning to the test user, test user can choose between to go on or stop.
- Step3: If test user chooses to go on, TM-UI sends the command to TM
- Step4: TM finishes the work and returns all the corresponding information (No matter success or fail, all the corresponding information should be returned)
- Step5: TM-UI displays information for test user
Alternative Paths
- In Step3, if test user chooses to stop, the operation should be stopped.
Postconditions
- The running test has been stopped.
Use Cases: Test log management
UC-9: Browsing the list of log records
Summary
- Test user browses the list of log records.
Rationale
- Browsing all the log information,.
Actors
- Test user, TL
Preconditions
- None
Basic Course of Events
- Step1: Test user sends browsing command to TL in TM-UI
- Step2: TL creates a list of log records.
- Step3: TM-UI displays the list for test user
Alternative Paths
- None
Postconditions
- list done
UC-10: Displaying the detailed information of a log record
Summary
- Opens a log record for the test user to read the detailed information
Rationale
- Presents the detailed information to test user
Actors
- Test user, TL
Preconditions
- UC-1 is running
Basic Course of Events
- Step1: Test user inputs the reading command and the target log record in TM-UI
- Step2: TM-UI gives the command and target log record to TL
- Step3: TL opens the specific log record and gives the record’s reference to TM-UI
- Step4: TM-UI displays the record.
Alternative Paths
- None
Postconditions
- The detailed information of requested log record is displayed to the test user.
UC-11: Deleting log records
Summary
- Deletes the specified log records
Rationale
- Test user can delete the useless log records when the information is not needed
Actors
- Test user, TL
Preconditions
- UC-1 is running
Basic Course of Events
- Step1: Test user inputs the deleting command and the target log records in TM-UI
- Step2: TM-UI sends the command and target log records to TL
- Step3: TL deletes the specific log records.
- Step4: TL tells TM-UI the delete operation is done.
- Step5: TM-UI displays the corresponding information
Alternative Paths
- User can delete a record or a batch of records
Postconditions
- Deleting done.
UC-12: Export the detail of log records
Summary
- Export log records’ detailed information
Rationale
- Export log records’ detailed information
Actors
- Test user, TL
Preconditions
- UC-1 is running
Basic Course of Events
- Step1: Test user inputs the exporting command and the target log records in TM-UI
- Step2: TM-UI sends the command, target log records and the parameters of the process (such as format, file name, folder, etc.) to TL
- Step3: TL exports the specific log records.
- Step4: TL tells TM-UI the export operation is done
- Step5: TM-UI display the corresponding information
Alternative Paths
- User can export a record or a batch of records
Postconditions
- Exporting done.
UC-13: Printing log records
Summary
- Print log records detailed information
Rationale
- Test user can print the log records (list or detail)
Actors
- Test user, TL
Preconditions
- UC1 is running
Basic Course of Events
- Step1: Test user inputs the print log command and the target log records in TM-UI
- Step2: TM-UI sends the command and target log records to TL
- Step3: TL prints the specific log records.
- Step4: TL tells TM-UI the print operation is done.
- Step5: TM-UI displays the corresponding information
Alternative Paths
- User can print a record or a batch of records
Postconditions
- Printing done.
UC-14: Searching for a list of wanted log records
Summary
- Searching records
Rationale
- Searching records
Actors
- Test user
Preconditions
- UC-1 is running
Basic Course of Events
- Step1: Test user tells TL to search and the corresponding condition in TM-UI
- Step2: TL execute the searching process and get a batch of records
- Step3: TL return the result records list to TM-UI
- Step4: TM-UI display the records
Alternative Paths
- In step4, if TL can't find corresponding log record, return warning information to TM-UI
Postconditions
- Search done and the list is showing
UC-15: Configure the log system
Summary
- Make some system configuration by TM-UI
Rationale
- TM-UI is the user interface of all test system, the user operation must through TM-UI including configuration.
Actors
- Test user, TL
Preconditions
- UC-1 has been done.
Basic Course of Events
- Step1: Test user input configuration TL command (where are they described? Can you give an example that could illustrate the command language and also the configuration purpose?)
- Step2: TM-UI gives the command to TL
- Step3: TL return one list of option
- Step4: TM-UI display the information and waiting test user make decision
- Step5: TM-UI inform TL the user response
- Step3: TL finish the work and return all the corresponding information
- Step4: TM-UI display information for test user
Alternative Paths
- None
Postconditions
- configuration done
Functional Requirements
FR-1: Input area
Summary
- Accept test user's input command
Rationale
- Test user needs an interface to input what he/she wants test system to do
Requirements
- After the system start, one input area should be displayed and waits for test user to input command. For example, after a prompt such as ">"
References
FR-2: Classify
Summary
- Classify all the command to three kinds. 1. The commands need TM to deal with. 2. The commands need TL to deal with. 3. The commands which TM-UI can deal with by itself. Just "help" command is belong to this kind by now.
Rationale
- Different commands need different module to deal with
Requirements
- All the classified command will be list in the classify module, the input command need to be checked whether is one of them and which kind is it belonged to.
References
FR-3: Translate
Summary
- Translate incoming command from test user to TTCN-3 standard form and vice versa.
Rationale
- Some TTCN-3 standard function will be used in the internal of test system, but they maybe can't be understood by test user easily. The transform module get rid of this problem
Requirements
- A list of corresponding two kind of command is given to transform the command
References
FR-4: Internal interface
Summary
- The interface between TM and TM-UI or TL
Rationale
- TM-UI and TM(TL) need a interface to communicate the command and the return result
Requirements
- A callback function or a Interface will be given to complete this function
References
FR-5: Help
Summary
- Maintain the help information
Rationale
- There are a lot of commands in the test system. The list of all command and a brief instruction is necessary as well as the full version of help file
Requirements
- A list of corresponding command and instruction is given to do the job
References
FR-6: Display
Summary
- Displays the information which needs to be shown to test user
Rationale
- Only displayed information can be gated by test user
Requirements
- Shows the information which needs to be displayed at the monitor or other redirect terminal such as a txt file or a external program
References
Nonfunctional Requirements
NF-1: Performance constraints for starting
Summary
- The interval between user clicks or enters command to open TM-UI and the TM-UI finish the initial work and allow user to operate must be short
Rationale
- If starting is not fast enough, users will avoid using the software.
Requirements
- The starting operation must take under 100ms on a 700mhz Pentium III running Linux kernel 2.6 at 50% CPU load.
References
NF-2: Performance constraints for quitting
Summary
- The interval between user enters command to quit TM-UI and the TM-UI finish the finishing work and end TM-UI session must be short
Rationale
- If quitting is not fast enough, users will avoid using the software.
Requirements
- The quitting operation must take under 100ms on a 700mhz Pentium III running Linux kernel 2.6 at 50% CPU load.
References
NF-3: Performance constraints for execution
Summary
- The interval between user enter a operation and the first return information must be short
Rationale
- If execution is not fast enough, users will avoid using the software.
Requirements
- The execution operation must take under 100ms on a 700mhz Pentium III running Linux kernel 2.6 at 50% CPU load.
References
NF-4: Performance constraints for displaying
Summary
- The displaying must perform quickly
Rationale
- If displaying not fast enough, users will avoid using the software.
Requirements
- The displaying operation must take under 100ms on a 700mhz Pentium III running Linux kernel 2.6 at 50% CPU load.
References