CS8494/SE TESTING AND IMPLEMENTATION UNIT IV

Software testing fundamentals-Internal and external views of Testing-white box

testing- basis path Testing-control structure testing-black box testing- Regression
Testing – Unit Testing – Integration Testing – Validation Testing – System Testing and
Debugging – Software Implementation Techniques: Coding practices-Refactoring.
Maintenance and Reengineering- BPR model-Reengineering process model-Reverse
and Forward Engineering

4.1 SOFTWARE TESTING FUNDAMENTALS

What is testing?
 Testing is a process of exercising the software to detect errors.
 The goal of testing is to find errors, and a good test is one that has a high
probability
 of finding an error.
 Software testing is a process of executing a program or application with the
intent of finding the software bugs.
Why is software testing necessary?
Software testing is very important because of the following reasons:
 Software testing is really required to point out the defects and errors that were
made during the development phases.
 To achieve customer’s reliability and their satisfaction in the application.
 It is very important to ensure the Quality of the product.
 Testing is required for an effective performance of software application or
product.
What is an error in software testing?
The mistake made by programmer is known as an Error. This could happen
because of the following reasons:
o Because of some confusion in understanding the functionality of the software
o Because of some miscalculation of the values
o Because of misinterpretation of any value, etc.
What is a Failure in software testing?
If under certain circumstances these defects get executed by the tester during
the testing then it results into the failure which is known as software failure.
Not all defects result in failures, some may stay inactive in the code and we may
never notice them.
Example: Defects in dead code will never result in failures.
 Error: Human mistake that caused fault
CS8494/SE TESTING AND IMPLEMENTATION UNIT IV
 Fault: Discrepancy in code that causes a failure.
 Failure: External behavior is incorrect
Artifacts of Testing:
 Test case:
A test case is a set of conditions or variables under which a tester will determine
whether a system under test satisfies requirements or works correctly.
 Test plan:
A Software Test Plan is a document describing the testing scope and activities.
It is the basis for formally testing any software/product in a project.
 Test script:
A Test Script is a set of instructions (written using a scripting/programming
language) that is performed on a system under test to verify that the system
performs as expected. Test scripts are used in automated testing.
What is the cost of defects in software testing?
The cost of defects can be measured by the impact of the defects and when we
find them.
Note: Earlier the defect is found lesser is the cost of defect.

Test Characteristics:
A good test has a high probability of finding an error
A good test is not redundant.
A good test should be “best of breed”(should cover more class of errors)
A good test should be neither too simple nor too complex
Principles of Testing:
There are seven principles of testing. They are as follows:
 Testing shows presence of defects:
- Testing can show the defects are present, but cannot prove that there
are no defects.
CS8494/SE TESTING AND IMPLEMENTATION UNIT IV
- Even after testing the application or product thoroughly we cannot say
that the product is 100% defect free.
- Testing always reduces the number of undiscovered defects remaining
in the software but even if no defects are found, it is not a proof of
correctness.
 Exhaustive testing is impossible:
- Testing everything including all combinations of inputs and
preconditions is not possible.
- So, instead of doing the exhaustive testing we can use risks and
priorities to focus testing efforts.
 Early testing: In the software development life cycle , testing activities should
start as early as possible and should be focused on defined objectives.
 Defect clustering: A small number of modules contains most of the defects
discovered during pre-release testing or shows the most operational failures.
 Pesticide paradox:
- If the same kinds of tests are repeated again and again, eventually the
same set of test cases will no longer be able to find any new bugs.
- To overcome this Pesticide Paradox , it is really very important to
review the test cases regularly and new and different tests need to be
written to exercise different parts of the software or system to
potentially find more defects.
 Testing is context depending: Testing is basically context dependent. Different
kinds of sites are tested differently
 Absence–of–errors fallacy:
- If the system built is unusable and does not fulfill the user’s needs and
expectations then finding and fixing defects does not help.
Verification Validation
Are we building the system right? Are we building the right system?
Verification is the process of evaluating Validation is the process of evaluating
products during development phase to find software at the end of the development
out whether they meet the specified phase to determine whether software
requirements. meets the customer expectations and
requirements.
The objective of Verification is to make sure The objective of Validation is to make sure
that the product being develop is as per the that the product actually meet up the
requirements and design specifications. user’s requirements, and check whether
CS8494/SE TESTING AND IMPLEMENTATION UNIT IV
the specifications were correct in the first
place.
Following activities are involved Following activities are involved
in Verification: Reviews, Meetings and in Validation: Testing like black box
Inspections. testing, white box testing, gray box
testing etc.
Verification is carried out by QA team to Validation is carried out by testing team.
check whether implementation software is
as per specification document or not.
Execution of code is not comes Execution of code is comes
under Verification. under Validation.
Verification process explains whether the Validation process describes whether the
outputs are according to inputs or not. software is accepted by the user or not.
Verification is carried out before the Validation activity is carried out just after
Validation. the Verification.
Following items are evaluated Following item is evaluated
during Verification: Plans, Requirement during Validation: Actual product or
Specifications, Design Specifications, Code, Software under test.
Test Cases etc,
Cost of errors caught in Verification is less Cost of errors caught in Validation is
than errors found in Validation. more than errors found in Verification.
It is basically manually checking the of It is basically checking of developed
documents and files like requirement program based on the requirement
specifications etc. specifications documents & files.

4.2 INTERNAL AND EXTERNAL VIEWS OF TESTING (Types of testing)

Testing is done by two methods(2 ways)
White box testing-Internal View
Black box testing-External View
4.2.1 White Box Testing
 White box testing is also known as Clear Box Testing, Open Box Testing,
Glass Box Testing, Transparent Box Testing, Code-Based Testing or
Structural Testing
 The tester chooses inputs ,process and determines the appropriate outputs.
 White box testing techniques analyze the internal design, code structure and
the working of the software rather than just the functionality as in black box
testing.
CS8494/SE TESTING AND IMPLEMENTATION UNIT IV

Working process of white box testing:

o Input: Requirements, Functional specifications, design documents, source code.
o Processing: Performing risk analysis for guiding through the entire process.
o Proper test planning: Designing test cases and execute rinse-repeat until
error-free software is reached. Also, the results are communicated.
o Output: Preparing final report of the entire testing process.
Advantages:
 White box testing is very thorough as the entire code and structures are
tested.
 It can start at an earlier stage as it doesn’t require any interface as in case of
black box testing.
 Easy to automate.
Disadvantages:
 Very expensive.
 Redesign of code and rewriting code needs test cases to be written again.
 Testers are required to have in-depth knowledge of the code and
programming language as opposed to black box testing.
 Very complex and at times not realistic.
Types of White Box Testing
Basis Path testing,
Conditional Testing,
Data flow testing,
Loop testing, etc
i. Basis Path Testing:
 Basis path testing is a white-box testing technique first proposed by Tom
McCabe.
 .It defines test cases based on the flows or logical path that can be taken
through the program.
 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
