Professional Documents
Culture Documents
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.
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.[ñ ~
]
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.
^
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);
}
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.
Note: Each test must be given a name, so you can identify it if it fails.
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.
^
"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:
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:
¦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 ñ
ñ
.
Within the
method we initializes the three properties with some values. Property book1
and book3 are the same.
^
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.
å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.