IJCEM International Journal of Computational Engineering & Management, Vol.

14, October 2011 57

ISSN (Online): 2230-7893
www.IJCEM.org

TESTABILITY OF SOFTWARE SYSTEM

Manu Phogat1, Dharmender Kumar2
1
Research Scholar,
DCRUST Murthal, Haryana, India.
[email protected]
2
Associate Professor, CSE Deptt,
DCRUST Murthal, Haryana, India.
[email protected]

Abstract
This paper investigates factors of the testability of object- Major Factors
oriented software systems. The starting point is given by a
study of the literature to obtain both an initial model of Testing Criterion. A major factor of the test effort picture
testability and existing OO metrics related to testability. is the degree of validity that the software is required to
The goal of this paper is to define and evaluate a set of have. Based on the validity requirements, a project uses a
metrics that can be used to assess the testability of the testing criterion (or code coverage criterion) that specifies
classes of an Object Oriented System. which parts of the software have to be tested. In effect, a
testing criterion will establish a lower bound on the
validity of the software, and an upper bound on the number
of test cases required. A project will thus have to make a
1. Introduction trade-off between the verification of validity on the one
hand, and the required amount of testing on the other.
What is it that makes code hard to test? Why is one class
easier to test than another? How can I tell that I‘m writing Documentation. There are many reasons why a software
a class that will be hard to test? What contributes to a system should be accompanied by documentation of
class‘ testability? How can quantify this notion? Software several kinds. With regards to testing, requirements and
testability is affected by many different factors, including specifications are of prime importance, capturing required
the required validity, the process and tools used, the and specified behavior, respectively. These documents
representation of the requirements, and so on — in the next should be correct and complete, and clear links should
section we will survey what has been written on this topic exist between the concepts captured in the various
so far. This paper investigates testability from the documents.
perspective of unit testing, where our units consist of the
classes of an object-oriented software system. Our Implementation. The implementation is the target of all
approach is to evaluate a set of object-oriented metrics testing, and thus the extent to which the implementation
with respect to their capabilities to predict the effort allows itself to be tested is a key factor of the testing effort.
needed for testing. We choose this approach because One important aspect of the implementation is
metrics are a good driver for the investigation of aspects of determinism; it should be possible to consistently repeat
software. The evaluation of metrics that are thought to tests. The major part of the implementation of an
have a bearing on the testing effort allows us, on the one application consists of source code expressed in one or
hand, to gain insight into the factors of testability, and to more programming languages. Factors of the source code
obtain refined metrics on the other. Both results can that relate to the testability of the implementation, and thus
subsequently be used in further studies. the testing effort, are the topic of this paper.

1.1 Testability Test Suite. Factors of the test suite itself also determine
the effort required to test. Desirable features of test suites
are correctness, automated execution and reuse of test
The ISO defines testability as ―attributes of software that
cases. Similar to the system-under-test, test suites need
bear on the effort needed to validate the software product‖
documentation detailing the implemented tests, a test plan,
[2]. Binder [1] offers an analysis of the various factors that
test results of previous test runs and reports.
contribute to a system‘s testability.

IJCEM
www.ijcem.org
IJCEM International Journal of Computational Engineering & Management, Vol. 14, October 2011 58
ISSN (Online): 2230-7893
www.IJCEM.org

Test Tools. which a component can be observed to generate the correct

The presence of appropriate test tools can alleviate many output for a given input. The notion of ‗controllability‘
problems that originate in other parts of the ‗fish bone‘ relates to the possibility of a component generating all
figure. For example, easy-to-use tools will demand less of values of its specified output domain. Adapting (the
the staff responsible for testing. Test case definition in the specification of) a component such that it becomes
presence of graphical user interfaces is another example observable and controllable can be done by introducing
where tooling can significantly reduce the required effort. extensions. Observable extensions add inputs to account
for previously implicit states in the component.
Process Capability. The organizational structure, staff and Controllable extensions modify the output domain such
resources supporting a certain activity are typically that all specified output values can be generated. Freedman
referred to collectively as a (business) process. Properties proposes to measure the number of bits required to
of the testing process obviously have great influence on the implement observable and controllable extensions to
effort required to perform testing. Important factors obtain an index of observability and controllability, and
include a commitment of the larger organization to support consequently a measure of testability.
testing, through funding, empowerment of those
responsible, and provision of capable staff. 3. Object-Oriented Technology:
2. Related Work A way to develop and package Software that draws heavily
from common experience and the manner in which real
world objects relate to each other.
A number of testability theories have been published in the
literature. Voas et. al. [4] defines software testability as the Object-Oriented Systems: All programming languages,
probability that a piece of software will fail on its next tools and methodologies that support Object-Oriented
execution during testing, provided it contains a fault. This Technology. The main properties of object-oriented
fault sensitivity is obtained by multiplying the probabilities technology are following:
that (1) the location containing the fault is executed; (2) the
 Objects