CS8494/SE TESTING AND IMPLEMENTATION UNIT IV
 Basis path testing involves execution of all possible blocks in a program
and achieves maximum path coverage with least number of test cases.
 It is a hybrid of branch testing and path testing methods.
Steps for Basis Path Testing:
The basic steps involved in basis path testing include
1. Draw a control graph(flow graph) (to determine different program
paths)
2. Calculate cyclomatic complexity (metrics to determine the number of
independent paths)
3. Find a basis set of paths(independent paths)
4. Generate test cases to exercise each path
Flow graph Notation:

Fig: Basic control flow graph structures

On a control flow graph, the used notations are,
o Arrows or edges represent flows of control.
o Circles or nodes represent actions.
o Areas bounded by edges and nodes are called regions.
o A predicate node is a node containing a condition.
CS8494/SE TESTING AND IMPLEMENTATION UNIT IV
Example 1:
Following program is for searching a number using binary search method.
Draw a flow graph for the same.

Solution:
STEP 1: Draw a control graph (flow graph) to determine different program
paths)
Flow graph for the above program :
CS8494/SE TESTING AND IMPLEMENTATION UNIT IV

STEP 2: Calculate cyclomatic complexity (metrics to determine the number of

independent paths)
Complexity is computed in one of three ways:
I. Cyclomatic complexity V(G) = The number of regions of the flow graph
corresponds to the cyclomatic complexity.
Eg: Total no of regions in given example( shaded roman letters)
=4
II. Cyclomatic complexity V(G) for a flow graph G is defined as
V(G) = E - N _+2
where E is the number of flow graph edges and N is the number of
flow graph nodes.
Eg: 2+2=4
III. Cyclomatic complexity V(G) for a flow graph G is also defined as
V(G) =P + 1
where P is the number of predicate nodes contained in the flow
graph G.
Eg: P+1=3+1=4. There are three predicate nodes: Nodes 3,5,8.

STEP 3: Find a basis set of paths

The basis paths are:
Path 1: 1,2,3,4,5,6,7,11
Path 2: 1,2,3,11
Path3: 1,2,3,4,5,8,9,3….
Path 4: 1,2,3,4,5,8,10,3…

STEP 4: Generate test cases to exercise each path

CS8494/SE TESTING AND IMPLEMENTATION UNIT IV
Example 2:
Following program is for performing simple subtraction:
1. Program ‘Simple Subtraction’
2. Input (x, y)
3. Output (x)
4. Output (y)
5. If x > y then DO
6. x – y = z
7. Else y – x = z
8. EndIf
9. Output (z)
10. Output “End Program”

STEP 1: Flow graph for the above program

STEP 2: Calculate the cyclomatic complexity:

The cyclomatic complexity can be computed three ways.
1. Cyclomatic complexity=total number of regions in the flow graph=2
2. Cyclomatic complexity=edges –nodes+2=9-9+2=2
3. Cyclomatic complexity=number of predicate nodes+1=1+1=2

STEP 3: SELECT basis set of path:

 An independent path is any path through the program that introduces at least one new
set of processing statements or a new condition.
 An independent path must move along at least one edge that has not been traversed
before the path is defined.
 For example, a set of independent paths for the flow graph
1. 2-3-4-5-6-8-9-10
2. 2-3-4-5-7-8-9-10
CS8494/SE TESTING AND IMPLEMENTATION UNIT IV

STEP 4: TEST CASES:

Path X Y Expected result

2-3-4-5-6-8-9-10
10 5 5 end program
2-3-4-5-7-8-9-10
5 10 5 end program
2-3-4-5-7-8-9-10
5 5 0 end program

ii) CONTROL STRUCTURE TESTING

a) Condition Testing:
 Condition testing, is to test a program by focusing on testing the conditions in
this program.
 It is used in computer programs that consists of statements, such as IF and
WHILE statements, which contain conditions that are combinations of Boolean
and Relational expressions.
 It tests relational operator like <, ≤, >, ≥, =, ≠ and Boolean operators like
OR (|), AND (&), NOT(⌐) that exist in your program.
 2 types of condition: i) simple condition ii) compound condition
 A simple condition is a Boolean variable or a relational expression, possibly
preceded with one NOT (¬) operator.
 A relational expression takes the form E1 <relational-operator> E2
where E1 and E2 are arithmetic expressions and <relational-operator> is
one of the following <, ≤, >, ≥, =, ≠
 A compound condition is composed of two or more simple conditions,
Boolean operators, and parentheses.
 The condition testing method focuses on testing each condition in the program
to ensure that it does not contain errors.

(b) Data Flow Testing

 Data flow testing is a family of test strategies based on selecting paths through
the program's control flow in order to explore sequences of events related to
the status of variables or data objects.
 The basic idea behind this form of testing, is to reveal the coding errors and
mistakes, which may results in to improper implementation and usage of the
CS8494/SE TESTING AND IMPLEMENTATION UNIT IV
data variables or data values in the programming code i.e. data anomalies,
such.
Advantages of Data Flow Testing:
Data Flow testing helps us to pinpoint any of the following issues:
 A variable that is declared but never used within the program.
 A variable that is used but never declared.
 A variable that is defined multiple times before it is used.
 Reallocating a variable before it is used.
(c) Loop Testing
 Loop Testing is the variant of testing that completely focuses on the validity
of the loop constructs. It is one of the part of Control Structure Testing.
 Loop testing is a White box testing. This technique is used to test loops in the
program.
Types of loop Test
The types of loop tested are,
i. Simple loop
ii. Nested loop
iii. Concatenated loop
iv. Unstructured loop
i) Simple loop:
A simple loop is tested in the following way:

The following set of tests can be applied to simple loops, where n is the
maximum number of allowable passes through the loop
1. Skip the loop entirely.
2. Only one pass through the loop.
3. Two passes through the loop.
4. m passes through the loop where m < n.
5. n - 1, n, n + 1 passes through the loop.
ii) Nested Loop(Loop inside the loop)
CS8494/SE TESTING AND IMPLEMENTATION UNIT IV
The number of possible tests would grow geometrically as the level of nesting
increases. To help to reduce the number of tests we follow,
1. Start at the innermost loop. Set all other loops to minimum values.
2. Conduct simple loop tests for the innermost loop while holding the outer
loops at their minimum iteration parameter (e.g., loop counter) values.
3. Work outward, conducting tests for the next loop, but keeping all other
outer loops at minimum values and other nested loops to “typical” values.
4. Continue until all loops have been tested.

iii) Concatenated Loops

 In the concatenated loops, if two loops are independent of each other then
they are tested using simple loops or else test them as nested loops.
 However if the loop counter for one loop is used as the initial value for the
others, then it will not be considered as an independent loops.

iv) Unstructured Loops

For unstructured loops, it requires restructuring of the design to reflect the
use of the structured programming constructs.
CS8494/SE TESTING AND IMPLEMENTATION UNIT IV

Limitation in Loop testing:

