Download as pdf or txt
Download as pdf or txt
You are on page 1of 15

System Testing

Document

Virtual Museum Explorer

By

Group - 10

Neel Mittal
15010142
Prashansi Kamdar
15010147
Suhas Kantekar
15010177
Table of Contents

1 Introduction 3
2 Scope 3
BLACK BOX TESTING
3 Testing Results 4
3.a Module 1 4
3.b Module 2 6
3.c Module 3 7
3.d Module 4 8
3.e Module 5 8
WHITE BOX TESTING 9
4 Control flow graphs 10
5 White box testing 13
6 Conclusion 13

2
INTRODUCTION
Black Box testing is the behavioral testing of the software system. The different test cases involving
some risks and prospective errors in the system were used to make a test suite and their test run results
are compiled in the document. (The different modules being tested were run and checked separately by
making sure other modules were working correctly.)
The white box testing is also compiled in the same document with control flow graphs and testing
results. White box testing is logical testing for the software system.

SCOPE
The following document deals with the behavioral and logical testing of the software system for a
Virtual Museum Explorer. The different modules have been thoroughly tested and the results have been
compiled. The modules during the testing phase which gave unexpected results have been changed and
the tests done and compiled are subject to the latest testing of the system.

3
Black Box Testing

TESTING RESULTS

MODULE 1 COLLIDER:

EQUIVALENCE CLASSES RELATED TO THE BOUNDARY_DOOR

Inputs: distance (moving object distance from boundary of door)


valid conditions: [5, INT_MAX) U (-INT_MAX, -5]
Invalid conditions: (-5, 5) {These conditions never arise, as object is stopped at distance 5 units
from boundary.}

Equivalence Test Class 1: Near door set = [5,6) U(-6,-5]

The table below shows the expected output and actual output shown by module for different
test cases in the test suite for the Equivalence test class 1, namely near door set.

S.No. Input Expected Output Output


1 -5 (boundary case) Door slides open As expected
2 +5 (boundary case) Door slides open As expected
3 -5.9 (boundary case) Door slides open As expected
4 +5.9 (boundary case) Door slides open As expected
5 -5.5 (non-boundary case) Door slides open As expected

4
Equivalence Test Class 2: Far Door Set = (-INT_MAX, -6] U [+6, INT_MAX]

The table below shows the expected output and actual output shown by module for different
test cases in the test suite for the Equivalence test class 2, namely far door set.

S.No. Input Expected Output Output


1 -6 (boundary case) Door doesn’t open As expected
2 +6 (boundary case) Door doesn’t open As expected
3 -9 (non-boundary case) Door doesn’t open As expected
4 +21 (non-boundary case) Door doesn’t open As expected

EQUIVALENCE CLASS RELATED TO BOUNDARY EXHIBITS


{This class has been defined because the expected outputs for both boundaries are different}

Inputs: distance (moving object distance from boundary)


valid conditions: [5, INT_MAX) U (-INT_MAX, -5]
Invalid conditions: (-5, 5) {These conditions never arise, as object is stopped at distance 5 units
from boundary.}

Equivalence Test Class 1: Near exhibit set = [5,6) U(-6,-5]

The table below shows the expected output and actual output shown by module for different
test cases in the test suite for the Equivalence test class 1, namely near exhibit set.

S.No. Input Expected Output Output


1 -5 (boundary case) Details are Displayed As expected
2 +5 (boundary case) Details are Displayed As expected
3 -5.9 (boundary case) Details are Displayed As expected
4 +5.9 (boundary case) Details are Displayed As expected
5 -5.5 (non-boundary case) Details are Displayed As expected

5
Equivalence Test Class 2: Far Exhibit Set = (-INT_MAX, -6] U [+6, INT_MAX]

The table below shows the expected output and actual output shown by module for different
test cases in the test suite for the Equivalence test class 2, namely far exhibit set.

S.No. Input Expected Output Output


1 -6 (boundary case) Details are not displayed As expected
2 +6 (boundary case) Details are not displayed As expected
3 -9 (non-boundary case) Details are not displayed As expected
4 +21 (non-boundary case) Details are not displayed As expected

The module sends a control signal to the details module to show details when a moving object
comes close to exhibit. It also sends the collider of the exhibit that was associated with it.

6
MODULE 2 DETAILS:

Input: (control signal from module collider, exhibit_collider)


Each object contains a plane that has the details associated with the exhibit.
Control signal: 1 implies that the moving object is near the exhibit and details need to be
dispalyed.

Valid input: (1, exhibit_collider) where k is in set {0,1}