fault corrupts the program‘s state; and (3) the corrupted
 Classes
state gets propagated to the output. High fault sensitivity
 Data abstraction and encapsulation
indicates high testability and vice versa.
Voas and Miller [4] present a different approach to fault  Inheritance
sensitivity, in which semantic information contained in  Polymorphism
program specification and design documents is analyzed.  Dynamic binding
An upper-bound on a component‘s fault sensitivity is given
by the amount of information loss occurring within the
component. Information loss can appear in roughly two Benefits of object-oriented system:
guises: Explicit information loss occurs because the values The Advantage or benefits of object oriented system
of variables local to the component may not be visible at are following:
the system level, and thus cannot be inspected during
testing. Implicit information loss is a consequence of the  The use of objects as basic modules assists
domain/range ratio (DRR) of the component. The DRR of the designer to model complex real-world
a component is given by the ratio of the cardinality of the systems (Model Complexity).
input to the cardinality of the output.  The flexibility of object-oriented code
McGregor et. al. [5] attempt to determine the testability of allows a rapid response to changes in their
an object-oriented system. They introduce the ―visibility requirements.
component‖ measure (VC for short), which can be  The reuse of standard components reduces
regarded as an adapted version of the DRR measure. The both the development time for new
VC has been designed to be sensitive to object oriented applications and the volume of code
features such as inheritance, encapsulation, collaboration generated.
and exceptions. Furthermore, a major goal of the VC is the  The increased maintainability of software
capability to use it during the early phases of a makes it more reliable and reduces
development process. Calculation of the VC will thus maintenance costs.
require accurate and complete specification documents.  Improve Productivity
Freedman [6] proposes ―domain testability‖, based on the  Designed for change
notions of observability and controllability as adopted in
hardware testing. Observability captures the degree to

IJCEM
www.ijcem.org
IJCEM International Journal of Computational Engineering & Management, Vol. 14, October 2011 59
ISSN (Online): 2230-7893
www.IJCEM.org

4. Software Testability Measurement Boolean Predicates: A wrong variable/constant

substitution, wrong equality/ inequality operator
Generally speaking, software testability measurement substitution, or exchanging operator and with operator or.
refers to the activities and methods that study, analyze, and The basic idea of this approach is similar to software
measure software testability during a software product life mutation testing. To check software testability at a
cycle. In the past, there were a number of research efforts location, a single fault is instrumented into the program at
addressing software testability measurement. Their focus this location. The newly instrumented program is compiled
was on how to measure software testability at the and executed with an assumed input distribution. Then,
beginning of a software test phase. Once software is three basic techniques (execution, infection, and
implemented, it is necessary to make an assessment to propagation estimation methods) are used to compute the
decide which software components are likely to be more probability of failure that would occur when that location
difficult and time-consuming in testing due to their poor has a fault.
component testability. If such a measure could be applied
at the beginning of a software testing phase, much more 4.1.2 Model Based Testability Measurement
effective testing resources allocation and prioritizing could
be possible. Another measurement approach of software testability is
As we understand, the objective of software testing is to proposed based on a well-defined model: such as a data
confirm that the given software product meets the specified flow model [8]. This approach consists of three steps:
requirements by validating the function and nonfunctional
 Step #1: Normalizing a program before the
requirements to uncover as many program problems and
testability measurement using a systematic tool.
errors as possible during a software test process. Unlike
Normalizing a program can make the
software testing, the major objective of software testability
measurements of testability more precise and
measurement is to find out which software components are
reasonable. A program, after being normalized,
poor in quality, and where faults can hide from software
must have the same semantics as the original one.
testing.
This is done mechanically. Two types of
normalization are performed here. They are
4.1 Measurement of Software Testability structure normalization and block normalization.
In the structure normalization, the program‘s
In the past few years, a number of methods have been control flow structure is reconstructed to make it
proposed to measure and analyze the testability of software regular to facilitate analyzing and property
[7, 8-9]. They can be classified into the following groups: measuring.
 Program-based measurement methods for  Step #2: Identifying the testable elements of the
software testability [7]; targeted program based on its normalized data
 Model-based measurement methods for software flow model. The elements include the number of
