You are on page 1of 13

c c c    

 
cccccccccccc

"  

"  

    

 

  

  

   
 
 
  

 
  
 
   

   


So Software Testing can be stated as the process of validating and verifying that a software
program/application/product:

1. Meets the business and technical requirements that guided its design and development.
2. Meets 


3. Meets   
.

Software Testing, depending on the testing method employed can be implemented at any time in the
development process. However, most of the test effort occurs after the requirements have been defined
and the coding process has been completed. As such, the methodology of the test is governed by the
Software Development methodology adopted.


Testing methods
    
Software testing methods are traditionally divided into black box testing and white box testing. These two
approaches are used to describe the point of view that a test engineer takes when designing test cases.
Black box testing
Bl  
takes an external perspective of the test object to derive test cases. These tests can
be functional or non-functional, though usually functional. The test designer selects valid and invalid
inputs and determines the correct output. There is no knowledge of the test object's internal structure.

This method of test design is applicable to all levels of software testing: unit, integration, functional
testing, system and acceptance. The higher the level, and hence the bigger and more complex the box,
the more one is forced to use black box testing to simplify. While this method can uncover unimplemented
parts of the specification, one cannot be sure that all existent paths are tested.

White box testing


^
  
(a.k.a. clear box testing, glass box testing, transparent box testing, or structural
testing) uses an internal perspective of the system to design test cases based on internal structure. It
requires programming skills to identify all paths through the software. The tester chooses test case inputs
to exercise paths through the code and determines the appropriate outputs. In electrical hardware testing,
every node in a circuit may be probed and measured; an example is in-circuit testing (ICT).

Since the tests are based on the actual implementation, if the implementation changes, the tests probably
will need to change, too. For example ICT needs updates if component values change, and needs
modified/new fixture if the circuit changes. This adds financial resistance to the change process, thus
buggy products may stay buggy. Automated optical inspection (AOI) offers similar component level
correctness checking without the cost of ICT fixtures, however changes still require test updates.
While white box testing is applicable at the unit, integration and system levels of the software
testing process, it is typically applied to the unit. While it normally tests paths within a unit, it can also test
paths between units during integration, and between subsystems during a system level test. Though this
method of test design can uncover an overwhelming number of test cases, it might not detect
unimplemented parts of the specification or missing requirements, but one can be sure that all paths
through the test object are executed. 
 ey Box Testing
  
involves having access to internal data structures and algorithms for purposes of
designing the test cases, but testing at the user, or black-box level. Manipulating input data and
formatting output do not qualify as grey box, because the input and output are clearly outside of the
"black-box" that we are calling the system under test. This distinction is particularly important when
conducting testing between two modules of code written by two different developers, where only the
interfaces are exposed for test. However, modifying a data repository does qualify as grey box, as the
user would not normally be able to change the data outside of the system under test. Grey box testing
may also include reverse engineering to determine, for instance, boundary values or error messages.


Testing Levels
nit Testing
In computer programming, m
 
is a software verification and validation method in which a
programmer tests if individual units of source code are fit for use. A unit is the smallest testable part of an
application. In procedural programming a unit may be an individual function or procedure. Unit testing is a
fundamental part of quality modern software development.


 
refers to tests that verify the functionality of a specific section of code, usually at the function
level. In an object-oriented environment, this is usually at the class level, and the minimal unit tests
include the constructors and destructors.
These types of tests are usually written by developers as they work on code (white-box style), to ensure
that the specific function is working as expected. One function might have multiple tests, to catch corner
cases or other branches in the code. Unit testing alone cannot verify the functionality of a piece of
software, but rather is used to assure that the building blocks the software uses work independently of
each other.


£  
 

£  
 
