Module1 - Basics of Software Testing - Lecture Notes

Software Testing (18IS62) 2023
Acharya Institute of Technology

Bangalore-107
Lecture Notes
Name of the Faculty: Pushpalatha K S
Title of the Subject / Subject Code: Software Testing/18IS62
Academic Year / Semester: 2022-2023
Name of the Department: Information Science & Engineering
Module-1:Basics of Software Testing
1.1 Basic Definitions

What is a Software?
Software is a set of instructions to perform some task.
Software is used in many applications of the real world.
Some of the examples are:
 Application software, such as word processors
 Firmware in a embedded system
 Middleware, which controls and co-ordinates distributed systems
 System software such as operating systems
 Video Games
 Websites
All of these applications need to run without any error and provide a quality service to the user of
the application. In this regard the software has to be tested for its accurate and correct working.
What is Software Engineering?
It is a systematic study of flow of software where its mainly concentrates on improving

the quality of software and deliver the software with in the given period of time.
Pushpalatha K.S, Asst.Prof., ISE Dept., AIT, B’lore. Page 1

Software development life-cycle (SDLC)
What is Software Testing?
» Software testing is the process of executing the program with the intent of finding errors.
» Software testing is an important phase of SDLC which requires maximum effort in releasing
the software product to the market.
» Software testing ensures the Quality assurance of the Software product.
» Software testing is the process of conforming that the product/software has been
Manufactured/Developed
- According to Specification
- It is working properly
- It satisfies the customer
The Process of validating & Verifying that a computer program/application/product

 Meets the requirements that guided its design & development
 Works as expected
 Can be implemented with the same characteristics
 And satisfies the needs of customer
Why do we test any Software?

 Quality or Acceptability of the product
 To discover problems or faults in the software.
Error: People make errors (mistakes). In programming language, these mistakes are called as
bugs. Errors tend to propagate from a requirement error to design and then to coding.
Fault: a fault is the result of an error. It is the representation of error where representation is the
mode of expression such as text, dataflow diagram, and source code. There are two types of
faults:
 A fault of commission- occurs when we enter something into a representation that is
incorrect.
 A fault of omission- occurs when we fail to enter correct information.
Failure: Failure is the result of a faults execution. Represents the wrong behaviour of the system

 Failures only occur in an executable representation.

 Relates failure to only to faults of commission.
 Fault the never happen to execute or not execute for a long time.
Incident: Incident is the occurrence/symptoms that alert users or customers about a failure.
Test: The act of exercising software with test cases.
Two goals of test are

 To find failures
 To demonstrate the correct execution.
Test Case: It has an identity and is associated with program behaviour. They also have a set of
inputs and expected outputs.
“A mistake in coding is called error , error found by tester is called defect, defect accepted
by development team then it is called bug ,build does not meet the requirements then it Is
failure.”
Software Quality:
Quality software is reasonably bug or defect free, delivered on time and within budget, meets
requirements and/or expectations, and is maintainable.
Key aspects of quality for the customer include:
 Good design – looks and style

 Good functionality – it does the job well
 Reliable – acceptable level of breakdowns or failure
 Consistency
 Durable – lasts as long as it should
 Good after sales service
 Value for money

Static quality attributes: Refers to the actual code and related documentation.
Static quality attributes include Structured, maintainable, testable code as well as the availability
of correct and complete documentation.
Dynamic quality attributes: Relate to the behavior of the application while in use.
Dynamic quality attributes include reliability, correctness, completeness, consistency, usability

and performance
Requirements
Requirements leading to two different programs:
 Requirement 1: It is required to write a program that inputs two integers and outputs the
maximum of these.
 Requirement 2: It is required to write a program that inputs a sequence of integers and
outputs the sorted version of this sequence
Requirements: Incompleteness
 Suppose that program max is developed to satisfy Requirement 1.

 The expected output of max when the input integers are 13 and 19 can be easily
determined to be 19.
 Suppose now that the tester wants to know if the two integers are to be input to the