testability [8,9]; non-comment lines, nodes, edges, p-uses, defs,
 Dependability assessment methods for software uses, d-u paths (pairs), and dominating paths.
testability [7].  Step #3: Measuring the program testability based
on data flow testing criteria. These data-flow
4.1.1Program Based Testability Measurement testing criteria include: ALL-NODES, ALL-
EDGES, ALL-P-USES, ALL-DEFS, ALL-
Since a fault can lie anywhere in a program, all places in USES, ALL-DU-PAIRS, and ALL-
the source code are taken into consideration while DOMINATING PATH.
estimating the program testability. J.-C. Lin et al. [8]
proposed a program-based method to measure software Though there is no correlation between the measurements
testability by considering the single faults in a program. and the number of faults, this approach can be used to
The faults are limited to single faults and are limited to check how easily software modules can be tested
faults of arithmetic expressions and predicates. C. Robach and Y. Le Traon [9] also used the data-flow
Arithmetic Expressions: Limited to single changes to a model to measure program testability. Unlike the previous
location. It is similar to mutations in mutation testing; approach, their method is developed for co-designed
Assignment Predicates: An incorrect variable/constant systems.
substitution, for example, a variable substituted incorrectly
for a constant, a constant substituted incorrectly for
variable, or a wrong operator

IJCEM
www.ijcem.org
IJCEM International Journal of Computational Engineering & Management, Vol. 14, October 2011 60
ISSN (Online): 2230-7893
www.IJCEM.org

4.1.3 Dependency Based Testability 3. All method overloading and over ridding allow.
Measurement 4. Not consider static method but treat public static
void main as a starting point.
5. Not consider abstract method.
Clearly, the two previous approaches need program source
code and/or a program-based model to support software The input, output and constant for the java class will
testability measurement. A. Bertolino and L. Strigni [7] be as follows
proposed a black-box approach, where the software
testability measurement is performed based on the Input:
dependency relationships between program inputs and 1. All parameter into the class.
outputs. The basic idea is to perform an oracle in a manual 2. Parameters pass into the method signature.
(or systematic) mode to decide whether a given program 3. All class method parameter of the parent class
behave correctly on a given test. The oracle decides the excluding system parameter.
test outcome by analyzing the behavior of the program 4. All method of interface implementation.
against its specification. In particular, an input/ output
(I/O) oracle only observes the input and the output of each Output:
test, and looks for failures. A program is correct with 1. The return value of the method
respect to its specification if it is correct on every input 2. Any exception either checked or unchecked by
setting; otherwise the program is faulty. If the program the method
generates an incorrect output, then the test has failed. If the 3. All implicit parameter & object attribute define in
oracle output is approved, then the test is successful. the class
4. Object reference in the method signature.

5. Goal Constant
In this paper working definition of testability is 1. Final
―Testability of a program is a degree of simplicity of the 2. Literal
program‖. In this work we are trying to understand the 3. Static final variable is also effectively used as a
simplicity in the form of complexity. Means if system‘s constant.
complexity is increase that means its simplicity decrease
and the effort of testing (Testability) will increase. 5.2 Complexity Measurement
Cyclomatic complexity is software metric (measurement).
5.1Testability Measurement
It was developed by Thomas J. McCabe [14] and is used to
Several techniques have been made for development of
measure the complexity of a program. It directly measures
meaningful testability [10, 11, and 12] but here we are
the number of linearly independent paths through a
using the testability measurement techniques of John
program's sourcecode. Cyclomatic complexity is computed
McGregor and S. Srinivas [13].They mentioned that
using the control flow graph of the program: the nodes of
Testability of a method into the class depends upon the
the graph correspond to the commands of a program, and a
visibility component. Testability of method is
directed edge connects two nodes if the second command
might be executed immediately after the first command.
TM=constant*(VC)
Testability of the class is
The cyclomatic complexity of a flow graph is as follows
θ=min (TM)
M = E − N + 2P
The definition of the visibility component (VC) is
Where
VC= Possible Input/Possible Output M = Cyclomatic complexity
E = Number of edges of the graph
Before doing implementation we are defining our input, N = Number of nodes of the graph
output and constant for testability analysis work and also P = Number of connected components.
taking some assumption for this work.

Assumption: Example:
1. Not consider system parameter 1. Vending Machine
2. Consider only concrete class. 1. public class VendingMachine

IJCEM
www.ijcem.org
IJCEM International Journal of Computational Engineering & Management, Vol. 14, October 2011 61
ISSN (Online): 2230-7893
www.IJCEM.org