o Loop bugs show up mostly in low-level software
o The bugs identified during loop testing are not very subtle.
o Many of the bugs might be detected by the operating system as such they
will cause memory boundary violations, detectable pointer errors, etc.
4.2.2. Black Box Testing
 Black box testing is also known as functional testing and Behavioral Testing.
 It is conducted at the software interface.
 It is a software testing technique whereby the internal workings of the item
being tested are not known by the tester.
 In black box testing the tester only knows the inputs and what the expected
outcomes should be and not how the program arrives at those outputs.
 The tester does not ever examine the programming code and does not need any
further knowledge of the program other than its specifications.
This method attempts to find errors in the following categories:
o Incorrect or missing functions
o Interface errors
o Errors in data structures or external database access
o Behavior or performance errors
o Initialization and termination errors
CS8494/SE TESTING AND IMPLEMENTATION UNIT IV
Advantages:
 The test is done from the point of view of the user, not the designer.
 The test is not biased because the designer and the tester are independent of
each other.
 The tester does not need knowledge of any specific programming languages.
 Test cases can be designed as soon as the specifications are complete.
Disadvantages:
 The test cases are difficult to design.
 Testing every possible input stream is unrealistic because it would take a
inordinate amount of time; therefore, many program paths are not tested.

Types of Black Box Testing:

Graph-Based Testing Methods
Equivalence Partitioning
Boundary Value Analysis
A) Graph based Testing methods:
 The first step in black-box testing is to understand the objects that are
modelled in software and the relationships that connect these objects.
 Once this has been accomplished, the next step is to define a series of tests
that verify “all objects have the expected relationship to one another”
 To accomplish these steps, you begin by creating a graph—a collection of
nodes that represent objects, links that represent the relationships between
objects, node weights that describe the properties of a node (e.g., a specific
data value or state behaviour), and link weights that describe some
characteristic of a link.

The symbolic representation of a graph is shown in Figure below

CS8494/SE TESTING AND IMPLEMENTATION UNIT IV

Nodes are represented as circles connected by links that take a number of

different forms.
A directed link (represented by an arrow) 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.
As a simple example, consider a portion of a graph for a word-processing
application where
Object #1 _ newFile (menu selection)
Object #2 _ documentWindow
Object #3 _ documentText

Fig: Simple example of Word processing application

B) Equivalence partitioning
 Dividing the test input data into a range of values and selecting one input
value from each range is called Equivalence Partitioning.
 This method is typically used to reduce the total number of test cases to a
finite set of testable test cases.
 Simply, it is the process of taking all possible test cases and placing
them into classes. One test value is picked from each class while
testing.
 Typically, an input condition is either a specific numeric value, a range of
values, a set of related values, or a Boolean condition.
 Test-case design for equivalence partitioning is based on an evaluation of
equivalence classes for an input condition.
CS8494/SE TESTING AND IMPLEMENTATION UNIT IV

The equivalence class guidelines can be as given below,

 If the input condition is range , then it has one valid and two invalid.ie if
input from 1-100
Invalid Valid Invalid
<1 1-100 >1
 If the input condition is a specific value , then it has one valid and two
invalid.ie if input is 55
Invalid Valid Invalid
<55 55 >55
 If the input condition is member of a set , then it has one valid and one
invalid. ie if input is >=2&&<=8
Valid Invalid
3,4,5,6,7 >7,<2
 If the input condition is Boolean , then it has one valid and one invalid.ie if
the input is true or false(text only)
Valid Invalid
A-Z,a-z 0,1,2,……..
By applying the guidelines for the derivation of equivalence classes, test cases
for each input domain data item can be developed and executed.
Example:

Valid Input: 18 – 56
Invalid Input: less than or equal to 17 (<=17), greater than or equal to 57 (>=57)
Valid Class: 18 – 56 = Pick any one input test data from 18 – 56
Invalid Class 1: <=17 = Pick any one input test data less than or equal to 17
Invalid Class 2: >=57 = Pick any one input test data greater than or equal to 57
CS8494/SE TESTING AND IMPLEMENTATION UNIT IV
C) Boundary value Analysis
 Boundary value analysis is another black box test design technique and it is
used to find the errors at boundaries of input domain rather than finding
those errors in the center of input.
 Boundary testing is the process of testing between extreme ends or
boundaries between partitions of the input values.
 A greater number of errors occurs at the boundaries of the input domain
rather than in the “center.”
So these extreme ends like Start- End, Lower- Upper, Maximum-Minimum,
Just Inside-Just Outside values are called boundary values and the testing is
called "boundary testing".
 Rather than focusing solely on input conditions, BVA derives test cases from
the output domain as well
 The basic idea in boundary value testing is to select input variable values at
their:
 Minimum
 Just above the minimum
 A nominal value
 Just below the maximum
 Maximum

Guidelines for BVA

i. If an input condition specifies a range bounded by values a and b, test
cases should be designed with values a and b and just above and just below
a and b.
ii. 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.
iii. Apply guidelines 1 and 2 to output conditions. For example, assume that a
temperature versus pressure table is required as output from an
engineering analysis program. Test cases should be designed to create an
CS8494/SE TESTING AND IMPLEMENTATION UNIT IV
output report that produces the maximum (and minimum) allowable
number of table entries.
iv. If internal program data structures have prescribed boundaries (e.g., a
table has a defined limit of 100 entries), be certain to design a test case to
exercise the data structure at its boundary.

Example:
Minimum boundary value is: 18
Maximum boundary value is: 56
Valid Inputs: 18,19,55,56
Invalid Inputs: 17 and 57
Test case Input Output
1 Enter the value 17 (18-1) Invalid
2 Enter the value 18 Valid
3 Enter the value 19 (18+1) Valid
4 Enter the value 55 (56-1) Valid
5 Enter the value 56 Valid
6 Enter the value 57 Invalid
Note: Equivalence Partitioning and Boundary value analysis are linked to each
other and can be used together at all levels of testing.

Difference between black box and white box testing

Black Box Testing White Box Testing
It is a way of software testing in which It is a way of testing the software in
the internal structure or the program or which the tester has knowledge about
the code is hidden and nothing is the internal structure of the code or the
known about it. program of the software.
It is mostly done by software testers It is mostly done by software
CS8494/SE TESTING AND IMPLEMENTATION UNIT IV
developers.
No knowledge of implementation is Knowledge of implementation is
needed. required.
It can be referred as outer or external It is the inner or the internal software
software testing. testing
It is functional test of the software. It is structural test of the software.
This testing can be initiated on the basis This type of testing of software is
of requirement specifications started after detail design document.
document.
No knowledge of programming is Programming knowledge is
required. necessary
Suitable for large projects Suitable for small projects
It is applicable to the higher levels of It is generally applicable to the lower
testing of software. levels of software testing.
It is also called closed testing. It is also called as clear box testing.
It is less time consuming. It is most time consuming.
It is not suitable or preferred for It is suitable for algorithm testing.
algorithm testing.
Example: search something on google Example: by input to check and verify
by using keywords loops
Types of Black Box Testing: Types of White Box Testing:
 A. Functional Testing  A. Path Testing
 B. Non-functional testing  B. Loop Testing
 C. Regression Testing  C. Condition testing

