Documente Academic
Documente Profesional
Documente Cultură
White box testing uses the internal mechanism of a system to create test cases, which
uses calculated paths to discover unidentified bugs within the system. This type of
testing is trying to enforce the quality of the software system however white box
testing is a cost effective method and is compared very closely to Black box
testing. The main jobs of these two functions have the same purpose however it is
majorly debated which one is more efficient and effective. Black box testing
concentrates mainly on the outputs of the system to identify bugs however this
function waits till a malfunctioning error has occurred. As explained above White box
testing is used to ensure that the code is complete and to the correct standard of the
software mechanism. Statistics haves proven that by using a complete and precise
systematic test design, will ensure that the majority of bugs within the system will be
identified.
When looking at white box testing in more detail it involves checking and ensuring
that every program statement is error free. White box testing allows:
Data Processing
Calculation correctness tests
Software Qualification tests
Maintainability tests
Reusability tests
Data Processing and Calculation Correctness tests
Within the main two concepts of Calculation Correctness tests and Data processing,
when a test case has been created (path) it is then proceeded to be tested and verified
which will ensure the correctness of the software program. This procedure is done in
sequence for every test case created, this gives the user the opportunity to test whether
the code / program has been implemented correctly to the requirements /
specification.
Software Qualification tests
When going through the software qualification tests it looks directly to the software
code itself. This tests works with the coding standards and work instructions set by
the client or developer.
Maintainability tests
The maintainability tests installs special features to detect failures, module structures
that support software development, extensions and improvements of the software
system. The reusability tests is part of an example of this, as explained below:
Reusability tests
Reusability tests are performed on the package which examines all of the reused
software that had been implemented into the software package. Addition to this
function it also adapts to the program allowing the present code to be re-usable for
future preferences.
When looking at the White box testing in more detail and analysing its procedures it
becomes aware that when testing each test case / path maybe become unrealistic and
unfeasible. We have to take into account on the amount of coverage of all the possible
paths and the amount of code that is produced. There are two possible solutions for
this situation:
Line Coverage this is to test and cover over all of the program code and the
coverage is calculated by the percentage of lines covered.
Path Coverage this is to test and cover all the available paths in the system
and the coverage is calculated by the percentage of paths covered.
Correctness tests and Path coverage
Path testings main goal is to go through the system covering all possible paths, this is
tested with all condition such as IF-THEN-ELSE and DO WHILE statements. To take
white box into account it is very impractical due to the amount of resources needed
for this type of testing. Path testing is used from the start of a method to when it
finishes, each path shows the flow of execution. By looking at white box complete
path coverage will show how extreme this type of testing is:
Example:
There is a software package that contains five conditional statements which will only
for this example allow two procedures eg IF-THEN-ELSE, DO WHILE. When
following this type of code, it is expected that it will contain over 512 paths (25 50
lines of code), therefore at least 512 test cases should be performed ensuring each
path has been covered. Just by looking at this on example gives a good representation
of the type of testing performed. In addition to this we can see that by having 50
modules a calculation can be made which will result in proximally 61,000 test cases
needed in order to carry out this procedure.
This is very disproportionate testing however can be very beneficial as this type of
testing should outline a great proportion of errors and defects within the software
system. This complete path coverage will be tested on systems such as hospital related
machines, emergency services system and mostly to do with high risk software
systems. This will substitute the price of costing for the price of the risk of this system
failing, therefore allowing for this long procedure to be carried out.
Correctness Tests and Line Coverage
The line coverage requires a different process to path coverage as explained above.
There are different types of line coverage depending on the users requirements and
specification of the software system. One function will be to run a full complete line
coverage process which will consist of each line of code being compiled and executed
at least once. This will be shown as a percentage of the lines compiled during the
testing process. Line coverage may also perform a less efficient method test which
consists of testing fewer test cases which will make the system more vulnerable to to
bugs and system errors.
When talking about correctness tests, flow chart and a flow graph can be used to
enforce the understanding of line coverage within the correctness tests.
A diamond will represent: the options covered by a conditional statement
A rectangle will represent: software sections connecting the diamonds.
The arrows / edges will represent: The flow of direction.
A flow diagram to show how car insurance can be calculated based on the users
circumstances. This diagram involves:
A Car Insurance Company and calculating the users annual car insurance will involve:
If the users car is less then 10,000 or greater then,
Is the year of the car older then 5 years,
How old is the user,
Does the user have any previous driving experience,
Does the user have more then two years no claims bonus.
Less then
10,000
1
Car
Insurance
Greater then
10,000
2 Car
price
Older then
5 Years
Less Then 5
Years
5 Year of
Car
7
Younger then
25
Older then or
= 25
8 How old
are you?
9
Less then 1
Year
12
More then 1
year
11 Years
Experien
ce
13
None
17
Calculate Car
Insurance
10
15
14) >2+ no
claims
bonus
More then 2
years ncb
16
From this diagram is possible to come out with another of different unique paths.
Overall to achieve complete path coverage an estimated 24 test cases would have to
be performed due to their being 24 individual unique paths.
Examples of unique paths have been displayed below.
13 = 1-2-4-5-6-8-9-11-12-17
14 = 1-2-4-5-6-8-9-13-14-15-17
23 = 1-2-4-5-7-8-10-11-13-14-15-17
24 = 1-2-4-5-7-8-10-11-13-14-16-17
By looking at this scenario, if the entities and modules increased the amount of testing
to be performed on this would grow rapidly. The increase in modules would then lead
to a more complex system. A scientist called McCabe then come up with a theory to
determine how complex a software system was and how easy it was to interoperate
this type of software system.
II.
Our Example
V(G) = 6
V(G) = 21 -17 + 2 = 6
V(G) = 5 + 1 = 6
Prepare test cases that will force execution of each path in the basis
set.
Condition Testing
Condition testing is a test-case design method that exercises the logical conditions
contained in a program module. A simple condition is a Boolean variable or a
relational expression, possibly preceded with one NOT () operator. A relational
expression takes the form
E1 <relational-operator> E2
where E1 and E2 are arithmetic expressions and <relational-operator> is one of the
following: <,>,, (nonequality), =, or . A compound condition is composed of two
or more simple conditions, Boolean operators, and parentheses. We assume that
Boolean operators allowed in a compound condition include OR , AND (&), and NOT
(). A condition without relational expressions is referred to as a Boolean expression.
If a condition is incorrect, then at least one component of the condition is incorrect.
Therefore, types of errors in a condition include Boolean operator errors
incorrect/missing/extra Boolean operators), Boolean variable errors, Boolean
parenthesis errors, relational operator errors, and arithmetic expression errors. The
condition testing method focuses on testing each condition in the program to ensure
that it does not contain errors