Software

Engineering
• Software Testing
• Component Testing
• White-Box Testing
• Black-Box Testing
• Integration Testing
• Top-Down Integration
• Bottom-Up Integration
• Continuous Integration
Defining Software Testing

• Software testing is the process of evaluating and verifying that a

software product or application does what it’s supposed to do.
• During software testing, an application is executed using test data.
Output of the application is then used to find errors, anomalies and
information about the program's non-functional attributes.
• The benefits of good testing include identifying bugs and improving
performance.
Defining Software Testing
• Testing within the context of software engineering is actually a series
of steps that are implemented sequentially.
• Initially, tests focus on each component individually, ensuring that it functions
properly as a unit. Hence, the name unit testing. Unit testing makes heavy use
of testing techniques that exercise specific paths in a component’s control
structure to ensure complete coverage and maximum error detection.
• Next, components must be assembled or integrated to form the complete
software package. Integration testing is done here. Test-case design
techniques that focus on inputs and outputs are more prevalent during
integration.
Defining Software Testing
• After the software has been integrated (constructed), a set of high-order tests
is conducted known as validation testing. Validation testing provides final
assurance that software meets all functional, behavioral, and performance
requirements.
Component Testing
• Component testing focuses on the smallest unit of software design
i.e. the software component or module.
• Using the component-level design description as a guide, important
control paths are tested to uncover errors within the boundary of the
module.
• Component testing focuses on the internal processing logic and data
structures within the boundaries of a component and can be
conducted in parallel for multiple components.
Component Testing
• As a component is not a stand-alone program, driver and stub software must
often be developed for each component test.
• In most applications a driver is nothing more than a “main program” that accepts
test-case data, passes such data to the component (to be tested), and prints
relevant results.
• Stubs serve to replace modules that are subordinate (invoked by) the component
to be tested. A stub or “dummy subprogram” uses the subordinate module’s
interface, may do minimal data manipulation, prints verification of entry, and
returns control to the module undergoing testing.
• Drivers and stubs represent testing “overhead.” That is, both are software that
must be coded but not delivered with the final software product. If drivers and
stubs are kept simple, actual overhead can be kept relatively low.
Component Testing
Component Testing
• Any software component can be tested in one of two ways:
• Knowing the intended functionalities of the component, tests can be
conducted to find out whether that component is successfully performing its
intended functionalities or not. This approach takes an external view and is
called black-box testing.
• Knowing the internal details of the component, tests can be conducted to
ensure that all internal operations are performed correctly and according to
specifications. This approach requires an internal view and is termed white-
box testing.
White-Box Testing
• White-box testing also known as glass-box testing examines the
internal workings of the software, including its code, logic, and
algorithms, to identify potential defects and improve code quality.
• For conducting white box testing, tester should have full knowledge of
the internal structure, logic, and code of the software as he should
focus in how the system works by testing internal paths, decisions,
and logic of the code.
• For example in the Library Management System, the tester might:
• Examine the source code of the borrowBook() function
• Write test cases to ensure all if-else paths are executed
White-Box Testing
• Purpose of White Box testing is to identify and resolve issues related
to code quality and logic errors.
• Using white-box testing methods, you can derive test cases that
• Guarantee that all independent paths within a module have been exercised at
least once
• Exercise all logical decisions on their true and false sides
• Execute all loops at their boundaries and within their operational bounds
White-Box Testing: Basis Path
Testing
• Basis path testing is a white-box testing technique first proposed by
Tom McCabe.
• 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.
• Test cases derived to exercise the basis set are guaranteed to execute
every statement in the program at least one time during testing.
• Before the basis path method can be introduced, a simple notation
for the representation of control flow, called a flow graph must be
introduced. The flow graph simply depicts logical control flow.
White-Box Testing: Basis Path
Testing
• To illustrate the use of a flow graph, consider the procedural design representation below. First a
flowchart is used to depict program control structure and then it is mapped into a corresponding
flow graph
White-Box Testing: Basis Path
Testing
• In the flow graph, each circle, called a flow graph node, represents
one or more procedural statements. A sequence of process boxes and
a decision diamond can map into a single node.
• The arrows on the flow graph, called edges or links, represent flow of
control and are analogous to flowchart arrows.
• Areas bounded by edges and nodes are called regions. When counting
regions, we also include the area outside the graph as a region.
White-Box Testing: Basis Path
Testing
• An independent path is any path through the program that introduces at least one new
set of processing statements or a new condition.
• When stated in terms of a flow graph, 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 on the previous slide is
• Path 1: 1-11
• Path 2: 1-2-3-4-5-10-1-11
• Path 3: 1-2-3-6-8-9-10-1-11
• Path 4: 1-2-3-6-7-9-10-1-11
• Note that each new path introduces a new edge.
• The path “1-2-3-4-5-10-1-2-3-6-8-9-10-1-11” is not considered to be an independent
path because it is simply a combination of already specified paths and does not traverse
any new edges.
White-Box Testing: Basis Path
Testing
• Paths 1 through 4 constitute a basis set for the flow graph. That is, if
you can design tests to force execution of these paths (a basis set),
every statement in the program will have been guaranteed to be
executed at least one time and every condition will have been
executed on its true and false sides.
White-Box Testing: Basis Path
Testing
• How do you know how many paths to look for?
• The computation of cyclomatic complexity provides the answer.
Cyclomatic complexity is a software metric that provides a
quantitative measure of the logical complexity of a program.
• When used in the context of the basis path testing method, the value
computed for cyclomatic complexity defines the number of
independent paths of a program and provides you with an upper
bound for the number of tests that must be conducted to ensure that
all statements have been executed at least once.
White-Box Testing: Basis Path
Testing
• Cyclomatic complexity is computed in one of three ways:
• The number of regions of the flow graph corresponds to the cyclomatic
complexity.
• 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.
• 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.
White-Box Testing: Basis Path
Testing
• Referring to the flow graph , the cyclomatic complexity can be
computed using each of the algorithms just noted:
• The flow graph has four regions.
• V (G) = 11 edges - 9 nodes + 2 = 4
• V (G) = 3 predicate nodes + 1 = 4
• Therefore, the cyclomatic complexity of the flow graph is 4.
• The value for V (G) provides an upper bound for the number of
independent paths that is an upper bound on the number of tests
that must be designed and executed to guarantee coverage of all
program statements.
White-Box Testing: Loop Testing
• Loop testing is a white-box testing technique that focuses exclusively
on the validity of loop constructs. Two different classes of loops are
simple loops and nested loops.
White-Box Testing: Loop Testing
• The following set of tests can be applied to simple loops, where n is
the maximum number of allowable passes through the loop.
• Skip the loop entirely.
• Only one pass through the loop.
• Two passes through the loop.
• m pass through the loop where m < n.
• n - 1, n, n + 1 passes through the loop.
White-Box Testing: Loop Testing
• If we were to extend the test approach for simple loops to nested
loops, the number of possible tests would grow geometrically as the
level of nesting increases. This would result in an impractical number
of tests.
• A practical approach that will help to reduce the number of tests is:
• Start at the innermost loop. Set all other loops to minimum values.
• Conduct simple loop tests for the innermost loop while holding the outer
loops at their minimum iteration parameter (e.g., loop counter) values.
• Work outward, conducting tests for the next loop, but keeping all other outer
loops at minimum values and other nested loops to “typical” values.
• Continue until all loops have been tested.
Black Box Testing
• Black box testing, also known as functional testing, assesses the software's
functionality from the user's perspective without any knowledge of the internal
implementation.
• Purpose of Black Box testing is to verify that the software functions as expected
and meets the specified requirements from a user's perspective.
• The tester only checks the input and expected output by Focusing on what the
system does, not how it does it.
• For example in the Library Management System, the tester might:
• Enter a book title in the search bar
• Click “Search”
• Check if relevant books appear in results
• He don’t care how the search function is implemented in the code.
Black Box Testing
• Due to time and budget considerations, it is practically impossible to
perform exhausting testing for each possible input test data,
especially when there is a large pool of input combinations.
• We need an easy way or special techniques that can select test cases
intelligently from the pool of test-case, such that all test scenarios are
covered. Two such techniques are
• Equivalence Partitioning
• Boundary Value Analysis
Black Box Testing
• Equivalence partitioning is a black-box testing method where a range
of input values are divided into equivalence data classes.
• In this, the tester tests a random input value from the defined interval
of equivalence data classes and if the output for that input value is
valid, then the whole class interval is considered valid and vice versa.
Black Box Testing
• Example: An application allow the user to enter the password of
length 8-12 numbers (minimum 8 and maximum 12 numbers).
Invalid Equivalence Class Valid Equivalence Class Invalid Equivalence Class