4.2.3 Regression Testing:

Regression testing is the process of testing changes to computer programs
to make sure that the older programming still works with the new changes.
Regression testing is a normal part of the program development process and, in
larger companies, is done by code testing specialists.
Need of Regression Testing:
Regression Testing is required when there is a
 Change in requirements and code is modified according to the
requirement
 New feature is added to the software
CS8494/SE TESTING AND IMPLEMENTATION UNIT IV
 Defect fixing
 Performance issue fix
How to do Regression Testing?
Software maintenance is an activity which includes enhancements, error
corrections, optimization and deletion of existing features. These modifications
may cause the system to work incorrectly. Therefore, Regression Testing
becomes necessary. Regression Testing can be carried out using the following
techniques:

Regression Test Process :

CS8494/SE TESTING AND IMPLEMENTATION UNIT IV
Retest All:
This is one of the methods for Regression Testing in which all the tests in
the existing test bucket or suite should be re-executed. This is very expensive as
it requires huge time and resources.
Regression Test Selection:
 Instead of re-executing the entire test suite, it is better to select part of
the test suite to be run
 Test cases selected can be categorized as 1) Reusable Test Cases 2)
Obsolete Test Cases.
 Re-usable Test cases can be used in succeeding regression cycles.
 Obsolete Test Cases can't be used in succeeding cycles.
Prioritization of Test Cases:
Prioritize the test cases depending on business impact, critical & frequently used
functionalities. Selection of test cases based on priority will greatly reduce the
regression test suite.

4.3. TESTING STRATEGIES

Following are the four strategies for conventional software:
i. Unit testing
ii. Integration testing
iii. Validation testing
iv. System testing

Fig: Testing strategy

CS8494/SE TESTING AND IMPLEMENTATION UNIT IV

Fig: Software testing steps

4.3.1 Unit Testing:

 Unit testing focus on the smallest unit of software design, i.e module or
software component.
 A unit is the smallest testable part of any software.
 It is performed by using the White Box Testing method.
Unit-test considerations:
o The purpose of unit testing is to validate that each unit of the software
performs as designed.
o It usually has one or more inputs and usually a single output
o In procedural programming, a unit may be an individual program,
function, procedure, etc.
o In object-oriented programming, the smallest unit is a method, which
may belong to a base/ super class, abstract class or derived/ child class.
o The module interface is tested .
o Local data structures are examined .
o All independent paths through the control structure are exercised.
o Boundary conditions are tested to ensure that the module operates
properly at boundaries established .
o Boundary testing is one of the most important unit testing tasks. Software
often fails at its boundaries.
o And finally, all error-handling paths are tested.
o Unit tests are illustrated schematically in figure below.
CS8494/SE TESTING AND IMPLEMENTATION UNIT IV

Fig: unit test

Unit-test procedures:
 Unit testing is normally considered as an adjunct to the coding step.
 The design of unit tests occurs before coding begins or after source code
has been generated.
The unit test environment is as shown in following figure:

Difference between stub and driver

Stub Driver
Stub is considered as subprogram. It is a simple main program.
Stub does not accept test case data. Driver accepts test case data.
It replaces the modules of the Pass the data to the tested
program into subprograms and is components and print the
tested by the next driver. returned result.
Advantages of Unit testing:
 The cost of fixing a defect detected during unit testing is lesser in
comparison to that of defects detected at higher levels
CS8494/SE TESTING AND IMPLEMENTATION UNIT IV
 Debugging is easy. When a test fails, only the latest changes need to be
debugged.
 If good unit tests are written it increases confidence in changing/
maintaining code
 Codes are more reusable.
4.3.2 Integration Testing
 Integration Testing is a level of software testing where individual units are
combined and tested as a group.
 The objective is to take unit-tested components and perform integration testing.
 The purpose of this level of testing is to expose faults in the interaction
between integrated units.
 Once all the modules have been unit tested, integration testing is performed.
 Integration Testing is the second level of testing performed after Unit
Testing and before System Testing.
 Developers themselves or independent testers perform Integration Testing.
 Integration testing is also used for the construction of software architecture.
Example:
During the process of manufacturing a ballpoint pen, the cap, the body, the tail
and clip, the ink cartridge and the ballpoint are produced separately and unit
tested separately. When two or more units are ready, they are assembled and
Integration Testing is performed. For example, whether the cap fits into the body
or not.
There are two approaches of incremental testing are,
a) Non incremental integration testing
b) Incremental integration testing

(a) Non Incremental Testing:

CS8494/SE TESTING AND IMPLEMENTATION UNIT IV
(i) Big bang Approach:
 It is the simplest integration testing approach,
 Here all component are integrated together at once and then tested.
 The entire program is tested as a whole. And chaos usually results!
 When a set of errors encountered correction is difficult .
Disadvantages:
o This approach is suitable only for very small systems.
o If once an error is found during this approach, it is very difficult to localize
the error as the error may potentially belong to any of the modules being
integrated.
o So, debugging is very expensive.
b) Incremental Integration Testing
 In this approach, testing is done by joining two or more modules that
are logically related.
 Then the other related modules are added and tested for the proper
functioning. The process continues until all of the modules are joined and
tested successfully.
 Simply, The programs are built and tested in small increments.
 The errors are easier to correct and isolate.
Stub and Driver:
Incremental Approach is carried out by using dummy programs called Stubs
and Drivers.
Stub: stub is called by the Module under Test.
Driver: Driver calls alls the Module to be tested.
Different incremental integration strategies:
Top-down integration
Bottom-up integration
Regression Testing
Smoke Testing
(i) Top-Down Integration
 It is an incremental approach for building the software architecture.
 In this integration testing, testing takes place from top to bottom.
 It starts with the main control module or program.
 Modules are merged by moving downward through the control
hierarchy.(I,e)
CS8494/SE TESTING AND IMPLEMENTATION UNIT IV
 First high-level modules are tested followed by low-level modules and
finally integrating the low-level modules to a high level to ensure the
system is working.

Fig: Top Down Integration

Integration takes place using depth first or breadth first approach.
- In Depth-first integration, the left-hand path, components M1, M2 , M5
would be integrated first. Next, M8 or (if necessary for proper functioning
of M2) M6 would be integrated. Then, the central and right-hand control
paths are built.
- In Breadth-first integration components M2, M3, and M4 would be
integrated first. The next control level, M5, M6, and so on, follows.
Problems with top-down approach of testing
o Test conditions are difficult to create.
o A set of errors occur, then correction is difficult to make due to the
isolation
(ii) Bottom-Up Integration:
Bottom-up integration is implemented in following steps:
 In bottom-up testing, each module at lower levels is tested with
higher modules until all modules are tested.
 The low level components are merged into clusters which perform a
specific software sub function.
 A control program for testing(driver) coordinate test case input and
output.
 After these steps are tested in cluster, The driver is removed and clusters
