-Project

Idea Description

To leverage the large volume information buried in deep web, previous work has proposed a
number of techniques and tools, including deep web understanding and integration, hidden web
Crawlers and deep web samplers. For all these approaches, the ability to crawl deep web is a key
challenge. Olston and Najork systematically present that crawling deep web has three steps:
locating deep web content sources, selecting relevant sources and extracting underlying
Content Following their statement, we discuss the two steps closely related to our work as below.
Locating deep web content sources: A recent study shows that the harvest rate of deep web is
low only 647,000 distinct web forms were found by sampling 25 million pages from the
Google index (about 2.5%) . Generic crawlers are mainly developed for characterizing deep web
and directory construction of deep web resources that do not limit search on a specific topic, but
attempt to fetch all searchable forms The Database Crawler in the Meta Querier is designed for
automatically discovering query interfaces. Database Crawler first finds root pages by an IPbased sampling, and then performs shallow crawling to crawl pages within a web server starting
from a given root page. The IP based sampling ignores the fact that one IP address may have
several virtual hosts, thus missing many websites. To overcome the drawback of IP based
Sampling in the Database Crawler, Denis et al. propose a stratified random sampling of hosts to
Characterize national deep web, using the Host graph provided by the Russian search engine
Index. I-Crawler combines pre-query and post-query approaches for classification of searchable
forms.

-Outcome Descriptive
Outcome of this project is it finds deep web pages for user search query with instant result.

-State transitions diagram

-Class diagram

-Sequence diagram

-Project quality and reliability testing of project design

Testing and Implementation
The Testing Process
We test the software process activities such as Design, Implementation, and
Requirement Engineering. Because, design errors are very costly to repair once
system has been started to operate, it is quite obvious to repair them at early stage
of the system. So analysis is the most important process of any project.

Requirement Traceability
As most interested portion is whether the system is meeting its requirements or not,
for that testing should be planned so that all requirements are individually tested.
We checked the output of certain combination of inputs so that we can know
whether it gives desirable results or not. Strictly sticking to your requirements
specifications, give you the path to get desirable results from the system.

Testing Schedule

We have tested each procedure back-to-back so that errors and omissions can be
found as early as possible. Once the system has been developed fully we tested it
on other machines, which differs in configuration.

TESTING STRATEGY
There are types of testing that we implement. They are as follows:

While deciding on the focus of testing activities, study project

priorities. For example, for an on-line system, pay more attention to
response time. Spend more time on the features used frequently.

Decide on the effort required for testing based on the usage of the
system. If the system is to be used by a large number of users,

evaluate the impact on users due to a system failure before deciding

on the effort.

A necessary part of the test case is a definition of the expected result.

Write test cases for invalid and unexpected as well as valid and
expected input conditions.

Thoroughly inspect the results of each test.

We have performed both Unit Testing and System Testing on WIMS to detect
and fix errors. A brief description of both is given below.
White Box Testing
White-box testing (also known as clear box testing, glass box testing,
transparent box testing, and structural testing) is a method of testing
software that tests internal structures or workings of an application, as
opposed to its functionality (i.e. black-box testing). In white-box testing an
internal perspective of the system, as well as programming skills, are used to
design test cases. The tester chooses inputs to exercise paths through the
code and determine the appropriate outputs.
While white-box testing can be applied at the unit, integration and system levels of
the software testing process, it is usually done at the unit level. It can test paths
within a unit, paths between units during integration, and between subsystems
during a systemlevel test. Though this method of test design can uncover many
errors or problems, it might not detect unimplemented parts of the specification or
missing requirements.
White-box test design techniques include:

Control flow testing

Data flow testing

Branch testing

Path testing

Statement coverage

Decision coverage

Overview

White-box testing is a method of testing the application at the level of the