program on one line followed by a carriage return, or on two separate lines with a
carriage return typed in after each number. The requirement as stated above fails to
provide an answer to this question.
Requirements: Ambiguity
 Requirement 2 is ambiguous. It is not clear whether the input sequence is to sorted in

ascending or in descending order. The behavior of sort program, written to satisfy this
requirement, will depend on the decision taken by the programmer while writing sort.
Correctness
 The ability of software products to perform their exact tasks, as defined by their
specification.
 Show consistency between two Formalisms (e.g., specifications design, design to source
code, requirements to specifications, the "what" to the "how").
Reliability
 The reliability is the probability of the successful execution of program on randomly

selected elements from its input domain
 The ability of a system to perform its requested functions under stated conditions
whenever required - having a long mean time between failures.

Completeness
 The Completeness refers to the availability of all features listed in the requirements, or in
the user manual.
 An incomplete software is one that does not fully implement all features required.
Consistency refers to adherence to a common set of conventions and assumptions. For
example, all buttons in the user interface might follow a common color coding
convention.
Robustness Provides acceptable performance in the face of correctness or reliability failures
(e.g., graceful degradation). Concerned with behavior in face of unusual conditions.
Testing Life Cycle
1.2 Test Cases

Test case has an identity and is associated with program behaviour. It has a set of inputs
& expected outputs.it is also useful to record the execution history of a test case, including when
and by whom it was run, the pass/fail result of each execution, and the version of software on
which it was run. Test cases are valuable as source code. Test cases need to be developed,
reviewed, used, managed, and saved.

Test case ID
Purpose
Preconditions
Inputs
Expected outputs
Post-conditions
Execution history
Date Result Version RunBy
Aim of Testing: Establishing the necessary preconditions, providing the test cases inputs,
observing the outputs, comparing these with the expected outputs, & then ensuring that the
expected post conditions exist to determine whether the test passed or failed.
1.3 Testing with Venn Diagrams

Testing is fundamentally concerned with behavior. Consider the universe of program
behaviors, given a program and its specification, let set S of specified behaviors and the set P be
programmed behaviors. Fault of omission are certain behaviors that are not been programmed &
fault of commission are those behaviors which are not been specified. The intersection of S & P
is the correct region i.e, the program is both specified & implemented. So testing is mainly
concerned with the determination of the extent of the program that are both specified &
implemented.
Specified & implemented program behaviors Specified, implemented, & tested behaviors
Consider the relationships among the sets S,P & T. region 2 & 5 indicates the specified
behaviors that are not tested, region 1 & 4 shows specified behaviors that are tested, and region 3
& 7 represents the test cases that are correspond to unspecified behaviors.

Similarly, region 2 & 6 shows programmed behaviors that are not tested, region 1 & 3
shows the programmed behaviors that are tested & region 4 & 7 indicates test cases that
correspond to unprogrammed behaviors. Region 1 indicates the program being specified,
programmed & tested also. Testing is incomplete for all the regions means either of unspecified
behaviors or unspecified programs or unverified test cases. Region 1 is where the test cases are
identified by a testing method.
1.4 Identifying test cases

Two Fundamental Approaches for testing are
1. Functional Testing
2. Structural testing
1. Functional Testing: It is based on the view that any program can be considered to be a
function that maps its input domain to values at its output range. The system is considered to
be a blackbox wherein the content (implementation or source code) of a black box is not known
& the function of the blackbox is understood completely in terms of its inputs & outputs.so it is
also called as Black Box Testing. It’s mainly concentrates on output generated for selected
inputs & execution condition. Here we design test cases based on the information from the
specification. Tester with a very little knowledge on the programming languages can do testing.
for Functional testing, Specification of the software is used.
Inputs Outputs
Functional test cases have two advantages:

