0% found this document useful (0 votes)
73 views67 pages

Se Unit-4-Psu

The document discusses various types and methods of software testing. It defines software testing as checking if actual results match expected results. There are two main steps: verification ensures correct implementation of functions, while validation ensures software meets customer requirements. Common testing types are white box and black box testing. The document also discusses unit testing, integration testing, regression testing, and techniques like boundary value analysis and cause-effect graphing.

Uploaded by

SpSukumaran
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
73 views67 pages

Se Unit-4-Psu

The document discusses various types and methods of software testing. It defines software testing as checking if actual results match expected results. There are two main steps: verification ensures correct implementation of functions, while validation ensures software meets customer requirements. Common testing types are white box and black box testing. The document also discusses unit testing, integration testing, regression testing, and techniques like boundary value analysis and cause-effect graphing.

Uploaded by

SpSukumaran
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
You are on page 1/ 67

SOFTWARE TESTING

• Software testing is defined as an activity to


check whether the actual results match the
expected .
• The process or method of finding error/s in a
software application or program so that the
application functions according to the end
user's requirement is called software testing.
Fundamentals of testing
Steps
Software testing can be divided into two steps:
1. Verification
2. Validation
1. Verification: it refers to the set of tasks that
ensure that software correctly implements a
specific function.
2. Validation: it refers to a different set of tasks
that ensure that the software that has been
built is traceable to customer requirements.
Verification: “Are we building the product
right?”
Validation: “Are we building the right
product?”
Software testing types
Types
• White box testing
• Black box testing
Cyclomatic Complexity
• Cyclomatic complexity is a source code complexity
measurement that is being correlated to a number of
coding errors. It is calculated by developing a Control Flow
Graph of the code that measures the number of linearly-
independent paths through a program module.
Cyclomatic complexity = E - N + 2 or P+1
where,
• E = number of edges in the flow graph.
• N = number of nodes in the flow graph.
• P = Number of predicate nodes (node that contains condition)
Steps for Basis Path testing

The basic steps involved in basis path testing:


– Draw a control graph
– Calculate Cyclomatic complexity  
– Find a basis set of paths
– Generate test cases to exercise each path
Flow graph notation for a program:
Example 1:
IF A = 10 THEN
IF B > C THEN
A=B
ELSE
A=C
ENDIF
ENDIF
Print A
Print B
Print C
Cyclomatic complexity is 8 - 7 + 2 = 3 or
2+1=3
Example 2:

i = 0;
n=4;
while (i<n-1) do
j = i + 1;
while (j<n) do
if A[i]<A[j] then
swap(A[i], A[j]);
end do;
i=i+1;
end do;
Flow graph for this program will be
Computing mathematically,
• V(G) = 9 - 7 + 2 = 4
• V(G) = 3 + 1 = 4 (Condition nodes are 1,2 and 3
nodes)
• Basis Set - A set of possible execution path of a
program
– 1, 7
– 1, 2, 6, 1, 7
– 1, 2, 3, 4, 5, 2, 6, 1, 7
– 1, 2, 3, 5, 2, 6, 1, 7
Properties of Cyclomatic complexity:

• V (G) is the maximum number of independent


paths in the graph
• V (G) >=1
• G will have one path if V (G) = 1
• Minimize complexity to 10
The common types of logical conditions that are tested using
condition testing are-
• A relation expression, like E1 op E2 where ‘E1’ and ‘E2’ are
arithmetic expressions and ‘OP’ is an operator.
• A simple condition like any relational expression preceded by a
NOT (~) operator. For example, (~E1) where ‘E1’ is an arithmetic
expression and ‘a’ denotes NOT operator.
• A compound condition consists of two or more simple
conditions, Boolean operator, and parenthesis.
For example, (E1 & E2)|(E2 & E3) where E1, E2, E3 denote
arithmetic expression and ‘&’ and ‘|’ denote AND or OR
operators.
• A Boolean expression consists of operands and a Boolean
operator like ‘AND’, OR, NOT.
For example, ‘A|B’ is a Boolean expression where ‘A’ and ‘B’
denote operands and | denotes OR operator.
Black box testing can be done in following ways:
1. Syntax Driven Testing – This type of testing is applied to systems that can be syntactically represented
by some language. For example- compilers, language that can be represented by context free
grammar. In this, the test cases are generated so that each grammar rule is used at least once.
2. Equivalence partitioning – It is often seen that many type of inputs work similarly so instead of giving
all of them separately we can group them together and test only one input of each group. The idea
is to partition the input domain of the system into a number of equivalence classes such that each
member of class works in a similar way, i.e., if a test case in one class results in some error, other
members of class would also result into same error.
The technique involves two steps:
Identification of equivalence class – Partition any input domain into minimum two sets: valid
values and invalid values. For example, if the valid range is 0 to 100 then select one valid input like
49 and one invalid like 104.
Generating test cases –
(i) To each valid and invalid class of input assign unique identification number.
(ii) Write test case covering all valid and invalid test case considering that no two invalid inputs
mask each other.
To calculate the square root of a number, the equivalence classes will be:
(a) Valid inputs:
– Whole number which is a perfect square- output will be an integer.
– Whole number which is not a perfect square- output will be decimal number.
– Positive decimals
(b) Invalid inputs:
– Negative numbers(integer or decimal).
– Characters other that numbers like “a”,”!”,”;”,etc.
• 3. Boundary value analysis – Boundaries are very good places for errors to
occur. Hence if test cases are designed for boundary values of input domain
then the efficiency of testing improves and probability of finding errors also
increase. For example – If valid range is 10 to 100 then test for 10,100 also
apart from valid and invalid inputs.
• 4. Requirement based testing – It includes validating the requirements given
in SRS of software system.
• 5. Compatibility testing – The test case result not only depend on product but
also infrastructure for delivering functionality. When the infrastructure
parameters are changed it is still expected to work properly. Some parameters
that generally affect compatibility of software are:
– Processor (Pentium 3,Pentium 4) and number of processors.
– Architecture and characteristic of machine (32 bit or 64 bit).
– Back-end components such as database servers.
– Operating System (Windows, Linux, etc).
• 6. Cause effect Graphing – This technique establishes relationship between logical input
called causes with corresponding actions called effect. The causes and effects are represented
using Boolean graphs. The following steps are followed:
– Identify inputs (causes) and outputs (effect).
– Develop cause effect graph.
– Transform the graph into decision table.
– Convert decision table rules to test cases.
• For example, in the following cause effect graph:
• It can be converted into decision table like:
REGRESSION TESTING
• A new requirement is added to an existing
feature
• A new feature or functionality is added
• The codebase is fixed to solve defects
• The source code is optimized to improve
performance.
• Changes in configuration.
UNIT TESTING
• UNIT TESTING is a level of software testing where individual units/
components of a software are tested.
• Workflow of Unit Testing:
– Unit Test Plan
• Prepare
• Review
• Rework
• Baseline
– Unit Test Cases/Scripts
• Prepare
• Review
• Rework
• Baseline
– Unit Test
• Perform
key reasons to perform unit testing
• To isolate a section of code.
• To verify the correctness of code.
• To test every function and procedure.
• To fix bug early in development cycle and to
save costs.
• To help the developers to understand the code
base and enable them to make changes quickly.
• To help for code reuse.
• Unit Testing Tools:
Here are some commonly used Unit Testing tools:
1. Jtest
2. Junit
3. NUnit
4. EMMA
5. PHPUnit
• Advantages of Unit Testing:
– Unit Testing allows developers to learn what functionality
is provided by a unit and how to use it to gain a basic
understanding of the unit API.
– Unit testing allows the programmer to refine code and
make sure the module works properly.
– Unit testing enables to test parts of the project without
waiting for others to be completed.
INTEGRATION TESTING
• INTEGRATION TESTING is a level of software testing where individual units
are combined and tested as a group. The purpose of this level of testing is to
expose faults in the interaction between integrated units. Test drivers and
test stubs are used to assist in Integration Testing.
• Integration Test case differs from other test cases in the sense it focuses
mainly on the interfaces & flow of data/information between the
modules. 
• Workflow of Integration Testing:
– Prepare the Integration Tests Plan
– Design the Test Scenarios, Cases, and Scripts.
– Executing the test Cases followed by reporting the defects.
– Tracking & re-testing the defects.
– Steps 3 and 4 are repeated until the completion of Integration is
successful.
Although each software module is unit tested, defects still
exist for various reasons like:

• A Module, in general, is designed by an individual software


developer whose understanding and programming logic may differ
from other programmers. Integration Testing becomes necessary
to verify the software modules work in unity
• At the time of module development, there are wide chances of
change in requirements by the clients. These new requirements
may not be unit tested and hence system integration Testing
becomes necessary.
• Interfaces of the software modules with the database could be
erroneous
• External Hardware interfaces, if any, could be erroneous
• Inadequate exception handling could cause issues.
Approaches, Strategies, Methodologies of
Integration Testing
•  Big Bang Approach -is an Integration testing approach in which all the
components or modules are integrated together at once and then tested as a
unit, Convenient for small systems.
– Disadvantages:
• Fault Localization is difficult.
• some interfaces link to be tested could be missed easily.
• Since all modules are tested at once, high-risk critical modules are not
isolated and tested on priority.  
•  Incremental Approach:  testing is done by integrating two or more modules
that are logically related to each other and then tested for proper functioning
of the application. 
– which is further divided into the following
•  Top Down Approach
•  Bottom Up Approach
• Sandwich Approach - Combination of Top Down and Bottom Up
Stubs and Drivers

• Stubs and Drivers are the dummy programs in


Integration testing used to facilitate the software
testing activity. These programs act as a substitutes
for the missing models in the testing. They do not
implement the entire programming logic of the
software module but they simulate data
communication with the calling module while
testing.
– Stub: Is called by the Module under Test.
– Driver: Calls the Module to be tested.
Bottom-up Integration Testing

• Bottom-up Integration Testing is a strategy in which the lower level


modules are tested first. These tested modules are then further used to
facilitate the testing of higher level modules. The process continues until
all modules at top level are tested. Once the lower level modules are
tested and integrated, then the next level of modules are formed.
• Advantages:
– Fault localization is easier.
– No time  is wasted waiting for all modules to be
developed unlike Big-bang approach
• Disadvantages:
– Critical modules (at the top level of software
architecture) which control the flow of application
are tested last and may be prone to defects.
– An early prototype is not possible
Top-down Integration Testing

• Top Down Integration Testing is a method in which integration testing


takes place from top to bottom following the control flow of software
system. The higher level modules are tested first and then lower level
modules are tested and integrated in order to check the software
functionality. Stubs are used for testing if some modules are not ready.
• Advantages:
– Fault Localization is easier.
– Possibility to obtain an early prototype.
– Critical Modules are tested on priority; major
design flaws could be found and fixed first.
• Disadvantages:
– Needs many Stubs.
– Modules at a lower level are tested inadequately.
Sandwich Testing

• Sandwich Testing is a strategy in which top level modules are tested with
lower level modules at the same time lower modules are integrated with
top modules and tested as a system. It is a combination of Top-down and
Bottom-up approaches therefore it is called Hybrid Integration Testing. It
makes use of both stubs as well as drivers.
VALIDATION TESTING
• Validation testing is the process of ensuring if
the tested and developed software satisfies
the client /user needs.
SYSTEM TESTING
• SYSTEM TESTING is a level of software
testing where a complete and integrated
software is tested
• System testing is a process of testing the
entire system that is fully functional
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.
• Debugging is the activity carried out by the
development team or a developer after getting
the test report about the defects in the
software from the testing team
Symptoms & Causes
• symptom and cause may be geographically
separated
• symptom may disappear when another problem
is fixed
• cause may be due to a combination of non-errors
• cause may be due to a system or compiler error
• cause may be due to assumptions that everyone
believes
• symptom may be intermittent
Consequences of Bugs
Debugging Techniques
• brute force / testing-guessing possible combinations of a
targeted
• Backtracking-backtrack the incorrect results through the
logic of the program until you find the point where the logic
went astray
• Induction- reasoning or thoughtful strategy-start with the
symptoms of the error , possibly in the result of one or
more test cases, and looking for relationship among the
symptoms, the error is often uncovered.
• Deduction- Use the data to eliminate possible causes

You might also like

pFad - Phonifier reborn

Pfad - The Proxy pFad of © 2024 Garber Painting. All rights reserved.

Note: This service is not intended for secure transactions such as banking, social media, email, or purchasing. Use at your own risk. We assume no liability whatsoever for broken pages.


Alternative Proxies:

Alternative Proxy

pFad Proxy

pFad v3 Proxy

pFad v4 Proxy