are merged by moving upward on the program structure.
Following figure shows the bottom up integration:
CS8494/SE TESTING AND IMPLEMENTATION UNIT IV

Fig: Bottom Up Approach

 Components are combined to form clusters 1, 2, and 3. Each of the clusters
is tested using a driver (shown as a dashed block). Components in clusters 1
and 2 are subordinate to Ma.
 Drivers D1 and D2 are removed and the clusters are interfaced directly to
Ma. Similarly, driver D3 for cluster 3 is removed prior to integration with
module Mb. Both Ma and Mb will ultimately be integrated with component
Mc, and so forth.
Steps in bottom-up integration strategy :
1. Low-level components are combined into clusters (sometimes called builds)
that perform a specific software sub function.
2. A driver (a control program for testing) is written to coordinate test case
input and output.
3. The cluster is tested.
4. Drivers are removed and clusters are combined moving upward in the
program structure.
Advantage:
 In bottom-up testing, no stubs are required.
 No time is wasted unlike big bang approach
Disadvantage:
 Complexity occurs when the system is made up of a large number of small
subsystems.
CS8494/SE TESTING AND IMPLEMENTATION UNIT IV
iii) Regression Testing:
- Regression testing is a type of software testing that is done to verify that a
code change in the software does not impact the existing
functionality of the product and the previous functionality of the
application is working fine and the new changes have not introduced
any new bugs.
- Previously executed test cases are re-executed in order to verify the
impact of change.
- In regression testing the software architecture changes every time when a
new module is added as part of integration testing.
Process of Regression testing:

Techniques for the selection of Test cases for Regression Testing:

 Select all test cases
 Select test cases randomly
 Select higher priority test cases(priority codes are assigned to each test
case, After assigning the priority codes, test cases with highest priorities
are selected for the process of regression testing.
 Select modification traversing test cases: (modified portions of the
source code are tested)
Most commonly used tools for regression testing are:
 Selenium
 WATIR (Web Application Testing In Ruby)
 QTP (Quick Test Professional)
CS8494/SE TESTING AND IMPLEMENTATION UNIT IV
RFT (Rational Functional Tester)

 Winrunner
 Silktest
Advantages of Regression Testing:
- It ensures that no new bugs has been introduced after adding new
functionalities to the system.
- It helps to maintain the quality of the source code.
Disadvantages of Regression Testing:
- It can be time and resource consuming if automated tools are not used.
- It is required even after very small changes in the code.
iv) Smoke Testing:
 It is most commonly used testing when product software is developed.
 Mainly used for complex, time-critical projects.
 It allows the software team to assess the project on frequent basis.
 The result of this testing is used to decide if a build is stable enough to
proceed with further testing. And also used to decide whether to
proceed with further testing.
 A build includes all data files, libraries, reusable modules, and
engineered Components that are required to implement one or more
product functions.
 It is executed "before" any detailed functional or regression tests are
executed on the software build.
 It can be conducted on both newly created software and enhanced
software.
 Smoke test is performed manually or with the help of automation
tools/scripts. If builds are prepared frequently, it is best to automate
smoke testing.
 For Example, a typical smoke test would be - Verify that the application
launches successfully, Check that the GUI is responsive ... etc.
Note: The term “smoke” is inspired from hardware testing, which checks for the
smoke from the hardware components once the hardware's power is switched on.
Benefits:
 Integration risk is minimized.
 The quality of the end product is improved
 Error diagnosis and correction are simplified.
 Progress is easier to assess
CS8494/SE TESTING AND IMPLEMENTATION UNIT IV
Difference between Regression and smoke testing

Regression testing Smoke testing

Regression testing is used to check At the time of developing a software

defects generated to other modules by product smoke testing is used.
making the changes in existing programs.
In regression tested components are It permits the software development
tested again to verify the errors. team to test projects on a regular basis.
Regression testing needs extra Smoke testing does not need an extra
manpower because the cost of the manpower because it does not affect
project increases. the cost of project.
Testers conduct the regression testing. Developer conducts smoke testing just
before releasing the product.

4.3.3 Validation Testing:

o Validation is determining if the system complies with the requirements
and performs functions for which it is intended and meets the
organization’s goals and user needs.
o Validation is done at the end of the development process and takes place
after verifications are completed.
o It answers the question like: Am I building the right product?
o Here, the software is completely assembled as a package in validation testing.
o It is a High level activity.
o It is performed after a work product is produced against established criteria
ensuring that the product integrates correctly into the environment.
o Validation succeeds when software functions in a manner that can
be reasonably accepted by the customer.

Configuration Review (also called an audit):

 An important element of the validation process is a configuration review.
 The aim of the review is to ensure that all elements of the software
configuration have been properly developed, are catalogued, and have
the necessary details to the support activities
(i) Acceptance Testing
o Acceptance testing is a testing technique performed to determine whether
or not the software system has met the requirement specifications.
CS8494/SE TESTING AND IMPLEMENTATION UNIT IV
o The main purpose of this test is to evaluate the system's compliance with
the business requirements and verify if it is has met the required criteria
for delivery to end users.

There are various forms of acceptance testing:

 Alpha Testing
 Beta Testing

Difference between Alpha and Beta testing

Alpha testing Beta testing
Alpha testing is executed at developers Beta testing is executed at end-user
end by the customer. sites in the absence of a developer.
It handles the software project and It usually handles software product.
applications.
It is not open to market and the public. It is always open to the market and
the public.
Alpha testing does not have any different Beta testing is also known as the field
name. testing.
Alpha testing is not able to test the errors In beta testing, the developer corrects
because the developer does not known the errors as users report the
the type of user. problems.
In alpha testing, developer modifies the In beta testing, developer modifies
codes before release the software the code after getting the feedback
without user feedback. from user.

4.3.4 System Testing:

 System Testing is the testing of a complete and fully integrated software
product.
CS8494/SE TESTING AND IMPLEMENTATION UNIT IV
 System Testing (ST) is a black box testing technique performed to evaluate
the complete system against specified requirements.
 In System testing, the functionalities of the system are tested from an end-to-
end perspective.
 System Testing is usually carried out by a team that is independent of the
development team in order to measure the quality of the system unbiased. It
includes both functional and Non-Functional testing.
Different Types of System Testing:
Recovery Testing :
- Recovery Testing is defined as a software testing type, that is
performed to determine whether operations can be continued after a
disaster or after the integrity of the system has been lost.
- The purpose of recovery testing is to verify the system’s ability to
recover from varying points of failure.
- Many computer-based systems must recover from faults and resume
processing with little or no downtime.
- It is done by professional testers.
The time taken to recover depends upon:
 The number of restart points
 A volume of the applications
 Training and skills of people conducting recovery activities and tools
available for recover.

Performance Testing:
- Performance testing, a non-functional testing technique performed to
determine the system parameters in terms of responsiveness and
stability under various workloads.
- Performance testing measures the quality attributes of the system,
such as scalability, reliability and resource usage.
Performance Testing Techniques:
 Load testing - It is the simplest form of testing conducted to understand