i. They are independent of how the software is implemented, so if the implementation
changes, the test cases are still useful.
Eg: In Banking d/b, if design of loan details changes, the test cases are useful.
ii. Test case development can occur in parallel with the implementation, thereby reducing
the overall project development intervals.
Eg: In banking d/b, if an account creation has been done or implemented in the software
interface, & given for testing team to test this part of software. At the same time, the loan
details can be implemented in parallel.
Disadvantages:

i. Significant redundancies may exist among test cases.

Eg: Test cases are repeated sometimes
ii. Possibilities of gaps of untested software.
Eg: In the implementation of Ms Word, scroll bar has been tested for the complete page
but not for the complete document. So there exists a gap in the untested software’s.
Functional testing methods are:

Boundary value analysis, robustness testing, worst case analysis, special value testing, input
domain equivalence classes, output range equivalence classes, decision table based testing.
In the below figure, Method A identifies a larger set of test cases that does Method B. for
both methods, the set of test cases is completely contained within the set of specified behaviour.
Functional methods are based on the specified behavior, it is hard to imagine these methods
identifying behaviors that are not specified.
2. Structural Testing: It is a technique used in test case identification. It is also called as white
box (clear box) testing, wherein the implementation (of black box) is known & used to identify
test cases. The ability to ‘see inside’ the black box allows the tester to identify test cases based
on the function is actually implemented. The tester should have knowledge of linear graph theory
concepts eg: graphs, edges, nodes. Here the test coverage metrices are defined which provides a
way to explicitly state the extent to which software has been tested.
In the below figure, Method A identifies a larger set of test cases than Method B. All
behaviors are completely programmed as structural methods are based on programs. It is hard to
find the unprogrammed behaviors.
Functional v/s Structural Testing
Functional Testing Structural Testing
It uses only specifications to identify the test It uses program source code (implementation)
cases to identify the test cases
It is also called as Black Box Testing as It is also called as White Box Testing(Clear
implementation of the black box is not known box) wherein the implementation (of black
& it depends on only its inputs & outputs box) is known & used to identify test cases
If unspecified behaviors are program In program behaviour, if all specified behaviour

implemented, then functional test cases are not has not been recognized, structural test cases
possible. Eg. For unspecified behaviors, Trojan are not able to recognize this.
Horse.
Functional Testing establishes Confidence Structural Testing seeks faults

Implementation is hidden Data flow and control flow are visible
Logic is available for analysis
1.5 Error and Fault Taxonomies

Testing and fault management are two edged. One is to maintain quality assurance during
the process of software development itself. The other is product oriented. Here the testing teams
deal with a basic prototype after the first phase of development and then try to improvise it.
Errors and faults are classified by different people in many different ways. These classifications
are based on their understanding of the testing process.
Faults are classified based on several ways like

- The development phase when error occurred.
- Consequence of failure
- Difficulty to resolve
- Risk of no resolution.
Faults classification by severity: Faults classification by input/output:
Mild Misspelled word Catastrophic System shutdown
Moderate Misleading or Infectious Shutdown that spreads

redundant information
Annoying Truncated names

Logic Faults
Disturbing Some “not processed
transactions” Missing Case(s)
Serious Loose a transaction Duplicate case(s)
Very serious Incorrect transaction Extreme condition neglected

execution Misinterpretation
Extreme Frequent “very serious Missing condition
errors
Extraneous condition(s)
Intolerable Database corruption
Test of wrong variable

Incorrect loop iteration Spurious result
Wrong operator(< instead of <=) Spelling/grammar
Cosmetic
Type Instance Computation Faults
Correct input not accepted Incorrect algorithm
Input Incorrect input accepted Missing computation
Description wrong or missing Incorrect operand
Parameters wrong or missing Incorrect operation
Wrong format Parenthesis error
Wrong result Insufficient precision (round-off, truncation)
Correct result at wrong time(too

Wrong built-in function
early, too late)
Output
Incomplete or missing result
Interface Faults Parameter mismatch(type,

number)
Incorrect interrupt handling
Incompatible types
I/O timing
Superfluous inclusion
Call to wrong procedure
Call to non-existent
procedure