Equivalence Class 1: show details set = (1, exhibit_collider)

The table below shows the expected output and actual output shown by module for different
test cases in the test suite for the Equivalence test class 1, namely show details set.

S.No. Input Expected Output Output


1 (1, Anubis collider) Details are displayed As expected
2 (1, Mona Lisa collider) Details are displayed As expected
3 (1, katana collider) Details are displayed As expected
4 (1,scream collider) Details are displayed As expected

Equivalence Class 2: no details set = (0, exhibit_collider)

The table below shows the expected output and actual output shown by module for different
test cases in the test suite for the Equivalence test class 2, namely no details set.

S.No. Input Expected Output Output


1 (0, Anubis collider) No output As expected
2 (0, Budhha collider) No output As expected
3 (0, Vishnu_collider) No output As expected

7
MODULE 3 INTERACTIVE CONTROLLER:

input: touch input (a,b)


a = {forward,backward,left,right, no_movement}
b = {rotate_left, rotate_right, no_rotation}

Equivalence class: No rotation

The table below shows the expected output and actual output shown by module for different
test cases in the test suite for the Equivalence test class 2, namely no details set.

S.No. Input Expected Output Output


1 (forward, no_rotation) Moves along y axis with current As expected
position as origin
2 (backward, no_rotation) Moves along -y axis with As expected
current position as origin
3 (left, no_rotation) Moves along -x axis with As expected
current position as origin
4 (right, no_rotation) Moves along x axis with current As expected
position as origin
5 (no movemnt, no_rotation) No movement shown As expected

8
Equivalence class: rotation

The table below shows the expected output and actual output shown by module for different
test cases in the test suite for the Equivalence test class 2, namely no details set.

S.No. Input Expected Output Output


1 (no_movement, rotate_left) Rotates left as long as this input As expected
is given
2 (forward, rotate_left) Rotates to left and moves along As expected
y axis with current position as
origin
3 (backward, rotate_left) Rotates to left and moves along As expected
-y axis with current position as
origin
4 (left, rotate_left) Rotates left and moves along -x As expected
axis with current position as
origin
5 (right, rotate_right) Rotates right and moves along x As expected
axis with current position as
origin

MODULE 3 INITIALISER

input: start of tour

expected output: player initilized at entry of museum


output: player initilaised at the entry of the museum(first section)

9
MODULE 4 MAIN MENU CONTROLLER

input: (a)
where a is in the set {automated tour, interactive tour, exit}

test case 1: (automated tour) automated tour is clicked


expected behavior: An automated tour of the museum starts
output behavior: An automated tour of the museum starts

test case 2: (interactive tour) interactive tour is clicked


expected behavior: An interactive tour of museum starts and movement controls are displayed
output behavior: same as expected behavior

test case 3: (exit) exit button is clicked


expected behavior: User exits the app
output behavior: app exited

10
WHITE BOX TESTING

The software contains scripts that are fully executed by most of the test cases used in the black
box testing suite. The same test cases can be used to do the white box testing of the system.
The Black box testing report, as it exhausts all logical test cases for software, is also taken as the
white box testing report and the different control flow graphs for the test cases are added.

The control flow diagrams for the different modules for test cases to exhaust the different
paths in the script are given in the document.

11
MODULE 1 COLLIDER

The control flow diagram below shows the paths present in the units for collider module.

Entry Door
closed

Boundary Boundary
_distance _distance
<6 >= 6

Open door/show
details

Exit

Fig : The above figure shows CFG for the Module Collider

12
MODULE 2 DETAILS

Entry

Inputs

Input = 1 Input = 0

Exhibit name Exhibit name

Details are shown

exit

13
MODULE 3INTERACTIVE CONTROLLER

Entry Inputs(direct
ion,
rotation)

left right Back


ward

For-
ward
Rotat Rotate
e left right

Moves
forrward
Moves
Moves right
left Moves
backwar
d
Rotates
left Rotates
right

Exit

14
Fig : the figure shows cfg for the Interface controller module

TESTING:
For different test cases for the white box testing and their outputs one can refer to the black
box testing results because our software’s logical test cases are exhausted by the test suite
created for black box testing. Different test cases have been run on the software and results are
compiled in the black box testing document which can be taken as it is for the results for the
white box testing of the software

CONCLUSION
Several issues came up during the initial rounds of testing which were then fixed. The tests
repeated to reach the final version of the Virtual Museum Explorer’s testing document. The
application works as intended and ready to be submitted to the client. All the related
documentation has been taken care of.

15

You might also like