the behavior of the system under a specific load.
Load testing will result in measuring important business critical
transactions and load on the database, application server, etc., are also
monitored.
CS8494/SE TESTING AND IMPLEMENTATION UNIT IV
 Soak testing : During soak tests the parameters such as memory
utilization is monitored to detect memory leaks or other performance
issues. The main aim is to discover the system's performance under
sustained use.
 Spike testing - Spike testing is performed by increasing the number of
users suddenly by a very large amount and measuring the performance of
the system. The main aim is to determine whether the system will be able
to sustain the workload.
Attributes of Performance Testing:
 Speed
 Scalability
 Stability
 reliability
 Stress Testing-It is performed to find the upper limit capacity of the
system and also to determine how the system performs if the current load
goes well above the expected maximum.
Security Testing:
- It ensures software systems and applications are free from any
vulnerabilities, threats, risks that may cause a big loss.
- The goal of security testing is to identify the threats in the system and
measure its potential vulnerabilities.
- It also helps in detecting all possible security risks in the system and
help developers in fixing these problems through coding.
- It is necessary to involve security testing in the SDLC life cycle in the
earlier phases
4.3.5 Debugging
 Debugging is the process of fixing a bug in the software. In other words, it
refers to identifying, analyzing and removing errors.
 This activity begins after the software fails to execute properly and concludes by
solving the problem and successfully testing the software.
 It is considered to be an extremely complex and tedious task because errors
need to be resolved at all stages of debugging.
 Debugging occurs as a consequence of successful testing. That is, when a test
case uncovers an error, debugging is the process that results in the removal of
the error.
CS8494/SE TESTING AND IMPLEMENTATION UNIT IV

 Although debugging can and should be an orderly process, it is still very much
an art. A software engineer, evaluating the results of a test, is often confronted
with a "symptomatic" indication of a software problem.
The Debugging Process
Steps involved in debugging are:
 Problem identification and report preparation.
 Assigning the report to software engineer to the defect to verify that it is
genuine.
 Defect Analysis using modeling, documentations, finding and testing
candidate flaws, etc.
 Defect Resolution by making required changes to the system.
 Validation of corrections.
CS8494/SE TESTING AND IMPLEMENTATION UNIT IV
o Debugging is not testing but always occurs as a consequence of testing. The
debugging process begins with the execution of a test case.
o Results are assessed and a lack of correspondence between expected and actual
performance is encountered.
o The debugging process will always have one of two outcomes:
 The cause will be found and corrected.
 The cause will not be found.
Characteristics of bugs:
 The symptom may disappear (temporarily) when another error is corrected.
 The symptom may actually be caused by non errors (e.g., round-off
inaccuracies).
 The symptom may be caused by human error that is not easily traced.
 The symptom may be a result of timing problems, rather than processing
problems.
 It may be difficult to accurately reproduce input conditions
Debugging approaches:
 Brute force
 Backtracking
 Cause elimination.
(i) Brute force:
o The brute force category of debugging is probably the most common and least
efficient method for isolating the cause of a software error.
o We apply brute force debugging methods when all else fails.
o Using a "let the computer find the error" philosophy, memory dumps are
taken, run-time traces are invoked, and the program is loaded with WRITE
statements.
o Although the mass of information produced may ultimately lead to success, it
more frequently leads to wasted effort and time. Thought must be expended
first!
(ii) Backtracking:
o Backtracking is a fairly common debugging approach that can be used
successfully in small programs.
o Beginning at the site where a symptom has been uncovered, the source code is
traced backward (manually) until the site of the cause is found.
o Unfortunately, as the number of source lines increases, the number of potential
backward paths may become unmanageably large.
CS8494/SE TESTING AND IMPLEMENTATION UNIT IV
(iii) Cause elimination:
o The third approach to debugging cause elimination is manifested by induction or
deduction and introduces the concept of binary partitioning.
o Data related to the error occurrence are organized to isolate potential causes.
Some of the widely used debuggers are:
 Radare2
 WinDbg
 Valgrind

4.4 SOFTWARE IMPLEMENTATION TECHNIQUES

 The goal coding is to implement the design in the best possible manner. Coding
affects both testing and maintenance very deeply.
 Various objectives of coding are:
1. Programs developed in coding should be readable.
2. They should execute efficiently.
3. The program should utilize less amount of memory.
4. The programs should not be lengthy.
4.4.1 Coding Practices:
There are some commonly used programming practices that help in avoiding the
common errors. These are enlisted below –
1. Control construct:
The single entry and single exit constructs need to be used. The standard control
constructs must be used instead of using wide variety of controls.
2. Use of gotos:
The goto statements make the program unstructured and it also imposes
overhead on compilation process. Hence avoid use of goto statements as far as
possible and another alternative must be thought of.
3. Information hiding :
Only access functions to the data structures must be made visible and the
information present in it must be hidden.
4. Nesting :
Nesting means defining one structure inside another. If the nesting is too deep
then it becomes hard to understand the code. Hence as far as possible - avoid
deep nesting of the code.
CS8494/SE TESTING AND IMPLEMENTATION UNIT IV

5.User defined data types

Modern programming languages allow the user to use defined data types as the
enumerated types. Use of user defined data types enhances the readability of
the code.
For example: In C we can define the name of the days using enumerated
datatype -
enum Day
{
Sunday;
Monday;
Tuesday;
Wednesday;
Thursday;
Friday;
Saturday;
}workday;
enum Day Today=Friday;
6. Module size
There is no standard rule about the size of the module but the large size of
the module will not be functionally cohesive.
7. Module interface
Complex module interface must be carefully examined. A simple rule of thumb
is that the module interface with more than five parameters must be
broken into multiple modules with simple interface.
8. Side effects
Avoid obscure side effects. If some part of the code is changed randomly then it
will cause some side effect.
9. Robustness
The program is said to robust if it does something even though some
unexceptional condition occurs. In such situations the programs do not crash
but it exits gracefully.
CS8494/SE TESTING AND IMPLEMENTATION UNIT IV
10. Switch case with defaults
The choice being passed to the switch case statement may have some
unpredictable value, and then the default case will help to execute the switch
case statement without any problem. Hence it is a good practice to always have
default case in the switch statement.
11. Empty catch block
If the exception is caught but if there is no action then it is not a good practice.
Therefore take some default action even if it is just writing some print
statement, whenever the exception is caught.
12. Empty if and while statements
In the if and while statements some conditions are checked. Hence if we write
some empty block on checking these conditions then those checks are proved
to be useless checks. Such useless checks should be avoided.
13. Check for read return
Many times the return values that we obtain from the read functions are not
checked because we blindly believe that the desired result is present in the
corresponding variable when the read function is performed. But this may
cause some serious errors. hence the return value must be checked for the read
operation.
14. Return from Finally Block
The return value must come from finally block whenever it is possible. This
helps in distinguishing the data values that are returning from the try-catch
statements.
15. Trusted Data sources
Counter check should be made before accessing the input data. For example
while reading the data from the file one must check whether the data accessed
is NULL or not.
16. Correlated Parameters
Many often there occurs co-relation between the data items. It is a good
practice to check these co-relations before performing any operation on those
data items.
17. Exceptions Handling
If due to some input condition if the program does not follow the main path and
follows an exceptional path. In such a situation, an exceptional path may get
followed. In order to make the software more reliable, it necessary to write the
code for execution.
CS8494/SE TESTING AND IMPLEMENTATION UNIT IV
4.4.2 Coding Standards
Any good software development approach suggests to adhere to some well-defined
standards or rules for coding. These rules are called coding standards.
 Naming Conventions
