SYSTEM TESTING AND
INTEGRATION
Implementation
is the act of carrying an undertaking into effect. Testing cannot be
successfully completed without a successful implementation, hence testing and
implementation work hand in hand. Implementation is the actual conversion of
the existing system to the newly designed system thereby putting the new system
into operation. Installing the new system into a machine is a stage in the
implementation process. When it is absolutely clear that the new system meets
all the users sets of requirement (system specification), the old system may be
abandoned for the new one. Training the users is another important aspect of
implementation, because it is after the users have been trained to handle the
new system that they can actually use it to process their various transaction requirements.
IMPLEMENTATION TECHNOLOGY
The objective of this project is to
develop an online store. When the user types in the URL of the supermarket
Store in the address field of the browser, a Web Server is contacted to get the
requested information. In the .NET Framework, XAMP acts as the Web Server. The
sole task of a Web Server is to accept incoming HTTP requests and to return the
requested resource in an HTTP response. The first thing XAMP does when a
request comes in is to decide how to handle the request. Its decision is based
upon the requested file's extension. For example, if the requested file has the
.asp extension, XAMP will route the request to be handled by asp.dll. If it has
the extension of .aspx, .ascx, etc, it will route the request to be handled by
ASP.NET Engine.
The PHP Engine then gets the requested file, and if necessary contacts
the database through ADO.NET for the required file and then the information is
sent back to the Client’s browser. Figure 5.1 shows how a client browser
interacts with the Web server and how the Web server handles the request from
client.
MYSQL DATABASE
In this project, MySQL is used as the
backend database. MySQL is an open source database management system. The
features of MySQL are given below:
MySQL
is a relational database management system. A relational database stores
information in different tables, rather than in one giant table. These tables
can be referenced to each other, to access and maintain data easily.
MySQL is open source database system. The database software can be used and modify by anyone according to their needs.
It is fast, reliable and easy to use. To
improve the performance, MySQL is multithreaded database engine. A
multithreaded application performs many tasks at the same time as if multiple
instances of that application were running simultaneously.
In being multithreaded MySQL has many
advantages. A separate thread handles each incoming connection with an extra
thread that is always running to manage the connections. Multiple clients can
perform read operations simultaneously, but while writing, only hold up another
client that needs access to the data being updated. Even though the threads
share the same process space, they execute individually and because of this
separation, multiprocessor machines can spread the thread across many CPUs as long
as the host operating system supports multiple CPUs. Multithreading is the key feature
to support MySQL’s performance design goals. It is the core feature around which
MySQL is built. MySQL database is connected to ASP.NET using an ODBC driver.
Open Database Connectivity ODBC) is a
widely accepted application-programming interface (API) for database access.
The ODBC driver is a library that implements the functions supported by ODBC
API. It processes ODBC function calls, submits SQL requests to MySQL server,
and returns results back to the application. If necessary, the driver modifies
an application's request so that the request conforms to syntax supported by MySQL.
INTEGRATING THE WEBSITE AND DATABASE
Customers ordering from an e-commerce
website need to be able to get information about a vendor’s products and
services, ask questions, select items they wish to purchase, and submit payment
information. Vendors need to be able to track customer inquiries and
preferences and process their orders. So a well organized database is essential
for the development and maintenance of an e-commerce site. In a static Web
page, content is determined at the time when the page is created. As users
access a static page, the page always displays the same information. Example of
a static Web page is the page displaying company information. In a dynamic Web
page, content varies based on user input and data received from external
sources. We use the term “data-based Web pages” to refer to dynamic Web pages
deriving some or all of their content from data files or databases. A
data-based Web page is requested when a user clicks a hyperlink or the submit
button on a Web page form. If the request comes from clicking a hyperlink, the
link specifies either a Web server program or a Web page that calls a Web
server program. In some cases, the program performs a static query, such as
“Display all items from the Inventory”. Although this query requires no user
input, the results vary depending on when the query is made. If the request is
generated when the user clicks a form’s submit button, instead of a hyperlink,
the Web server program typically uses the form inputs to create a query. For
example, the user might select five products to be purchased and then submit
the input to the Web server program. The Web server program then services the
order, generating a dynamic Web page response to confirm the transaction. In
either case, the Web server is responsible for formatting the query results by
adding HTML tags. The
Web
server program then sends the program’s output back to the client’s browser as
a Web page.
WEB
PAGE PROGRAMMING OPTIONS
An e-commerce
organization can create data-based Web pages by using server-side and
client-side processing technologies or a hybrid of the two. With server-side processing,
the Web server receives the dynamic Web page request, performs all processing
necessary to create the page, and then sends it to the client for display in
the client’s browser. Client-side processing is done on the client workstation
by having the client browser execute a program that interacts directly with the
database.
Figure 5.2 outlines commonly used server-side, client-side, and hybrid
Web and data processing technologies; client-side scripts are in dashed lines
to indicate they are unable to interact directly with a database or file but
are used to validate user input on the client, then send the validated inputs
to the server for further processing.
SERVER-SIDE PROCESSING.
Generally dynamic or data-driven Web pages use HTML forms to collect user
inputs, submitting them to a Web server. A program running on the server
processes the form inputs, dynamically composing a Web page reply. This program,
which is called, servicing program, can be either a compiled executable program
or a script interpreted into machine language each time it is run.
Compiled
server programs. When a user submits HTML- form data for processing by a compiled server
program, the Web Server invokes the servicing program. The servicing program is
not part of the Web server but it is an independent executable program running
on the Web server; it processes the user input, determines the action which
must be taken, interacts with any external sources (Eg: database) and finally
produces an HTML document and terminates. The Web server then sends the HTML
document back to the user’s browser where it is displayed. Figure 5.3 shows the
flow of HTTP request from the client to the Web server, which is sent to the
servicing program. The program creates an HTML document to be sent to the
client browser.
Popular
languages for creating compiled server programs are Java, Visual Basic, and C++,
but almost any language that can create executable programs can be used,
provided that it supports commands used by one of the protocols that establish
guidelines for communication between Web servers and servicing programs. The
first such protocol, introduced in 1993, for use with HTML forms was the Common
Gateway Interface (CGI); many servicing programs on Web sites still use CGI
programs. However, a disadvantage of using CGI-based servicing programs is that
each form submitted to a Web server starts its own copy of the servicing
program on the Web server.
A busy Web server is likely to run
out of memory when it services many forms simultaneously; thus, as interactive
Web sites have gained popularity, Web server vendors have developed new
technologies to process form inputs without starting a new copy of the
servicing program for each browser input. Examples of these technologies for
communicating with Web servers include Java Servlets and Microsoft’s ASP.NET;
they allow a single copy of the servicing program to service multiple users
without starting multiple instances of the program.
Server-Side Scripts. Web-based applications can also use server-side
scripts to create dynamic Web pages that are able to retrieve and display
information from a backend database and modify data records. The processing
architecture is the same as the processing architecture used for compiled
server programs except the Web server processing is performed through and
interpreted script rather than a compiled program.
If needed, a developer can have a single Web server process a variety of
scripts written with any or all of these technologies. The Web server knows
which script interpreter to invoke by taking note of the requesting script’s
file extension. Table below demonstrates some commonly used extensions and the
related technologies.
Processing
Technology for different File Extensions
File
Extension
|
Processing
technology interpreter/compiler
|
.PHP
|
PHP Script
|
.asp
|
Microsoft Active Server Page
|
.aspx
|
Microsoft
ASP.NET web page
|
.js
|
Microsoft
Scripting Language “JScript” file extension
|
.vbp
|
Visual Basic
Project
|
Server-side
hybrid processing. Compiled
server-side programs offer two main advantages: First, they are compiled and
stored in a machine-readable format; so they usually run faster than scripts.
Second, compiled programs are usually created in integrated development
environments that provide debugging utilities. The advantage of using scripts
is that their modification requires only a text editor rather than installation
of an associated development environment.
Hybrid server-side programming
strives to combine the advantages of compiled server-side programs and
server-side scripts; a server-side script is created but not compiled. The
first time a user accesses a Web page calling the script, the script is
compiled into machine-readable format and stored as an executable file. With
this approach, the developer works with ordinary text files and does not need
to install an integrated programming development environment to modify the
script. Performance is improved because the program does not need to be
translated into machine language each time it runs.
CLIENT-SIDE PROCESSING.
Client-side Web page processing is
achievable through compiled programs downloaded, installed, and executed on the
client workstation or by creating scripts with the HTML Web page commands
interpreted by the client browser.
Downloading
and running compiled programs on client workstations. When
a user clicks a hyperlink on a Web page associated with a compiled client-side
program, the user’s browser must have the ability to run the executable program
file; this program interacts with the user, sending and retrieving data from a
database server as needed.
Many times, the user is asked to install
certain ActiveX components to view some animations or play games. This new
component plugs in into the existing system, thus extending the
functionality of the system.
Java Applets are another example of
compiled programs on client workstations. An applet is a program written in the
Java programming language that can be included in an HTML page, much in the
same way an image is included in a page. When we use a Java technology-enabled
browser to view a page that contains an applet, the applet's code is
transferred to our system and executed by the browser
Client-side scripts. In
a client-side script, source code written in such languages as JavaScript and
VBScript is embedded in an HTML document, along with the static HTML text; it
is placed within delimiter tags to indicate to the user’s browser that the text
is code that must be interpreted. If the user’s browser is able to recognize
and interpret the code, it is processed. If the browser is unable to recognize
and interpret the code, it is displayed as text on the Web page.
Although basic client-side scripts
cannot be used by a Web page to interact with a remote database, they are often
used to validate user inputs entered on HTML forms submitted for processing by
a server-side program; for example, a script running on a client workstation
might check the inputs users submit to a Web page to make sure they entered all
required data and appropriate data values. This approach avoids transmitting inputs
to the Web server that are incomplete or include errors, while offloading error
checking and handling from the Web server program to the client workstation.
Client-side
scripts can also be used to create advanced Web page features, including:
animations, calculations, playing sound and video, and image maps allowing users
to move their cursors over an image and click to access different Web page
links.
JavaScript is the most commonly used
client-side scripting language and is supported by most browsers.
Use of a client-side scripting language
depends on the user’s operating system, browser platforms, and developer
expertise. If the Web pages in question are to be accessed by a variety of
users over the Internet, JavaScript is probably better than VBScript, as
JavaScript is the only scripting language able to run on nearly all browsers. If
the Web pages are to be accessed on an intranet and if the organization has standardized
on Microsoft’s browser and Web server, VBScript is a satisfactory scripting language
for creating client-side scripts.
INTEGRATION
With
all the web pages of this online supermarket now fully developed (i.e. designed
and Implemented), this integration stage deals with bringing these web pages
together to form a website. During this stage, we found out that the pages were
easily joined except when there was a data exchange between them. In such a
case of data exchange, I encountered problem which lead to logical error in the
computation of data in the website. We were able to track the problem down and
solve it during the integration testing.
TESTING
Software
testing is a critical element of software quality assurance and represents the
ultimate view of specification, design and coding. The increasing visibilities
of software as a system element and attachment “coast” associated with the
software failure are motivating force for well planned , through testing.
Hence, software testing is the stage in development cycle during which the
program is executed with the intention of finding and correcting errors. The
requirement of the client as determined during investigation is compared
against the software performance. Redesign -and coding of different units and
submit of the software may be done if any defiance in the performance standard
is detected. Testing is either done at module level (verification testing) or
either entire system implementation (validation Testing). In the development of
this online super-market, both verification and validation were carried out.
This was done to avoid caring an error from one stage of the system life to
another stage. It has proved that the cost of correcting the error at the next
stage of development will amount to about three (3) times what it would have
cost if discovered earlier enough.
Test
Plan
At
each stage/phase of this website development, there were verification tests.
The specification documentation was verified with my supervisor for conformity
with the requirements or the problem statement being addressed. After the
development of the system design document, the specification document guided us
and at the end, the design document was verified to ascertain conformity with
the specification document. All these tests were being carried out to avoid
error in the system when it is fully diploid to the internet. When the design
was verified and confirmed to be in conformity with the specification document,
we continued with the system implementation or coding. When the entire system
was completed, I proceeded to validation testing. At this stage, the completed
website was tested against its specification document. We were satisfied with
the result.
Test
Result (Actual versus Expected)
The result of the tests carried out
was as expected. The tests carried out includes customer registration, customer
purchase with credit card, customer login, customer authentication, Admin
login, Admin authentication, update inventory, delete inventory, Add products
and many more. The summary of the test result is as shown in the table below.
Test
Conducted
|
Expected
Result
|
Actual
Result
|
Customer registration
|
A customer should be able to
register.
|
Customer registration was
successful
|
Customer login
|
A customer should be able to
login with his username and password
|
Customer was able to login with
his username and password.
|
Admin login
|
The administrator should be
able to login with his username and password to view admin page.
|
Admin login was successful
|
View customers
|
The admin should be able to
view customers that have registered on his cite
|
The admin was able to view customers
and their details.
|
View ordered goods
|
The admin should be able to see
the order placed by his customers.
|
Admin was able to view order
list, customer name and goods ordered
|
View payment
|
The admin should be able to
view his statement of account.
|
The admin was able to get the
report of his sales online
|
Placing an order
|
The customers should be able to
place order for goods and the money equivalent deducted from his/her account
|
The customer was able to place
order for goods and only the specified amount was deducted from their
account.
|
Create a valid credit account
to use and purchase online
|
The customer should be able to
create a valid credit account to shop with
|
Customer was able to create a
valid credit card account and use the pin to shop.
|
Other things were tested in
like manner and the results gotten were as specified.
|
||
Table 5.1
Performance Evaluation.
During the testing process (both
verification and validation testing) we noticed the website performed the
expected function. It runs faster on a local network in which it is being
tested and we presume that it will be as such on the internet depending on the
speed of the pc, the operating system, and connection speed. With these
findings, it could be assumed that the website is very efficient and has high
performance.