Anda di halaman 1dari 7

Develop test cases for white box testing

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.

Example: topic name


I.

Flow Graph Notation

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.

Complete Full Path Coverage


1 = 1-2-3-5-6-8-9-11-12-17
2 = 1-2-3-5-6-8-9-13-14-15-17
3 = 1-2-3-5-6-8-9-11-13-14-16
4 = 1-2-3-5-6-8-10-11-17

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.

Independent Program Paths

McCabes Cyclomatic Complexity Metrics


As explained above McCabes theory was to find out how complex a system was and
how much testing would be sufficient in order to complete white box testing. McCabe
came up with a formula to distinguish the complexity, and this was done by
measuring the number of independent paths needed to achieve full line coverage. This
strategy would be based on taking the characteristics of the flow diagram and placing
this information into the formula. An example of this is shown below:
McCabes formulae:
V(G) = R
V (G) = E N + 2
V(G) = P + 1
R = The number of regions that is involved in the program flow graph. (Any enclosed
area including the outer layer of the flow diagram.)
E = The number of edges
N = The number of nodes
P = The number of decisions
I have now taken McCabes theory and have applied it to our Car Insurance Scenario:

Applying McCabes theories.


Red Circles indicate the regions within our car insurance example
The amount of arrows subtracted by the number of nodes
The diamond shapes are represented as P as they are decision entities.

Our Example
V(G) = 6
V(G) = 21 -17 + 2 = 6
V(G) = 5 + 1 = 6

Resulting metrics calculations indicate that the maximum number of independent


paths needed to achieve full line coverage is 6. To summarise Mccabes objective is
that programs with cyclomatic complexities of less then 5 are simple and easy to
understand, 20+ independent paths needed results in the complexity is perceived as
high and extreme testing would have to be performed. Also any program containing
50 and above the software for practical purposes becomes known unpractical maybe
even impossible.
III.
IV.

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

Advantages of White Box Testing


Introspection this gives the user or tester the opportunity to test internally which
allows a better perspective of objects and modules within the software. This is
effective when the Graphical user Interface is changing frequently.
Identification By going through each line the test is able to reveal what test cases
have been applied to what object and lists the number of lines that have not yet been
executed.
Effectiveness This type of testing gives the end user or the supplier the confidence
that every path has been tested to a certain extent, which should limit the amount of
bugs within an application. White box testing is the most effective testing as it the
most thorough when testing an individual application.
Disadvantages of White Box Testing
A skilled and trained tester will be needed to perform this type of testing. This type of
testing requires a certain level of skill, ensuring that every path and test case has been
examined at least once.
This type of testing is time consuming and may be very cost effective.
Also it has been said that it is nearly impossible to look into every bit of code within
the infrastructure to find all possible errors.

Anda mungkin juga menyukai