Data Faults
Incorrect initialization
Incorrect storage/access
Wrong flag/index value
Incorrect packing/unpacking
Wrong variable used
Wrong data reference
Scaling or units error
Incorrect data reference
Incorrect subscript
Incorrect type
Incorrect data scope
Sensor data out of limits
Off by one
Inconsistent data

1.6 Levels of Testing
A level of Testing describes the levels of abstraction found in the waterfall model of the
software development life cycle. The diagram represents the correspondence between testing and
design levels. In terms of functional testing, the three levels of definition (specification, preliminary
design, and detailed design) correspond directly to three levels of testing- system, integration, and
unit testing. The structural testing is appropriate at the unit level, while functional testing is more
appropriate at the system level.
1.7 Generalized pseudocode:

Pseudocode provides a “language neutral” way to express program source code. Here we list
different terms such as expression, variable list, and field description.
Language Elements Generalized Pseudocode Construct
Comments // text
Data Structure declaration Type <typename> <list of variable>End<typename>
Data declaration Type <variable list>
Assignment statement <variable>=<expression>
Input Read(<variable list>)

Output Print(<variable list>)
Condition <expression><relational operator><expression>
Compound Statement <condition><logical connective><expression>
Sequence Statements in sequential order
Simple selection If<condition> then <then clause> Endif
Selection If<condition>
Multiple Selection Case <variable>
Case 1: <predicate>
<case clause>
………
Case n: <predicate>
<case clause>
EndCase
Counter-controlled repetition For <counter>=<start> to <end>
Pretest repetition While <condition>… EndWhile
Posttest repetition Do……until <condition>
1.8 Example1: The Triangle Problem

Problem Statement
Simple version: The triangle program accepts three integers, a, b, and c, as input. These are taken to
be sides of a triangle. The output of the program is the type of triangle determined by the three sides:
Equilateral, Isosceles, Scalene, or Not A Triangle.
Improved version: “Simple version” plus better definition of inputs: The integers a, b, and c must
satisfy the following conditions:
c1. 1 ≤ a ≤ 200 c4. a < b + c
c2. 1 ≤ b ≤ 200 c5. b < a + c
c3. 1 ≤ c ≤ 200 c6. c < a + b
Final Version: “Improved version” plus better definition of outputs: If an input value fails any of
conditions c1, c2, or c3, the program notes this with an output message, for example, “Value of b is
not in the range of permitted values.” If values of a, b, and c satisfy conditions c1, c2, and c3, one of
four mutually exclusive outputs is given:
1. If all three sides are equal, the program output is Equilateral.
2. If exactly one pair of sides is equal, the program output is Isosceles.

3. If no pair of sides is equal, the program output is Scalene.
4. If any of conditions c4, c5, and c6 is not met, the program output is NotATriangle.
Problems persist!
What output is expected for the input set (2, 2, 5)?
• Isosceles because a = b?
•NotATriangle because c > a+b?
Pseudocode
Program: Triangle1
int a,b,c,match
print "Enter 3 integers which are sides of a triangle”
read (a,b,c)
print "side a”
print "side b”
print "side c”
match=0;
If a==b //1
Then match=match+1; //2
EndIf
If a==c //3
EndIf
If b==c //5
EndIf
If match==0 //7
Then If (a+b)<=c //8
Then print "NotATriangle” //12.1
Else If (b+c)<=a //9
Else If (a+c)<=b //10
Else print "Scalene” //11
EndIf
EndIf
EndIf
Else If match=1 //13
Then If (a+c)<=b //14
Else print "isosceles" //15.1
EndIf
Else if match==2 //16
Then if(a+c)<=b //17
Else print "Isosceles” //15.2
EndIf
Else if match==3 //18
Then if (b+c)<=a //19


Else print "Isosceles” //15.3
EndIf
Else print "Equilateral" //20
EndIf
EndIf
EndIf
EndIf
//End Tringle1
Flowchart
Structural implementation for simpler version of triangle program
Program: Triangle2
int a,b,c,match
read (a,b,c)

