0% found this document useful (0 votes)
2 views32 pages

Static Techniques

Uploaded by

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

Static Techniques

Uploaded by

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

1

Maveric Systems Limited

Section 3 – Static techniques

Version 1.0

ISEB Foundation Certificate in Software Testing

Copyright © Maveric Systems 2006


2

Presentation Coverage

• Reviews and the Test Process


• The Review Process
• Static Analysis By Tools

Copyright © Maveric Systems 2006


3

Reviews And Test Process

Copyright © Maveric Systems 2006


4

Definition

Static Testing
•Testing of a component or system at specification or
implementation level without execution of that software, e.g.,
reviews or static code analysis
•The process of evaluating a system or component based on its
form, structure, content, documentation
Dynamic Testing
•Testing that involves the execution of the software of a
component or system

Copyright © Maveric Systems 2006


5

Static Testing in SDLC

Copyright © Maveric Systems 2006


6

What is Review?

• An evaluation of a product or project status to ascertain


discrepancies from planned results and to recommend
improvements
• Review is “A retrospective view or survey”
• Review is a process during which a work product – Is
presented to interested parties for comment or approval

Copyright © Maveric Systems 2006


7

Why Review?

• Effective means of isolating incidents


• Isolating incidents at an early stage of development
• Saving substantial time and cost to the development

Copyright © Maveric Systems 2006


8

When to Review?

Review should happen as soon as possible after the item to


be tested has been created

USE

Correctable fault CODING

Cost of
fault
escalates
Major redesign DESIGN

REQUIREMENT
Hidden error SPECIFICATION

Copyright © Maveric Systems 2006


9

What to Review?

• Any document can be subjected to review


• Requirement specification, design specification, code,
test plans, user guides, etc.
• Reviews can also be done for process improvements

Copyright © Maveric Systems 2006


10

Benefits of Review

• Reduce lifetime cost


• Early detection of defects
• Identify omitted requirements
and design errors
• Reduce development timelines
• Identify deviation from standards
and reduce fault levels
• Can require 15% of development
budget and save 35% to 50% of
development time

Copyright © Maveric Systems 2006


11

Review Process

Copyright © Maveric Systems 2006


12

Phases of a Formal Review


• Planning
̶ Selecting the personnel and role allocation
̶ Defining entry and exit criteria
• Kick-off
̶ Explaining objective
̶ Distribution of documents
• Checking entry criteria
• Individual Preparation
̶ Done by each participant

Copyright © Maveric Systems 2006


13

Phases of a Formal Review (CONTD.)


• Review Meeting
̶ Document defects
̶ Prepare Minutes of Meeting
• Rework
̶ Fixing defects found
• Follow-up
̶ Check that defects are fixed
̶ Gathering metrics
̶ Ensure exit criteria are met

Copyright © Maveric Systems 2006


14

Roles in Review
• Manager
• Moderators
• Author
• Reviewers / inspectors
• Recorder / Scribe

Copyright © Maveric Systems 2006


15

Types of Review
• Walkthrough
• Inspection
• Informal Review
• Technical review

Copyright © Maveric Systems 2006


16

Walkthrough
• Purpose : Understanding design and code,
finding defects
• A step-by-step presentation by the author of
a document in order to gather information
and to establish a common understanding of
its content
• Little or no preparation is usually required
• Led by author. Peers are other participants
• Dry runs of design, code and test cases

Copyright © Maveric Systems 2006


17

Inspection
• A type of peer review that relies on visual
examination of documents to detect defects
• A group review quality process for
̶ Product & Process improvement
• Main purpose is to find defects such as
violations of development standards and
non-conformance to higher level
documentation
• Led by moderator
• Reader, Recorder, Author and Inspector are
other participants
• Formal review process
Copyright © Maveric Systems 2006
18

Informal Review
• Unplanned and undocumented
• Find problems quickly and cheaply
• No Formal Process
• Varies in usefulness depending on the reviewer

Copyright © Maveric Systems 2006


19

