6.1.

TESTING
The development of software systems involves a service of production activities where
opportunities for injection of human fallibilities are enormous. Errors may begin to occur at the
very inception of the process where the objectives may be erroneously or imperfectly specified,
as well as later design and development stages. Because of human inability to perform and
communicate with perfection, software companies are accompanied by a quality assurance
activity.

Testing is to determine errors in a software code. It is crucial element of software quality

assurance and represents the ultimate review of specifications, design and coding. The increasing
visibility of a software as a system element and the attendant costs associated with a software
failure are motivating forces for well-planned through testing. Usually software development
organizations expend between 30 to 40 percent of total project effort on testing. . Our goal is to
design a series of test cases that have a high likelihood of finding errors.

6.2. TESTING TECHNIQUES

Software design is a critical element of software quality assurance and represents the
ultimate review of specification, design and code generation. Once source code has been
generated software must be tested to uncover as many as errors as possible before delivery to
the customer. Our goal is to design a series of test cases that have a high likelihood of finding
errors. To test the software, there are so many testing techniques which provide systematic
guidance for designing tests that exercise the internal logic of software components and
exercise the input and output domains of the program to uncover errors in program function,
behavior and performance.

If testing is conducted successfully, it will uncover errors in the software. As the secondary
benefits, testing demonstrates that software functions appear to be working according to
specification, that behavioral and performance requirements appear to have been met. The
software can be tested by one of the two ways: -

Knowing the specified function that a product has been designed to perform, tests can
be conducted that demonstrate each function is fully operational while at the same time
searching for errors in each function.
 Knowing the internal working of the product, tests can be conducted to ensure that
internal operations are performed according to specifications and all internal
components have been adequately exercised.

The first approach is called white box testing and the second, black box testing.

6.2.1. White Box Testing:-

White box testing is a test case design method that uses the control structural of the
procedural design to derive test cases. It is also called glass box testing. Using this method,
we can derive test cases that-

Guarantee that all independent paths within a module have been exercised at least
once.
Exercise all logical decisions on their true and false sides Executes all loops at their
boundaries and within their operational bounds.
Execute all loops at their boundaries and within their operational bounds.
Exercise internal data structures to ensure their validity.

What is White Box Testing?

The purpose of any security testing method is to ensure the robustness of a system in the face of
malicious attacks or regular software failures. White box testing is performed based on the
knowledge of how the system is implemented. White box testing includes analyzing data flow,
control flow, information flow, coding practices, and exception and error handling within the
system, to test the intended and unintended software behavior. White box testing can be
performed to validate whether code implementation follows intended design, to validate
implemented security functionality, and to uncover exploitable vulnerabilities.

White box testing requires access to the source code. Though white box testing can be performed
any time in the life cycle after the code is developed, it is a good practice to perform white box
testing during the unit testing phase.
6.2.2 .Black Box Testing

Black box testing focuses on the functional requirements of the software i.e. it enables the
software engineer to derive sets of input conditions that will fully exercise all functional
requirements for a program. It is also called behavioral testing.

It attempts to find errors in the following areas:

Incorrect or missing functions

Interface errors
Errors in data structures or external database access
Performance errors
Initialization errors
This software is developing as a product to be used by many customers; it is impractical to
perform formal acceptance tests with each one. So out software product builders will use a
process called Alpha and Beta testing to uncover errors that only the end-user seems able to find.

Advantages and Disadvantages:-

Advantages of Black Box Testing

more effective on larger units of code than glass box testing

tester needs no knowledge of implementation, including specific programming languages

tester and programmer are independent of each other

tests are done from a user's point of view

will help to expose any ambiguities or inconsistencies in the specifications

test cases can be designed as soon as the specifications are complete

Disadvantages of Black Box Testing

only a small number of possible inputs can actually be tested, to test every possible input
stream would take nearly forever

without clear and concise specifications, test cases are hard to design