print "side a”
print "side b”
print "side c”
If (a<b+c) AND (b<a+c) AND (c<a+b)

Then IsATriangle=True
Else IsATriangle=False
EndIf
If IsATriangle
Then If (a==b) AND (b==c)
Then print "Equilateral"
Else If (a!=b) AND (b!=c) AND (c!=a)
Then print "Scalene”
Else print "Isosceles”
EndIf
EndIf
Else print “NotATriangle”
EndIf
//End Tringle2
Structural implementation for improved version of triangle program
Program: Triangle3
int a,b,c
int c1,c2,c3, IaAtriangle
Do
read (a,b,c)
c1=(1<=a) AND (a<=200)
c2=(1<=b) AND (b<=200)
c3=(1<=c) AND (c<=200)
if(!c1)
Then print “value of a is not in the range of permitted values”
EndIf
if(!c2)
Then print “value of b is not in the range of permitted values”
EndIf
if(!c3)
Then print “value of c is not in the range of permitted values”
EndIf
While (c1 && c2 && c3)
print "side a”
print "side b”
print "side c”
If (a<b+c) AND (b<a+c) AND (c<a+b)

Then IsATriangle=True
Else IsATriangle=False
EndIf

If IsATriangle
Then If (a==b) AND (b==c)
Then print "Equilateral"
Else If (a!=b) AND (b!=c) AND (c!=a)
Then print "Scalene”
Else print "Isosceles”
EndIf
EndIf
Else print “NotATriangle”
EndIf
//End Tringle3
1.9 Example2: The NextDate Function

NextDate is a function of three variables: month, date, and year. It returns the date of the day after the
input date. The month, date, and year variables have integer values subject to these conditions:
c1. 1 ≤ month ≤12
c2. 1 ≤ day ≤ 31
c3. 1812 ≤ year ≤ 2012
If any of conditions c1, c2, or c3 fails, NextDate produces an output indicating the corresponding
variable has an out-of-range value — for example, “Value of month not in the range 1..12”. Because
numerous invalid day–month–year combinations exist, NextDate collapses these into one message:
“Invalid Input Date.” Complexity is added when an year is a leap year or a century year.
Pseudocode:
Program: NextDate1 //Simple version

int tmday,tmmonth,tmyear,day,month,year;
print “Enter today’s date in the form of mm/dd/yyyy”
read(month,day,year)
switch (month)
case 1:
case 3:
case 5:
case 7:
case 8:
case 10:
If day<31
then tmday=day+1;
Else
tmday=1;
tmmonth=month+1;
EndIf
case 4:
case 6:
case 9:
case 11:
If day<30
then tmday=day+1;
Else
tmday=1;
tmmonth=month+1;
EndIf
case 12:
If day<31
Then tmday=day+1;
Else
tmday=1;
tmmonth=1;
If (year==2013)
Then print "input is invalid”
Else
tmyear =year+1;
EndIf
EndIf
case 2:
If day<28
then tmday=day+1;
Else
if(day==28)
Then If year%4=0
Then tmday=29 //leap year
Else
tmday=1;
tmmonth=3;
EndIf
Else If day=29
Then tmday=1;
tmmonth=3;
Else
Print "Feb can’t have 30 days:”
Endif
Endif
Endif
EndCase
Print "Next Date is tmmonth/tmday/tmyear”
End NextDate1
Program: NextDate2 //Improved version