source code. The test cases are derived through the use of the design
techniques mentioned above: control flow testing, data flow testing,
branch testing, path testing, statement coverage and decision coverage
as well as modified condition/decision coverage.
White-box testing is the use of these techniques as guidelines to create
an error free environment by examining any fragile code. These White-box
testing techniques are the building blocks of white-box testing, whose
essence is the careful testing of the application at the source code level to
prevent any hidden errors later on. These different techniques exercise
every visible path of the source code to minimize errors and create an
error-free environment. The whole point of white-box testing is the ability
to know which line of the code is being executed and being able to
identify what the correct output should be.
Levels
1. Unit testing. White-box testing is done during unit testing to ensure that
the code is working as intended, before any integration happens with
previously tested code. White-box testing during unit testing catches any
defects early on and aids in any defects that happen later on after the
code is integrated with the rest of the application and therefore prevents
any type of errors later on.

2. Integration testing. White-box testing at this level is written to test the

interactions of each interface with each other. The Unit level testing made
sure that each code was tested and working accordingly in an isolated
environment and integration examines the correctness of the behavior in
an open environment through the use of white-box testing for any
interactions of interfaces that are known to the programmer.
3. Regression testing. White-box testing during regression testing is the use
of recycled white-box test cases at the unit and integration testing levels.

Basic Procedure

White-box testing's basic procedures involve the understanding of the source

code that you are testing at a deep level to be able to test them. The
programmer must have a deep understanding of the application to know
what kinds of test cases to create so that every visible path is exercised for
testing. Once the source code is understood then the source code can be
analyzed for test cases to be created. These are the three basic steps that
white-box testing takes in order to create test cases:
Input, involves different types of requirements, functional specifications, detailed
designing of documents, proper source code, security specifications.

This is the

preparation stage of white-box testing to layout all of the basic information.

Processing Unit involves performing risk analysis to guide whole testing process,
proper test plan, execute test cases and communicate results. This is the phase of
building test cases to make sure they thoroughly test the application the given
results are recorded accordingly.
Output, prepare final report that encompasses all of the above preparations and
results.
Advantages

White-box testing is one of the two biggest testing methodologies used

today. It primarily has three advantages:
1. A side effect of having the knowledge of the source code is beneficial to
thorough testing.
2. Optimization of code by revealing hidden errors and being able to remove
these possible defects.
3. Gives the programmer introspection because developers carefully describe
any new implementation.
Disadvantages

Although White-box testing has great advantages, it is not perfect and

contains some disadvantages. It has two disadvantages:
1. White-box testing brings complexity to testing because to be able to test
every important aspect of the program, you must have great knowledge of
the program. White-box testing requires a programmer with a high-level of
knowledge due to the complexity of the level of testing that needs to be
done.
2. On some occasions, it is not realistic to be able to test every single existing
condition of the application and some conditions will be untested.

Black Box Testing

Black-box testing is a method of software testing that examines the
functionality of an application (e.g. what the software does) without peering
into its internal structures or workings. This method of test can be applied to
virtually every level of software testing: unit, integration, system and
acceptance. It typically comprises most if not all higher level testing, but can
also dominate unit testing as well.
Test Procedures

Specific

knowledge

of

the

application's

code/internal

structure

and

programming knowledge in general is not required. The tester is aware of

what the software is supposed to do but is not aware of how it does it. For
instance, the tester is aware that a particular input returns a certain,
invariable output but is not aware of how the software produces the output in
the first place.
Test Cases

Test cases are built around specifications and requirements, i.e., what the
application is supposed to do. Test cases are generally derived from external
descriptions of the software, including specifications, requirements and
design parameters. Although the tests used are primarily functional in
nature, non-functional tests may also be used. The test designer selects both
valid and invalid inputs and determines the correct output without any
knowledge of the test object's internal structure.
Test Design Techniques
Typical black-box test design techniques include:

Decision table testing

All-pairs testing

State transition Analysis

Equivalence partitioning

Boundary value analysis

Causeeffect graph

Error guessing

Advantages

Efficient when used on large systems.

Since the tester and developer are independent of each other, testing is
balanced and unprejudiced.