2. { Step 2. Cyclometic Complexity

3. final private int COIN = 25;
4. final private int VALUE = 50;
5. private int totValue;
6. private int currValue; A
7. private Dispenser d;
8. public VendingMachine()
9. { B
10.totValue = 0;
11.currValue = 0;
12.d = new Dispenser(); C D
13.}
14. public void insert()
E
15. {
16. currValue += COIN;
17. System.out.println("Current value = " + currValue );
F
18. }
19. public void return()
20. {
21. if ( currValue == 0 )
22. System.err.println( "no coins to return" );
23. else Control graph of vending machine
24. {
The cyclomatic complexity of a control flow graph is as
25. System.out.println("Take your coins");
follows
26. currValue = 0;}
In control graph of vending machine the number of edges
27. } are 14 and number of nodes are 12, putting these values in
28. public void vend( int selection ) the formula we will get the cyclomatic complexity 4.
29. {
30. int expense; M = E − N + 2P
31. expense = d.dispense( currValue, selection );
32. totValue += expense; 6. Conclusion
33. currValue -= expense;
34. System.out.println( "Current value = " + currValue ); Software testability is an important factor during the
35. } software development life cycle. This paper gives the
36. } view that testability is the degree of the simplicity of the
program and it will increase as the complexity of the
Step 1. Testability Analysis program will increases and its complexity will depends on
whole software development life cycle. It also emphasis is
on the measurement of testability , its measuring technique
S. Method VC TM Class and related work of the testability and in last we presents
No Name (ζ) (ή) Testability
(θ)
our approach of measuring testability with using some
example.

1 Vending 3/3=1 2*1=2 After the study our conclusion is that testability is a quality
Machine factor that attempts to predict how much effort will be
() required for software testing and to estimate the difficulty
2 void 3/3=1 2*1=2 2 of causing a fault to result in a failure (called revealing the
insert() fault).
3 void 3/3=1 2*1=2
return() 7. References
4 void 4/4=1 2*1=2 1.R. Binder. Design for testability in object-oriented
vend()
systems. Comm. of the ACM, 37(9):87–101, 1994

IJCEM
www.ijcem.org
IJCEM International Journal of Computational Engineering & Management, Vol. 14, October 2011 62
ISSN (Online): 2230-7893
www.IJCEM.org

2. ISO. International standard ISO/IEC 9126. Information

technology: Software product evaluation: Quality
characteristics and guidelines for their use, 1991.
3. J. Voas. PIE: A dynamic failure-based technique. IEEE
Transactions on Software Engineering, 18(8):717–727,
August 1992.
4. J. Voas and K. Miller. Semantic metrics for software
testability. Journal of Systems and Software, 20:207–216,
March 1993.
5. J. McGregor and S. Srinivas. A measure of testing
effort. In Proceedings of the Conference on Object-
Oriented Technologies, pages 129–142. USENIX
Association, June 1996.
6. R. Freedman. Testability of software components. IEEE
Transactions on Software Engineering, 17(6):553–564,
June 1991.
7. Bertolino, A., and L. Strigini, ―On the Use of Testability
Measurement for Dependability Assessment,‖ IEEE Trans.
on Software Engineering, Vol. 22, No. 2, February 1996,
pp. 97–108.
8. Lin, J.-C., I. Ho, and S.-W. Lin, ―An Estimated Method
for Software Testability Measurement,‖ Proc. of 8th
International Workshop on Software Technology and
Engineering Practice (STEP ‘97), 1997.
9. Robach, C., and Y. Le Traon, ―Testability Analysis of
Co-Designed Systems,‖ Proc. of 4th Asian Test
Symposium (ATS‘95), 1995.
10. R. S. Freedman, ―Testability of Software
Components‖, IEEE Transactions on Software
Engineering, vol. 17, No. 6, June 1991, pp. 553-563.
11. J. Voas, PIE: A dynamic failure-based technique, IEEE
Transactions on Software Engineering 18 (8) (1992) 717–
727.
12. J. Voas, K. Miller, Software testability: The new
verification, IEEE Software 12 (1995) 17–28.
13. J. McGregor and S. Srinivas. A measure of testing
effort. In Proceedings of the Conference on Object-
Oriented Technologies, pages 129{142}. USENIX
Association, June 1996.
14. T.J.McCabe, ―A Complexity Measure‖, IEEE Tran.
Software Eng., vol. SE-2, No.4, Dec.1976, pp. 308-320.

IJCEM
www.ijcem.org