Following are some commonly used naming conventions in the coding
 Package name and variable names should be in lower case.
 Variable names must not begin with numbers.
 The type name should be noun and it should start with capital letter.
 Constants must be in upper case (For example PI, SIZE)
 Method name must be given in lower case.
 The variables with large scope must have long name. For example
count_total, sum, Variables with short scope must have short name.
For example i,j.
 The prefix is must be used for Boolean type of variables. For example
isEmpty or isFull
 Files
Reader must get an idea about the purpose of the file by its name. In some
programming language like Java –
 The file extension must be Java.
 The name of the file and the class defined in the file must have the same na
 Line length in the file must be limited to 80 characters.
 Commenting/Layout
Comments are non-executable part of the code. But it is very important because it
enhances the readability of the code. The purpose of the code is to explain the
logic of the program.
 Single line comments must be given by //
 For the names of the variables comments must be given.
 A black of comment must be enclosed within /* and */.
 Statements
There are some guidelines about the declaration and executable statements.
 Declare some related variables on same line and unrelated variables on
another line.
 Class variable should never be declared public.
 Make use of only loop control within the for loop.
 Avoid make use of break and continue statements in the loop.
CS8494/SE TESTING AND IMPLEMENTATION UNIT IV
 Avoid complex conditional expressions. Make use of temporary variables
instead.
 Avoid the use of do...while statement.
Advantages of coding standards:
 Coding standard brings uniform appearance in system implementation.
 The code becomes readable and hence can be understood easily.
 The coding standard helps in adopting good programming practices.
4.4.3 Refactoring:
 Refactoring is a reorganization technique that simplifies the design (or code) of
a component without changing its function or behavior.
 Refactoring is the process of changing a software system in such a way that
it does not alter the external behavior of the code [design] yet improves its
internal structure.
 When software is refactored, the existing design is examined for redundancy,
unused design elements, inefficient or unnecessary algorithms, poorly
constructed or inappropriate data structures, or any other design failure that can
be corrected to yield a better design.
 One approach to refactoring is to improve the structure of source code at one
point and then extend the same changes systematically to all applicable
references throughout the program. The result is to make the code more efficient,
scalable, maintainable or reusable, without actually changing any functions of
the program itself.
 Purpose of refactoring is long lasting and healthy code.
Advantages:
 Improved code readability
 Reduced complexity to improve source code maintainability
 Create a more expressive internal architecture
 Object model to improve extensibility.
 Cost of testing and debugging is reduced due to refactoring.
Risk in refactoring:
 Existing work code may break due to the changes being made.
 This is the reason why refactoring is not frequently done.
In order to mitigate or avoid this, 2 rules must be followed.
Rule 1: Refactor in small steps
Rule 2: For testing the existing functionalities make use of test scripts.
CS8494/SE TESTING AND IMPLEMENTATION UNIT IV

4.5 MAINTENANCE AND REENGINEERING

 A business process is “a set of logically related tasks performed to achieve
a defined business outcome”
 Examples of business processes include designing a new product, purchasing
services and supplies, hiring a new employee, and paying suppliers.
 The overall business is segmented in the following manner:

 Each business system (also called business function) is composed of one or more
business processes, and each business process is defined by a set of sub
processes.
 Business process reengineering (BPR) is an approach to change management in
which the related tasks required to obtain a specific business outcome are
radically redesigned.
4.5.1 A BPR Model:
 Business process reengineering is an iterative process.
 Business goals and the processes that achieve them must be adapted to a
changing business environment.
 For this reason, there is no start and end to BPR—it is an evolutionary
process. A model for business process reengineering is depicted in Figure
below.
CS8494/SE TESTING AND IMPLEMENTATION UNIT IV
Fig: A BPR Model
The model defines six activities:
Business definition. Business goals are identified within the context of four
key drivers: cost reduction, time reduction, quality improvement, and
personne development and empowerment. Goals may be defined at the
business level or for a specific component of the business.
Process identification. Processes that are critical to achieving the goals
defined in the business definition are identified. They may then be ranked by
importance, by need for change, or in any other way that is appropriate for the
reengineering activity.
Process evaluation. The existing process is thoroughly analyzed and
measured Process tasks are identified; the costs and time consumed by
process tasks ar noted; and quality/performance problems are isolated.
Process specification and design. Based on information obtained during the
first three BPR activities, use cases (Chapters 5 and 6) are prepared for each
process that is to be redesigned. Within the context of BPR, use cases identify a
scenario that delivers some outcome to a customer. With the use case as the
specification of the process, a new set of tasks are designed for the process.
Prototyping. A redesigned business process must be prototyped before it is
fully integrated into the business. This activity “tests” the process so that
refinements can be made.
Refinement and instantiation. Based on feedback from the prototype, the
business process is refined and then instantiated within a business system.
4.5.2 Reengineering Process Model:
These activities occur in a linear sequence, but this is not always the case.
The reengineering paradigm shown below is a cyclical model.
CS8494/SE TESTING AND IMPLEMENTATION UNIT IV
Fig: A software reengineering process model
Inventory analysis:
 Every software organization should have an inventory of all applications.
 The inventory can be nothing more than a spreadsheet model containing
information that provides a detailed description (e.g., size, age, business
criticality) of every active application.
 It is important to note that the inventory should be revisited on a regular cycle.
Document restructuring:
What causes Document restructuring?
Any software organization must choose the one that is most appropriate for
each case.
 Creating documentation is far too time consuming
 Documentation must be updated, but your organization has limited resources.
 The system is business critical and must be fully re documented.
Reverse Engineering:
 In this, the information are collected from the given or exist application.
 It takes less time than forward engineering to develop an application.
 In reverse engineering the application are broken to extract knowledge or
its architecture.
 Reverse engineering for software is the process of analyzing a program in
an effort to create a representation of the program at a higher level of
abstraction than source code.
 The term reverse engineering has its origins in the hardware world. A
company disassembles a competitive hardware product in an effort to
understand its competitor’s design and manufacturing “secrets.”
 Reverse engineering for software is quite similar. In most cases, however,
the program to be reverse engineered is not a competitor’s. Rather, it is the
company’s own work (often done many years earlier).
 Reverse engineering is a process of design recovery.
 Reverse engineering tools extract data, architectural, and procedural design
information from an existing program.
Code Restructuring:
 The most common type of reengineering is code restructuring.
 Here, the source code is analyzed using a restructuring tool. Violations of
