Test Cases JAva
Test Cases JAva
Test Cases JAva
TESTING
7.1 TESTING
Testing is the debugging program is one of the most critical aspects of the computer
programming triggers, without programming that works, the system would never produce an
output of which it was designed. Testing is best performed when user development is asked to
assist in identifying all errors and bugs. The sample data are used for testing. It is not quantity but
quality of the data used the matters of testing. Testing is aimed at ensuring that the system was
accurately an efficiently before live operation commands.
Testing objectives:
The main objective of testing is to uncover a host of errors, systematically and with
minimum effort and time. Stating formally, we can say, testing is a process of executing a program
with intent of finding an error.
2 A good test case is one that has probability of finding an error, if it exists.
4 The software more or less confirms to the quality and reliable standards.
Levels of Testing:
In order to uncover present in different phases we have the concept of levels of testing.
This examines the logic of the program. For example, the logic for updating various sample
data and with the sample files and directories were tested and verified.
Executing this specification starting what the program should do and how it should
performed under various conditions. Test cases for various situation and combination of conditions
in all the modules are tested.
In the unit testing we test each module individually and integrate with the overall system.
Unit testing focuses verification efforts on the smallest unit of software design in the module. This
is also known as module testing. The module of the system is tested separately. This testing is
carried out during programming stage itself. In the testing step each module is found to work
satisfactorily as regard to expected output from the module. There are some validation checks for
fields also. For example the validation check is done for varying the user input given by the user
which validity of the data entered. It is very easy to find error debut the system.
Each Module can be tested using the following two Strategies:
Black box testing is a software testing techniques in which functionality of the software
under test (SUT) is tested without looking at the internal code structure, implementation
details and knowledge of internal paths of the software. This type of testing is based entirely on
the software requirements and specifications.
In Black Box Testing we just focus on inputs and output of the software system without
bothering about internal knowledge of the software program.
The above Black Box can be any software system you want to test. For example : an
operating system like Windows, a website like Google ,a database like Oracle or even your own
custom application. Under Black Box Testing , you can test these applications by just focusing on
the inputs and outputs without knowing their internal code implementation.
Software tester compares the actual outputs with the expected outputs.
Functional testing – This black box testing type is related to functional requirements of a system;
it is done by software testers.
Non-functional testing – This type of black box testing is not related to testing of a specific
functionality, but non-functional requirements such as performance, scalability, usability.
Regression testing – Regression testing is done after code fixes , upgrades or any other system
maintenance to check the new code has not affected the existing code.
It is one of two parts of the "box testing" approach of software testing. Its counter-part,
blackbox testing, involves testing from an external or end-user type perspective. On the other hand,
Whitebox testing is based on the inner workings of an application and revolves around internal
testing. The term "whitebox" was used because of the see-through box concept. The clear box or
whitebox name symbolizes the ability to see through the software's outer shell (or "box") into its
inner workings. Likewise, the "black box" in "black box testing" symbolizes not being able to see
the inner workings of the software so that only the end-user experience can be tested
Expected output
The testing can be done at system, integration and unit levels of software development. One of the
basic goals of whitebox testing is to verify a working flow for an application. It involves testing a
series of predefined inputs against expected or desired outputs so that when a specific input does
not result in the expected output, you have encountered a bug.
The first thing a tester will often do is learn and understand the source code of the
application. Since white box testing involves the testing of the inner workings of an application,
the tester must be very knowledgeable in the programming languages used in the applications they
are testing. Also, the testing person must be highly aware of secure coding practices. Security is
often one of the primary objectives of testing software. The tester should be able to find security
issues and prevent attacks from hackers and naive users who might inject malicious code into the
application either knowingly or unknowingly.
The second basic step to white box testing involves testing the application’s source code
for proper flow and structure. One way is by writing more code to test the application’s source
code. The tester will develop little tests for each process or series of processes in the application.
This method requires that the tester must have intimate knowledge of the code and is often done
by the developer. Other methods include manual testing, trial and error testing and the use of
testing tools as we will explain further on in this article.
1 Alpha Testing
2 Beta Testing
3 Acceptance Testing
Alpha Testing:
This refers to the system testing that is carried out by the test team with the Organization.
Beta Testing:
This refers to the system testing that is performed by a selected group of friendly customers
Acceptance Testing:
This refers to the system testing that is performed by the customer to determine whether
or not to accept the delivery of the system.
2. Updating of a All the details should This type of test is covered in all
particular record not be updated. the Asp files where updations are
made.
Test plan:
The test-plan is basically a list of testcases that need to be run on the system. Some of the testcases
can be run independently for some components (report generation from the database, for example,
can be tested independently) and some of the testcases require the whole system to be ready for
their execution. It is better to test each component as and when it is ready before integrating the
components. It is important to note that the testcases cover all the aspects of the system (ie, all the
requirements stated in the RS document).