there may be unnecessary repetition of test inputs if the tester is not informed of test cases
the programmer has already tried

may leave many program paths untested

cannot be directed toward specific segments of code which may be very complex (and
therefore more error prone)

most testing related research has been directed toward glass box testing

A. Alpha Testing

The Alpha test is conducted at the developers site by a customer. The software
is used in a natural setting with the developer looking over the shoulder of the user
and recording errors and usage problem. Alpha test are conducted in controlled environment.

B. Beta Testing

The Beta-test is conducted at one or more customer sites by the end-user of the
software. Unlike Alpha testing, the developer is generally not present. Therefore, the Beta-
test is a live application of the software in an environment that cannot be controlled by
the developer. The customer records all problems ( real or imagined ) that are
encountered during Beta testing and reports there to the developer at regular intervals. As
a result of problems reported during Beta-tests, software engineers make modifications
and then prepare for release of the software product to the entire customer base.

In this project we will performed incremental testing in which components and subsystem
of the system are tested separately before integrating them to form the system from
system testing.

6.3 TESTING STRATEGIES

Designing effective test cases is important but so is the strategy we use to execute them. A
strategy for software test case design methods that result in the successful construction of
software. The strategy provides a road map that describes the steps to be conducted as a
part of testing.

There are a number of testing strategies, which have the following generic characteristics: -

Testing begins at the component level and works outward toward the integration
of the entire computerbased system.
 Different testing techniques are approximate at different points in time.

Testing is conducted by the developer of the software and (for large projects) an
independent test group.

Testing and debugging are different activities, but debugging must be

accommodated in any testing strategy.

System testing

Validation testing

Integration testing
Unit testing

Code

Design
Requirements

System engineering

TESTING STRATEGY

Initially, system engineering defines the role of software and leads to software requirement
analysis where the information domain, function, behavior, performance, constraints and
validation criteria for software are established. Moving inward along the spiral, we come to
the design and finally to coding. There are a number of testing strategies, which are given
below: -
Unit testing

In the unit testing interfaces, local data structures, boundary conditions, independent paths,
error-handling paths are tested. Test cases should be design to uncover errors due to
erroneous computations, incorrect comparisons, or improper control flow. For this purpose
basis path and loop testing is done. After source level code has been developed, reviewed
and verified for correspondence to component level design, unit test case design begins. In
unit test application drivers are developed which are programs, accept test case data,
passes such data to the component to be tested and prints relevant results. Stubs are also
developed which serve to replace modules, that are subordinate the component to be tested.

Six Rules of Unit Testing:-

1. Write the test first

2. Never write a test that succeeds the first time

3. Start with the null case, or something that doesn't work

4. Don't be afraid of doing something trivial to make the test work

5. Loose coupling and testability go hand in hand

6. Use mock objects

Limitations of unit testing

Testing, in general, cannot be expected to catch every error in the program. The same is true for
unit testing. By definition, it only tests the functionality of the units themselves. Therefore, it
may not catch integration errors, performance problems, or other system-wide issues. Unit
testing is more effective if it is used in conjunction with other software testing activities.

Like all forms of software testing, unit tests can only show the presence of errors; it cannot show
the absence of errors.

Software testing is a combinatorial problem. For example, every Boolean decision statement
requires at least two tests: one with an outcome of "true" and one with an outcome of "false". As
a result, for every line of code written, programmers often need 3 to 5 lines of test code.
Therefore, it is unrealistic to test all possible input combinations for any non-trivial piece of
software without an automated characterization test generation tool such as JUnit Factory used
with Java code or many of the tools listed in List of unit testing frameworks.

To obtain the intended benefits from unit testing, a rigorous sense of discipline is needed
throughout the software development process. It is essential to keep careful records, not only of
the tests that have been performed, but also of all changes that have been made to the source
code of this or any other unit in the software. Use of a version control system is essential. If a
later version of the unit fails a particular test that it had previously passed, the version-control
software can provide a list of the source code changes (if any) that have been applied to the unit
since that time.

