Improve Your Technology

Just another blog for techology

Software Testing

Software Testing


1. Software Testing Techniques:


Once source code has been generated, software must be tested to uncover as many as possible before delivery to your customer. Your goal is to design a series of test cases that have a high likelihood of finding errors. Software is tested in two different perspectives:

(1) Internal program logic is exercised using “white box” test case design techniques and

(2) Software requirements are exercised using “black box” test case design techniques.

In both test cases the intent is to find maximum number of errors with minimum amount of effort and time


1.1. Testing Objectives


  1. Testing is a process of executing a program with the intent of finding an error.
  2. A good test case is one that has a high probability of finding an as yet undiscovered error.
  3. a successful test is one that uncover an as yet discovered error


These objectives imply a dramatic change in viewpoint. They move counter to the commonly held view that a successful test is one in which no error are found. Our objective is to design tests that systematically uncover different classes of errors and to do so with minimum amount of time and effort.


1.2 Testing Principles


ü       All tests should be traceable to customer requirements.

ü       Tests should be planned long before testing begins.

ü       The Pareto principle applies to software testing.

Pareto principle implies that 80 percent of all errors uncovered during testing will likely be traceable to 20 percent of all program components.

ü       Testing should begin “in the small” and progress toward testing “in the large”.

ü       Exhaustive testing is not possible.

ü       To be most effective, testing should be conducted by an independent third party.


1.3. Testability


Software testability is simply how easily can be tested. Testing is so profoundly difficult, it pays to know what can be done streamline it. Testability used to mean how adequately a particular set of tests will cover the product. It’s also used by military to mean how easily a tool can be checked and repaired in the field. These two meanings are not the same as software testability.

ü       Operability. “The better it works, the more effectively it can be tested.”

ü       Observability. “What you see is what you test.”

ü       Controllability. “The better we can control the software, the more the testing can be automated and optimized.”

ü       Decomposability. “By controlling the scope of testing, we can more quickly isolate problems and perform smarter retesting.”

ü       Simplicity. “The less there is to test, the more quickly we can test it.”

ü       Stability. “The fewer the changes, the fewer the disruptions to testing.”

ü       Understandability. “The more information we have, the smarter we will test.”


Attributes of a “Good” test:

1.       A good test has a high probability of finding an error: To achieve this goal, the .tester must understand the software and attempt and attempt to develop a mental picture of how the software might fail. Ideally, the classes of failure are probed.

2.       A good test is not redundant. Testing time and resources are limited. There is no point conducting a test that has the same purpose as another test. Every test should have a different purpose.

3.       A good test should be “best of breed”.

4.       A good test should be neither too simple nor too complex.


2. Test case design:


A rich variety of test case design methods have evolved for software. These methods provide the developer with a systematic approach to testing. (1) Knowing the specified that demonstrate each function; (2) knowing the internal workings of a product, tests can be conducted to ensure that “all gears mesh”, that is, internal operations are performed according to specifications and all internal components have been adequately exercised. The first approached is called black-box testing and the second, white-box testing. When computer software is considered. Black-box testing alludes to tests that are conducted at the software interface. White-box testing of software is predicted on close examination of procedural detail.


3. White-box testing:


White-box testing also called as glass-box testing, is a test case design method that uses the control structure of the procedural design to derive test cases.

(1)     Guarantee that all independent paths within a module have been exercised at least once,

(2)     exercise all logical decisions on their true and false sides,

(3)     Execute all loops at their boundaries and with in their operational bounds, and

(4)     Exercise internal data structures to ensure their validity.


Why don’t we spend all our energy on black-box tests? The answer lies in the nature of software defects

ü       Logic errors and incorrect assumptions are inversely proportional to the probability that a program path will be executed.

ü       We often believe that a logical path is not likely to be executed when, in fact, it may be executed on regular basis.

ü       Typographical errors are random.


3.1. Basis Graph Notation