Tester can be non-technical.

There is no need for the tester to have detailed functional knowledge of

system.

Tests will be done from an end user's point of view, because the end user
should accept the system. (This testing technique is sometimes also called
Acceptance testing.)

Testing

helps

to

identify vagueness

and

contradictions

in

functional

specifications.

Test cases can be designed as soon as the functional specifications are

complete.

Disadvantages

Test cases are challenging to design without having clear functional

specifications.

It is difficult to identify tricky inputs if the test cases are not developed based
on specifications.

It is difficult to identify all possible inputs in limited testing time. As a result,

writing test cases may be slow and difficult.

There are chances of having unidentified paths during the testing process.

There is a high probability of repeating tests already performed by the

programmer.

Unit Testing
In computer programming, unit testing is a software testing method by
which individual units of source code, sets of one or more computer program
modules together with associated control data, usage procedures, and
operating procedures are tested to determine if they are fit for use.
Intuitively, one can view a unit as the smallest testable part of an
application. In procedural programming, a unit could be an entire module,
but it is more commonly an individual function or procedure. In objectoriented programming, a unit is often an entire interface, such as a class, but
could be an individual method. Unit tests are short code fragments created
by

programmers

or

occasionally

by

white

box

testers

during

the

development process.
Ideally, each test case is independent from the others. Substitutes such as
method stubs, mock objects, fakes, and test harnesses can be used to assist
testing a module in isolation. Unit tests are typically written and run by
software developers to ensure that code meets its design and behaves as
intended.

Benefits

The goal of unit testing is to isolate each part of the program and show that
the individual parts are correct. A unit test provides a strict, written contract
that the piece of code must satisfy. As a result, it affords several benefits.
Unit tests find problems early in the development cycle.
In test-driven development (TDD), which is frequently used in both Extreme
Programming and Scrum, unit tests are created before the code itself is
written. When the tests pass, that code is considered complete. The same
unit tests are run against that function frequently as the larger code base is
developed either as the code is changed or via an automated process with
the build. If the unit tests fail, it is considered to be a bug either in the
changed code or the tests themselves. The unit tests then allow the location
of the fault or failure to be easily traced. Since the unit tests alert the
development team of the problem before handing the code off to testers or
clients, it is still early in the development process.
Facilitates change

Unit testing allows the programmer to re factor code at a later date, and
make sure the module still works correctly. The procedure is to write test
cases for all functions and methods so that whenever a change causes a
fault, it can be quickly identified.
Readily available unit tests make it easy for the programmer to check
whether a piece of code is still working properly.
In continuous unit testing environments, through the inherent practice of
sustained maintenance, unit tests will continue to accurately reflect the
intended use of the executable and code in the face of any change.
Depending upon established development practices and unit test coverage,
up-to-the-second accuracy can be maintained.

Simplifies integration

Unit testing may reduce uncertainty in the units themselves and can be used
in a bottom-up testing style approach. By testing the parts of a program first
and then testing the sum of its parts, integration testing becomes much
easier.
An elaborate hierarchy of unit tests does not equal integration testing.
Integration with peripheral units should be included in integration tests, but
not in unit tests. Integration testing typically still relies heavily on humans
testing manually; high-level or global-scope testing can be difficult to
automate, such that manual testing often appears faster and cheaper.
Documentation

Unit testing provides a sort of living documentation of the system.

Developers looking to learn what functionality is provided by a unit and how
to use it can look at the unit tests to gain a basic understanding of the unit's
interface.
Unit test cases embody characteristics that are critical to the success of the
unit. These characteristics can indicate appropriate/inappropriate use of a
unit as well as negative behaviors that are to be trapped by the unit. A unit
test case, in and of itself, documents these critical characteristics, although
many software development environments do not rely solely upon code to
document the product in development.
By contrast, ordinary narrative documentation is more susceptible to drifting
from the implementation of the program and will thus become outdated
(e.g., design changes, feature creep, relaxed practices in keeping documents
up-to-date).
Design

