S.E.assignment Testing Techniques

6
SOFTWARE TESTING FUNDAMMENTALS Testing presents an interesting anomaly for the software engineer. During earlier software engineering activities, the engineer attempts to build software from an abstract concept to a tangible product. Now comes testing. The engineer creates a series of test cases that are indented to “demolish” the software that has been built. In fact testing is the one step in the software process that could be viewed as destructive rather than constructive. Testing requires that the developer discard preconceived notions of the “correctness” of software just developed and overcome a conflict of interest that occurs when errors are uncovered. TESTING OBJECTVES Testing is a process of executing a program with the intent of finding an error. A good test case is one that has probability of finding an as yet undiscovered error. A successful test is one that uncovers as-yet undiscovered error. Data collected as testing is conducted provide a good indication of software reliability and some indication of software reliability & some indication of software quality as a whole. But testing cannot show the absence of errors & defects, it can show only that software errors and defects are present. It is important to keep this statement in mind as testing is being conducted. TESTING PRINCIPLES Tests should be traceable to customer requirements. As the objective of software testing is to uncover errors, most severe defects are those that cause the program to fail to meet its requirements. Tests should be planned before testing begins. They can be planned as soon as the requirements model is complete. The Pareto principle is applied t software testing, which implies that 80% of all errors uncovered during testing will likely be traceable to 20% of all program components. Testing should be such that it starts “in the small” and proceeds to testing “in the large”. It means that the first tests planned and executed should focus in individual components, while, as testing proceeds, focus should shift to find errors in integrated clusters of components and finally is the whole system. Exclusive testing is not possible. Since the number of path permutations for even an averagely sized program is exceptionally large, it is impossible to adequately cover  program logic and to ensure that all procedural design condition has been exercised.

Transcript of S.E.assignment Testing Techniques

8/8/2019 S.E.assignment Testing Techniques

http://slidepdf.com/reader/full/seassignment-testing-techniques 1/6

SOFTWARE TESTING FUNDAMMENTALS

Testing presents an interesting anomaly for the software engineer. During earlier software

engineering activities, the engineer attempts to build software from an abstract concept to

a tangible product. Now comes testing. The engineer creates a series of test cases that are

indented to “demolish” the software that has been built. In fact testing is the one step inthe software process that could be viewed as destructive rather than constructive.

Testing requires that the developer discard preconceived notions of the “correctness” of software just developed and overcome a conflict of interest that occurs when errors are

uncovered.

TESTING OBJECTVES

• Testing is a process of executing a program with the intent of finding an error.

• A good test case is one that has probability of finding an as yet undiscovered

error.• A successful test is one that uncovers as-yet undiscovered error.

Data collected as testing is conducted provide a good indication of software reliability

and some indication of software reliability & some indication of software quality as awhole. But testing cannot show the absence of errors & defects, it can show only that

software errors and defects are present. It is important to keep this statement in mind

as testing is being conducted.

TESTING PRINCIPLES

• Tests should be traceable to customer requirements. As the objective of software

testing is to uncover errors, most severe defects are those that cause the program to

fail to meet its requirements.

• Tests should be planned before testing begins. They can be planned as soon as the

requirements model is complete.

• The Pareto principle is applied t software testing, which implies that 80% of all errors

uncovered during testing will likely be traceable to 20% of all program components.

• Testing should be such that it starts “in the small” and proceeds to testing “in thelarge”. It means that the first tests planned and executed should focus in individual

components, while, as testing proceeds, focus should shift to find errors in integratedclusters of components and finally is the whole system.

• Exclusive testing is not possible. Since the number of path permutations for even an

averagely sized program is exceptionally large, it is impossible to adequately cover 

 program logic and to ensure that all procedural design condition has been exercised.

8/8/2019 S.E.assignment Testing Techniques

http://slidepdf.com/reader/full/seassignment-testing-techniques 2/6

TESTABILITY

Software testability is simply hoe easily (a computer program) can be tested. Since

testing is so profoundly difficult, it pays to know what can be done to streamline it.Sometimes programmers are willing to do things that will help the testing process and a

checklist of possible design points, features etc can be useful in negotiating with them.

Sometimes, testability is used to mean how adequately a particular set of tests will cover that product.

Characteristics that leads to testable software are:

1. Operability:

“The better it works, the more efficiently it can be tested”.

2. Observability:

“What you see is what you test.”

3. Controllability:

“The better we can control the software, the more the testing can be automated andoptimized.”

4. Decomposability:

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

5. Simplicity:

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

6. Stability:

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

7. Understandabilty:

“The more information we have. The smarter we will test.”

Attributes to be a good test:

• A good test has a high probability of finding error. To achieve this goal, the tester 

must understand the software and attempt to develop a mental picture of how thesoftware might fail.

• A good test is not redundant. Testing time and resources are limited. There is no

 point in conducting a test that has the same purpose as another test.

A good test should be “best of breed.” In a group of test that have a similar intent,time & resource limitations may mitigate toward the execution of only a subset of 

these tests. In such case, the test that has highest likelihood of uncovering a