int tmday,tmmonth,tmyear,day,month,year;
int c1,c2,c3
Do
print “Enter today’s date in the form of mm/dd/yyyy”
read(month,day,year)
c1=(1<=day) AND (day<=31)
c2=(1<=month) AND (month<=12)
c3=(1812<=year) AND (year<=2012)
if(!c1)
Then print “day out of range”
EndIf
if(!c2)
Then print “month out of range”
EndIf
if(!c3)
Then print ”year out of range ”
EndIf
While (c1 && c2 && c3)
Switch (month)
case 1:
case 3:
case 5:
case 7:
case 8:
case 10:
If day<31
then tmday=day+1;
Else
tmday=1;
tmmonth=month+1;
EndIf
case 4:
case 6:
case 9:
case 11:
If day<30
then tmday=day+1;
Else
If day=30
tmday=1;
tmmonth=month+1;
Else
Print “Invalid Date input”
EndIf
EndIf
case 12:
If day<31
Then tmday=day+1;
Else
tmday=1;
tmmonth=1;
if(year==2013)
Then print "input is invalid”
Else
tmyear=year+1;
EndIf
EndIf
case 2:
If day<28
then tmday=day+1;
Else
If day==28
Then If year%4=0
Then tmday=29 //leap year
Else
tmday=1;
tmmonth=3;
EndIf
Else
If day=29
Then If year%400=0
tmday=1;
tmmonth=3;
Else
If day>29
Then print "Feb can’t have 30 days:”
Endif
Endif
Endif
EndIf
EndIf
EndCase
Print "Next Date is tmmonth/tmday/tmyear”
End NextDate2
1.10 The Commission Problem
Problem Statement
A rifle salesperson in the former Arizona Territory sold rifle locks, stocks, and barrels made by a
gunsmith in Missouri. Locks cost $45, stocks cost $30, and barrels cost $25. The salesperson had to
sell at least one complete rifle per month, and production limits were such that the most the
salesperson could sell in a month was 70 locks, 80 stocks, and 90 barrels. After each town visit, the
salesperson sent a telegram to the Missouri gunsmith with the number of locks, stocks, and barrels
sold in that town. At the end of a month, the salesperson sent a very short telegram showing –1 locks
sold. The gunsmith then knew the sales for the month were complete and computed the salesperson’s
commission as follows: 10% on sales up to (and including) $1000, 15% on the next $800, and 20%
on any sales in excess of $1800. The commission program produced a monthly sales report that gave
the total number of locks, stocks, and barrels sold, the
salesperson’s total dollar sales, and, finally, the commission.
Pseudocode
program Commission
int locks,stocks,barrels

float lockprice,stockprice,barrelprice
int totallocks,totalstocks,totalbarrels
float locksales,stocksales,barrelsales,sales,commision
lockprice=45
stockprice=30
barrelprice=25
totallocks=0
totalstocks=0
totalbarrels=0
read (locks)
while (locks!=-1) //input devices uses -1 to indicate end of data
read (stocks, barrels)
totallocks=totallocks+locks
totalbarrels=totalbarrels+barrels
totalstocks=totalstocks+stocks
read (locks)
EndWhile
print ("locks sold=",totallocks)

print ("stocks sold=",totalstocks)
print ("barrels sold=",totalbarrels)
locksales=lockprice*totallocks
stocksales=stockprice*totalstocks
barrelsales=barrelprice*totalbarrels
sales=locksales+stocksales+barrelsales
print ("Total sales=",sales);
If(sales>1800.0)
Then
commision=0.10*1000
commision=commision+0.15*800.0
commision=commision+0.20*(sales-1800.0)
Else If (sales>1000.0)
Then
commision=0.10*1000
commision=commision+0.15*(sales-1000)
Else
commision=0.10*sales
EndIf
EndIf
Print ("commision is $",commision);
End Commission

1.11 Simple automated teller machine

Is the ATM machine used in all banking transactions used to withdraw cash at the insertion of a
legitimate debit or credit card.

1.12 Currency converter

Is an application that converts currency of one country into equivalent of another country.
1.13 Saturn windshield wiper

The windshield wiper on some Saturn automobiles is controlled by a lever with a dial. The
lever has four positions, OFF, INT (for intermittent), LOW, and HIGH, and the dial has three
positions, numbered simply 1, 2, and 3. The dial positions indicate three intermittent speeds, and the
dial position is relevant only when the lever is at the INT position. The decision table below shows
the windshield wiper speeds (in wipes per minute) for the lever and dial positions.

