(back)
(Home)
| <<TESTING PHASE>> | |||
| << Various testing strategies involved >> | |||
| Unit Testing, Integration Testing, Validation Testing, System Testing | |||
| << Symbols representation used in the below testing section >> | |||
| Symbols | |||
<< Testing Carpark Security >> |
|||
|
<< Testing Carpark Management >> |
|||
|
* It is advised to look at the main flow of the system first before proceeding to the rest of the section in the carpark management option. *
|
|||
| Member | System User | Utility | Report |
| << Screen structure flow of program >> | |||
| Carpark Security option | Carpark Management option | ||
| << Summary of the system cyclometric complexity >> | |||
|
Summary of Carpark Management Main flow of system Member System user Utility Report
|
Summary of Carpark Security, Summary for Overall system |
||
|
Car park management application is a Client-Server based application, with Graphical User Interface (GUI) that handles all the main activities for car park management and car park security. The application also provides file maintenance for administrator of the system to maintain information on car park user, system user, and utility. This section presents the Unit Test Plans for the programs that have been developed in Car park management application.
|
|
Unit testing is an integral component of the software development life
cycle. It serves to verify that the program works as per the
specifications. The unit test plans are also necessary to perform unit
level regression testing when there are modifications made to the
programs.
|
|
The scope should include the testing of the following areas:
|
||||
|
The purpose of this test is to :
|
||||||
|
The test objectives are :
|
||||||||||
|
The symbols' representation is as follow:
- The circle in the figure represents that it will branch to another flowchart, in this case, it will branch to the member option flowchart.
|
-This indicate the start of the program in the flow chart.
-This indicate the end of the program in the flow chart.
- This represent the action to be executed upon the entry into it e.g.
print out a error message to screen
- The diamond shape represents a decision box with decision coming out
as shown above e.g. "yes" and "no" are the decision.
The inner of the shape contains what need to be decided e.g.
question to select member or don't select member option.
- The circle actually represents the starting of the flowchart as well
as it also indicates that the current flowchart came from other
flowchart.
| Module | Cyclomatic Complexity |
| Car in | 6 |
| Car out | 3 |
| Close | 1 |
| Total = 6+3+1 = 10 | |
| Module | Cyclomatic Complexity |
| Overall flow | 8 |
| Screen (normal user) | 5 |
| Screen (supervisor) | 7 |
| Total = 8+5+7 = 20 | |
| Module | Cyclomatic Complexity |
| Add | 3 |
| Delete | 2 |
| Edit | 3 |
| Replace Card number | 2 |
| Find by card no | 2 |
| Find by name | 4 |
| Find by NRIC | 2 |
| Find by plate number | 4 |
| Total = 3+2+3+2+2+4+2+4=22 | |
| Module | Cyclomatic Complexity |
| Main flow | 2 |
| Add new user | 4 |
| Search user | 9 |
| Total = 2+4+9=15 | |
| Module | Cyclomatic Complexity |
| Monitor Carpark status | 3 |
| Purge Parking lots record | 2 |
| Reset last card number | 5 |
| Total = 3+2+5=10 | |
| Module | Cyclomatic Complexity |
| General flow | 5 |
| Generate car status report using date | 3 |
| Generate car status report using date range | 3 |
| Generate car parking report using date range | 3 |
| Generate car parking report using date range and plate number | 3 |
| Total = 5+3+3+3+3=17 | |
| Module | Cyclomatic Complexity |
| Car park security | 10 |
| Main flow of system | 20 |
| Member | 22 |
| System user | 15 |
| Utility | 10 |
| Report | 17 |
| Total = 10+20+22+15+10+17=94 (relatively complex system) | |
The project is split into manageable modules under the 2 main categories namely the carpark security system and carpark management system. Flowcharts and test cases are created for the testing of each modules. We have actually applied white box testing for every module or component. Errors can be detected early and easily since individual module is tested independently. The integration of modules will be done when each module have been tested satisfactory.
|
|
|
|
In this stage, we have adopted the incremental approach to combine the
module. Although it may delay the testing phase, errors can be localized
rather than having hidden errors in some module which we will have hard
time finding and correcting.
We did it in the "sandwich fashion" such that supervisory modules like the maintenance module have to be integrated with the carpark management subsystem first before the lower level module can be added on. Concurrently, the lower modules like the generation of report module can integrated with the database platform first. Eventually, all modules will be integrated and tested again as a whole system. We find it easier to manage and it is more in a way more systematic and organized. |
|
|
|
In this stage, we actually came up with a initial prototype and allow
every member to go through the system so that all the functional
requirements are satisfied. Comments are taken and discussed. Further
refinements is made to conform to the actual user's demand.
Any deviation or error discovered are corrected and negotiations with the customer is also done to solve such deficiencies. |
|
|
|
In this stage, to prevent "finger pointing" incident, we
conduct the tests again on the whole system. Any potential problems or
bad simulation of data will be recorded and later reflected to the
individual in charge of the module.
We perform sensitivity testing on the system to uncover any hidden errors. For example, we try entering various combinations of data for a member record to fully test the capability of the system. In addition, duplication records is also tested to see whether the system is able to recognized the errors. Continuous testing and new test data is needed to get the system to be ready before it becomes operational. |