whole class of errors should be used.

• A good test should be neither too simple nor to complex. Although it is possible

to combine a series of tests into one test case, the possible side effects associated

with this approach may mask errors. In general each test should be executedseparately.

8/8/2019 S.E.assignment Testing Techniques

http://slidepdf.com/reader/full/seassignment-testing-techniques 3/6

White box testing  It is also known as glass box testing. It is a test case design method that usesthe control structure of the procedural design to derive test cases.

It is used to derive following test cases:

1. Guarantee that all independent paths within modules have been exercised atleast

once.2. Exercise all logical decisions on their true false sides.

3. Execute all loops at their boundaries and within their operational bounds.4. Exercise internal data structure to ensure their validity.

Why to use White – Box Testing?

• 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, itmay be regularly executed.

Typographical errors are random and hence difficult to debug.

Basis Path Testing 

Basis path testing is a white box testing technique. The basis method enables the test case

designer to derive a logical complexity measure of a procedural design and use this

measure as guide for defining a basis set of execution paths. Test cases derived toexercise the basis set are guaranteed to execute every statement in the program at least

one time during testing.

It is one of a number of techniques for control structure testing. Although it is simple and

highly effective, it is not sufficient in itself. Thus various other testing techniques were

developed.

Control Structure Testing 

This a testing technique used for deriving test cases related to the control structures. In

this testing technique the test cases are designed to test each path of the control structures

such as:

• Condition Testing

• Data Flow Testing

• Loop Testing, etc.

Black – Box Testing 

Black–box testing, also called behavioral testing, focuses on the functional requirementsof the software. It is not an alternative to white-box techniques but is a complementary

approach to it which is used to uncover a different class of errors than white–box

methods.

8/8/2019 S.E.assignment Testing Techniques

http://slidepdf.com/reader/full/seassignment-testing-techniques 4/6

Types of Errors Detected By Black Box Testing:1. Incorrect or missing functions.2. Interface errors.

3. Errors in data structures or external data base access.

4. Behavior or performance errors.

5. Initialization and termination errors.

Why is Black-Box testing used?

• To derive test cases that reduce the number of additional test cases that must

 be designed to achieve reasonable testing.

• To derive test cases that tell us something about the presence or absence of 

classes of errors, rather than an error associated only with the specific test at

hand.

Testing Methods Used In Black-Box Techniques: Graph-Based Testing Methods

Equivalence Partitioning

Boundary Value Analysis

Comparison Testing

These methods could be explained as under:

1. Graph-Based Testing Techniques:

The first step in black-box testing is to understand the objects that are

modeled in software and the relationships that connect these objects. Stated in

another way, software testing begins by creating a graph of important objects andtheir relationships and then devising a series of tests that will cover the graph sothat object and relationship is exercised and errors are uncovered.

To accomplish these steps the software engineer begins by creating a graph

which represents the following:

A collection of nodes that represents objects.

Links that represent the relationship between objects.

 Node weights that describe the properties of a node

Link weights that describe some characteristics of a link.

8/8/2019 S.E.assignment Testing Techniques

http://slidepdf.com/reader/full/seassignment-testing-techniques 5/6

2. Equivalence Partitioning:

Equivalence partitioning is a black-box testing method that divides the input

domain of a program into classes of data from which test cases can be derived. An

ideal test case single-handedly uncovers a class of errors that might otherwise requiremany cases to be executed before the general error is observed. Equivalence

 partitioning strives to define a test case that uncovers classes of errors, thereby

reducing the total number of test cases that must be developed.

An equivalence class represents a set of valid or invalid states for inputconditions. Typically, an input condition is a specific numeric value, a range of 

values, a set of related values, or a Boolean condition. Equivalence classes may be

defined according to the following guidelines:

OBJECT

#1

OBJECT

#2 

OBJEC

T#1

OBJECT

#3

8/8/2019 S.E.assignment Testing Techniques

http://slidepdf.com/reader/full/seassignment-testing-techniques 6/6

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 invalidequivalence classes are defined.

If an input condition specifies a member of a set, one valid and one invalidequivalence class is defined.

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

3. Boundary Value Analysis:

It has been observed that programs working correctly for a set of equivalence class

values, fail on some special values. These values often lie on the equivalence class

 boundary. Thus, the test cases having such values are likely to be “high yield” test cases,and choosing such test cases in the goal of the boundary value analysis.

Boundary Value Analysis (BVA) is a test case design technique that complements

equivalence partitioning. Rather than selecting any element of an equivalence class, BVAleads to selection to test cases at the “edges” of the class. Rather than focusing solely on

input conditions…..

Guidelines for BVA are:

If an input condition specifies a range bounded by values a & b, test casesshould be designed with values of a & b and just above and just above and just

 below a & b.

If an input condition specifies a number of values, test cases should be

developed that exercise the minimum and maximum numbers. Values just

above and below minimum and maximum are also tested. Apply both of the above guidelines to output conditions.

If internal program data structures have predefined boundaries are certaindesign a test case to exercise the data structure as its boundary.