(sometimes called Integration and Testing, abbreviated "I&T" is the phase in software
testing in which individual software modules are combined and tested as a group. It occurs after unit
testing and before system testing. Integration testing takes as its input modules that have been unit
tested, groups them in larger aggregates, applies tests defined in an integration test plan to those
aggregates, and delivers as its output the integrated system ready for system testing.

Integration testing works to expose defects in the interfaces and interaction between integrated
components (modules). Progressively larger groups of tested software components corresponding to
elements of the architectural design are integrated and tested until the software works as a system.

"  

"  
of software or hardware is testing conducted on a complete, integrated system to
evaluate the system's compliance with its specified requirements. System testing falls within the scope
of black box testing, and as such, should require no knowledge of the inner design of the code or logic. [1]

As a rule, system testing takes, as its input, all of the "integrated" software components that have
successfully passed integration testing and also the software system itself integrated with any applicable
hardware system(s). The purpose of integration testing is to detect any inconsistencies between the
software units that are integrated together (called ~ ~ ) or between any of the ~ ~ and
the hardware. System testing is a more limiting type of testing; it seeks to detect defects both within the
"inter-assemblages" and also within the system as a whole.


" £  
 

" £  
 
("£), in the context of software systems and software engineering, is a
testing process that exercises a software system's coexistence with others. System integration testing
takes multiple integrated systems that have passed system testing as input and tests their required
interactions. Following this process, the deliverable systems are passed on to acceptance testing.
Systems integration testing (SIT) is a testing phase that may occur after unit testing and prior to user
acceptance testing (UAT). Many organizations do not have a SIT phase and the first test of UAT may
include the first integrated test of all software components.


å 
 

å 
 
is any type of software testing that seeks to uncover software errors by partially
retesting a modified program. The intent of regression testing is to assure that a bug fix has been
successfully corrected based on the error that was found, while providing a general assurance that no
other errors were introduced in the process of fixing the original problem. Regression is commonly used
to efficiently test bug fixes by systematically selecting the appropriate minimum test suite needed to
adequately cover the affected software code/requirements change. Ñ    of regression
testing include rerunning previously run tests and checking whether previously fixed faults have re-
emerged.

"One of the main reasons for regression testing is that it's often extremely difficult for a programmer to
figure out how a change in one part of the software will echo in other parts of the software.


¦  

In engineering and its various subdisciplines,   
is black-box testing performed on
a system (e.g. software, lots of manufactured mechanical parts, or batches of chemical products) prior to
its delivery.[1] It is also known as functional testing, black-box testing, release acceptance, QA testing,
application testing, confidence testing, final testing, validation testing, or factory acceptance testing.[ñ ~ 

]

In software development,   


by the system provider is often distinguished from
acceptance testing by the customer (the user or client) prior to accepting transfer of ownership. In such
environments, acceptance testing performed by the customer is known as user acceptance testing (UAT).
This is also known as end-user testing, site (acceptance) testing, or field (acceptance) testing.

Acceptance testing can mean one of two things:

1. A smoke test is used as an acceptance test prior to introducing a new build to the main testing
process, i.e. before integration or regression.
2. Acceptance testing performed by the customer, often in their lab environment on their own HW, is
known as user acceptance testing (UAT). Acceptance testing may be performed as part of the
hand-off process between any two phases of development.


¦l  

¦~   is simulated or actual operational testing by potential users/customers or an independent
test team at the developers' site. Alpha testing is often employed for off-the-shelf software as a form of
internal acceptance testing, before the software goes to beta testing.

B 

~   comes after alpha testing. Versions of the software, known as beta versions, are released to
a limited audience outside of the programming team. The software is released to groups of people so that
further testing can ensure the product has few faults or bugs. Sometimes, beta versions are made
available to the open public to increase the feedback field to a maximal number of future users.
c

^ 



„Unit is a simple open source „ava testing framework used to write and run repeatable
automated tests. It is an instance of the xUnit architecture for unit testing framework. Eclipse
supports creating test cases and running test suites, so it is easy to use for your „ava
applications.

„Unit features include:

½ Assertions for testing expected results


½ Test fixtures for sharing common test data
½ Test suites for easily organizing and running tests
½ Graphical and textual test runners

^ 
  
A test case is a class which holds a number of test methods. For example if you want to test
some methods of a class  you create a class   which extends the „Unit  Ñ~ 
class and place your test methods in there.

  m
 m 
l 

1. Create a subclass of TestCase:
public class BookTest extends TestCase{
//..
}

2. Write a test method to assert expected results on the object under test:
Note: The naming convention for a test method is testXXX()
public void testCollection() {
Collection collection = new ArrayList();
assertTrue(collection.isEmpty());
}

3. Write a 
method that uses reflection to dynamically create a test suite containing all the
 
methods:
public static Test suite(){
return new TestSuite(BookTest.class);
}

4. Activate the „Unit view in Eclipse (    


   ~~  ).

You find the  tab near the ~ñ~  tab. You can change the position of the tab by
drag and drop it.
5. Right click on the subclass of  Ñ~ and choose     to run the test.


 
m

A test fixture is useful if you have two or more tests for a common set of objects. Using a test
Fixture avoids duplicating the test code necessary to initialize and cleanup those common
objects for each test.

To create a test fixture, define a  


method that initializes common object and a
~  
method to cleanup those objects. The „Unit framework automatically invokes the
 
method before a each test is run and the ~  
method after each test is run.

The following test uses a test fixture:

public class BookTest2 extends TestCase {


private Collection collection;

protected void setUp() {


collection = new ArrayList();
}

protected void tearDown() {


collection.clear();
}

public void testEmptyCollection(){


assertTrue(collection.isEmpty());
}
}

½ 
  
 m

l  
„Unit supports two ways (static and dynamic) of running single tests.
In static way you override the  
method inherited form TestCase class and call the
desired test case. A convenient way to do this is with an anonymous inner class.

Note: Each test must be given a name, so you can identify it if it fails.

TestCase test = new BookTest("equals test") {


public void runTest() {
testEquals();
}
};

The dynamic way to create a test case to be run uses reflection to implement  . It
assumes the name of the test is the name of the test case method to invoke. It dynamically finds
and invokes the test method. The dynamic way is more compact to write but it is less static type
safe. An error in the name of the test case goes unnoticed until you run it and get a
 ñ ñ . We leave the choice of which to use up to you.

TestCast test = new BookTest("testEquals");

^ 
 "m


If you have two tests and you'll run them together you could run the tests one at a time yourself,
but you would quickly grow tired of that. Instead, „Unit provides an object   which runs
any number of test cases together. The suite method is like a main method that is specialized to
run tests.

Create a suite and add each test case you want to execute:

public static void suite(){


TestSuite suite = new TestSuite();
suite.addTest(new BookTest("testEquals"));
suite.addTest(new BookTest("testBookAdd"));
return suite;
}

Since „Unit 2.0 there is an even simpler way to create a test suite, which holds all testXXX()
methods. You only pass the class with the tests to a TestSuite and it extracts the test methods
automatically.
Note: If you use this way to create a TestSuite all test methods will be added. If you do not want
all test methods in the TestSuite use the normal way to create it.
Example:

public static void suite(){


return new TestSuite(BookTest.class);
}

¦l
ll
Create a new „ava project named „UnitExample.
Add a package ~  ~  ~  ~where you place the example classes and a
package  ~  ~  ~  ~where you place your test classes.

 l B 
Create a new class  in the package ~  ~  ~  ~.
Add two properties  of type  and  ñof type  .
Add a constructor to set the two properties.
Provide a getter- and setter-method for each of them.
Add a method trunk for a method  ~
ñ ñ which checks if the object is an instance
of
the class Book and the values of the object are equal. The method return a boolean value.
Note: Do not write the logic of the  ~
 method, we do it after finish creating the test
method.
The following source code shows the class Book.
public class Book {
private String title;
private double price;
/**
* Constructor
*
* @param title
* @param price
*/
public Book(String title,
double price) {
this.title = title;
this.price = price;
}
/**
* Check if an object is an instance of book
* and the values of title and price are equal
* then return true, otherwise return false
*/
public boolean equals(Object object) {
return false;
}
public double getPrice() {
return price;
}
public void setPrice(double price) {
this.price = price;
}
public String getTitle() {
return title;
}
public void setTitle(String title) {
this.title = title;
}
}
   B  
Create a new test case   in the package  ~  ~  ~  ~Right click on
the package and choose    Ñ~ .
In the wizard choose the methods stubs  
, ~  
and ñ   ñ
.

The following source code shows the class BookTest

public class BookTest extends TestCase {


/**
* setUp() method that initializes common objects
*/
protected void setUp() throws Exception {
super.setUp();
}
/**
* tearDown() method that cleanup the common objects
*/
protected void tearDown() throws Exception {
super.tearDown();
}
/**
* Constructor for BookTest.
* @param name
*/
public BookTest(String name) {
super(name);
}
}

Now we want to write a test for the  ~


 method of the class  . We provide three
private properties, book1, book2 and book3 of type  

private Book book1;
private Book book2;
private Book book3;

Within the  
method we initializes the three properties with some values. Property book1
and book3 are the same.

protected void setUp() throws Exception {


super.setUp();
book1 = new Book("ES", 12.99);
book2 = new Book("The Gate", 11.99);
book3 = new Book("ES", 12.99);
}

Within the tearDown() method we cleanup the properties:

protected void tearDown() throws Exception {


super.tearDown();
book1 = null;
book2 = null;
book3 = null;
}

Now, add a test method   ~


to the test case. Within the method we use the
~  ~ 
method of the „Unit framework to test if the return-value of the equals(..) method
is false, because book1 and book2 are not the same. If the return-value is false the logic of the
equals() method is correct, otherwise there is a logical problem while comparing the objects. We
want to test if the method compares the objects correctly by using the assertTrue() method.
Book1 and Book3 are the same, because both are an instance of the class Book and have the
same values.

The following source code shows the testEquals() method:

public void testEquals(){


assertFalse(book2.equals(book1));
assertTrue(book1.equals(book1));
}

^

 l
  ml  

We have finished the test and now we can add the logic to the  ~
method stub. Open the
class Book and add the logic to the  ~
method. First we check if the object given by the
method is an instance of  . Then compare the properties  and  ñ, if they are equal
return true.
public boolean equals(Object object) {
if (object instanceof Book) {
Book book = (Book) object;
return getTitle().equals(book.getTitle())
&& getPrice() == book.getPrice();
}
return false;
}

Ñ  m
 

In order to run the test method   ~
add a method 
to the class   .
Note: You can also create a separate class where you add the 
method.
Within the method create a new instance of   and use the method ~ 
 to add a
test. Here we use the dynamically way to add a test to a TestSuite.

The method looks like the follows:

public static Test suite(){


TestSuite suite = new TestSuite();
suite.addTest(new BookTest("testEquals"));
return suite;
}

åm   
After finishing all test methods we want to run the „Unit test case. Right mouse button on the
class BookTest and choose  ¦    .
On the „Unit view (Menu Windows -> show view) of Eclipse you can see how many runs, errors
and failures occurred.


You might also like