Module1 - Basics of Software Testing - Lecture Notes

Uploaded by

Module1 - Basics of Software Testing - Lecture Notes

Uploaded by

Software Testing (18IS62) 2023

Acharya Institute of Technology

Name of the Faculty: Pushpalatha K S

Title of the Subject / Subject Code: Software Testing/18IS62

Academic Year / Semester: 2022-2023

Name of the Department: Information Science & Engineering

Module-1:Basics of Software Testing

1.1 Basic Definitions

It is a systematic study of flow of software where its mainly concentrates on improving

Pushpalatha K.S, Asst.Prof., ISE Dept., AIT, B’lore. Page 1

Software development life-cycle (SDLC)

What is Software Testing?

The Process of validating & Verifying that a computer program/application/product

Why do we test any Software?

Pushpalatha K.S, Asst.Prof., ISE Dept., AIT, B’lore. Page 2

 Failures only occur in an executable representation.

Test: The act of exercising software with test cases.

Two goals of test are

Key aspects of quality for the customer include:

 Good design – looks and style

Pushpalatha K.S, Asst.Prof., ISE Dept., AIT, B’lore. Page 3

Dynamic quality attributes include reliability, correctness, completeness, consistency, usability

Requirements leading to two different programs:

 Suppose that program max is developed to satisfy Requirement 1.

 Requirement 2 is ambiguous. It is not clear whether the input sequence is to sorted in

 The reliability is the probability of the successful execution of program on randomly

Pushpalatha K.S, Asst.Prof., ISE Dept., AIT, B’lore. Page 4

Testing Life Cycle

1.2 Test Cases

Pushpalatha K.S, Asst.Prof., ISE Dept., AIT, B’lore. Page 5

1.3 Testing with Venn Diagrams

Pushpalatha K.S, Asst.Prof., ISE Dept., AIT, B’lore. Page 6

1.4 Identifying test cases

Functional test cases have two advantages:

Pushpalatha K.S, Asst.Prof., ISE Dept., AIT, B’lore. Page 7

i. Significant redundancies may exist among test cases.

Functional testing methods are:

Functional v/s Structural Testing

Functional Testing Structural Testing

If unspecified behaviors are program In program behaviour, if all specified behaviour

Functional Testing establishes Confidence Structural Testing seeks faults

Pushpalatha K.S, Asst.Prof., ISE Dept., AIT, B’lore. Page 8

Implementation is hidden Data flow and control flow are visible

Logic is available for analysis

1.5 Error and Fault Taxonomies

Faults are classified based on several ways like

Faults classification by severity: Faults classification by input/output:

Mild Misspelled word Catastrophic System shutdown

Moderate Misleading or Infectious Shutdown that spreads

Annoying Truncated names

Serious Loose a transaction Duplicate case(s)

Very serious Incorrect transaction Extreme condition neglected

Pushpalatha K.S, Asst.Prof., ISE Dept., AIT, B’lore. Page 9

Incorrect loop iteration Spurious result

Wrong operator(< instead of <=) Spelling/grammar

Type Instance Computation Faults

Correct input not accepted Incorrect algorithm

Input Incorrect input accepted Missing computation

Description wrong or missing Incorrect operand

Parameters wrong or missing Incorrect operation

Wrong format Parenthesis error

Wrong result Insufficient precision (round-off, truncation)

Correct result at wrong time(too

Interface Faults Parameter mismatch(type,

Pushpalatha K.S, Asst.Prof., ISE Dept., AIT, B’lore. Page 10

Wrong flag/index value

Wrong variable used

Wrong data reference

Scaling or units error

Incorrect data reference

Incorrect data scope

Sensor data out of limits

Pushpalatha K.S, Asst.Prof., ISE Dept., AIT, B’lore. Page 11

1.6 Levels of Testing

1.7 Generalized pseudocode:

Language Elements Generalized Pseudocode Construct