When software is developed using a test-driven approach, the combination of

writing the unit test to specify the interface plus the refactoring activities
performed after the test is passing, may take the place of formal design.
Each unit test can be seen as a design element specifying classes, methods,
and observable behavior.
Limitations

Testing will not catch every error in the program, since it cannot evaluate
every execution path in any but the most trivial programs. The same is true
for unit testing. Additionally, unit testing by definition only tests the
functionality of the units themselves. Therefore, it will not catch integration
errors or broader system-level errors (such as functions performed across
multiple units, or non-functional test areas such as performance). Unit
testing should be done in conjunction with other software testing activities,
as they can only show the presence or absence of particular errors; they
cannot prove a complete absence of errors. In order to guarantee correct
behavior for every execution path and every possible input, and ensure the
absence of errors, other techniques are required, namely the application of
formal methods to proving that a software component has no unexpected
behavior.
Integration Testing
Integration

testing

(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 validation 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.

Purpose

The purpose of integration testing is to verify functional, performance, and

reliability requirements placed on major design items. These "design items",
i.e. assemblages (or groups of units), are exercised through their interfaces
using black box testing, success and error cases being simulated via
appropriate parameter and data inputs. Simulated usage of shared data
areas and inter-process communication is tested and individual subsystems
are exercised through their input interface. Test cases are constructed to test
whether all the components within assemblages interact correctly, for
example across procedure calls or process activations, and this is done after
testing individual modules, i.e. unit testing. The overall idea is a "building
block" approach, in which verified assemblages are added to a verified base
which is then used to support the integration testing of further assemblages.
Some different types of integration testing are big bang, top-down, and bottom-up.
Other Integration Patterns are: Collaboration Integration, Backbone Integration,
Layer Integration, Client/Server Integration, Distributed Services Integration and
High-frequency Integration.

Big Bang

In this approach, all or most of the developed modules are coupled together
to form a complete software system or major part of the system and then
used for integration testing. The Big Bang method is very effective for saving
time in the integration testing process. However, if the test cases and their
results are not recorded properly, the entire integration process will be more
complicated and may prevent the testing team from achieving the goal of
integration testing.
A type of Big Bang Integration testing is called Usage Model testing. Usage
Model Testing can be used in both software and hardware integration testing.
The basis behind this type of integration testing is to run user-like workloads

in integrated user-like environments. In doing the testing in this manner, the

environment is proofed, while the individual components are proofed
indirectly through their use. Usage Model testing takes an optimistic
approach to testing, because it expects to have few problems with the
individual components. The strategy relies heavily on the component
developers to do the isolated unit testing for their product. The goal of the
strategy is to avoid redoing the testing done by the developers, and instead
flesh-out problems caused by the interaction of the components in the
environment. For integration testing, Usage Model testing can be more
efficient and provides better test coverage than traditional focused functional
integration testing. To be more efficient and accurate, care must be used in
defining the user-like workloads for creating realistic scenarios in exercising
the environment. This gives confidence that the integrated environment will
work as expected for the target customers.

Top-down and Bottom-up

Bottom up Testing is an approach to integrated testing where the lowest

level components are tested first, then used to facilitate the testing of higher
level components. The process is repeated until the component at the top of
the hierarchy is tested.
All the bottom or low-level modules, procedures or functions are integrated
and then tested. After the integration testing of lower level integrated
modules, the next level of modules will be formed and can be used for
integration testing. This approach is helpful only when all or most of the
modules of the same development level are ready. This method also helps to
determine the levels of software developed and makes it easier to report
testing progress in the form of a percentage.

Top down Testing is an approach to integrated testing where the top

integrated modules are tested and the branch of the module is tested step
by step until the end of the related module.
Sandwich Testing is an approach to combine top down testing with bottom
up testing.
The main advantage of the Bottom-Up approach is that bugs are more easily
found. With Top-Down, it is easier to find a missing branch link.
Validation Testing
Validations are independent procedures that are used together for checking
that a product, service, or system meets requirements and specifications and
that it fulfils its intended purpose. The words "verification" and "validation"
are sometimes preceded with "Independent" (or IV&V), indicating that the
verification and validation is to be performed by a disinterested third party.
Overview
Validation is intended to ensure a product, service, or system (or portion thereof, or
set thereof) result in a product, service, or system (or portion thereof, or set thereof)
that meets the operational needs of the user. For a new development flow or
verification flow, validation procedures may involve modeling either flow and using
simulations to predict faults or gaps that might lead to invalid or incomplete
verification or development of a product, service, or system (or portion thereof, or
set thereof). A set of validation requirements (as defined by the user),
specifications, and regulations may then be used as a basis for qualifying a
development flow or verification flow for a product, service, or system (or portion
thereof, or set thereof). Additional validation procedures also include those that are
designed specifically to ensure that modifications made to an existing qualified
development flow or verification flow will have the effect of producing a product,
service, or system (or portion thereof, or set thereof) that meets the initial design
requirements, specifications, and regulations; these validations help to keep the
flow qualified. It is a process of establishing evidence that provides a high degree of

assurance

that

product,

service,

or

system

accomplishes

its

intended

requirements. This often involves acceptance of fitness for purpose with end users
and other product stakeholders. This is often an external process.
Aspects of Validation

The most tested attributes in validation tasks may include, but are not
limited to

Selectivity/specificity

Accuracy and precision

Repeatability

Reproducibility

Limit of detection especially for trace elements

Limit of quantification

Curve fitting and its range

System suitability

To solve this kind of difficulties, some regulatory bodies or compendia methods

usually provide the advices on what the circumstances or conditions that the
performing of a specified system suitability test should be bearded and compulsory.

TEST CASE

FOR

LOGIN

Test Case ID No: Login_1

Test Case Name: Login

Tes
t
Cas
e

Test
Conditi

Operator

Expected

Action

Result

Result

on

No.
1

Successf 1.Enter
ul

Username

Login

2.Enter

System
should display
successful
login message

Password
3.Click
Login
button

Unsucce

1.Enter

System

ssful

Username

should display

Login

2.Enter

due

to

wrong
userna
me

Password

message
invalid
username

3.Click
&

correct

Login
button

passwor
d

Unsucce

1.Enter

System

ssful

Username

should display

Login

2.Enter

due

to

Password

wrong
passwor

3.Click

Login

&

correct
usernam
e

button

Actual

message
invalid
password

Pass/
Fail

 TEST CASE

FOR

REGISTRATION

DETAILS

Test Case ID No: Registration_1

Test Case Name: Registration details

Test
Cas
e

Test
Condition

Operato

Expected

r Action

Result

Actual
Result

No.
1

Successful
Registratio
n

Fill

all

System should

fields

display

with

summery page

Order

correct
data

Unsuccessf

Leave

System should

ul

some

display

registratio

fields

message

empty

empty field

Unsuccessf

Enter the

System should

ul

incorrec

display

message

due

to

empty

fill

fields

registration
due

to

email

ID

invalid

email

ID

incorrect
email ID
4

Unsuccessf

Enter the

System should

ul

incorrec

display

t Mobile

message

No.

invalid

registration
due

to

Mobile

No.

incorrect
Mobile No.
5

Unsuccessf

Enter

System should

ul

different

display

registration

passwor

message

due

ds

Password does

to

in

mismatch

passwor

of

ds & re-

password &

enter

re-enter

passwor

password

ds field

not match

Pass/
Fail

-Deployment and maintenance

Once the software has been fully tested and no high priority issues remain in the software, it is
time to deploy to production where customers can use the system.
Once a version of the software is released to production, there is usually a maintenance team that
looks after any post-production issues.
If an issue is encountered in the production the development team is informed and depending on
how severe the issue is, it might either require a hot-fix which is created and shipped in a short
period of time or if not very severe, it can wait until the next version of the software.