Scribd
Upload
31 views

Introduction To V&V Techniques and Principles

This document provides an introduction to software verification and validation techniques, including human-based testing, formal correctness proofs, and machine-based testing. It discusses definitions of testing, the evolving attitudes around testing from the 1950s to the 2000s, and challenges like invalid inputs and who should perform the testing. Key techniques covered are black-box and white-box testing.

Uploaded by

jhaumosha
Copyright
© © All Rights Reserved
Available Formats
Download as PDF, TXT or read online on Scribd
31 views

Introduction To V&V Techniques and Principles

This document provides an introduction to software verification and validation techniques, including human-based testing, formal correctness proofs, and machine-based testing. It discusses definitions of testing, the evolving attitudes around testing from the 1950s to the 2000s, and challenges like invalid inputs and who should perform the testing. Key techniques covered are black-box and white-box testing.

Uploaded by

jhaumosha
Copyright
© © All Rights Reserved
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 34

Introduction to V&V Techniques

and Principles
Software Design and Development
with a focus on
Software Testing and Verification
Lecture 2

Verification and Validation


at the unit/component-level of system
development, is what this course is mostly
about.
Adds value...by improving product quality and
reducing risks.
Three approaches:
Human-based testing
Formal correctness proofs
Machine-based testing

Human-Based Testing
Desk Checking, Walkthroughs, Reviews /
Inspections
Applicable to requirements / specifications,
design, code, proof of correctness arguments,
test plans / designs / cases, maintenance
plans, etc.
Can be extremely effective...

Formal Correctness Proofs


pre-condition

{X2}
SP2 := 4
while SP2 <= X

loop invariant

{ ( i SP2 = 2 &
(i-1)
2 X) & (X = X) }

SP2 := SP2 * 2
end_while
i
{ ( i SP2 = 2 > X & 2(i-1) X) & (X = X) }
post-condition

Formal Correctness Proofs (contd)


Require formal specifications and appropriate
proof methods.
Do not eliminate the need for testing.

Machine-Based Testing
Execution of (crafted) test cases
Actual and expected results (i.e., program
behaviors) are compared.

Definitions of TESTING
Hetzel: Any activity aimed at evaluating an
attribute or capability of a program or system.
It is the measurement of software quality.
Beizer: The act of executing tests. Tests are
designed and then executed to demonstrate
the correspondence between an element and
its specification.

Definitions of TESTING (contd)


Myers: The process of executing a program
with the intent of finding errors.
IEEE: The process of exercising or evaluating a
system or system component by manual or
automated means to verify that it satisfies
specified requirements or to identify
differences between expected and actual
results.

Definitions of TESTING (contd)


Testing undertaken to demonstrate that a
system performs correctly is sometimes
referred to as validation testing.
Testing undertaken to expose defects is
sometimes referred to as defect testing.

Evolving Attitudes About Testing


1950s
Machine languages used
Testing is debugging
1960s
Compilers developed
Testing is separate from debugging

Evolving Attitudes About Testing (contd)


1970s
Software engineering concepts introduced
Testing begins to evolve as a technical
discipline
1980s
CASE tools developed
Testing expands to Verification and Validation
(V&V)

Evolving Attitudes About Testing (contd)


1990s
Increased focus on shorter development
cycles
Quality focus increases
Testing skills and knowledge in greater
demand
Increased acceptance of testing as a
discipline

Evolving Attitudes About Testing (contd)


2000s
More focus on shorter development cycles
Increased use of Agile methods: Test-First /
Test-Driven Development, customer
involvement in testing, and the use of
automated testing frameworks (e.g., JUnit)
Better integration of testing / verification /
reliability ideas
Growing interest in software safety,
protection, and security

Lets Pause for a Moment


Imagine that its summertime and that a
3-day weekend is just starting Wouldnt
it be great to just grab a fishin pole and
head on out to the lake!

Fishermans Dilemma
You have 3 days for fishing and 2 lakes from
which to choose. Day 1 at lake X nets 8 fish.
Day 2 at lake Y nets 32 fish. Which lake do
you return to for day 3?
Does your answer depend on any
assumptions?

Di Lemma
In general, the probability of the existence of
more errors in a section of a program is
directly related to the number of errors
already found in that section.

Invalid and Unexpected Inputs


Test cases must be written for INVALID and
UNEXPECTED, as well as valid and expected,
input conditions.
In many systems, MOST of the code is
concerned with input error checking and
handling.

Anatomy of a Test Case


What are the parts of a test case?
1. a description of input condition(s)
2. a description of expected results
Where do expected results come from?

Who Should Test Your Program?


Most people are inclined to defend what they
produce not find fault with it.
Thus, programmers should in principle avoid
testing their own programs.
But what if this is not possible or appropriate?

Testing Techniques
Black-Box: Testing based solely on analysis
of requirements (unit/component
specification, user documentation, etc.). Also
know as functional testing.
White-Box: Testing based on analysis of
internal logic (design, code, etc.). (But
expected results still come from
requirements.) Also known as structural
testing.

Testing Techniques
Black-Box: Testing based solely on analysis
of requirements (unit/component
specification, user documentation, etc.). Also
know as functional testing.
White-Box: Testing based on analysis of
internal logic (design, code, etc.). (But
expected results still come from
requirements.) Also known as structural
testing.

You might also like