6.2.1.2 White Box
Testing
Also known as glass box, structural, clear box and open box
testing.
It is a software testing technique whereby explicit knowledge
of the internal workings of the item being tested is used to select the test
data.
Unlike black box testing, white box testing uses specific
knowledge of programming code to examine outputs. The test is accurate only if
the tester knows what the program is supposed to do. He or she can then see if
the program diverges from its intended goal.
White box testing does not account for errors caused by
omission, and all visible code must also be readable.
6.2.2 The Testing
Process
The most widely used testing process consists of 5 stages:
i) Unit testing
ii) Module testing
iii) Sub-system testing
iv) System testing
v) Acceptance (alpha) testing.
i) Unit Testing
Unit testing is where individual components are tested
independently to ensure they operate correctly.
ii) Module Testing
A module is a collection of dependent components e.g. an
object class, an abstract data type or collection of procedures and functions.
Module testing is where related components (modules) are tested without other
system modules.
iii) Sub-System Testing
Sub-systems are integrated to make up a system. Sub-system
testing aims at finding errors of unanticipated interactions between
sub-systems and system components. Sub-system testing also aims at validating
that the system meets the functional and non-functional components.
iv) Acceptance Testing (Alpha Testing)
Acceptance testing is also known as alpha testing or last
testing.
In this case the system is tested with real data (from client)
and not simulated test data.
Acceptance testing:
Ø Reveals errors and omissions in systems requirements
definition.
Ø Test whether the system meets the users' needs or if
the system performance is acceptable.
Acceptance testing is carried out till users /clients agree
it's an acceptable implementation of the system.
NB: Beta Testing
Beta testing approach is used for software to be marketed. It
involves delivering it to a number of potential customers who agree to use it
and report problems to the developers. After this feedback, it is modified and
released again for another beta testing or general use.
6.2.2.1 Test Data
|
Test
|
Action
|
Expected
|
Result
|
|
Login Test
|
User attempts to login.
|
The user should be redirected to the Admin page after a
successful login attempt
|
Login successful and the user redirected to the Admin Page.
|
|
Security Test
|
User browses the website pages.
|
A user should be able to view only the pages that he/she is
authorized to view.
|
User has access to authorized pages and denied access to
unauthorized pages.
|
|
Information
Management Test
|
Admin performs CRUD database operations.
|
The admin should be able to perform the CRUD database
operations.
|
Records successfully viewed, updated and deleted.
|
|
File problem
|
File detail to the database containing problem details
|
The user should be able to send the records of the parcel from
the database.
|
Data successfully added.
|
|
Logout test
|
User tries to logout of the system.
|
A user should be able to successfully logout.
|
User successfully logs out of the system.
|
|
Ping
|
Technician ping the device before telnet
|
Technician knows the IP address of the device
|
Device respond ping
|
|
telnet
|
Technician tries to login to remote device
|
Technician should be able to access the device by providing
correct credential
|
Successful login
|
|
DHCP
|
Students and lectures try to get IP address automatically once
connect cable or access Wi-Fi
|
User are supposed to get IP address and access his VLANS
|
Automatic get IP address
|
|
Access routers and switches
|
Technician tries to access a device
|
Provide correct password
For global, privilege and configuration mode
|
Access authorized
|
| 
