Summary of weekly activities: Week 4

For the testing phase of our program development, black box testing techniques were employed to uncover any errors in our program design/coding. Each module was tested for proper functionality using various testing techniques before they were integrated and tested again.

The following is a brief summary of what methodologies were employed.

Equivalence Partitioning

Equivalence partitioning aids in reducing the number of test cases by dividing the domain of input conditions into a number of equivalence classes. In such a case, we can then generate test cases by just using sample values from each equivalence class for verification of the whole class.

The valid carpark lot numbers in our program range from 1001 to 1400.

Hence the valid input range is 1001<=x<=1400

Testing with 3 chosen values(650,1111,1521) resulted in the following:

X=650 invalid

X=1111 valid

X=1521 invalid

The results confirmed the functionality of our module in this case.

Boundary Value Analysis

It has been observed that data from the edges or boundaries of ranges are more likely to generate errors than data from the middle of the range. Boundary value testing attempts to detect such errors by taking test values from just above/below and on the boundary and is generally used to test data structures such as arrays.

In this case we used it to test our parking lot system which has an array from lvlLots[0] to lvlLots[99] for each level.

The valid range is hence from 0 to 99.

We derived 6 test cases, [-1,100,0,99,1,98]

-1/100=>invalid input

0,99=>valid input

1,98=>valid input

This confirmed the that this particular module worked as expected.

Integration Testing

Different integration approaches:
Ø Big-Bang Approach
Ø Incremental Approach
Big-Bang Approach
After all components are unit tested, proceed abruptly to integration testing where all components are assembled at the same time. A primitive approach that is not very useful except for small and trivial system.

Ø Excessive use of test harness or scaffolding software
Ø No localization of error, thus debugging is much harder
Ø Concentrated usage of limited resources
Ø No flexibility in scheduling

Incremental Approach
Proceed with integration testing as soon as a reasonable amount of components are unit tested. Incremental approach consists of top-down, bottom-up and sandwich fashion. Approach is useful for large complex system that requires much planning and testing.

Ø Localize errors incrementally, thus enhancing debugging process
Ø Partial aggregation of components often constitute important subsystems that can have autonomy
i.e. successfully integrated subsystem can be delivered to customers according to a incremental delivery schedule
Ø Flexibility in scheduling as integration can begin before all components are unit tested

Intelligent carpark system integration approach
Approach chosen: Incremental approach, bottom-up fashion

Bottom-up Procedure:
1. Low-level modules tested in builds
2. Driver needed for each build
3. Interface between and within builds are tested
4. Combine builds moving upward in structure

Step 1: Low-level modules tested in builds
The low level modules are grouped into builds according to their functions. The associated components have been unit tested using black box testing. When sufficient components are tested they can be incrementally integrated. The two main functions of Figure 1 shown below are compute carpark rates and find path to carpark slot.

Step 2: Driver needed for each build
Driver modules are written to test each and every build. These driver are replaced one at a time, following "depth first" rule. Figure 2 below show how the CarparkRates build and the PathToCarparkSlots build replaces their drivers with working modules.

Step 3: Interface between and within builds are tested
The interface modules are to be tested at this stage. The ParkingSystem 1/2 are both tested and then integrated to work as the interface between the lower levels builds. Figure 3 below shows the integration of the interface modules.

Step 4: Combine builds moving upward in structure
Successive builds are made until the entire software system has been integrated. Actions to combine builds are repeated as we move up the hierarchy of our software design. Figure 4 below shows a simplified diagram of the final integration testing for the CarparkRates and PathToCarparkSlots builds.

Rationales behind choosing bottom-up Incremental Approach
The Incremental Approach is chosen as it allows us the flexibility of scheduling our work. When certain software components are being unit tested, integration testing may be proceeded with them first. Since there will be builds of modules that constitute to important subsystem that can have autonomy, there is no point in waiting for all components to be unit tested.

The bottom-up fashion has a main disadvantage of not having an operational skeleton of the software during early stages of integration testing. In this way, the hierarchical structure of the software cannot be assessed until later. However, in our lab project, we are not required to do integration testing for a system with great complexity. By choosing the bottom-up fashion of the Incremental Approach, it allows us the maximum efficiency and flexibility.