1.0 Introduction
3.0 The Typing Of Languages
The typing of languages can have a large bearing on the effect of the Boundary Value Analysis approach. Strongly typed languages such as PASCAL and ADA require that all constants or variables defined must have an associated data type, which dictates the data ranges of these values upon definition.
A large reason for languages like these to be created was to prevent the nature of errors that Boundary Value Analysis is used to discover. Although BVA is not completely ineffective when used in conjunction with languages of this nature, BVA can be seen as unsuitable for systems created using them.
Boundary Value Analysis is therefore more suitable to more “free-form” languages such as COBOL and FORTRAN which are not so strongly typed. These are also known as weak typing languages and can be seen as languages which allow one type (i.e. a String) to be seen as another (i.e. an Int). This can be useful but it can also cause bugs. These bugs or errors are normally found in the ranges that BVA operates in and therefore can find.
The practice of testing software has become one of the most important aspects of the process of software creation. When we are testing software the first and potentially most crucial step is to design test cases. There are many methods associated with test case design. This report will document the approach known as Boundary Value analysis (BVA).
As the incredibly influential Dijkstra stated “Testing can show the presence of bugs, but not the absence”. Although this is true we find that testing can be very good at the first, if implemented correctly. For this reason we need to know of the techniques available so we can find the correct method for the system under test (SUT).
We will look at the various topics associated with Boundary Value Analysis and use some simple examples to show their meaning and purpose. There will be some examples to show the usefulness of each method. There will be an ongoing “small scale” example to help picture each method. This will be accompanied by two examples introduced by P.C. Jorgensen [1]. These will be used to show some more “true to life” requirements for testing techniques. There will be a chapter detailing test cases for these two more indepth examples.
2.0 The Testing Problem
Developing effective and efficient testing techniques has been a major problem when creating test cases; this has been the point of discussion for many years. There are several well known techniques associated with creating test cases for a system.
There are many issues that can undermine the integrity of the result from and given test suite (set of tests) implementation. These issues or questions can be as basic as where do we start? They can become more complicated when we try to ascertain where testing should end and if we have covered all the required permutations.
The typing of languages can have a large bearing on the effect of the Boundary Value Analysis approach. Strongly typed languages such as PASCAL and ADA require that all constants or variables defined must have an associated data type, which dictates the data ranges of these values upon definition.
A large reason for languages like these to be created was to prevent the nature of errors that Boundary Value Analysis is used to discover. Although BVA is not completely ineffective when used in conjunction with languages of this nature, BVA can be seen as unsuitable for systems created using them.
Boundary Value Analysis is therefore more suitable to more “free-form” languages such as COBOL and FORTRAN which are not so strongly typed. These are also known as weak typing languages and can be seen as languages which allow one type (i.e. a String) to be seen as another (i.e. an Int). This can be useful but it can also cause bugs. These bugs or errors are normally found in the ranges that BVA operates in and therefore can find.
No comments:
Post a Comment