<8 8-12 >12

• Let’s consider some password values for valid and invalid class
• 1234 is of length 4 which is an invalid password as 4<8.
• 567890234 is of length 9 which is a valid password as 9 lies between 8-12
• 4536278654329 is of length 13 which is an invalid password as 13>12.
Black Box Testing
• Boundary Value Analysis is the process of testing between extreme ends or
boundaries between partitions of the input values.
• It is mostly used technique as it is believed that software is most likely to
fail at upper and lower limits of input data values.
• The basic idea in boundary value testing is to select input variable values at
their:
• Minimum
• Just below the minimum
• Just above the minimum
• A nominal value
• Just below the maximum
• Maximum
• Just above the maximum
Black Box Testing
• Example: A software allows people of age 20 to 50 years (both 20 and
50 are inclusive) to fill a form, for which the user has to enter his age
in the age field option of the software.
• The boundary values are 20 (min value) and 50 (max value).

Valid Value
Invalid Value (min-1) (min, min+1, nominal value, Invalid Value (max+1)
max-1, max)
19 20, 21, 30, 49, 50 51
Black Box Testing: Example
• Let’s say your Library Management System allows users to borrow up to 5
books at a time.

• So you test:
• A valid input: 3 (falls within 0–5)
• An invalid input: -1 (below range)
• Another invalid input: 6 (above range).
• You save time by not testing every single value (0,1,2,3,4,5), just one from
each category.
Black Box Testing: Example
• Again, consider the same book borrowing rule: a user can borrow
between 0 and 5 books.
• Boundary Values:
• Minimum = 0 Maximum = 5
• Test cases using Boundary Value Analysis are
Test Input Purpose
-1 Just below minimum (invalid)
0 Minimum boundary (valid)
1 Just above minimum (valid)
4 Just below maximum (valid)
5 Maximum boundary (valid)
6 Just above maximum (invalid)
Black Box Testing
• During Black Box testing, both Boundary Value Analysis and
Equivalence Partitioning are used together as one helps in finding
bugs at boundaries and another helps to determine bugs that exist
between the defined range of input data values.
Integration Testing
• Integration testing is a type of software testing in which individual
components (usually modules or classes) are combined and tested
together to expose defects in their interactions.
• During Integration testing multiple parts of a software are gradually
integrated and then tested as a group.
Integration Testing
• Consider a software consisting of 10 different modules. Each of these modules
are unit tested. They all pass, which means they work well individually.
• However, conflicts can arise when these modules are integrated together, for
several reasons:
• Data can be lost across an interface
• One component can have an adverse effect on another
• Sub-functions, when combined, may not produce the desired major function
• Individually acceptable imprecision may be magnified to unacceptable levels
• global data structures can present problems.
• Testers must perform integration testing to check this. Out of the 10 modules,
testers can first choose and integrate 2 modules. If these modules interact
smoothly, they carry on with another 2 modules, until all modules are tested.
Integration Testing
• The objective of integration testing is to take unit-tested components
and build a program structure that has been dictated by design.
• There is often a tendency to attempt non-incremental integration;
that is, to construct the program using a “big bang” approach. All
components are combined in advance and the entire program is
tested as a whole.
• Chaos usually results! Errors are encountered, but correction is
difficult because isolation of causes is complicated by the vast
expanse of the entire program.
Integration Testing
• Incremental integration is the exact opposite of the big bang
approach. The program is constructed and tested in small increments,
where errors are easier to isolate and correct; interfaces are more
likely to be tested completely; and a systematic test approach may be
applied.
• The incremental integration strategies are:
• Top-down Integration
• Bottom-up Integration
Integration Testing: Top-Down
Integration
• In Top-down integration, modules are integrated by moving
downward through the control hierarchy, beginning with the main
module (main program) and proceeds towards the sub modules.
• Submodules are integrated into the structure in either a depth-first or
breadth-first manner.
Integration Testing: Top-Down
Integration
• The integration process is performed in a series of five steps:
• The main control module is used as a test driver and stubs are substituted for all
components directly subordinate to the main control module.
• Depending on the integration approach selected (i.e., depth or breadth first),
subordinate stubs are replaced one at a time with actual components.
• Tests are conducted as each component is integrated.
• On completion of each set of tests, another stub is replaced with the real
component.
• The process continues from step 2 until the entire program structure is
built.
• The top-down integration strategy verifies control flow early in the test
process.
Integration Testing: Top-Down
Integration
Integration Testing: Bottom-Up
Integration
• Bottom-up integration testing, as its name implies, begins
construction and testing with atomic modules (i.e., components at
the lowest levels in the program structure).
• Because components are integrated from the bottom up, the
functionality provided by submodules components to the given
component is always available and the need for stubs is eliminated.
Integration Testing: Bottom-Up
Integration
• A bottom-up integration strategy may be implemented with the following
steps:
• Low-level components are combined into clusters that perform a specific software sub-
function.
• A driver (a control program for testing) is written to coordinate test-case input and
output.
• The cluster is tested.
• Drivers are removed and clusters are combined moving upward in the program
structure.
• As integration moves upward, the need for separate test drivers lessens. In
fact, if the top two levels of program structure are integrated top down, the
number of drivers can be reduced substantially and integration of clusters is
greatly simplified.
Integration Testing: Bottom-Up
Integration
Example of how to do
Integration Testing
• The web application for booking flights is designed to provide a
hassle-free booking experience. The System Under Test (SUT)
comprises various modules. Each module serves a specific role to
provide a flawless user experience.
• The primary module functions as a user interface, making it easier for
users to engage with the application. The interface lets users enter
their travel preferences, including date, destination, departure cities,
and passenger details.
Example of how to do
Integration Testing
• The searching flight module processes the primary module user input.
It searches a flight database or other APIs for available flights that
meet the criteria supplied. The module then presents the search
findings, which include flight choices, schedules, airlines, and pricing.
• The payment module manages the safe and effective processing of
payments for the chosen flights. After the user has finished the
payment procedure, the confirmation module creates a booking
confirmation. This confirmation contains booking references,
passenger names, and other crucial details. It can be sent to the user
or printed.
Example of how to do
Integration Testing
• Top-Down Approach Example
• The top-down testing starts by validating the primary module
separately. It means the primary module is tested independently from
the subordinate modules without integration.
• The lower modules are then integrated and tested one at a time once
the main module has passed each of its independent tests. The flight
search module is first integrated and tested with the primary module.
The payment module is then integrated, tested, and finally, the
confirmation module. The process continues until all of the units are
integrated and tested.
Example of how to do
Integration Testing
• Bottom-Up Approach Example
• The flight search, payment, and confirmation modules are unit tested,
ensuring they work as intended. First, the payment and search flight
modules are combined and tested. This test verifies that customers
can correctly complete all aspects of the booking procedure, including
searching for flights and making payments.
• Then, search flight and confirmation modules are combined to ensure
that consumers receive confirmations of bookings after finishing the
payment procedure. The process continues until all the modules are
tested.
Example of how to do
Integration Testing
• Big-Bang Approach Example
• All modules, including primary, flight search, payment, and
confirmation, are combined into a single system under the Big-Bang
technique. Several test cases are carried out to evaluate how well the
system functions, interacts, and performs.