structured programming constructs are noted and code is the restructured
CS8494/SE TESTING AND IMPLEMENTATION UNIT IV
(this can be done automatically) or even rewritten in a more modern
programming language.
 The resultant restructured code is reviewed and tested to ensure that no
anomalies have been introduced. Internal code documentation is updated.
Data Restructuring:
 Data restructuring is a full-scale reengineering activity.
 In most cases, data restructuring begins with a reverse engineering activity.
Current data architecture is dissected, and necessary data models are
defined.
 Data objects and attributes are identified, and existing data structures are
reviewed for quality.
Forward engineering:
 Forward Engineering is a method of creating or making an application with
the help of the given requirements.
 Forward engineering is also known as Renovation and Reclamation.
Forward engineering is required high proficiency skill.
 It takes more time to construct or develop an application
4.5.3 Reverse Engineering
Reverse engineering can extract design information from source code, but the
abstraction level, the completeness of the documentation, the degree to which
tools and a human analyst work together, and the directionality of the process
are highly variable. The core of reverse engineering is an activity called extract
abstractions.
The abstraction level:
 The abstraction level of a reverse engineering process and the tools used to
effect it refers to the sophistication of the design information that can be
extracted from source code.
 The abstraction level should be as high as possible. That is, the reverse
engineering process should be capable of deriving procedural design
representations (a low-level abstraction), program and data structure
information (a somewhat higher level of abstraction), object models, data
and/or control flow models (a relatively high level of abstraction), and
entity relationship models (a high level of abstraction).
The completeness level:
 The completeness of a reverse engineering process refers to the level of detail
CS8494/SE TESTING AND IMPLEMENTATION UNIT IV
that is provided at an abstraction level. In most cases, the completeness
decreases as the abstraction level increases.
 For example, given a source code listing, it is relatively easy to develop a
complete procedural design representation.


Reverse Engineering to Understand Data:
o Reverse engineering of data occurs at different levels of abstraction and is often
the first reengineering task.
o At the program level, internal program data structures must often be reverse
engineered as part of an overall reengineering effort.
o At the system level, global data structures (e.g., files, databases) are often
reengineered to accommodate new database management paradigms (e.g., the
move from flat file to relational or object-oriented database systems).
Internal data structures:
o Reverse engineering techniques for internal program data focus on the definition
of classes of objects. This is accomplished by examining the program code with
the intent of grouping related program variables. In many cases, the data
organization within the code identifies abstract data types.
Database structure:
o Regardless of its logical organization and physical structure, a database allows
the definition of data objects and supports some method for establishing
relationships among the objects.
CS8494/SE TESTING AND IMPLEMENTATION UNIT IV
o Reengineering one database schema into another requires an understanding of
existing objects and their relationships. The following steps may be used to
define the existing data model as a precursor to reengineering a new database
model:
(1) build an initial object model,
(2) determine candidate keys (the attributes are examined to determine
whether they are used to point to another record or table; those that serve
as pointers become candidate keys),
(3) refine the tentative classes,
(4) define generalizations, and
(5) discover associations using techniques that are analogous to the CRC
approach.
Reverse Engineering to Understand Processing:
o Reverse engineering to understand processing begins with an attempt to
understand and then extract procedural abstractions represented by the
source code. To understand procedural abstractions, the code is analyzed at
varying levels of abstraction: system, program, component, pattern, and
statement.
o The overall functionality of the entire application system must be
understood before more detailed reverse engineering work occurs. This
establishes a context for further analysis and provides insight into
interoperability issues among applications within the system.
o A block diagram, representing the interaction between these functional
abstractions, is created. Each component performs some subfunction and
represents a defined procedural abstraction.
o A processing narrative for each component is developed. In some situations,
system, program, and component specifications already exist. When this is
the case, the specifications are reviewed for conformance to existing code.
Reverse Engineering to Understand User Interface
o The redevelopment of user interfaces has become one of the most common
types of reengineering activity. But before a user interface can be rebuilt,
reverse engineering should occur. To fully understand an existing user
interface, the structure and behavior of the interface must be specified.
o Merlo and his colleagues suggest three basic questions that must be
answered as reverse engineering of the UI commences:
CS8494/SE TESTING AND IMPLEMENTATION UNIT IV
 What are the basic actions (e.g., keystrokes and mouse clicks) that the
interface must process?
 What is a compact description of the behavioral response of the system to
these actions?
 What is meant by a “replacement,” or more precisely, what concept of
equivalence of interfaces is relevant here?
It is important to note that a replacement GUI may not mirror the old interface
exactly (in fact, it may be radically different). It is often worthwhile to develop a
new interaction metaphor. For example, an old UI requests that a user provide a
scale factor (ranging from 1 to 10) to shrink or magnify a graphical image. A
reengineered GUI might use a slide-bar and mouse to accomplish the same
function.

Forward Engineering:
o The forward engineering process applies software engineering principles,
concepts, and methods to re-create an existing application.
o In most cases, forward engineering does not simply create a modern
equivalent of an older program.

New user and technology requirements are integrated into the reengineering
effort. The redeveloped program extends the capabilities of the older application.
Forward Engineering for Client-Server Architectures:
 Many main frame applications have been reengineered to accommodate client-
server architecture(including web apps). In essence, centralized computing
resources(including software) are distributed among many cliebt platforms.
 Although a variety of different distributed environments can be designed, the
typical mainframe application that is reengineered into a client-server
architecture has the following features:
 Application functionality migrates to each client computer.
 New GUI interfaces are implemented at the client sites. • Database
functions are allocated to the server.
 Specialized functionality (e.g., compute-intensive analysis) may remain at
the server site.
CS8494/SE TESTING AND IMPLEMENTATION UNIT IV
 New communications, security, archiving, and control requirements must
be established at both the client and server sites.
Three layers of abstraction can be identified.
Database foundation layer:
o The functions of the existing database management system and the data
architecture of the existing database must be reverse engineered as a
precursor to the redesign of the database foundation layer.
o The client-server database is reengineered to ensure that transactions are
executed in a consistent manner, that all updates are performed only by
authorized users, that core business rules are enforced, that queries can be
accommodated efficiently, and that full archiving capability has been
established.
The business rules layer:
 The business rules layer represents software resident at both the client
and the server. This software performs control and coordination tasks to
ensure that transactions and queries between the client application and
the database conform to the established business process.
The client applications layer:
 The client applications layer implements business functions that are
required by specific groups of end users.
Forward Engineering for Object-Oriented Architectures:
o Object-oriented software engineering has become the development
paradigm of choice for many software organizations.
o The existing software is reverse engineered so that appropriate data,
functional, and behavioral models can be created. If the reengineered
system extends the functionality or behavior of the original application,
use cases are created. The data models created during reverse engineering
are then used in conjunction with CRC modeling to establish the basis for
the definition of classes.
o Class hierarchies, object-relationship models, object-behavior models, and
subsystems are defined, and object-oriented design commences.
*************