Expertiza_Wiki - User contributions [en]

CSC/ECE 517 Fall 2009/wiki2 15 ms

2009-10-15T02:39:48Z

Alakshm3: /* Definition of Abstraction */

=Introduction=
"Object-oriented programming is a method of implementation in which programs are organized as cooperative collections of objects, each of which repressents an instance of some class, and whose classes are all members of a hierarchy of classes united via inheritance relationships."taken from Object-Oriented Analysis and Design by Grady Booch 
For all the things that we define as object oriented, the main framework is the object model. An object model can be defined as the collection of principles that form the foundation of object oriented design. The main elements of an object model are -:
*Abstraction
*Encapsulation
*Modularity
*Hierarchy

The goal of this article is to describe how abstraction relates to object oriented languages.

=Definition of Abstraction=
Abstraction (from the Latin abs, meaning away from and trahere, meaning to draw) is the process of taking away or removing characteristics from something in order to reduce it to a set of essential characteristics.[taken from [http://www.tutorialspoint.com/ruby/ruby_modules.htm what is abstraction?]]

An alternate definition given in the book object oriented analysis and design,states that-: 

"An abstraction denotes the essential characteristics of an object that distinguish it from all other kinds of objects and thus provide crisply defined conceptual boundaries,relative to the perceptive of the viewer."

The gist is that abstraction is a concept wherein all but the relevant information about an object is hidden in order to reduce complexity and increase the efficiency. This concept even applies in the field of arts wherein an object or a piece of art created by an artist is a representation of the original model with all the unwanted details removed.
In other words it is nothing but recognizing the similarities between objects and ignoring for some time their differences. It focuses on the outside view of the object and separate it's behavior from it's implementation. 
<table BORDER=3>
<tr>
<td>
[[Image:Abstraction.jpg]]
</td>
</tr>
</table>
'''Abstraction focuses on the essential characteristics of some object, relative to perspective of the viewer.''' 
The above picture shows a car which is being viewed by two people. One of them is a mechanic and the other is a layman. Now when
mechanic thinks of a car, what comes to his mind are it's parts, mileage etc. When a layman thinks about a car, what comes to
his mind is color of the car, the look etc. Hence each person sees the same object in a different light.

=Types of abstractions=
There are different types of abstractions as suggested by Seidewitz and Stark of which some closely model problem domain entities These are as following (mentioned in the order of their usefulness) -: 

* Entity abstraction - Object represents a useful model of a problem domain or solution domain entity.

* Action abstraction - Object provides a generalized set of operations, all of which perform the same kind of function.

* Virtual Machine abstraction - This is where an object groups together operations that are all used by some superior level of control, or operations that all use some junior-level set of operations.

* Conincidental abstraction - An object that packages a set of operations that have no relation to each other.

Entity abstractions is what is used widely because it directly parallels a given problem domain. 

Definitions taken from object oriented analysis and design by Grady Booch

==Key Abstractions==

A abstraction which describes the system is referred as a '''key abstraction'''. They give boundaries to our problem.They highlight things that are more relevant to our system and hence to the design and suppress the things that are outside the system. There are two important steps in identifying the key abstractions. These are -: 

* Discovery : Discovery is the process of recognizing the abstraction used in the design of the system.
For example, a customer doing a bank transaction speaks in terms of accounts,deposits and withdrawals;
these works are part of the vocabulary of the problem domain.

* Invention : Through invention, we can create new classes and objects that are not necessarily part of the problem domain, but are useful in design and implementation.
For example A developer of such a system uses these same abstractions, but must also introduce new ones, such as databases, screen
mangers, lists, queues and so on. These key abstractions are artifacts of the particular design, not of the problem domain.

= Abstraction in Different O-O languages =

== Java ==
Java implements abstraction using Abstract classes and methods. Any class which cannot be instantiated and contains one or more abstract methods in referred as an '''Abstract class''' in JAVA. Such class can only be inherited.

The code shown below is an implementation of the picture example given previously. Here, there is an abstract class called 'Car' which contains an abstract method called 'thingsILookFor()'. Classes 'Mechanic' and 'LayMan' extent the class 'Car'.

''' Example : Java code for the above figure.'''


/* The abstract class car is extended by both the classes Mechanic and LayMan. */
/* They implement the abstract method thingsILookFor */
/* according to what they consider important in a car */


public abstract class Car {

abstract void thingsILookFor();

}

public class Mechanic extends Car {

private int enginePower;

private int carMileage;

void thingsILookFor() {

enginePower = 1000;

carMileage = 32;
}

}

public class LayMan extends Car {

private string color;

private int seats;

void thingsILookFor() {

color = "yellow";

seats = 4;
}


== C++ ==
'''Abstract classes:''' These classes can be used as a framework to build new classes that provide new functionality. These class have one or more virtual function.
Functions of the base class whose functionality can be overridden by functions of the derived class at run time are called '''virtual functions'''.

In the code below the Class 'Car' has a virtual function 'things_I_like'. This method is implemented by the Class Mechanic and LayMan according the perspective of the class.


class Car
{

public:
virtual void things_I_like()
{
cout << " No method implementation \n";
}
}

class Mechanic:public car
{

public:
virtual void things_I_like()
{
cout << " I like the car to have a powerful engine\n";
}

}
class LayMan:public car
{

public:
virtual void dump()
{
cout << " I like the car to be spacious and have bright colors\n";
}

}


== Ruby ==
Ruby has no Abstract classes like in Java or Virtual function like in C++, but the same functionality can be implemented as follows.

In this example the class 'Car' has not implemented the method 'thingsILike()'. Suppose the class 'Mechanic' and 'LayMan' were not defined and now if we call Car.new.thingsILike, it will raise an error. Hence this method needs to be implemented by the subclasses as shown in the example.

In the code below the method 'thingsILike' is implemented differently by the class Mechanic and LayMan. They implement the method according to the context in which they see the class 'Car'.


class Car
def thingsILike()
raise NotImplementedError.new("no implementation found \n")
end
end

class Mechanic < Car
def thingsILike()
puts " I like the horse power of the engine and the mileage \n"
end
end

class LayMan < Car
def thingsILike()
puts " I like the color \n"
end
end


=References=
* [http://www.amazon.com/Object-Oriented-Analysis-Design-Applications-2nd/dp/0805353402 Object oriented Analysis and design by Grady Booch]

* [http://searchcio-midmarket.techtarget.com/sDefinition/0,,sid183_gci343038,00.html Definition of Abstraction]
* [http://epf.eclipse.org/wikis/openup/core.tech.common.extend_supp/guidances/concepts/key_abstractions_1474DBF2.html Key Abstraction]
* [http://www.mymindleaks.com/blog/programming/object-oriented-programming-abstraction/ Object Oriented Programming - Abstraction]
* [http://www.madsci.org/posts/archives/apr2001/987192403.Eg.r.html What is meant by abstraction?]
* [http://www.codeproject.com/KB/architecture/OOP_Concepts_and_manymore.aspx#Generalization What is abstraction?]
* [http://www.answers.com/topic/object-oriented-programming A discussion on object oriented programming]
* [http://computer-programming-tutorials.suite101.com/article.cfm/a_brief_introduction_to_objectoriented_design An example on Anstraction]
* [http://delivery.acm.org/10.1145/30000/25315/p54-seidewitz.pdf?key1=25315&key2=8831215521&coll=GUIDE&dl=GUIDE&CFID=55753397&CFTOKEN=61066169 A paper on "Toward a general object-oriented software development methodology"]
* [http://www.research.att.com/~bs/abstraction-and-machine.pdf An article on Abstraction by Bjarne Stroustrup]

=Further Reading=
* [http://developer.apple.com/iphone/library/documentation/cocoa/Conceptual/OOP_ObjC/Articles/ooObjectModel.html iphone reference library - The object model]
* [http://java.sun.com/docs/books/tutorial/java/concepts/ Lesson: Object-Oriented Programming Concepts]
* [http://computing.southern.edu/halterman/OOPJ/ A textbook on Object oriented programming using Java]

CSC/ECE 517 Fall 2009/wiki2 15 ms

2009-10-15T02:38:33Z

Alakshm3: /* C++ */

=Introduction=
"Object-oriented programming is a method of implementation in which programs are organized as cooperative collections of objects, each of which repressents an instance of some class, and whose classes are all members of a hierarchy of classes united via inheritance relationships."taken from Object-Oriented Analysis and Design by Grady Booch 
For all the things that we define as object oriented, the main framework is the object model. An object model can be defined as the collection of principles that form the foundation of object oriented design. The main elements of an object model are -:
*Abstraction
*Encapsulation
*Modularity
*Hierarchy

The goal of this article is to describe how abstraction relates to object oriented languages.

=Definition of Abstraction=
Abstraction (from the Latin abs, meaning away from and trahere, meaning to draw) is the process of taking away or removing characteristics from something in order to reduce it to a set of essential characteristics.[taken from [http://www.tutorialspoint.com/ruby/ruby_modules.htm what is abstraction?]]

An alternate definition given in the book object oriented analysis and design,states that-: 

"An abstraction denotes the essential characteristics of an object that distinguish it from all other kinds of objects and thus provide crisply defined conceptual boundaries,relative to the perceptive of the viewer."

The gist is that abstraction is a concept wherein all but the relevant information about an object is hidden in order to reduce complexity and increase the efficiency. This concept even applies in the field of arts wherein an object or a piece of art created by an artist is a representation of the original model with all the unwanted details removed.
In other words it is nothing but recognizing the similarities between objects and ignoring for some time their differences. It focuses on the outside view of the object and separate it's behavior from it's implementation. 
<table BORDER=3>
<tr>
<td>
[[Image:Abstraction.jpg]]
</td>
</tr>
</table>
'''Abstraction focuses on the essential characteristics of some object, relative to perspective of the viewer.''' 

The above picture shows a car which is being viewed by two people. One of them is a mechanic and the other is a layman. Now when mechanic thinks of a car, what comes to his mind are it's parts, mileage etc. When a layman thinks about a car, what comes to his mind is color of the car, the look etc. Hence each person sees the same object in a different light.

=Types of abstractions=
There are different types of abstractions as suggested by Seidewitz and Stark of which some closely model problem domain entities These are as following (mentioned in the order of their usefulness) -: 

* Entity abstraction - Object represents a useful model of a problem domain or solution domain entity.

* Action abstraction - Object provides a generalized set of operations, all of which perform the same kind of function.

* Virtual Machine abstraction - This is where an object groups together operations that are all used by some superior level of control, or operations that all use some junior-level set of operations.

* Conincidental abstraction - An object that packages a set of operations that have no relation to each other.

Entity abstractions is what is used widely because it directly parallels a given problem domain. 

Definitions taken from object oriented analysis and design by Grady Booch

==Key Abstractions==

A abstraction which describes the system is referred as a '''key abstraction'''. They give boundaries to our problem.They highlight things that are more relevant to our system and hence to the design and suppress the things that are outside the system. There are two important steps in identifying the key abstractions. These are -: 

* Discovery : Discovery is the process of recognizing the abstraction used in the design of the system.
For example, a customer doing a bank transaction speaks in terms of accounts,deposits and withdrawals;
these works are part of the vocabulary of the problem domain.

* Invention : Through invention, we can create new classes and objects that are not necessarily part of the problem domain, but are useful in design and implementation.
For example A developer of such a system uses these same abstractions, but must also introduce new ones, such as databases, screen
mangers, lists, queues and so on. These key abstractions are artifacts of the particular design, not of the problem domain.

= Abstraction in Different O-O languages =

== Java ==
Java implements abstraction using Abstract classes and methods. Any class which cannot be instantiated and contains one or more abstract methods in referred as an '''Abstract class''' in JAVA. Such class can only be inherited.

The code shown below is an implementation of the picture example given previously. Here, there is an abstract class called 'Car' which contains an abstract method called 'thingsILookFor()'. Classes 'Mechanic' and 'LayMan' extent the class 'Car'.

''' Example : Java code for the above figure.'''


/* The abstract class car is extended by both the classes Mechanic and LayMan. */
/* They implement the abstract method thingsILookFor */
/* according to what they consider important in a car */


public abstract class Car {

abstract void thingsILookFor();

}

public class Mechanic extends Car {

private int enginePower;

private int carMileage;

void thingsILookFor() {

enginePower = 1000;

carMileage = 32;
}

}

public class LayMan extends Car {

private string color;

private int seats;

void thingsILookFor() {

color = "yellow";

seats = 4;
}


== C++ ==
'''Abstract classes:''' These classes can be used as a framework to build new classes that provide new functionality. These class have one or more virtual function.
Functions of the base class whose functionality can be overridden by functions of the derived class at run time are called '''virtual functions'''.

In the code below the Class 'Car' has a virtual function 'things_I_like'. This method is implemented by the Class Mechanic and LayMan according the perspective of the class.


class Car
{

public:
virtual void things_I_like()
{
cout << " No method implementation \n";
}
}

class Mechanic:public car
{

public:
virtual void things_I_like()
{
cout << " I like the car to have a powerful engine\n";
}

}
class LayMan:public car
{

public:
virtual void dump()
{
cout << " I like the car to be spacious and have bright colors\n";
}

}


== Ruby ==
Ruby has no Abstract classes like in Java or Virtual function like in C++, but the same functionality can be implemented as follows.

In this example the class 'Car' has not implemented the method 'thingsILike()'. Suppose the class 'Mechanic' and 'LayMan' were not defined and now if we call Car.new.thingsILike, it will raise an error. Hence this method needs to be implemented by the subclasses as shown in the example.

In the code below the method 'thingsILike' is implemented differently by the class Mechanic and LayMan. They implement the method according to the context in which they see the class 'Car'.


class Car
def thingsILike()
raise NotImplementedError.new("no implementation found \n")
end
end

class Mechanic < Car
def thingsILike()
puts " I like the horse power of the engine and the mileage \n"
end
end

class LayMan < Car
def thingsILike()
puts " I like the color \n"
end
end


=References=
* [http://www.amazon.com/Object-Oriented-Analysis-Design-Applications-2nd/dp/0805353402 Object oriented Analysis and design by Grady Booch]

* [http://searchcio-midmarket.techtarget.com/sDefinition/0,,sid183_gci343038,00.html Definition of Abstraction]
* [http://epf.eclipse.org/wikis/openup/core.tech.common.extend_supp/guidances/concepts/key_abstractions_1474DBF2.html Key Abstraction]
* [http://www.mymindleaks.com/blog/programming/object-oriented-programming-abstraction/ Object Oriented Programming - Abstraction]
* [http://www.madsci.org/posts/archives/apr2001/987192403.Eg.r.html What is meant by abstraction?]
* [http://www.codeproject.com/KB/architecture/OOP_Concepts_and_manymore.aspx#Generalization What is abstraction?]
* [http://www.answers.com/topic/object-oriented-programming A discussion on object oriented programming]
* [http://computer-programming-tutorials.suite101.com/article.cfm/a_brief_introduction_to_objectoriented_design An example on Anstraction]
* [http://delivery.acm.org/10.1145/30000/25315/p54-seidewitz.pdf?key1=25315&key2=8831215521&coll=GUIDE&dl=GUIDE&CFID=55753397&CFTOKEN=61066169 A paper on "Toward a general object-oriented software development methodology"]
* [http://www.research.att.com/~bs/abstraction-and-machine.pdf An article on Abstraction by Bjarne Stroustrup]

=Further Reading=
* [http://developer.apple.com/iphone/library/documentation/cocoa/Conceptual/OOP_ObjC/Articles/ooObjectModel.html iphone reference library - The object model]
* [http://java.sun.com/docs/books/tutorial/java/concepts/ Lesson: Object-Oriented Programming Concepts]
* [http://computing.southern.edu/halterman/OOPJ/ A textbook on Object oriented programming using Java]

CSC/ECE 517 Fall 2009/wiki2 15 ms

2009-10-15T02:34:34Z

Alakshm3: /* Ruby */

=Introduction=
"Object-oriented programming is a method of implementation in which programs are organized as cooperative collections of objects, each of which repressents an instance of some class, and whose classes are all members of a hierarchy of classes united via inheritance relationships."taken from Object-Oriented Analysis and Design by Grady Booch 
For all the things that we define as object oriented, the main framework is the object model. An object model can be defined as the collection of principles that form the foundation of object oriented design. The main elements of an object model are -:
*Abstraction
*Encapsulation
*Modularity
*Hierarchy

The goal of this article is to describe how abstraction relates to object oriented languages.

=Definition of Abstraction=
Abstraction (from the Latin abs, meaning away from and trahere, meaning to draw) is the process of taking away or removing characteristics from something in order to reduce it to a set of essential characteristics.[taken from [http://www.tutorialspoint.com/ruby/ruby_modules.htm what is abstraction?]]

An alternate definition given in the book object oriented analysis and design,states that-: 

"An abstraction denotes the essential characteristics of an object that distinguish it from all other kinds of objects and thus provide crisply defined conceptual boundaries,relative to the perceptive of the viewer."

The gist is that abstraction is a concept wherein all but the relevant information about an object is hidden in order to reduce complexity and increase the efficiency. This concept even applies in the field of arts wherein an object or a piece of art created by an artist is a representation of the original model with all the unwanted details removed.
In other words it is nothing but recognizing the similarities between objects and ignoring for some time their differences. It focuses on the outside view of the object and separate it's behavior from it's implementation. 
<table BORDER=3>
<tr>
<td>
[[Image:Abstraction.jpg]]
</td>
</tr>
</table>
'''Abstraction focuses on the essential characteristics of some object, relative to perspective of the viewer.''' 

The above picture shows a car which is being viewed by two people. One of them is a mechanic and the other is a layman. Now when mechanic thinks of a car, what comes to his mind are it's parts, mileage etc. When a layman thinks about a car, what comes to his mind is color of the car, the look etc. Hence each person sees the same object in a different light.

=Types of abstractions=
There are different types of abstractions as suggested by Seidewitz and Stark of which some closely model problem domain entities These are as following (mentioned in the order of their usefulness) -: 

* Entity abstraction - Object represents a useful model of a problem domain or solution domain entity.

* Action abstraction - Object provides a generalized set of operations, all of which perform the same kind of function.

* Virtual Machine abstraction - This is where an object groups together operations that are all used by some superior level of control, or operations that all use some junior-level set of operations.

* Conincidental abstraction - An object that packages a set of operations that have no relation to each other.

Entity abstractions is what is used widely because it directly parallels a given problem domain. 

Definitions taken from object oriented analysis and design by Grady Booch

==Key Abstractions==

A abstraction which describes the system is referred as a '''key abstraction'''. They give boundaries to our problem.They highlight things that are more relevant to our system and hence to the design and suppress the things that are outside the system. There are two important steps in identifying the key abstractions. These are -: 

* Discovery : Discovery is the process of recognizing the abstraction used in the design of the system.
For example, a customer doing a bank transaction speaks in terms of accounts,deposits and withdrawals;
these works are part of the vocabulary of the problem domain.

* Invention : Through invention, we can create new classes and objects that are not necessarily part of the problem domain, but are useful in design and implementation.
For example A developer of such a system uses these same abstractions, but must also introduce new ones, such as databases, screen
mangers, lists, queues and so on. These key abstractions are artifacts of the particular design, not of the problem domain.

= Abstraction in Different O-O languages =

== Java ==
Java implements abstraction using Abstract classes and methods. Any class which cannot be instantiated and contains one or more abstract methods in referred as an '''Abstract class''' in JAVA. Such class can only be inherited.

The code shown below is an implementation of the picture example given previously. Here, there is an abstract class called 'Car' which contains an abstract method called 'thingsILookFor()'. Classes 'Mechanic' and 'LayMan' extent the class 'Car'.

''' Example : Java code for the above figure.'''


/* The abstract class car is extended by both the classes Mechanic and LayMan. */
/* They implement the abstract method thingsILookFor */
/* according to what they consider important in a car */


public abstract class Car {

abstract void thingsILookFor();

}

public class Mechanic extends Car {

private int enginePower;

private int carMileage;

void thingsILookFor() {

enginePower = 1000;

carMileage = 32;
}

}

public class LayMan extends Car {

private string color;

private int seats;

void thingsILookFor() {

color = "yellow";

seats = 4;
}


== C++ ==
'''Abstract classes:''' These classes can be used as a framework to build new classes that provide new functionality. These class have one or more virtual function.
Functions of the base class whose functionality can be overridden by functions of the derived class at run time are called '''virtual functions'''.


class debugger
{

public:
virtual void dump()
{
cout << " No method implementation \n";
}
}

class X:public debugger
{

public:
virtual void dump()
{
cout << " dump method implementation for class X\n";
}

}
class Y:public debugger
{

public:
virtual void dump()
{
cout << " dump method implementation for class Y\n";
}

}


== Ruby ==
Ruby has no Abstract classes like in Java or Virtual function like in C++, but the same functionality can be implemented as follows.

In this example the class 'Car' has not implemented the method 'thingsILike()'. Suppose the class 'Mechanic' and 'LayMan' were not defined and now if we call Car.new.thingsILike, it will raise an error. Hence this method needs to be implemented by the subclasses as shown in the example.

In the code below the method 'thingsILike' is implemented differently by the class Mechanic and LayMan. They implement the method according to the context in which they see the class 'Car'.


class Car
def thingsILike()
raise NotImplementedError.new("no implementation found \n")
end
end

class Mechanic < Car
def thingsILike()
puts " I like the horse power of the engine and the mileage \n"
end
end

class LayMan < Car
def thingsILike()
puts " I like the color \n"
end
end


=References=
* [http://www.amazon.com/Object-Oriented-Analysis-Design-Applications-2nd/dp/0805353402 Object oriented Analysis and design by Grady Booch]

* [http://searchcio-midmarket.techtarget.com/sDefinition/0,,sid183_gci343038,00.html Definition of Abstraction]
* [http://epf.eclipse.org/wikis/openup/core.tech.common.extend_supp/guidances/concepts/key_abstractions_1474DBF2.html Key Abstraction]
* [http://www.mymindleaks.com/blog/programming/object-oriented-programming-abstraction/ Object Oriented Programming - Abstraction]
* [http://www.madsci.org/posts/archives/apr2001/987192403.Eg.r.html What is meant by abstraction?]
* [http://www.codeproject.com/KB/architecture/OOP_Concepts_and_manymore.aspx#Generalization What is abstraction?]
* [http://www.answers.com/topic/object-oriented-programming A discussion on object oriented programming]
* [http://computer-programming-tutorials.suite101.com/article.cfm/a_brief_introduction_to_objectoriented_design An example on Anstraction]
* [http://delivery.acm.org/10.1145/30000/25315/p54-seidewitz.pdf?key1=25315&key2=8831215521&coll=GUIDE&dl=GUIDE&CFID=55753397&CFTOKEN=61066169 A paper on "Toward a general object-oriented software development methodology"]
* [http://www.research.att.com/~bs/abstraction-and-machine.pdf An article on Abstraction by Bjarne Stroustrup]

=Further Reading=
* [http://developer.apple.com/iphone/library/documentation/cocoa/Conceptual/OOP_ObjC/Articles/ooObjectModel.html iphone reference library - The object model]
* [http://java.sun.com/docs/books/tutorial/java/concepts/ Lesson: Object-Oriented Programming Concepts]
* [http://computing.southern.edu/halterman/OOPJ/ A textbook on Object oriented programming using Java]

CSC/ECE 517 Fall 2009/wiki1b 4 xy

2009-09-21T07:21:29Z

Alakshm3:

==''' Functional and Integration testing and beyond''' ==
Recognition of software test engineering as a specialty area has increased during the last twenty years. Testing is one of the key focus areas in software engineering. It is an essential activity that observes the functionality of a software system validates its intended behavior and identifies the potential malfunctions. Testing is also the primary way to improve software reliability.

The test cases should be carefully designed to cover many aspects in the SDLC such as possible aberrations from user’s requirements, system behavior upon malicious inputs, and robustness to extensive load conditions and so on. As more and more software is used in critical applications, the time and cost involved in testing is also increasing owing to the higher quality required. Although test automation saves a lot of time and can be used for regression load tests, manual testing is still widely used in the industry.

== '''Terms''' ==
# Driver: Supporting code or data used for testing the whole or part of the software system
# Sub-system: Component or Module of a software system
# System Under Test: The software system which has to be tested
# Stub: Dummy procedure or module that can be used to simulate or substitute an actual portion of a system
# Test: Sequence of steps to validate the system design and implementation
# Usecase :Scenario that describing an interaction between a user and a system

== '''Integration testing''' ==
Integration is a systematic approach to build the complete software structure specified in the design from unit-tested
modules.Integration testing is the next phase of unit testing. Generally in software development complete software is divided into various sub-systems mostly developed by different teams. More often than not each sub-system works very well individually but when they are integrated then lot of problems. So the main focus of integration tests is not the functionality of individual modules but the interaction between these modules like interaction with operating system, interaction between client and server

There are many approaches that can be followed for Integration Testing

=== '''Big Bang Testing Approach''' ===
As the name suggests all the components are integrated at once. After all the integration is completed a set of tests are run which not only validate a single component of sub-system but also test and validate the interaction between different components. This approach is more useful in smaller systems because integration of smaller systems are easier.
* Advantages:
** Since all the modules are combined and all are tested at the same time, this approach of integration is less time consuming
* Disadvantages:
** Debugging and solving a fault is not that trivial. Because in this type of testing many modules are integrated one cannot be sure whether the bug found was present in any sub-system or interaction between different sub-systems.
** Testing process cannot be started until all the sub-systems have finished their development.
** Writing test cases are also non-trivial.
<table>
<tr>
<td>
[[Image:Bigbang.jpg]]
</td>
</tr>
</table>
 
 
=== '''Incremental Testing Approach''' ===
Testing is done after integration of one module at a time. After finishing the unit testing of each module or sub-system they are integrated and tested. Stubs are used for modules in the system which are not integrated till now.
* Advantages:
** Problems detection is early compared to the Big Bang approach
** No need to wait till the unit testing of all the modules have finished
** Debugging is much simpler
* Disadvantages:
** This approach is a time taking process because the integration tests have to run multiple times
** Stubs have to be developed to substitute the missing modules
<table>
<tr>
<td>
[[Image:Incremental testing.jpg]]
</td>
</tr>
</table>
 
 
Various Approach can be taken for Incremental Testing
* '''Top-Down Approach''': In this approach the system is tested according to the work flow or code flow. The Top level module is tested first then each lower level module is integrated and tested.Top level modules are modules which call other modules and lower level modules are the ones which are called by other modules. Terminal modules are modules which do not call any other module.
<table>
<tr>
<td>
[[Image:Topdown testing.jpg]]
</td>
</tr>
</table>
 
 
In the above figure Module A is the top most module in the system then B,C,D are lower level modules. Generally module A is the user interface and stubs for each interface are used. Then each module is integrated and the tested.
* Advantages:
** The testing flow follows the architecture of the system so any bug in the top level design or implementation could be found at early stages
** If the top level modules call multiple lower modules then the testing can be done in various combinations
For example in the figure A calls B and C. The testing can be done as follows
A-B-C-D
A-C-B-D
* Disadvantage :
** The main problem with this approach is the use of stub. Mostly stubs are written to print out some trace statement based on the output of module A after running the test. Now if multiple scenarios have to be tested then different version of Stub B have to written, which is an extra overhead

* '''Bottom-Up Approach''': The bottom-up approach is the opposite of the top-down approach. In this approach the terminal approaches are tested first, then the higher modules and finally the top-most one. Drivers are used in this approach.
<table>
<tr>
<td>
[[Image:Bottomup testing.jpg]]
</td>
</tr>
</table>
 
 
In the above figure E,D are the terminal modules which are tested first. Then the higher level modules B,C are tested and finally the topmost module is tested
*Advantages:
** No need to write stubs
** If the terminal modules does the main work in the system then they will be tested first
*Disadvantages:
** Need to write drivers
** The testing is not according to the architecture of the system

== '''Functional testing''' ==
Functional testing is designed to ensure the system requirements and specifications are achieved. It can start with testing of the requirements and whether the application compiles with the organizational policies and procedures.
During the design phase, after knowing the functionality of the module/modules and the system, some errors can be predicted in advance. A functional test should incorporate such type of scenarios too. In this case the erroneous transactions/ applications are deliberately introduced and the system should be able to correctly find them. In general, all the use cases in the user’s requirements become the functional test cases.
 
For example, suppose we are to develop the software for an elevator. For designing the test cases for this software,
all the scenarios and operations that can take place in the elevator need to be analyzed. To begin from the basic operations, the
elevator should be bidirectional and it should stop at each floor (unless we have two elevators in the requirement for even and
odd floors separately).The elevator should stop at the desired floor.

Generally Functional testing is '''Black Box''' testing. In this method the SUT (System under Test) is considered as a Black box. In this phase of testing the internals of the SUT like the design or algorithm are not considered by the tester. Inputs are provided to the black box and the outputs are validated to the expected output specified in the design document.

2 approaches can be taken for writing the functional tests
* '''Requirement based approach''': In this approach the specification for the system or software design is used as the base to write functional test.
* '''Business process based approach''': Business process refer to the day-to-day use of the system. This knowledge is used to do functional testing of the system.

Regression testing is another form of functional testing where you test the earlier features and functionality of the module which were working on the desired lines but have to be tested currently after some changes have been in the system. The changes might not be in the particular module but it can be affected due to inter dependencies.

CSC/ECE 517 Fall 2009/wiki1b 4 xy

2009-09-21T07:19:26Z

Alakshm3:

==''' Functional and Integration testing and beyond''' ==
Recognition of software test engineering as a specialty area has increased during the last twenty years. Testing is one of the key focus areas in software engineering. It is an essential activity that observes the functionality of a software system validates its intended behavior and identifies the potential malfunctions. Testing is also the primary way to improve software reliability.

The test cases should be carefully designed to cover many aspects in the SDLC such as possible aberrations from user’s requirements, system behavior upon malicious inputs, and robustness to extensive load conditions and so on. As more and more software is used in critical applications, the time and cost involved in testing is also increasing owing to the higher quality required. Although test automation saves a lot of time and can be used for regression load tests, manual testing is still widely used in the industry.

== '''Terms''' ==
# Driver: Supporting code or data used for testing the whole or part of the software system
# Sub-system: Component or Module of a software system
# System Under Test: The software system which has to be tested
# Stub: Dummy procedure or module that can be used to simulate or substitute an actual portion of a system
# Test: Sequence of steps to validate the system design and implementation
# Usecase :Scenario that describing an interaction between a user and a system

== '''Integration testing''' ==
Integration is a systematic approach to build the complete software structure specified in the design from unit-tested
modules.Integration testing is the next phase of unit testing. Generally in software development complete software is divided into various sub-systems mostly developed by different teams. More often than not each sub-system works very well individually but when they are integrated then lot of problems. So the main focus of integration tests is not the functionality of individual modules but the interaction between these modules like interaction with operating system, interaction between client and server

There are many approaches that can be followed for Integration Testing

=== '''Big Bang Testing Approach''' ===
As the name suggests all the components are integrated at once. After all the integration is completed a set of tests are run which not only validate a single component of sub-system but also test and validate the interaction between different components. This approach is more useful in smaller systems because integration of smaller systems are easier.
* Advantages:
** Since all the modules are combined and all are tested at the same time, this approach of integration is less time consuming
* Disadvantages:
** Debugging and solving a fault is not that trivial. Because in this type of testing many modules are integrated one cannot be sure whether the bug found was present in any sub-system or interaction between different sub-systems.
** Testing process cannot be started until all the sub-systems have finished their development.
** Writing test cases are also non-trivial.
<table>
<tr>
<td>
[[Image:Bigbang.jpg]]
</tr>
</td>
</table>
 
 
=== '''Incremental Testing Approach''' ===
Testing is done after integration of one module at a time. After finishing the unit testing of each module or sub-system they are integrated and tested. Stubs are used for modules in the system which are not integrated till now.
* Advantages:
** Problems detection is early compared to the Big Bang approach
** No need to wait till the unit testing of all the modules have finished
** Debugging is much simpler
* Disadvantages:
** This approach is a time taking process because the integration tests have to run multiple times
** Stubs have to be developed to substitute the missing modules
[[Image:Incremental testing.jpg]]
 
 
Various Approach can be taken for Incremental Testing
* '''Top-Down Approach''': In this approach the system is tested according to the work flow or code flow. The Top level module is tested first then each lower level module is integrated and tested.Top level modules are modules which call other modules and lower level modules are the ones which are called by other modules. Terminal modules are modules which do not call any other module.
[[Image:Topdown testing.jpg]]
 
 
In the above figure Module A is the top most module in the system then B,C,D are lower level modules. Generally module A is the user interface and stubs for each interface are used. Then each module is integrated and the tested.
* Advantages:
** The testing flow follows the architecture of the system so any bug in the top level design or implementation could be found at early stages
** If the top level modules call multiple lower modules then the testing can be done in various combinations
For example in the figure A calls B and C. The testing can be done as follows
A-B-C-D
A-C-B-D
* Disadvantage :
** The main problem with this approach is the use of stub. Mostly stubs are written to print out some trace statement based on the output of module A after running the test. Now if multiple scenarios have to be tested then different version of Stub B have to written, which is an extra overhead

* '''Bottom-Up Approach''': The bottom-up approach is the opposite of the top-down approach. In this approach the terminal approaches are tested first, then the higher modules and finally the top-most one. Drivers are used in this approach.
[[Image:Bottomup testing.jpg]]
 
 
In the above figure E,D are the terminal modules which are tested first. Then the higher level modules B,C are tested and finally the topmost module is tested
*Advantages:
** No need to write stubs
** If the terminal modules does the main work in the system then they will be tested first
*Disadvantages:
** Need to write drivers
** The testing is not according to the architecture of the system

== '''Functional testing''' ==
Functional testing is designed to ensure the system requirements and specifications are achieved. It can start with testing of the requirements and whether the application compiles with the organizational policies and procedures.
During the design phase, after knowing the functionality of the module/modules and the system, some errors can be predicted in advance. A functional test should incorporate such type of scenarios too. In this case the erroneous transactions/ applications are deliberately introduced and the system should be able to correctly find them. In general, all the use cases in the user’s requirements become the functional test cases.
 
For example, suppose we are to develop the software for an elevator. For designing the test cases for this software,
all the scenarios and operations that can take place in the elevator need to be analyzed. To begin from the basic operations, the
elevator should be bidirectional and it should stop at each floor (unless we have two elevators in the requirement for even and
odd floors separately).The elevator should stop at the desired floor.

Generally Functional testing is '''Black Box''' testing. In this method the SUT (System under Test) is considered as a Black box. In this phase of testing the internals of the SUT like the design or algorithm are not considered by the tester. Inputs are provided to the black box and the outputs are validated to the expected output specified in the design document.

2 approaches can be taken for writing the functional tests
* '''Requirement based approach''': In this approach the specification for the system or software design is used as the base to write functional test.
* '''Business process based approach''': Business process refer to the day-to-day use of the system. This knowledge is used to do functional testing of the system.

Regression testing is another form of functional testing where you test the earlier features and functionality of the module which were working on the desired lines but have to be tested currently after some changes have been in the system. The changes might not be in the particular module but it can be affected due to inter dependencies.

CSC/ECE 517 Fall 2009/wiki1b 4 xy

2009-09-21T07:17:50Z

Alakshm3:

==''' Functional and Integration testing and beyond''' ==
Recognition of software test engineering as a specialty area has increased during the last twenty years. Testing is one of the key focus areas in software engineering. It is an essential activity that observes the functionality of a software system validates its intended behavior and identifies the potential malfunctions. Testing is also the primary way to improve software reliability.

The test cases should be carefully designed to cover many aspects in the SDLC such as possible aberrations from user’s requirements, system behavior upon malicious inputs, and robustness to extensive load conditions and so on. As more and more software is used in critical applications, the time and cost involved in testing is also increasing owing to the higher quality required. Although test automation saves a lot of time and can be used for regression load tests, manual testing is still widely used in the industry.

== '''Terms''' ==
# Driver: Supporting code or data used for testing the whole or part of the software system
# Sub-system: Component or Module of a software system
# System Under Test: The software system which has to be tested
# Stub: Dummy procedure or module that can be used to simulate or substitute an actual portion of a system
# Test: Sequence of steps to validate the system design and implementation
# Usecase :Scenario that describing an interaction between a user and a system

== '''Integration testing''' ==
Integration is a systematic approach to build the complete software structure specified in the design from unit-tested
modules.Integration testing is the next phase of unit testing. Generally in software development complete software is divided into various sub-systems mostly developed by different teams. More often than not each sub-system works very well individually but when they are integrated then lot of problems. So the main focus of integration tests is not the functionality of individual modules but the interaction between these modules like interaction with operating system, interaction between client and server

There are many approaches that can be followed for Integration Testing

=== '''Big Bang Testing Approach''' ===
As the name suggests all the components are integrated at once. After all the integration is completed a set of tests are run which not only validate a single component of sub-system but also test and validate the interaction between different components. This approach is more useful in smaller systems because integration of smaller systems are easier.
* Advantages:
** Since all the modules are combined and all are tested at the same time, this approach of integration is less time consuming
* Disadvantages:
** Debugging and solving a fault is not that trivial. Because in this type of testing many modules are integrated one cannot be sure whether the bug found was present in any sub-system or interaction between different sub-systems.
** Testing process cannot be started until all the sub-systems have finished their development.
** Writing test cases are also non-trivial.
[[Image:Bigbang.jpg]]
 
 
=== '''Incremental Testing Approach''' ===
Testing is done after integration of one module at a time. After finishing the unit testing of each module or sub-system they are integrated and tested. Stubs are used for modules in the system which are not integrated till now.
* Advantages:
** Problems detection is early compared to the Big Bang approach
** No need to wait till the unit testing of all the modules have finished
** Debugging is much simpler
* Disadvantages:
** This approach is a time taking process because the integration tests have to run multiple times
** Stubs have to be developed to substitute the missing modules
[[Image:Incremental testing.jpg]]
 
 
Various Approach can be taken for Incremental Testing
* '''Top-Down Approach''': In this approach the system is tested according to the work flow or code flow. The Top level module is tested first then each lower level module is integrated and tested.Top level modules are modules which call other modules and lower level modules are the ones which are called by other modules. Terminal modules are modules which do not call any other module.
[[Image:Topdown testing.jpg]]
 
 
In the above figure Module A is the top most module in the system then B,C,D are lower level modules. Generally module A is the user interface and stubs for each interface are used. Then each module is integrated and the tested.
* Advantages:
** The testing flow follows the architecture of the system so any bug in the top level design or implementation could be found at early stages
** If the top level modules call multiple lower modules then the testing can be done in various combinations
For example in the figure A calls B and C. The testing can be done as follows
A-B-C-D
A-C-B-D
* Disadvantage :
** The main problem with this approach is the use of stub. Mostly stubs are written to print out some trace statement based on the output of module A after running the test. Now if multiple scenarios have to be tested then different version of Stub B have to written, which is an extra overhead

* '''Bottom-Up Approach''': The bottom-up approach is the opposite of the top-down approach. In this approach the terminal approaches are tested first, then the higher modules and finally the top-most one. Drivers are used in this approach.
[[Image:Bottomup testing.jpg]]
 
 
In the above figure E,D are the terminal modules which are tested first. Then the higher level modules B,C are tested and finally the topmost module is tested
*Advantages:
** No need to write stubs
** If the terminal modules does the main work in the system then they will be tested first
*Disadvantages:
** Need to write drivers
** The testing is not according to the architecture of the system

== '''Functional testing''' ==
Functional testing is designed to ensure the system requirements and specifications are achieved. It can start with testing of the requirements and whether the application compiles with the organizational policies and procedures.
During the design phase, after knowing the functionality of the module/modules and the system, some errors can be predicted in advance. A functional test should incorporate such type of scenarios too. In this case the erroneous transactions/ applications are deliberately introduced and the system should be able to correctly find them. In general, all the use cases in the user’s requirements become the functional test cases.
 
For example, suppose we are to develop the software for an elevator. For designing the test cases for this software,
all the scenarios and operations that can take place in the elevator need to be analyzed. To begin from the basic operations, the
elevator should be bidirectional and it should stop at each floor (unless we have two elevators in the requirement for even and
odd floors separately).The elevator should stop at the desired floor.

Generally Functional testing is '''Black Box''' testing. In this method the SUT (System under Test) is considered as a Black box. In this phase of testing the internals of the SUT like the design or algorithm are not considered by the tester. Inputs are provided to the black box and the outputs are validated to the expected output specified in the design document.

2 approaches can be taken for writing the functional tests
* '''Requirement based approach''': In this approach the specification for the system or software design is used as the base to write functional test.
* '''Business process based approach''': Business process refer to the day-to-day use of the system. This knowledge is used to do functional testing of the system.

Regression testing is another form of functional testing where you test the earlier features and functionality of the module which were working on the desired lines but have to be tested currently after some changes have been in the system. The changes might not be in the particular module but it can be affected due to inter dependencies.

CSC/ECE 517 Fall 2009/wiki1b 4 xy

2009-09-21T07:01:48Z

Alakshm3:

==''' Functional and Integration testing and beyond''' ==
Recognition of software test engineering as a specialty area has increased during the last twenty years. Testing is one of the key focus areas in software engineering. It is an essential activity that observes the functionality of a software system validates its intended behavior and identifies the potential malfunctions. Testing is also the primary way to improve software reliability.

The test cases should be carefully designed to cover many aspects in the SDLC such as possible aberrations from user’s requirements, system behavior upon malicious inputs, and robustness to extensive load conditions and so on. As more and more software is used in critical applications, the time and cost involved in testing is also increasing owing to the higher quality required. Although test automation saves a lot of time and can be used for regression load tests, manual testing is still widely used in the industry.

== '''Terms''' ==
# Driver: Supporting code or data used for testing the whole or part of the software system
# Sub-system: Component or Module of a software system
# System Under Test: The software system which has to be tested
# Stub: Dummy procedure or module that can be used to simulate or substitute an actual portion of a system
# Test: Sequence of steps to validate the system design and implementation
# Usecase :Scenario that describing an interaction between a user and a system

== '''Integration testing''' ==
Integration is a systematic approach to build the complete software structure specified in the design from unit-tested
modules.Integration testing is the next phase of unit testing. Generally in software development complete software is divided into various sub-systems mostly developed by different teams. More often than not each sub-system works very well individually but when they are integrated then lot of problems. So the main focus of integration tests is not the functionality of individual modules but the interaction between these modules like interaction with operating system, interaction between client and server

There are many approaches that can be followed for Integration Testing

=== '''Big Bang Testing Approach''' ===
As the name suggests all the components are integrated at once. After all the integration is completed a set of tests are run which not only validate a single component of sub-system but also test and validate the interaction between different components. This approach is more useful in smaller systems because integration of smaller systems are easier.
* Advantages:
** Since all the modules are combined and all are tested at the same time, this approach of integration is less time consuming
* Disadvantages:
** Debugging and solving a fault is not that trivial. Because in this type of testing many modules are integrated one cannot be sure whether the bug found was present in any sub-system or interaction between different sub-systems.
** Testing process cannot be started until all the sub-systems have finished their development.
** Writing test cases are also non-trivial.
[[Image:Bigbang.jpg]]
 
 
=== '''Incremental Testing Approach''' ===
Testing is done after integration of one module at a time. After finishing the unit testing of each module or sub-system they are integrated and tested. Stubs are used for modules in the system which are not integrated till now.
* Advantages:
** Problems detection is early compared to the Big Bang approach
** No need to wait till the unit testing of all the modules have finished
** Debugging is much simpler
* Disadvantages:
** This approach is a time taking process because the integration tests have to run multiple times
** Stubs have to be developed to substitute the missing modules
[[Image:Incremental testing.jpg]]
 
 
Various Approach can be taken for Incremental Testing
* '''Top-Down Approach''': In this approach the system is tested according to the work flow or code flow. The Top level module is tested first then each lower level module is integrated and tested.Top level modules are modules which call other modules and lower level modules are the ones which are called by other modules. Terminal modules are modules which do not call any other module.
[[Image:Topdown testing.jpg]]
 
 
In the above figure Module A is the top most module in the system then B,C,D are lower level modules. Generally module A is the user interface and stubs for each interface are used. Then each module is integrated and the tested.
* Advantages:
** The testing flow follows the architecture of the system so any bug in the top level design or implementation could be found at early stages
** If the top level modules call multiple lower modules then the testing can be done in various combinations
For example in the figure A calls B and C. The testing can be done as follows
A-B-C-D
A-C-B-D
* Disadvantage :
** The main problem with this approach is the use of stub. Mostly stubs are written to print out some trace statement based on the output of module A after running the test. Now if multiple scenarios have to be tested then different version of Stub B have to written, which is an extra overhead

* '''Bottom-Up Approach''': The bottom-up approach is the opposite of the top-down approach. In this approach the terminal approaches are tested first, then the higher modules and finally the top-most one. Drivers are used in this approach.
[[Image:Bottomup testing.jpg]]
 
 
Bottom Up Approach
In the above figure E,D are the terminal modules which are tested first. Then the higher level modules B,C are tested and finally the topmost module is tested
*Advantages:
** No need to write stubs
** If the terminal modules does the main work in the system then they will be tested first
*Disadvantages:
** Need to write drivers
** The testing is not according to the architecture of the system

== '''Functional testing''' ==
Functional testing is designed to ensure the system requirements and specifications are achieved. It can start with testing of the requirements and whether the application compiles with the organizational policies and procedures.
During the design phase, after knowing the functionality of the module/modules and the system, some errors can be predicted in advance. A functional test should incorporate such type of scenarios too. In this case the erroneous transactions/ applications are deliberately introduced and the system should be able to correctly find them. In general, all the use cases in the user’s requirements become the functional test cases.
 
For example, suppose we are to develop the software for an elevator. For designing the test cases for this software,
all the scenarios and operations that can take place in the elevator need to be analyzed. To begin from the basic operations, the
elevator should be bidirectional and it should stop at each floor (unless we have two elevators in the requirement for even and
odd floors separately).The elevator should stop at the desired floor.

Generally Functional testing is '''Black Box''' testing. In this method the SUT (System under Test) is considered as a Black box. In this phase of testing the internals of the SUT like the design or algorithm are not considered by the tester. Inputs are provided to the black box and the outputs are validated to the expected output specified in the design document.

2 approaches can be taken for writing the functional tests
* '''Requirement based approach''': In this approach the specification for the system or software design is used as the base to write functional test.
* '''Business process based approach''': Business process refer to the day-to-day use of the system. This knowledge is used to do functional testing of the system.

Regression testing is another form of functional testing where you test the earlier features and functionality of the module which were working on the desired lines but have to be tested currently after some changes have been in the system. The changes might not be in the particular module but it can be affected due to inter dependencies.

CSC/ECE 517 Fall 2009/wiki1b 4 xy

2009-09-21T06:57:54Z

Alakshm3:

==''' Functional and Integration testing and beyond''' ==
Recognition of software test engineering as a specialty area has increased during the last twenty years. Testing is one of the key focus areas in software engineering. It is an essential activity that observes the functionality of a software system validates its intended behavior and identifies the potential malfunctions. Testing is also the primary way to improve software reliability.

The test cases should be carefully designed to cover many aspects in the SDLC such as possible aberrations from user’s requirements, system behavior upon malicious inputs, and robustness to extensive load conditions and so on. As more and more software is used in critical applications, the time and cost involved in testing is also increasing owing to the higher quality required. Although test automation saves a lot of time and can be used for regression load tests, manual testing is still widely used in the industry.

== '''Terms''' ==
# Driver: Supporting code or data used for testing the whole or part of the software system
# Sub-system: Component or Module of a software system
# System Under Test: The software system which has to be tested
# Stub: Dummy procedure or module that can be used to simulate or substitute an actual portion of a system
# Test: Sequence of steps to validate the system design and implementation
# Usecase :Scenario that describing an interaction between a user and a system

== '''Integration testing''' ==
Integration is a systematic approach to build the complete software structure specified in the design from unit-tested
modules.Integration testing is the next phase of unit testing. Generally in software development complete software is divided into various sub-systems mostly developed by different teams. More often than not each sub-system works very well individually but when they are integrated then lot of problems. So the main focus of integration tests is not the functionality of individual modules but the interaction between these modules like interaction with operating system, interaction between client and server

There are many approaches that can be followed for Integration Testing

=== '''Big Bang Testing Approach''' ===
As the name suggests all the components are integrated at once. After all the integration is completed a set of tests are run which not only validate a single component of sub-system but also test and validate the interaction between different components. This approach is more useful in smaller systems because integration of smaller systems are easier.
* Advantages:
** Since all the modules are combined and all are tested at the same time, this approach of integration is less time consuming
* Disadvantages:
** Debugging and solving a fault is not that trivial. Because in this type of testing many modules are integrated one cannot be sure whether the bug found was present in any sub-system or interaction between different sub-systems.
** Testing process cannot be started until all the sub-systems have finished their development.
** Writing test cases are also non-trivial.
[[Image:Bigbang.jpg]]
 
 
=== '''Incremental Testing Approach''' ===
Testing is done after integration of one module at a time. After finishing the unit testing of each module or sub-system they are integrated and tested. Stubs are used for modules in the system which are not integrated till now.
* Advantages:
** Problems detection is early compared to the Big Bang approach
** No need to wait till the unit testing of all the modules have finished
** Debugging is much simpler
* Disadvantages:
** This approach is a time taking process because the integration tests have to run multiple times
** Stubs have to be developed to substitute the missing modules
[[Image:Incremental testing.jpg]]
 
 
Various Approach can be taken for Incremental Testing
* '''Top-Down Approach''': In this approach the system is tested according to the work flow or code flow. The Top level module is tested first then each lower level module is integrated and tested.Top level modules are modules which call other modules and lower level modules are the ones which are called by other modules. Terminal modules are modules which do not call any other module.
[[Image:Topdown testing.jpg]]
 
 
In the above figure Module A is the top most module in the system then B,C,D are lower level modules. Generally module A is the user interface and stubs for each interface are used. Then each module is integrated and the tested.
* Advantages:
** The testing flow follows the architecture of the system so any bug in the top level design or implementation could be found at early stages
** If the top level modules call multiple lower modules then the testing can be done in various combinations
For example in the figure A calls B and C. The testing can be done as follows
A-B-C-D
A-C-B-D
* Disadvantage :
** The main problem with this approach is the use of stub. Mostly stubs are written to print out some trace statement based on the output of module A after running the test. Now if multiple scenarios have to be tested then different version of Stub B have to written, which is an extra overhead

* '''Bottom-Up Approach''': The bottom-up approach is the opposite of the top-down approach. In this approach the terminal approaches are tested first, then the higher modules and finally the top-most one. Drivers are used in this approach.
[[Image:Bottomup testing.jpg]]
 
 
Bottom Up Approach
In the above figure E,D are the terminal modules which are tested first. Then the higher level modules B,C are tested and finally the topmost module is tested
*Advantages:
** No need to write stubs
** If the terminal modules does the main work in the system then they will be tested first
*Disadvantages:
** Need to write drivers
** The testing is not according to the architecture of the system

== '''Functional testing''' ==
Functional testing is designed to ensure the system requirements and specifications are achieved. It can start with testing of the requirements and whether the application compiles with the organizational policies and procedures.
During the design phase, after knowing the functionality of the module/modules and the system, some errors can be predicted in advance. A functional test should incorporate such type of scenarios too. In this case the erroneous transactions/ applications are deliberately introduced and the system should be able to correctly find them. In general, all the use cases in the user’s requirements become the functional test cases.
 
For example, suppose we are to develop the software for an elevator. For designing the test cases for this software,
all the senarios and operations that can take place in the elevator need to be analyzed. To begin from the basic operations, the
elevator should be bidirectional and it should stop at each floor (unless we have two elevators in the requirement for even and
odd floors separately).The elevator should stop at the desired floor.

Generally Functional testing is '''Black Box''' testing. In this method the SUT (System under Test) is considered as a Black box. In this phase of testing the internals of the SUT like the design or algorithm are not considered by the tester. Inputs are provided to the black box and the outputs are validated to the expected output specified in the design document.

2 approaches can be taken for writing the functional tests
* '''Requirement based approach''': In this approach the specification for the system or software design is used as the base to write functional test.
* '''Business process based approach''': Business process refer to the day-to-day use of the system. This knowledge is used to do functional testing of the system.

Regression testing is another form of functional testing where you test the earlier features and functionality of the module which were working on the desired lines but have to be tested currently after some changes have been in the system. The changes might not be in the particular module but it can be affected due to inter dependencies.

CSC/ECE 517 Fall 2009/wiki1b 4 xy

2009-09-21T06:55:58Z

Alakshm3:

==''' Functional and integration testing and beyond''' ==
Recognition of software test engineering as a specialty area has increased during the last twenty years. Testing is one of the key focus areas in software engineering. It is an essential activity that observes the functionality of a software system validates its intended behavior and identifies the potential malfunctions. Testing is also the primary way to improve software reliability.

The test cases should be carefully designed to cover many aspects in the SDLC such as possible aberrations from user’s requirements, system behavior upon malicious inputs, and robustness to extensive load conditions and so on. As more and more software is used in critical applications, the time and cost involved in testing is also increasing owing to the higher quality required. Although test automation saves a lot of time and can be used for regression load tests, manual testing is still widely used in the industry.

== '''Terms''' ==
# Driver: Supporting code or data used for testing the whole or part of the software system
# Sub-system: Component or Module of a software system
# System Under Test: The software system which has to be tested
# Stub: Dummy procedure or module that can be used to simulate or substitute an actual portion of a system
# Test: Sequence of steps to validate the system design and implementation
# Usecase :Scenario that describing an interaction between a user and a system

== '''Integration testing''' ==
Integration is a systematic approach to build the complete software structure specified in the design from unit-tested
modules.Integration testing is the next phase of unit testing. Generally in software development complete software is divided into various sub-systems mostly developed by different teams. More often than not each sub-system works very well individually but when they are integrated then lot of problems. So the main focus of integration tests is not the functionality of individual modules but the interaction between these modules like interaction with operating system, interaction between client and server

There are many approaches that can be followed for Integration Testing

=== '''Big Bang Testing Approach''' ===
As the name suggests all the components are integrated at once. After all the integration is completed a set of tests are run which not only validate a single component of sub-system but also test and validate the interaction between different components. This approach is more useful in smaller systems because integration of smaller systems are easier.
* Advantages:
** Since all the modules are combined and all are tested at the same time, this approach of integration is less time consuming
* Disadvantages:
** Debugging and solving a fault is not that trivial. Because in this type of testing many modules are integrated one cannot be sure whether the bug found was present in any sub-system or interaction between different sub-systems.
** Testing process cannot be started until all the sub-systems have finished their development.
** Writing test cases are also non-trivial.
[[Image:Bigbang.jpg]]
 
 
=== '''Incremental Testing Approach''' ===
Testing is done after integration of one module at a time. After finishing the unit testing of each module or sub-system they are integrated and tested. Stubs are used for modules in the system which are not integrated till now.
* Advantages:
** Problems detection is early compared to the Big Bang approach
** No need to wait till the unit testing of all the modules have finished
** Debugging is much simpler
* Disadvantages:
** This approach is a time taking process because the integration tests have to run multiple times
** Stubs have to be developed to substitute the missing modules
[[Image:Incremental testing.jpg]]
 
 
Various Approach can be taken for Incremental Testing
* '''Top-Down Approach''': In this approach the system is tested according to the work flow or code flow. The Top level module is tested first then each lower level module is integrated and tested.Top level modules are modules which call other modules and lower level modules are the ones which are called by other modules. Terminal modules are modules which do not call any other module.
[[Image:Topdown testing.jpg]]
 
 
In the above figure Module A is the top most module in the system then B,C,D are lower level modules. Generally module A is the user interface and stubs for each interface are used. Then each module is integrated and the tested.
* Advantages:
** The testing flow follows the architecture of the system so any bug in the top level design or implementation could be found at early stages
** If the top level modules call multiple lower modules then the testing can be done in various combinations
For example in the figure A calls B and C. The testing can be done as follows
A-B-C-D
A-C-B-D
* Disadvantage :
** The main problem with this approach is the use of stub. Mostly stubs are written to print out some trace statement based on the output of module A after running the test. Now if multiple scenarios have to be tested then different version of Stub B have to written, which is an extra overhead

* '''Bottom-Up Approach''': The bottom-up approach is the opposite of the top-down approach. In this approach the terminal approaches are tested first, then the higher modules and finally the top-most one. Drivers are used in this approach.
[[Image:Bottomup testing.jpg]]
 
 
Bottom Up Approach
In the above figure E,D are the terminal modules which are tested first. Then the higher level modules B,C are tested and finally the topmost module is tested
*Advantages:
** No need to write stubs
** If the terminal modules does the main work in the system then they will be tested first
*Disadvantages:
** Need to write drivers
** The testing is not according to the architecture of the system

== '''Functional testing''' ==
Functional testing is designed to ensure the system requirements and specifications are achieved. It can start with testing of the requirements and whether the application compiles with the organizational policies and procedures.
During the design phase, after knowing the functionality of the module/modules and the system, some errors can be predicted in advance. A functional test should incorporate such type of scenarios too. In this case the erroneous transactions/ applications are deliberately introduced and the system should be able to correctly find them. In general, all the use cases in the user’s requirements become the functional test cases.
 
For example, suppose we are to develop the software for an elevator. For designing the test cases for this software,
all the senarios and operations that can take place in the elevator need to be analyzed. To begin from the basic operations, the
elevator should be bidirectional and it should stop at each floor (unless we have two elevators in the requirement for even and
odd floors separately).The elevator should stop at the desired floor.

Generally Functional testing is '''Black Box''' testing. In this method the SUT (System under Test) is considered as a Black box. In this phase of testing the internals of the SUT like the design or algorithm are not considered by the tester. Inputs are provided to the black box and the outputs are validated to the expected output specified in the design document.

2 approaches can be taken for writing the functional tests
* '''Requirement based approach''': In this approach the specification for the system or software design is used as the base to write functional test.
* '''Business process based approach''': Business process refer to the day-to-day use of the system. This knowledge is used to do functional testing of the system.

Regression testing is another form of functional testing where you test the earlier features and functionality of the module which were working on the desired lines but have to be tested currently after some changes have been in the system. The changes might not be in the particular module but it can be affected due to inter dependencies.

CSC/ECE 517 Fall 2009/wiki1b 4 xy

2009-09-21T05:58:23Z

Alakshm3: /* '''Integration testing''' */

==''' Functional and integration testing and beyond''' ==
Recognition of software test engineering as a specialty area has increased during the last twenty years. Testing is one of the key focus areas in software engineering. It is an essential activity that observes the functionality of a software system validates its intended behavior and identifies the potential malfunctions. Testing is also the primary way to improve software reliability.

The test cases should be carefully designed to cover many aspects in the SDLC such as possible aberrations from user’s requirements, system behavior upon malicious inputs, and robustness to extensive load conditions and so on. As more and more software is used in critical applications, the time and cost involved in testing is also increasing owing to the higher quality required. Although test automation saves a lot of time and can be used for regression load tests, manual testing is still widely used in the industry.

== '''Terms''' ==
# Driver: Supporting code or data used for testing the whole or part of the software system
# Sub-system: Component or Module of a software system
# System Under Test: The software system which has to be tested
# Stub: Dummy procedure or module that can be used to simulate or substitute an actual portion of a system
# Test: Sequence of steps to validate the system design and implementation
# Usecase :Scenario that describing an interaction between a user and a system

== '''Integration testing''' ==
Integration is a systematic approach to build the complete software structure specified in the design from unit-tested
modules.Integration testing is the next phase of unit testing. Generally in software development complete software is divided into various sub-systems mostly developed by different teams. More often than not each sub-system works very well individually but when they are integrated then lot of problems. So the main focus of integration tests is not the functionality of individual modules but the interaction between these modules like interaction with operating system, interaction between client and server

There are many approaches that can be followed for Integration Testing

=== '''Big Bang Testing Approach''' ===
As the name suggests all the components are integrated at once. After all the integration is completed a set of tests are run which not only validate a single component of sub-system but also test and validate the interaction between different components. This approach is more useful in smaller systems because integration of smaller systems are easier.
* Advantages:
** Since all the modules are combined and all are tested at the same time, this approach of integration is less time consuming
* Disadvantages:
** Debugging and solving a fault is not that trivial. Because in this type of testing many modules are integrated one cannot be sure whether the bug found was present in any sub-system or interaction between different sub-systems.
** Testing process cannot be started until all the sub-systems have finished their development.
** Writing test cases are also non-trivial.
[[Image:Bigbang.jpg]]
 
 
=== '''Incremental Testing Approach''' ===
Testing is done after integration of one module at a time. After finishing the unit testing of each module or sub-system they are integrated and tested. Stubs are used for modules in the system which are not integrated till now.
* Advantages:
** Problems detection is early compared to the Big Bang approach
** No need to wait till the unit testing of all the modules have finished
** Debugging is much simpler
* Disadvantages:
** This approach is a time taking process because the integration tests have to run multiple times
** Stubs have to be developed to substitute the missing modules
[[Image:Incremental testing.jpg]]
 
 
Various Approach can be taken for Incremental Testing
* '''Top-Down Approach''': In this approach the system is tested according to the work flow or code flow. The Top level module is tested first then each lower level module is integrated and tested.Top level modules are modules which call other modules and lower level modules are the ones which are called by other modules. Terminal modules are modules which do not call any other module.
[[Image:Topdown testing.jpg]]
 
 
In the above figure Module A is the top most module in the system then B,C,D are lower level modules. Generally module A is the user interface and stubs for each interface are used. Then each module is integrated and the tested.
* Advantages:
** The testing flow follows the architecture of the system so any bug in the top level design or implementation could be found at early stages
** If the top level modules call multiple lower modules then the testing can be done in various combinations
For example in the figure A calls B and C. The testing can be done as follows
A-B-C-D
A-C-B-D
* Disadvantage :
** The main problem with this approach is the use of stub. Mostly stubs are written to print out some trace statement based on the output of module A after running the test. Now if multiple scenarios have to be tested then different version of Stub B have to written, which is an extra overhead

* '''Bottom-Up Approach''': The bottom-up approach is the opposite of the top-down approach. In this approach the terminal approaches are tested first, then the higher modules and finally the top-most one. Drivers are used in this approach.
[[Image:Bottomup testing.jpg]]
 
 
Bottom Up Approach
In the above figure E,D are the terminal modules which are tested first. Then the higher level modules B,C are tested and finally the topmost module is tested
*Advantages:
** No need to write stubs
** If the terminal modules does the main work in the system then they will be tested first
*Disadvantages:
** Need to write drivers
** The testing is not according to the architecture of the system

== '''Functional testing''' ==
Functional testing is designed to ensure the system requirements and specifications are achieved. It can start with testing of the requirements and whether the application compiles with the organizational policies and procedures.
Regression testing is another form of functional testing where you test the earlier features and functionality of the module which were working on the desired lines but have to be tested currently after some changes have been in the system. The changes might not be in the particular module but it can be affected due to inter dependencies. During the design phase, after knowing the functionality of the module/modules and the system, some errors can be predicted in advance. A functional test should incorporate such type of scenarios too. In this case the erroneous transactions/ applications are deliberately introduced and the system should be able to correctly find them. In general, all the use cases in the user’s requirements become the functional test cases.
As an example, suppose we are to develop the software for an elevator. For designing the test cases for this software, all the scenarios and operations that can take place in the elevator need to be analyzed. To begin from the basic operations, the elevator should be bidirectional and it should stop at each floor (unless we have two elevators in the requirement for even and odd floors separately).The elevator should stop at the desired floor.

CSC/ECE 517 Fall 2009/wiki1b 4 xy

2009-09-21T05:11:08Z

Alakshm3:

==''' Functional and integration testing and beyond''' ==
Recognition of software test engineering as a specialty area has increased during the last twenty years. Testing is one of the key focus areas in software engineering. It is an essential activity that observes the functionality of a software system validates its intended behavior and identifies the potential malfunctions. Testing is also the primary way to improve software reliability.

The test cases should be carefully designed to cover many aspects in the SDLC such as possible aberrations from user’s requirements, system behavior upon malicious inputs, and robustness to extensive load conditions and so on. As more and more software is used in critical applications, the time and cost involved in testing is also increasing owing to the higher quality required. Although test automation saves a lot of time and can be used for regression load tests, manual testing is still widely used in the industry.

== '''Terms''' ==
# Driver: Supporting code or data used for testing the whole or part of the software system
# Sub-system: Component or Module of a software system
# System Under Test: The software system which has to be tested
# Stub: Dummy procedure or module that can be used to simulate or substitute an actual portion of a system
# Test: Sequence of steps to validate the system design and implementation
# Usecase :Scenario that describing an interaction between a user and a system

== '''Integration testing''' ==
Integration is a systematic approach to build the complete software structure specified in the design from unit-tested
modules.Integration testing is the next phase of unit testing. Generally in software development complete software is divided into various sub-systems mostly developed by different teams. More often than not each sub-system works very well individually but when they are integrated then lot of problems. So the main focus of integration tests is not the functionality of individual modules but the interaction between these modules like interaction with operating system, interaction between client and server

There are many approaches that can be followed for Integration Testing

* '''Big Bang Testing Approach''' As the name suggests all the components are integrated at once. After all the integration is completed a set of tests are run which not only validate a single component of sub-system but also test and validate the interaction between different components. This approach is more useful in smaller systems because integration of smaller systems are easier.
** Advantages:
*** Since all the modules are combined and all are tested at the same time, this approach of integration is less time consuming
** Disadvantages:
*** Debugging and solving a fault is not that trivial. Because in this type of testing many modules are integrated one cannot be sure whether the bug found was present in any sub-system or interaction between different sub-systems.
*** Testing process cannot be started until all the sub-systems have finished their development.
*** Writing test cases are also non-trivial.
[[Image:Bigbang.jpg]]
 
 
* '''Incremental Testing Approach''' Testing is done after integration of one module at a time. After finishing the unit testing of each module or sub-system they are integrated and tested. Stubs are used for modules in the system which are not integrated till now.
** Advantages:
*** Problems detection is early compared to the Big Bang approach
*** No need to wait till the unit testing of all the modules have finished
*** Debugging is much simpler
** Disadvantages:
*** This approach is a time taking process because the integration tests have to run multiple times
*** Stubs have to be developed to substitute the missing modules
[[Image:Incremental testing.jpg]]
 
 
Various Approach can be taken for Incremental Testing
* '''Top-Down Approach''': In this approach the system is tested according to the work flow or code flow. The Top level module is tested first then each lower level module is integrated and tested.Top level modules are modules which call other modules and lower level modules are the ones which are called by other modules. Terminal modules are modules which do not call any other module.
[[Image:Topdown testing.jpg]]
 
 
In the above figure Module A is the top most module in the system then B,C,D are lower level modules. Generally module A is the user interface and stubs for each interface are used. Then each module is integrated and the tested.
* Advantages:
** The testing flow follows the architecture of the system so any bug in the top level design or implementation could be found at early stages
** If the top level modules call multiple lower modules then the testing can be done in various combinations
For example in the figure A calls B and C. The testing can be done as follows
A-B-C-D
A-C-B-D
* Disadvantage :
** The main problem with this approach is the use of stub. Mostly stubs are written to print out some trace statement based on the output of module A after running the test. Now if multiple scenarios have to be tested then different version of Stub B have to written, which is an extra overhead

* '''Bottom-Up Approach''': The bottom-up approach is the opposite of the top-down approach. In this approach the terminal approaches are tested first, then the higher modules and finally the top-most one. Drivers are used in this approach.
[[Image:Bottomup testing.jpg]]
 
 
Bottom Up Approach
In the above figure E,D are the terminal modules which are tested first. Then the higher level modules B,C are tested and finally the topmost module is tested
*Advantages:
** No need to write stubs
** If the terminal modules does the main work in the system then they will be tested first
*Disadvantages:
** Need to write drivers
** The testing is not according to the architecture of the system

== '''Functional testing''' ==
Functional testing is designed to ensure the system requirements and specifications are achieved. It can start with testing of the requirements and whether the application compiles with the organizational policies and procedures.
Regression testing is another form of functional testing where you test the earlier features and functionality of the module which were working on the desired lines but have to be tested currently after some changes have been in the system. The changes might not be in the particular module but it can be affected due to inter dependencies. During the design phase, after knowing the functionality of the module/modules and the system, some errors can be predicted in advance. A functional test should incorporate such type of scenarios too. In this case the erroneous transactions/ applications are deliberately introduced and the system should be able to correctly find them. In general, all the use cases in the user’s requirements become the functional test cases.
As an example, suppose we are to develop the software for an elevator. For designing the test cases for this software, all the scenarios and operations that can take place in the elevator need to be analyzed. To begin from the basic operations, the elevator should be bidirectional and it should stop at each floor (unless we have two elevators in the requirement for even and odd floors separately).The elevator should stop at the desired floor.

CSC/ECE 517 Fall 2009/wiki1b 4 xy

2009-09-21T05:10:45Z

Alakshm3:

==''' Functional and integration testing and beyond''' ==
Recognition of software test engineering as a specialty area has increased during the last twenty years. Testing is one of the key focus areas in software engineering. It is an essential activity that observes the functionality of a software system validates its intended behavior and identifies the potential malfunctions. Testing is also the primary way to improve software reliability.

The test cases should be carefully designed to cover many aspects in the SDLC such as possible aberrations from user’s requirements, system behavior upon malicious inputs, and robustness to extensive load conditions and so on. As more and more software is used in critical applications, the time and cost involved in testing is also increasing owing to the higher quality required. Although test automation saves a lot of time and can be used for regression load tests, manual testing is still widely used in the industry.

== '''Terms''' ==
# Driver: Supporting code or data used for testing the whole or part of the software system
# Sub-system: Component or Module of a software system
# System Under Test: The software system which has to be tested
# Stub: Dummy procedure or module that can be used to simulate or substitute an actual portion of a system
# Test: Sequence of steps to validate the system design and implementation
# Usecase :Scenario that describing an interaction between a user and a system

== '''Integration testing''' ==
Integration is a systematic approach to build the complete software structure specified in the design from unit-tested
modules.Integration testing is the next phase of unit testing. Generally in software development complete software is divided into various sub-systems mostly developed by different teams. More often than not each sub-system works very well individually but when they are integrated then lot of problems. So the main focus of integration tests is not the functionality of individual modules but the interaction between these modules like interaction with operating system, interaction between client and server

There are many approaches that can be followed for Integration Testing

* '''Big Bang Testing Approach''' As the name suggests all the components are integrated at once. After all the integration is completed a set of tests are run which not only validate a single component of sub-system but also test and validate the interaction between different components. This approach is more useful in smaller systems because integration of smaller systems are easier.
** Advantages:
*** Since all the modules are combined and all are tested at the same time, this approach of integration is less time consuming
** Disadvantages:
*** Debugging and solving a fault is not that trivial. Because in this type of testing many modules are integrated one cannot be sure whether the bug found was present in any sub-system or interaction between different sub-systems.
*** Testing process cannot be started until all the sub-systems have finished their development.
*** Writing test cases are also non-trivial.
[[Image:Bigbang.jpg]]
 
 
* '''Incremental Testing Approach''' Testing is done after integration of one module at a time. After finishing the unit testing of each module or sub-system they are integrated and tested. Stubs are used for modules in the system which are not integrated till now.
** Advantages:
*** Problems detection is early compared to the Big Bang approach
*** No need to wait till the unit testing of all the modules have finished
*** Debugging is much simpler
** Disadvantages:
*** This approach is a time taking process because the integration tests have to run multiple times
*** Stubs have to be developed to substitute the missing modules
[[Image:Incremental testing.jpg]]
 
 
Various Approach can be taken for Incremental Testing
* '''Top-Down Approach''': In this approach the system is tested according to the work flow or code flow. The Top level module is tested first then each lower level module is integrated and tested.Top level modules are modules which call other modules and lower level modules are the ones which are called by other modules. Terminal modules are modules which do not call any other module.
[[Image:Topdown testing.jpg]]
 
 
In the above figure Module A is the top most module in the system then B,C,D are lower level modules. Generally module A is the user interface and stubs for each interface are used. Then each module is integrated and the tested.
* Advantages:
** The testing flow follows the architecture of the system so any bug in the top level design or implementation could be found at early stages
** If the top level modules call multiple lower modules then the testing can be done in various combinations
For example in the figure A calls B and C. The testing can be done as follows
A-B-C-D
A-C-B-D
* Disadvantage :
** The main problem with this approach is the use of stub. Mostly stubs are written to print out some trace statement based on the output of module A after running the test. Now if multiple scenarios have to be tested then different version of Stub B have to written, which is an extra overhead

* '''Bottom-Up Approach''': The bottom-up approach is the opposite of the top-down approach. In this approach the terminal approaches are tested first, then the higher modules and finally the top-most one. Drivers are used in this approach.
[[Image:TBottomup testing.jpg]]
 
 
Bottom Up Approach
In the above figure E,D are the terminal modules which are tested first. Then the higher level modules B,C are tested and finally the topmost module is tested
*Advantages:
** No need to write stubs
** If the terminal modules does the main work in the system then they will be tested first
*Disadvantages:
** Need to write drivers
** The testing is not according to the architecture of the system

== '''Functional testing''' ==
Functional testing is designed to ensure the system requirements and specifications are achieved. It can start with testing of the requirements and whether the application compiles with the organizational policies and procedures.
Regression testing is another form of functional testing where you test the earlier features and functionality of the module which were working on the desired lines but have to be tested currently after some changes have been in the system. The changes might not be in the particular module but it can be affected due to inter dependencies. During the design phase, after knowing the functionality of the module/modules and the system, some errors can be predicted in advance. A functional test should incorporate such type of scenarios too. In this case the erroneous transactions/ applications are deliberately introduced and the system should be able to correctly find them. In general, all the use cases in the user’s requirements become the functional test cases.
As an example, suppose we are to develop the software for an elevator. For designing the test cases for this software, all the scenarios and operations that can take place in the elevator need to be analyzed. To begin from the basic operations, the elevator should be bidirectional and it should stop at each floor (unless we have two elevators in the requirement for even and odd floors separately).The elevator should stop at the desired floor.

CSC/ECE 517 Fall 2009/wiki1b 4 xy

2009-09-21T05:10:08Z

Alakshm3:

==''' Functional and integration testing and beyond''' ==
Recognition of software test engineering as a specialty area has increased during the last twenty years. Testing is one of the key focus areas in software engineering. It is an essential activity that observes the functionality of a software system validates its intended behavior and identifies the potential malfunctions. Testing is also the primary way to improve software reliability.

The test cases should be carefully designed to cover many aspects in the SDLC such as possible aberrations from user’s requirements, system behavior upon malicious inputs, and robustness to extensive load conditions and so on. As more and more software is used in critical applications, the time and cost involved in testing is also increasing owing to the higher quality required. Although test automation saves a lot of time and can be used for regression load tests, manual testing is still widely used in the industry.

== '''Terms''' ==
# Driver: Supporting code or data used for testing the whole or part of the software system
# Sub-system: Component or Module of a software system
# System Under Test: The software system which has to be tested
# Stub: Dummy procedure or module that can be used to simulate or substitute an actual portion of a system
# Test: Sequence of steps to validate the system design and implementation
# Usecase :Scenario that describing an interaction between a user and a system

== '''Integration testing''' ==
Integration is a systematic approach to build the complete software structure specified in the design from unit-tested
modules.Integration testing is the next phase of unit testing. Generally in software development complete software is divided into various sub-systems mostly developed by different teams. More often than not each sub-system works very well individually but when they are integrated then lot of problems. So the main focus of integration tests is not the functionality of individual modules but the interaction between these modules like interaction with operating system, interaction between client and server

There are many approaches that can be followed for Integration Testing

* '''Big Bang Testing Approach''' As the name suggests all the components are integrated at once. After all the integration is completed a set of tests are run which not only validate a single component of sub-system but also test and validate the interaction between different components. This approach is more useful in smaller systems because integration of smaller systems are easier.
** Advantages:
*** Since all the modules are combined and all are tested at the same time, this approach of integration is less time consuming
** Disadvantages:
*** Debugging and solving a fault is not that trivial. Because in this type of testing many modules are integrated one cannot be sure whether the bug found was present in any sub-system or interaction between different sub-systems.
*** Testing process cannot be started until all the sub-systems have finished their development.
*** Writing test cases are also non-trivial.
[[Image:Bigbang.jpg]]
 
 
* '''Incremental Testing Approach''' Testing is done after integration of one module at a time. After finishing the unit testing of each module or sub-system they are integrated and tested. Stubs are used for modules in the system which are not integrated till now.
** Advantages:
*** Problems detection is early compared to the Big Bang approach
*** No need to wait till the unit testing of all the modules have finished
*** Debugging is much simpler
** Disadvantages:
*** This approach is a time taking process because the integration tests have to run multiple times
*** Stubs have to be developed to substitute the missing modules
[[Image:Incremental testing.jpg]]
 
 
Various Approach can be taken for Incremental Testing
* '''Top-Down Approach''': In this approach the system is tested according to the work flow or code flow. The Top level module is tested first then each lower level module is integrated and tested.Top level modules are modules which call other modules and lower level modules are the ones which are called by other modules. Terminal modules are modules which do not call any other module.
[[Image:Topdown testing.jpg]]
 
 
In the above figure Module A is the top most module in the system then B,C,D are lower level modules. Generally module A is the user interface and stubs for each interface are used. Then each module is integrated and the tested.
* Advantages:
** The testing flow follows the architecture of the system so any bug in the top level design or implementation could be found at early stages
** If the top level modules call multiple lower modules then the testing can be done in various combinations
For example in the figure A calls B and C. The testing can be done as follows
A-B-C-D
A-C-B-D
* Disadvantage :
** The main problem with this approach is the use of stub. Mostly stubs are written to print out some trace statement based on the output of module A after running the test. Now if multiple scenarios have to be tested then different version of Stub B have to written, which is an extra overhead

* '''Bottom-Up Approach''': The bottom-up approach is the opposite of the top-down approach. In this approach the terminal approaches are tested first, then the higher modules and finally the top-most one. Drivers are used in this approach.
[[Image:Topdown testing.jpg]]
 
 
Bottom Up Approach
In the above figure E,D are the terminal modules which are tested first. Then the higher level modules B,C are tested and finally the topmost module is tested
*Advantages:
** No need to write stubs
** If the terminal modules does the main work in the system then they will be tested first
*Disadvantages:
** Need to write drivers
** The testing is not according to the architecture of the system

== '''Functional testing''' ==
Functional testing is designed to ensure the system requirements and specifications are achieved. It can start with testing of the requirements and whether the application compiles with the organizational policies and procedures.
Regression testing is another form of functional testing where you test the earlier features and functionality of the module which were working on the desired lines but have to be tested currently after some changes have been in the system. The changes might not be in the particular module but it can be affected due to inter dependencies. During the design phase, after knowing the functionality of the module/modules and the system, some errors can be predicted in advance. A functional test should incorporate such type of scenarios too. In this case the erroneous transactions/ applications are deliberately introduced and the system should be able to correctly find them. In general, all the use cases in the user’s requirements become the functional test cases.
As an example, suppose we are to develop the software for an elevator. For designing the test cases for this software, all the scenarios and operations that can take place in the elevator need to be analyzed. To begin from the basic operations, the elevator should be bidirectional and it should stop at each floor (unless we have two elevators in the requirement for even and odd floors separately).The elevator should stop at the desired floor.

File:Bottomup testing.jpg

2009-09-21T04:55:09Z

Alakshm3: Bottom up testing

Bottom up testing

CSC/ECE 517 Fall 2009/wiki1b 4 xy

2009-09-21T04:25:27Z

Alakshm3:

==''' Functional and integration testing and beyond''' ==
Recognition of software test engineering as a specialty area has increased during the last twenty years. Testing is one of the key focus areas in software engineering. It is an essential activity that observes the functionality of a software system validates its intended behavior and identifies the potential malfunctions. Testing is also the primary way to improve software reliability.

The test cases should be carefully designed to cover many aspects in the SDLC such as possible aberrations from user’s requirements, system behavior upon malicious inputs, and robustness to extensive load conditions and so on. As more and more software is used in critical applications, the time and cost involved in testing is also increasing owing to the higher quality required. Although test automation saves a lot of time and can be used for regression load tests, manual testing is still widely used in the industry.

== '''Terms''' ==
# Driver: Supporting code or data used for testing the whole or part of the software system
# Sub-system: Component or Module of a software system
# System Under Test: The software system which has to be tested
# Stub: Dummy procedure or module that can be used to simulate or substitute an actual portion of a system
# Test: Sequence of steps to validate the system design and implementation
# Usecase :Scenario that describing an interaction between a user and a system

== '''Integration testing''' ==
Integration is a systematic approach to build the complete software structure specified in the design from unit-tested
modules.Integration testing is the next phase of unit testing. Generally in software development complete software is divided into various sub-systems mostly developed by different teams. More often than not each sub-system works very well individually but when they are integrated then lot of problems. So the main focus of integration tests is not the functionality of individual modules but the interaction between these modules like interaction with operating system, interaction between client and server

There are many approaches that can be followed for Integration Testing

* '''Big Bang Testing Approach''' As the name suggests all the components are integrated at once. After all the integration is completed a set of tests are run which not only validate a single component of sub-system but also test and validate the interaction between different components. This approach is more useful in smaller systems because integration of smaller systems are easier.
** Advantages:
*** Since all the modules are combined and all are tested at the same time, this approach of integration is less time consuming
** Disadvantages:
*** Debugging and solving a fault is not that trivial. Because in this type of testing many modules are integrated one cannot be sure whether the bug found was present in any sub-system or interaction between different sub-systems.
*** Testing process cannot be started until all the sub-systems have finished their development.
*** Writing test cases are also non-trivial.
[[Image:Bigbang.jpg]]
 
 
* '''Incremental Testing Approach''' Testing is done after integration of one module at a time. After finishing the unit testing of each module or sub-system they are integrated and tested. Stubs are used for modules in the system which are not integrated till now.
** Advantages:
*** Problems detection is early compared to the Big Bang approach
*** No need to wait till the unit testing of all the modules have finished
*** Debugging is much simpler
** Disadvantages:
*** This approach is a time taking process because the integration tests have to run multiple times
*** Stubs have to be developed to substitute the missing modules
[[Image:Incremental testing.jpg]]
 
 
Various Approach can be taken for Incremental Testing
* '''Top-Down Approach''': In this approach the system is tested according to the work flow or code flow. The Top level module is tested first then each lower level module is integrated and tested.
[[Image:Topdown testing.jpg]]
 
 
In the above figure Module A is the top most module in the system then B,C,D are lower level modules. Generally module A is the user interface and stubs for each interface are used. Then each module is integrated and the tested.
* Advantages:
** The testing flow follows the architecture of the system
* Disadvantage :
** The main problem with this approach is the use of stub. Mostly stubs are written to print out some trace statement based on the output of module A after running the test. Now if multiple scenarios have to be tested then different version of Stub B have to written, which is an extra overhead

* '''Bottom-Up Approach''':

== '''Functional testing''' ==
Functional testing is designed to ensure the system requirements and specifications are achieved. It can start with testing of the requirements and whether the application compiles with the organizational policies and procedures.
Regression testing is another form of functional testing where you test the earlier features and functionality of the module which were working on the desired lines but have to be tested currently after some changes have been in the system. The changes might not be in the particular module but it can be affected due to inter dependencies. During the design phase, after knowing the functionality of the module/modules and the system, some errors can be predicted in advance. A functional test should incorporate such type of scenarios too. In this case the erroneous transactions/ applications are deliberately introduced and the system should be able to correctly find them. In general, all the use cases in the user’s requirements become the functional test cases.
As an example, suppose we are to develop the software for an elevator. For designing the test cases for this software, all the scenarios and operations that can take place in the elevator need to be analyzed. To begin from the basic operations, the elevator should be bidirectional and it should stop at each floor (unless we have two elevators in the requirement for even and odd floors separately).The elevator should stop at the desired floor.

File:Topdown testing.jpg

2009-09-21T04:23:25Z

Alakshm3: TOP DOWN TESTING

TOP DOWN TESTING

CSC/ECE 517 Fall 2009/wiki1b 4 xy

2009-09-21T04:15:11Z

Alakshm3:

==''' Functional and integration testing and beyond''' ==
Recognition of software test engineering as a specialty area has increased during the last twenty years. Testing is one of the key focus areas in software engineering. It is an essential activity that observes the functionality of a software system validates its intended behavior and identifies the potential malfunctions. Testing is also the primary way to improve software reliability.

The test cases should be carefully designed to cover many aspects in the SDLC such as possible aberrations from user’s requirements, system behavior upon malicious inputs, and robustness to extensive load conditions and so on. As more and more software is used in critical applications, the time and cost involved in testing is also increasing owing to the higher quality required. Although test automation saves a lot of time and can be used for regression load tests, manual testing is still widely used in the industry.

== '''Terms''' ==
# Driver: Supporting code or data used for testing the whole or part of the software system
# Sub-system: Component or Module of a software system
# System Under Test: The software system which has to be tested
# Stub: Dummy procedure or module that can be used to simulate or substitute an actual portion of a system
# Test: Sequence of steps to validate the system design and implementation
# Usecase :Scenario that describing an interaction between a user and a system

== '''Integration testing''' ==
Integration is a systematic approach to build the complete software structure specified in the design from unit-tested
modules.Integration testing is the next phase of unit testing. Generally in software development complete software is divided into various sub-systems mostly developed by different teams. More often than not each sub-system works very well individually but when they are integrated then lot of problems. So the main focus of integration tests is not the functionality of individual modules but the interaction between these modules like interaction with operating system, interaction between client and server

There are many approaches that can be followed for Integration Testing

* '''Big Bang Testing Approach''' As the name suggests all the components are integrated at once. After all the integration is completed a set of tests are run which not only validate a single component of sub-system but also test and validate the interaction between different components. This approach is more useful in smaller systems because integration of smaller systems are easier.
** Advantages:
*** Since all the modules are combined and all are tested at the same time, this approach of integration is less time consuming
** Disadvantages:
*** Debugging and solving a fault is not that trivial. Because in this type of testing many modules are integrated one cannot be sure whether the bug found was present in any sub-system or interaction between different sub-systems.
*** Testing process cannot be started until all the sub-systems have finished their development.
*** Writing test cases are also non-trivial.
[[Image:Bigbang.jpg]]
 
 
* '''Incremental Testing Approach''' Testing is done after integration of one module at a time. After finishing the unit testing of each module or sub-system they are integrated and tested. Stubs are used for modules in the system which are not integrated till now.
** Advantages:
*** Problems detection is early compared to the Big Bang approach
*** No need to wait till the unit testing of all the modules have finished
*** Debugging is much simpler
** Disadvantages:
*** This approach is a time taking process because the integration tests have to run multiple times
*** Stubs have to be developed to substitute the missing modules

Various Approach can be taken for Incremental Testing
* '''Top-Down Approach''': In this approach the system is tested according to the work flow or code flow. The Top level module is tested first then each lower level module is integrated and tested.
[[Image:Incremental testing.jpg]]
 
 
In the above figure Module A is the top most module in the system then B,C,D are lower level modules. Generally module A is the user interface and stubs for each interface are used. Then each module is integrated and the tested.
** Advantages:
*** The testing flow follows the architecture of the system
** Disadvantage :
*** The main problem with this approach is the use of stub. Mostly stubs are written to print out some trace statement based on the output of module A after running the test. Now if multiple scenarios have to be tested then different version of Stub B have to written, which is an extra overhead
***

== '''Functional testing''' ==
Functional testing is designed to ensure the system requirements and specifications are achieved. It can start with testing of the requirements and whether the application compiles with the organizational policies and procedures.
Regression testing is another form of functional testing where you test the earlier features and functionality of the module which were working on the desired lines but have to be tested currently after some changes have been in the system. The changes might not be in the particular module but it can be affected due to inter dependencies. During the design phase, after knowing the functionality of the module/modules and the system, some errors can be predicted in advance. A functional test should incorporate such type of scenarios too. In this case the erroneous transactions/ applications are deliberately introduced and the system should be able to correctly find them. In general, all the use cases in the user’s requirements become the functional test cases.
As an example, suppose we are to develop the software for an elevator. For designing the test cases for this software, all the scenarios and operations that can take place in the elevator need to be analyzed. To begin from the basic operations, the elevator should be bidirectional and it should stop at each floor (unless we have two elevators in the requirement for even and odd floors separately).The elevator should stop at the desired floor.

CSC/ECE 517 Fall 2009/wiki1b 4 xy

2009-09-21T03:11:32Z

Alakshm3:

CSC/ECE 517 Fall 2009/wiki1b 4 xy

2009-09-21T03:10:00Z

Alakshm3:

CSC/ECE 517 Fall 2009/wiki1b 4 xy

2009-09-21T03:09:08Z

Alakshm3:

File:Incremental testing.jpg

2009-09-21T03:08:07Z

Alakshm3: Incremental Testing

Incremental Testing

CSC/ECE 517 Fall 2009/wiki1b 4 xy

2009-09-21T02:48:31Z

Alakshm3:

CSC/ECE 517 Fall 2009/wiki1b 4 xy

2009-09-21T02:47:15Z

Alakshm3:

CSC/ECE 517 Fall 2009/wiki1b 4 xy

2009-09-21T02:46:30Z

Alakshm3:

CSC/ECE 517 Fall 2009/wiki1b 4 xy

2009-09-21T02:45:19Z

Alakshm3:

CSC/ECE 517 Fall 2009/wiki1b 4 xy

2009-09-21T02:43:46Z

Alakshm3:

CSC/ECE 517 Fall 2009/wiki1b 4 xy

2009-09-21T02:41:41Z

Alakshm3:

CSC/ECE 517 Fall 2009/wiki1b 4 xy

2009-09-21T02:38:41Z

Alakshm3:

File:Bigbang.jpg

2009-09-21T02:38:00Z

Alakshm3: Big Bang Testing

Big Bang Testing

CSC/ECE 517 Fall 2009/wiki1b 4 xy

2009-09-21T02:24:38Z

Alakshm3:

CSC/ECE 517 Fall 2009/wiki1b 4 xy

2009-09-21T01:33:58Z

Alakshm3: /* ''' Functional and integration testing and beyond''' */

CSC/ECE 517 Fall 2009/wiki1b 4 xy

2009-09-21T00:57:19Z

Alakshm3:

=''' Functional and integration testing and beyond''' =
Recognition of software test engineering as a specialty area has increased during the last twenty years. Testing is one of the key focus areas in software engineering. It is an essential activity that observes the functionality of a software system validates its intended behavior and identifies the potential malfunctions. Testing is also the primary way to improve software reliability.

The test cases should be carefully designed to cover many aspects in the SDLC such as possible aberrations from user’s requirements, system behavior upon malicious inputs, and robustness to extensive load conditions and so on. As more and more software is used in critical applications, the time and cost involved in testing is also increasing owing to the higher quality required. Although test automation saves a lot of time and can be used for regression load tests, manual testing is still widely used in the industry.

== '''Terms''' ==
# Driver: Supporting code or data used for testing the whole or part of the software system
# Sub-system: Component or Module of a software system
# System Under Test: The software system which has to be tested
# Stub: Dummy procedure or module that can be used to simulate or substitute an actual portion of a system
# Test: Sequence of steps to validate the system design and implementation
# Usecase :Scenario that describing an interaction between a user and a system

== '''Integration testing''' ==
Integration is a systematic approach to build the complete software structure specified in the design from unit-tested
modules.Integration testing is the next phase of unit testing. Generally in software development complete software is divided into various sub-systems mostly developed by different teams. More often than not each sub-system works very well individually but when they are integrated then lot of problems. So the main focus of integration tests is not the functionality of individual modules but the interaction between these modules like interaction with operating system, interaction between client and server

There are many approaches that can be followed for Integration Testing

* Big-Bang: As the name suggests all the components are integrated at once. After all the integration is completed a set of tests are run which not only validate a single component of sub-system but also test and validate the interaction between different components.
** Advantages:
*** Since all the modules are combined and all are tested at the same time, this approach of integration is less time consuming
** Disadvantages:
**# Debugging and solving a fault is not that trivial. Because in this type of testing many modules are integrated one cannot be sure whether the bug found was present in any sub-system or interaction between different sub-systems.
**# Testing process cannot be started until all the sub-systems have finished their development.
**# Writing test cases are also non-trivial.

* Incremental Testing: As the name suggests testing is done after integration of one sub-system at a time. This solves the disadvantages of the Big-Bang.
** Disadvantages:
**# This approach is a time taking process. For a large system

== '''Functional testing''' ==
Functional testing is designed to ensure the system requirements and specifications are achieved. It can start with testing of the requirements and whether the application compiles with the organizational policies and procedures.

Regression testing is another form of functional testing where you test the earlier features and functionality of the module which were working on the desired lines but have to be tested currently after some changes have been in the system. The changes might not be in the particular module but it can be affected due to inter dependencies. During the design phase, after knowing the functionality of the module/modules and the system, some errors can be predicted in advance. A functional test should incorporate such type of scenarios too. In this case the erroneous transactions/ applications are deliberately introduced and the system should be able to correctly find them. In general, all the use cases in the user’s requirements become the functional test cases.
As an example, suppose we are to develop the software for an elevator. For designing the test cases for this software, all the scenarios and operations that can take place in the elevator need to be analyzed. To begin from the basic operations, the elevator should be bidirectional and it should stop at each floor (unless we have two elevators in the requirement for even and odd floors separately).The elevator should stop at the desired floor.

CSC/ECE 517 Fall 2009/wiki1b 4 xy

2009-09-21T00:55:05Z

Alakshm3: /* ''' Functional and integration testing and beyond''' */

=''' Functional and integration testing and beyond''' =
Recognition of software test engineering as a specialty area has increased during the last twenty years. Testing is one of the key focus areas in software engineering. It is an essential activity that observes the functionality of a software system validates its intended behavior and identifies the potential malfunctions. Testing is also the primary way to improve software reliability.

The test cases should be carefully designed to cover many aspects in the SDLC such as possible aberrations from user’s requirements, system behavior upon malicious inputs, and robustness to extensive load conditions and so on. As more and more software is used in critical applications, the time and cost involved in testing is also increasing owing to the higher quality required. Although test automation saves a lot of time and can be used for regression load tests, manual testing is still widely used in the industry.

== '''Terms''' ==
# Driver: Supporting code or data used for testing the whole or part of the software system
# Sub-system: Component or Module of a software system
# System Under Test: The software system which has to be tested
# Stub: Dummy procedure or module that can be used to simulate or substitute an actual portion of a system
# Test: Sequence of steps to validate the system design and implementation
# Usecase :Scenario that describing an interaction between a user and a system

== '''Integration testing''' ==
Integration is a systematic approach to build the complete software structure specified in the design from unit-tested
modules.Integration testing is the next phase of unit testing. Generally in software development complete software is divided into various sub-systems mostly developed by different teams. More often than not each sub-system works very well individually but when they are integrated then lot of problems. So the main focus of integration tests is not the functionality of individual modules but the interaction between these modules like interaction with operating system, interaction between client and server

There are many approaches that can be followed for Integration Testing

* Big-Bang: As the name suggests all the components are integrated at once. After all the integration is completed a set of tests are run which not only validate a single component of sub-system but also test and validate the interaction between different components.
** Advantages:

*** Since all the modules are combined and all are tested at the same time, this approach of integration is less time consuming
 
** Disadvantages:
 
**# Debugging and solving a fault is not that trivial. Because in this type of testing many modules are integrated one cannot be sure whether the bug found was present in any sub-system or interaction between different sub-systems.
 
**# Testing process cannot be started until all the sub-systems have finished their development.
 
**# Writing test cases are also non-trivial.

* Incremental Testing: As the name suggests testing is done after integration of one sub-system at a time. This solves the disadvantages of the Big-Bang.
** Disadvantages:
**# This approach is a time taking process. For a large system

== '''Functional testing''' ==
Functional testing is designed to ensure the system requirements and specifications are achieved. It can start with testing of the requirements and whether the application compiles with the organizational policies and procedures.

Regression testing is another form of functional testing where you test the earlier features and functionality of the module which were working on the desired lines but have to be tested currently after some changes have been in the system. The changes might not be in the particular module but it can be affected due to inter dependencies. During the design phase, after knowing the functionality of the module/modules and the system, some errors can be predicted in advance. A functional test should incorporate such type of scenarios too. In this case the erroneous transactions/ applications are deliberately introduced and the system should be able to correctly find them. In general, all the use cases in the user’s requirements become the functional test cases.
As an example, suppose we are to develop the software for an elevator. For designing the test cases for this software, all the scenarios and operations that can take place in the elevator need to be analyzed. To begin from the basic operations, the elevator should be bidirectional and it should stop at each floor (unless we have two elevators in the requirement for even and odd floors separately).The elevator should stop at the desired floor.

CSC/ECE 517 Fall 2009/wiki1b 4 xy

2009-09-21T00:14:50Z

Alakshm3: /* '''Functional testing''' */

=''' Functional and integration testing and beyond''' =
Recognition of software test engineering as a specialty area has increased during the last twenty years. Testing is one of the key focus areas in software engineering. It is an essential activity that observes the functionality of a software system validates its intended behavior and identifies the potential malfunctions. Testing is also the primary way to improve software reliability.

The test cases should be carefully designed to cover many aspects in the SDLC such as possible aberrations from user’s requirements, system behavior upon malicious inputs, and robustness to extensive load conditions and so on. As more and more software is used in critical applications, the time and cost involved in testing is also increasing owing to the higher quality required. Although test automation saves a lot of time and can be used for regression load tests, manual testing is still widely used in the industry.

== '''Terms''' ==
# Sub-system: Component or Module of a software system
# System Under Test: The software system which has to be tested

== '''Integration testing''' ==

Integration testing is the next phase of unit testing. Generally in software development complete software is divided into various sub-systems mostly developed by different teams. More often than not each sub-system works very well individually but when they are integrated then lot of problems.

There are many approaches that can be followed for Integration Testing

* Big-Bang: As the name suggests all the components are integrated at once. After all the integration is completed a set of tests are run which not only validate a single component of sub-system but also test and validate the interaction between different components.
** Disadvantages:
**# Debugging and solving a fault is not that trivial. Because since this type of testing is done for the first time one cannot be sure whether the bug found was present in any sub-system or interaction between different sub-systems.
**# Testing process cannot be started until all the sub-systems have finished their development.
**# Writing test cases are also non-trivial.

* Incremental Testing: As the name suggests testing is done after integration of one sub-system at a time. This solves the disadvantages of the Big-Bang.
** Disadvantages:
**# This approach is a time taking process. For a large system

== '''Functional testing''' ==
Functional testing is designed to ensure the system requirements and specifications are achieved. It can start with testing of the requirements and whether the application compiles with the organizational policies and procedures.

Regression testing is another form of functional testing where you test the earlier features and functionality of the module which were working on the desired lines but have to be tested currently after some changes have been in the system. The changes might not be in the particular module but it can be affected due to inter dependencies. During the design phase, after knowing the functionality of the module/modules and the system, some errors can be predicted in advance. A functional test should incorporate such type of scenarios too. In this case the erroneous transactions/ applications are deliberately introduced and the system should be able to correctly find them. In general, all the use cases in the user’s requirements become the functional test cases.
As an example, suppose we are to develop the software for an elevator. For designing the test cases for this software, all the scenarios and operations that can take place in the elevator need to be analyzed. To begin from the basic operations, the elevator should be bidirectional and it should stop at each floor (unless we have two elevators in the requirement for even and odd floors separately).The elevator should stop at the desired floor.

CSC/ECE 517 Fall 2009/wiki1b 4 xy

2009-09-20T22:56:13Z

Alakshm3:

=''' Functional and integration testing and beyond''' =
Recognition of software test engineering as a specialty area has increased during the last twenty years. Testing is one of the key focus areas in software engineering. It is an essential activity that observes the functionality of a software system validates its intended behavior and identifies the potential malfunctions. Testing is also the primary way to improve software reliability.

The test cases should be carefully designed to cover many aspects in the SDLC such as possible aberrations from user’s requirements, system behavior upon malicious inputs, and robustness to extensive load conditions and so on. As more and more software is used in critical applications, the time and cost involved in testing is also increasing owing to the higher quality required. Although test automation saves a lot of time and can be used for regression load tests, manual testing is still widely used in the industry.

== '''Terms''' ==
# Sub-system: Component or Module of a software system
# System Under Test: The software system which has to be tested

== '''Integration testing''' ==

Integration testing is the next phase of unit testing. Generally in software development complete software is divided into various sub-systems mostly developed by different teams. More often than not each sub-system works very well individually but when they are integrated then lot of problems.

There are many approaches that can be followed for Integration Testing

* Big-Bang: As the name suggests all the components are integrated at once. After all the integration is completed a set of tests are run which not only validate a single component of sub-system but also test and validate the interaction between different components.
** Disadvantages:
**# Debugging and solving a fault is not that trivial. Because since this type of testing is done for the first time one cannot be sure whether the bug found was present in any sub-system or interaction between different sub-systems.
**# Testing process cannot be started until all the sub-systems have finished their development.
**# Writing test cases are also non-trivial.

* Incremental Testing: As the name suggests testing is done after integration of one sub-system at a time. This solves the disadvantages of the Big-Bang.
** Disadvantages:
**# This approach is a time taking process. For a large system

== '''Functional testing''' ==
Functional testing is designed o ensure the system requirements and specifications are achieved. It can start with testing of the requirements and whether the application compiles with the organizational policies and procedures. Regression testing is another form of functional testing where you test the earlier features and functionalities of the module which were working on the desired lines but have to be tested currently after some changes have been in the system. The changes might not be in the particular module but it can be affected due to inter dependencies. During the design phase, after knowing the functionality of the module/modules and the system, some errors can be predicted in advance. A functional test should incorporate such type of scenarios too. In this case the erroneous transactions/ applications are deliberately introduced and the system should be able to correctly find them. In general, all the use cases in the user’s requirements become the functional test cases.
As an example, suppose we are to develop the software for an elevator. For designing the test cases for this software, all the scenarios and operations that can take place in the elevator need to be analyzed. To begin from the basic operations, the elevator should be bidirectional and it should stop at each floor (unless we have two elevators in the requirement for even and odd floors separately).The elevator should stop at the desired floor.

CSC/ECE 517 Fall 2009/wiki1b 4 xy

2009-09-20T22:53:57Z

Alakshm3:

CSC/ECE 517 Fall 2009/wiki1b 4 xy

2009-09-20T22:47:28Z

Alakshm3:

CSC/ECE 517 Fall 2009/wiki1b 4 xy

2009-09-20T22:46:09Z

Alakshm3:

=''' Functional and integration testing and beyond''' =

== '''Integration testing''' ==

Integration testing is the next phase of unit testing. Generally in software development complete software is divided into various sub-systems mostly developed by different teams. More often than not each sub-system works very well individually but when they are integrated then lot of problems.

There are many approaches that can be followed for Integration Testing

* Big-Bang: As the name suggests all the components are integrated at once. After all the integration is completed a set of tests are run which not only validate a single component of sub-system but also test and validate the interaction between different components.
** Disadvantages:
**# Debugging and solving a fault is not that trivial. Because since this type of testing is done for the first time one cannot be sure whether the bug found was present in any sub-system or interaction between different sub-systems.
**# Testing process cannot be started until all the sub-systems have finished their development.
**# Writing test cases are also non-trivial.

* Incremental Testing: As the name suggests testing is done after integration of one sub-system at a time. This solves the disadvantages of the Big-Bang.
** Disadvantages:
**# This approach is a time taking process. For a large system

CSC/ECE 517 Fall 2009/wiki1b 4 xy

2009-09-20T22:38:02Z

Alakshm3:

'''Integration testing:''' Integration testing is the next phase of unit testing. Generally in software development complete software is divided into various sub-systems mostly developed by different teams. More often than not each sub-system works very well individually but when they are integrated then lot of problems.

There are many approaches that can be followed for Integration Testing

* Big-Bang: As the name suggests all the components are integrated at once. After all the integration is completed a set of tests are run which not only validate a single component of sub-system but also test and validate the interaction between different components.
** Disadvantages:
Debugging and solving a fault is not that trivial. Because since this type of testing is done for the first time one cannot be sure whether the bug found was present in any sub-system or interaction between different sub-systems.
Testing process cannot be started until all the sub-systems have finished their development.
Writing test cases are also non-trivial.

* Incremental Testing: As the name suggests testing is done after integration of one sub-system at a time. This solves the disadvantages of the Big-Bang.
** Disadvantages:
This approach is a time taking process. For a large system