Technical Review
• Purpose: Understanding design and code,
finding defects
• A step-by-step presentation by the author of a
document in order to gather information and to
establish a common understanding of its content
• Little or no preparation is usually required
• Led by author. Peers are other participants
• Dry runs of design, code and test cases

Copyright © Maveric Systems 2006


20

Comparison of Review Types

Review type Primary Led by Participants


purpose
Walkthrough Educational or Author Peers
Informational
Inspection Finding faults Moderator Reader,
and process Recorder,
improvement Author,
Inspector
Informal Find problems Not defined Not defined
review quickly and
cheaply
Technical Finding faults Chairperson Peers, technical
review experts

Copyright © Maveric Systems 2006


21

Success Factors for Reviews


• Clear predefined objective
• Right people for the objective in hand
• Express defects objectively
• Defects found should be welcomed
• Review the product, not the person
• Choose the appropriate review technique
• Checklist is used to increase effectiveness of
defect identification
• Management support
• Emphasis on learning and Process Improvement

Copyright © Maveric Systems 2006


22

Static Analysis by Tools

Copyright © Maveric Systems 2006


23

Static Analysis by Tools


• Analysis of a program carried out without
executing the program
• Static analysis can detect possible faults such as
̶ Unreachable code
̶ Undeclared variables
̶ Parameter type mismatches, etc.

Copyright © Maveric Systems 2006


24

Static Analysis by Tools (CONTD.)


• Values of Static analysis
̶ Early detection of defects prior to test execution
̶ Identification of defects not easily found by dynamic testing
̶ Improved maintainability of code and design
̶ Detecting dependencies and inconsistencies in software model
• Types of Defects discovered
̶ Undefined variable referencing
̶ Inconsistent interface between modules / components
̶ Redundant / unused variables
̶ Standards violation
̶ Syntax violations of code and model
̶ Security vulnerabilities

Copyright © Maveric Systems 2006


25

Static Analysis by Tools (CONTD.)

Techniques Used by Static Analysis Tools:


•Semantic checking
•Strong type checking
•Memory allocation checking
•Logical statement checking
•Interface and include problem checking
•Security checking
•Metrics
•Crawl source code

Copyright © Maveric Systems 2006


26

Static Analysis by Tools (CONTD.)

Copyright © Maveric Systems 2006


27

Compilers

• A computer program that translates


code expressed in a higher order
language into their machine code
equivalents
• Compiler finds fault in the syntax using
static analysis
• Many compilers also provide
information on variable use

Copyright © Maveric Systems 2006


28

Data Flow Analysis

• A form of static Analysis based on the


definition and usage of variables
• Considers the use of data on paths
through the code
• ‘Definitions’ and ‘Use’
̶ Data definition – use pair
̶ Data definition – ‘C’ use pair
̶ Data definition – ‘P’ use pair

Copyright © Maveric Systems 2006


29

Control Flow Graph

• Control flow graph is defined as a diagrammatic


representation of the possible alternative
control flow paths through a component
• It is an abstract data structure used in
compilers
• It is an abstract representation of a procedure
or program, maintained internally by a
compiler

Copyright © Maveric Systems 2006


30

Control Flow Graph (CONTD.)

Entry 1 if (y<0)

pow=0-y; 2 3 else pow=y

4 z=1.0

while (pow !=0)


5
z=z*x
6 7 if (y<0)
pow=pow-1;

z=1.0/z 8 9 printf(z)
Exit

Copyright © Maveric Systems 2006


31

Complexity Metrics

• ‘Complexity’ can be defined as the degree to


which a system or component has a design or
implementation that is difficult to understand
and verify
• The metrics used to arrive at this complexity
are called complexity metrics
• Lines of code, Cyclomatic complexity

Copyright © Maveric Systems 2006


32

Conclusion

Contents covered
•Review and the Test Process
•Static Review Process
•Static review techniques
•Static Analysis
•Static Analysis using Tools

Copyright © Maveric Systems 2006

You might also like