5.2 Critical Fault Assumption
The Critical Fault Assumption also known as the single fault assumption in reliability theory. The assumption relies on the statistic that failures are only rarely the product of two or more simultaneous faults. Upon using this assumption we can reduce the required calculations dramatically.
The amount of test cases for our example as you can recall was 9. Upon inspection we find that the function f that computes the number of test cases for a given number of variables n can be shown as:
f = 4n + 1
As there are four extreme values this accounts for the 4n. The addition of the constant one constitutes for the instance where all variables assume their nominal value.
There are two approaches to generalising Boundary Value Analysis. We can do this by the number of variables or by the ranges these variables use. To generalise by the number of variables is relatively simple. This is the approach taken as shown by the general Boundary Value Analysis technique using the critical fault assumption.
Generalizing by ranges depends on the type of the variables. For example in the NextDate example proposed by P.C. Jorgensen [1], we have variable for the year, month and day. Languages similar to the likes of FORTRAN would normally encode the month’s variable so that January corresponded to 1 and February corresponded to 2 etc. Also it would be possible in some languages to declare an enumerated type {Jan, Feb, Mar,……, Dec}. Either way this type of declaration is relatively simple because the ranges have set values.
When we do not have explicit bounds on these variable ranges then we have to create our own. These are know as artificial bounds and can be illustrated via the use of the Tri-angle problem. The point raised by P.C. Jorgensen was that we can easily impose a lower bound on the length of an edge for the tri-angle as an edge with a negative length would be “silly”. The problem occurs when trying to decide upon an upper bound for the length of each length. We could use a certain set integer, we could allow the program to use the highest possible integer (normally denoted as something to the effect of MaxInt). The
arbitrary nature of this problem can lead to messy results or non concise test cases.
5.4 Limitations of BVA
Boundary Value Analysis works well when the Program Under Test (PUT) is a “function of several independent variables that represent bounded physical quantities” [1]. When these conditions are met BVA works well but when they are not we can find deficiencies in the results.
For example the NextDate problem, where Boundary Value Analysis would place an even testing regime equally over the range, tester’s intuition and common sense shows that we require more emphasis towards the end of February or on leap years.
The reason for this poor performance is that BVA cannot compensate or take into consideration the nature of a function or the dependencies between its variables. This lack of intuition or understanding for the variable nature means that BVA can be seen as quite rudimentary.
No comments:
Post a Comment