It is also essential to implement a sustainable process for ensuring that test case failures are
reviewed daily and addressed immediately. If such a process is not implemented and ingrained
into the team's workflow, the application will evolve out of sync with the unit test suite-
increasing false positives and reducing the effectiveness of the test suite.

Integration testing:-

Integration testing is systematic technique for constructing the program structure while at
the same time conducting the tests to uncover errors associated with interfacing. The
objective is to take unit tested components and build a program structure that has been
dictated by design. There are two types of integration Bottom up integration and Top
down integration. Regression and smoke testing are done in integration testing strategy.

Validation testing

Next step is the validation testing where requirements established as part of software
requirements analysis are validated against the software that has been constructed. At the
culmination of integration testing, software is completely assembled as a package,
interfacing errors has been uncovered and corrected, and a final series of software tests i.e.
validation testing begins. Validation succeeds when software functions in a manner that can
be reasonably expected by the customer.

Software validations can be achieved through a series of black-box tests that demonstrate
conformity with requirements. Configuration review, alpha testing and beta testing
techniques are conducted to enable the customer to validate all requirements. Acceptance
tests are conducted by the end-users over a period of weeks or months.

System testing

Finally, we arrive at system testing where the software and other system elements are tested as a
whole. System testing verifies that all elements mesh properly and that overall system function /
performance is achieved. Ultimately software is incorporated with other system elements and a
series of system integration and validation tests are conducted.

6.4. TEST CASES

TEST CASE -1

TEST NO. : 1

TEST TYPE : UNIT TESTING

INPUT : PASSWORD

OBJECTIVE : CHECKING PASSWORD SECURITY

EXPECTED OUTPUT : ACCESS TO AUTHORIZED USERS ONLY

ACTUAL OUTPUT : PASSWORD SECURITY SUCCESSFUL

RESULT : ACCESS TO ONLY AUTHORIZED USERS

TEST CASE -2

TEST NO. :2

TEST TYPE : UNIT TESTING

INPUT : DATA ENTRY TO COLLEGE INFORMATION

OBJECTIVE : TO STORE VALID DATA IN THE TABLE

EXPECTED OUTPUT : SUCCESSFUL DATA STORAGE

ACTUAL OUTPUT : SUCCESSFUL DATA STORAGE

RESULT : DATA STORED

TEST CASE - 3

TEST NO. :3

TEST TYPE : UNIT TESTING

INPUT : DATA ENTRY TO VARIFICATION OF USER TYPE

OBJECTIVE : TO OPEN USER OR ADMIN PAGE

EXPECTED OUTPUT : SUCCESSFUL OPEN USER HOME PAGE

ACTUAL OUTPUT : SUCCESSFUL OPEN USER HOME PAGE

RESULT : ACKNOWLEGMENT

T E S T C A S E -4

TEST NO. :4

TEST TYPE : UNIT TESTING

INPUT : DATA ENTRY TO QUESTION EDITOR

OBJECTIVE : FOR STORAGE

EXPECTED OUTPUT : SUCCESSFUL INSERT IN DATABASE

ACTUAL OUTPUT : SUCCESSFUL INSERT IN DATABASE

RESULT : ACKNOWLEGMENT
TEST CASE -5

TEST NO. :5

TEST TYPE : UNIT TESTING

INPUT : GENERATION OF QUESTION PAPER

OBJECTIVE : TO SAVE DATA INTO THE DATABASE

EXPECTED OUTPUT : SAVE DETAILS

ACTUAL OUTPUT : SAVE DETAILS

RESULT : OK

TEST CASE 6

TEST NO :6

TEST TYPE : UNIT TESTING

INPUT : GENERATED PAPER TO DOC

OBJECTIVE : FOR EXAMINATION

EXPECTED OUTPUT : DOC FILE

ACTUAL OUTPUT : DOC FILE

RESULT : OK