Basis path testing is white-box testing technique. The basis path method enables the test case designer to derive a logical complexity measure of a procedural design and use this measure as a guide for defining a basis set of execution paths.

3.1.1.         Flow Graph Notation: A simple notation for the representation of control flow is called a flow graph notation. The flow graph depicts logical control flow. We use a flow graph to consider the procedural design representation.

3.1.2.         Cyclomatic Complexity: Cyclomatic complexity is software metric that provides a quantitative measure of the logical complexity of a program. It defines the number if independent paths in the basis set of a program and provides us with an upper bound for the number of tests that must be conducted to ensure that all statements have been executed at least once.  An independent path is any path through the program that introduces at least one new set of processing statements or a new condition.

3.1.3.         Graph Matrices: to develop a software tool that assists in basis path testing, a data structure, called a graph matrix. A graph matrix is a square matrix whose size is equal to the number of nodes on the flow graph. Each row and column corresponds to an identified node, and matrix entries correspond to connections between nodes.


3.2. Control Structure Testing

3.2.1.         Condition Testing: Conditional testing is a case design method that exercises the logical conditions contained in a program module. A compound condition is composed of two or more simple conditions. A condition without relational expressions is referred to as a Boolean expression.

The purpose of condition testing is to detect not only errors in the conditions of a program but also other errors in the program.


Brach testing is probably the simplest condition testing strategy.

Domain testing requires three or four tests to be derived for a relations expression.

A condition testing strategy that builds on the techniques just outlined, called BRO (branch and relational operator) testing, the technique guarantees the detection of branch and relational operators in the condition occurs only once and has no common variables.


3.2.2.         Data Flow Testing: Data flow testing methods selects test paths of a program according to the locations of definitions and uses of variables in the program.


3.2.3.         Loop Testing: Loops are the cornerstone for the vast majority of all algorithms implemented in software. It focuses exclusively on the validity of loop constructs.


4. Black-Box Testing


Black-box testing also called behavioral testing, focus on the functional requirements of the software. This test testing enables the software engineer to derive sets of input conditions that will fully exercise all functional requirements for a program. It tends to be applied later stages of testing, because black-box testing purposely disregards structure, attention is focused on the information domain.


4.1.              Graph-Based Testing Methods: 


Graph – a collection of nodes that represent objects; links that represent the relationships between objects; node weight that describe some characteristic of link. A direct link indicates that a relationship moves in only one direction. A bidirectional link, also called a symmetric link, implies that the relationship applies in both directions. Parallel links are used when a number of different relationships are established between graph nodes.


The transitivity of sequential relationships is studied to determine how the impact of relationships propagates across objects defined in a graph. The symmetry of relationship is also important guide to the design of test cases. If a link is indeed bidirectional, it’s important to test this feature.


4.2.              Equivalence Partitioning:

An equivalence class represents a set of valid or invalid states for input conditions. Below are some examples

ü       If an input condition specifies a range, one valid and two invalid equivalence classes are defined.

ü       If an input condition requires a specific value, one valid and two invalid equivalence classes are defined.

ü       If an input condition specifies a member of a set, one valid and one invalid equivalence classes are defined.

ü       If an input condition is Boolean, one valid and one invalid class are defined.


4.3.              Boundary Value Analysis


Boundary value analysis has been developed as a testing technique. It is a test case design technique that complements equivalence partitioning. For e.g. if internal program data structures have prescribed boundaries, be certain to design a test case to exercise the data structure at its boundary.


4.4.              Comparison Testing


There are some situations in which the reliability of software is absolutely critical. In such applications redundant hardware and software are often used to minimize the possibility of error. When redundant software is developed, separate software engineering teams develop independent version of an application using the same specification. In such situations each version can be tested with the same test data to ensure that all provided identical output. These independent versions form the basis of black-box testing technique called comparison testing or back-t-back testing.



August 22, 2008 - Posted by | Software Engineer, Testing |

No comments yet.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: