0% found this document useful (0 votes)
15 views

Testing Unit 3

Uploaded by

Kamna Choudhary
Copyright
© © All Rights Reserved
Available Formats
Download as PPT, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
15 views

Testing Unit 3

Uploaded by

Kamna Choudhary
Copyright
© © All Rights Reserved
Available Formats
Download as PPT, PDF, TXT or read online on Scribd
You are on page 1/ 24

Software Testing

“Testing is the process of


executing a program with the
intention of detecting errors."
Objective
The objective of this presentation is to
show the
 How to define Software Testing

Principles
 What are the types of Software Tests

 What is Test Planning

 Test Execution and Reporting

 Real-Time Testing
How to define Software
Testing Principles
 Testing
The execution of a program to find its faults
 Verification
The process of proving the programs
correctness.
 Validation
The process of finding errors by executing
the program in a real environment
 Debugging
Diagnosing the error and correct it
Software Testing Principles
 To remove as many defects as possible
before test since the quality
improvement potential of testing is
limited
What are the Types of
Software Tests
 Unit Testing (White Box)
 Integration Testing
 Function Testing (Black Box)
 Regression Testing
 System Test
 Acceptance and Installation Tests
Unit Testing (White Box
OR GLASS BOX)
 Individual components are tested.
 It is a path test.
 To focus on a relatively small segment
of code and aim to exercise a high
percentage of the internal path
 Disadvantage: the tester may be biased
by previous experience. And the test
value may not cover all possible values.
Integration Testing
 Top-down Integration Test
 Bottom-up Integration Test
Top-down Integration Test
 The control program is tested first.
Modules are integrated one at a time.
Emphasize on interface testing
 Advantages: No test drivers needed

Interface errors are discovered early


Modular features aid debugging
 Disadvantages: Test stubs are needed

Errors in critical modules at low levels are


found late.
Top-down Testing

T1
T1 A
A
T2
T2 B

B T3
T3 C
T4
Bottom-up Integration Test
 Allow early testing aimed at proving
feasibility
Emphasize on module functionality and
performance
 Advantages: No test stubs are needed
Errors in critical modules are found early
 Disadvantages: Test drivers are needed
Interface errors are discovered late
Bottom-up
testing

Test Test Test


Drivers Drivers Drivers

Level N Level N Level N

Test Test
Drivers Drivers

Level N-1 Level N-1


Function Testing (Black
Box)
 Designed to exercise the to its
external specifications
 Testers not biased by knowledge of
the program’s design.
 Disadvantages:
1. The need for explicitly stated
requirements
2. Only cover a small portion of the
possible test conditions.
Regression Testing
 Test the effects of the newly introduced
changes on all the previously integrated
code.
 The common strategy is to accumulate a
comprehensive regression bucket but also
to define a subset.
 The full bucket is run only occasionally, but
the subset is run against every spin.
 Disadvantages:
1. To decide how much of a subset to use and
which tests to select.
What is Test Planning
 Define the functions, roles and methods for
all test phases.
 Test planning usually start during the
requirements phase.
 Major test plan elements are:
1. Objectives for each test phase
2. Schedules and responsibilities for each test
activity
3. Availability of tools, facilities and test
libraries.
4. Set the criteria for test completion
Test Execution & Reporting
 Testing should be treated like an
experiment.
 Testing require that all anomalous
behavior be noted and investigated.
 Big companies keep a special library
with all copies of test reports, incident
forms, and test plans
Real-Time Testing
 Real-Time testing is necessary because the
deployment system is usually more complicate
than development system
 Rules apply for testing real time system
1. Evaluate possible deadlocks, thrashing to
special timing conditions
2. Use tests to simulate hardware faults.
3. Use hardware simulation to stress the software
design.
4. Design ways to simulate modules missing in the
development system.
Static Analysis
 Static analysis, also called static code analysis, is a
method of computer program debugging that is done by
examining the code without executing the program.
 Generally, static analysis occurs before software testing in early development.
 Static analysis is generally good at finding coding issues such as:
• Programming errors
• Coding standard violations
• Undefined values
• Syntax violations
• Security vulnerabilities
Types of static analysis

 There are several static analysis methods an organization could use,


which include:
• Control analysis -- focuses on the control flow in a calling structure.
For example, a control flow could be a process, function, method or in
a subroutine.
• Data analysis -- makes sure defined data is properly used while also
making sure data objects are properly operating.
• Fault/failure analysis -- analyzes faults and failures in model
components.
• Interface analysis -- verifies simulations to check the code and
makes sure the interface fits into the model and simulation.
Symbolic execution
 Symbolic execution is a software testing technique that is useful to aid
the generation of test data and in proving the program quality.
 symbolic execution is a way of executing a program
abstractly, so that one abstract execution covers multiple
possible inputs of the program that share a particular
execution path through the code.
 Symbolic execution is a method of
analyzing a smart contract by
executing functions using symbolic
values (e.g., x > 5 ) instead of
concrete values (e.g., x == 5 ).
Control Flow Graph
 A Control Flow Graph (CFG) is the graphical representation of control
flow or computation during the execution of programs or applications.
 In a control-flow graph each node in the graph represents a
basic block, i.e. a straight-line piece of code without any
jumps or jump targets; jump targets start a block, and
jumps end a block. Directed edges are used to represent
jumps in the control flow.
 Control flow testing is a type of white box testing
approach. The goal of this technique is to use a control
structure to determine the execution order of statements or
instructions in a programme.
Cyclomatic complexity
 Cyclomatic complexity is a software metric used to
measure the complexity of a program.
 Thomas J. McCabe developed this metric in 1976.
McCabe interprets a computer program as a set of a
strongly connected directed graph.
 Nodes represent parts of the source code having no
branches and arcs represent possible control flow
transfers during program execution.
 The notion of program graph has been used for this
measure, and it is used to measure and control the
number of paths through a program. The complexity
of a computer program can be correlated with the
Contt.
 How to Calculate Cyclomatic Complexity?
 McCabe proposed the cyclomatic number, V (G) of
graph theory as an indicator of software complexity.
The cyclomatic number is equal to the number of
linearly independent paths through a program in its
graphs representation. For a program control graph G,
cyclomatic number, V (G), is given as:
 V (G) = E - N + 2 * P
 E = The number of edges in graphs G
 N = The number of nodes in graphs G
 P = The number of connected components in graph G .
Case Tools For Software Metrics
 Many CASE tools (Computer Aided Software Engineering tools)
exist for measuring software. They are either open source or
are paid tools. Some of them are listed below:
1. Analyst4j tool is based on the Eclipse platform and
available as a stand-alone Rich Client Application or as an
Eclipse IDE plug-in. It features search, metrics, analyzing
quality, and report generation for Java programs.
2. CCCC(C & C++ Code Counter) is an open source
command-line tool. It analyzes C++ and Java lines and
generates reports on various metrics, including Lines of Code
and metrics proposed by Chidamber & Kemerer and Henry &
Kafura.
3. Chidamber & Kemerer Java Metrics is an open source
command-line tool. It calculates the C&K object-oriented
metrics by processing the byte-code of compiled Java.
Contt..
1. Dependency Finder is an open source. It is a suite of tools
for analyzing compiled Java code. Its core is a dependency
analysis application that extracts dependency graphs and
mines them for useful information. This application comes as a
command-line tool, a Swing-based application, and a web
application.
2. Eclipse Metrics Plug-in 1.3.6 by Frank Sauer is an open
source metrics calculation and dependency analyzer plugin for
the Eclipse IDE. It measures various metrics and detects
cycles in package and type dependencies.
3. Eclipse Metrics Plug-in 3.4 by Lance Walton is open source.
It calculates various metrics during build cycles and warns, via
the problems view, of metrics 'range violations'.
4. OO Meter is an experimental software metrics tool developed
by Alghamdi. It accepts Java/C# source code and UML models
in XMI and calculates various metrics.
5. Semmle is an Eclipse plug-in. It provides an SQL like querying
language for object-oriented code, which allows searching for
bugs, measure code metrics, etc.

You might also like