0% found this document useful (0 votes)
93 views54 pages

Z Cart

Download as pdf or txt
Download as pdf or txt
Download as pdf or txt
You are on page 1/ 54

GOVERNMENT COLLEGE UNIVERSITY FAISALABAD

Z-Cart Multivendor
By
Nimra Qayum
2017-GCUF-056010

Saleha Ashraf

2017-GCUF-0611319
Project Submitted in Partial Contentment of the Requirements for the Degree
of

BACHELOR OF SCIENCE
IN
INFORMATION TECHNOLOGY

Department of Computer Science and Information Technology


Government Graduate College Samanabad Faisalabad

2021
i
CERTIFICATE
This is to certify that Nimra Qayum, Saleha Ashraf bearing Registration No.
2017-GCUF-056010, and 2017-GCUF-0611319 has completed the final project titled
as “Z-cart Multivendor” at the Department of Information Technology, Govt.
Graduate College Samanabad Faisalabad, to fulfill the partial requirement for the
degree of BS – IT.

Supervisor
Muhammad Majid Signature: ____________

Committee Members
Muhammad Majid Signature: _______________

Umair Yousaf Signature: ______________

Hina Zafar Signature: _____________

Kinza Naeem Signature: _____________

Project Coordinator Head of Department

Principal

ii
DECLARATION
The work reported in this project was carried by me under the supervision of
Project Supervisor, Muhammad Majid, at Government College Samanabad
Faisalabad.
We hereby declare that this project and the contents of the project are the
product of my effort.
We further declare that this work has not been submitted for the award of any
other degree.
The institution may take action if the provided information is found inaccurate
at any stage.

Name : Nimra Qayum


Registration No. : 2017-GCUF-056010

Name : Saleha Ashraf


Registration No. : 2017-GCUF-0611319

iii
ACKNOWLEDGEMENT
In the name of ALMIGHTY ALLAH, the most merciful, the most beneficent.
Who is the Lord and Owner of all authorities and capabilities who endowed his great
less on us? He is the entire source of knowledge of wisdom and who blessed us with
the ability to do work. We all grateful to the prophet Muhammad (PBUH) who gave
us the spirit to learn. No doubt in it because of ALMIGHTY ALLAH that today we
can complete our project.

We are also thankful to our honorable Supervisor Muhammad Majid,


Department of Information Technology of Government College University Faisalabad,
for his guidance, encouragement, support, and admirable help. He always encouraged
us to come to our project work. In fact, without his efforts and guidance, we may not
be able to complete our work.

We should like to thanks all the faculty of Information Technology of


Government Graduate College Samanabad Faisalabad for this great support and help
for proper completion of our project work. We should feel it necessary to express our
exclusive love and adoration to our parents and other family members for their support,
encouragement, and tremendous contribution to our project completion.

May all they live long to see our dreams being fulfilled. Ameen!

iv
ABSTRACT
Our project (Z-cart Multivendor) Website that will provide a platform at which
the people belonging to the different profession sold their products online and buy from
the same website these products related directly to daily life such as smartphones,
laptops etc. On other hand people who want to conduct online business sell product
through the online platform have their different portal through which they can manage
their product. Peoples may be allowed to both buy and sell the same commodity in a
same website.

Also the buyer has their own portal through which they can manage their
activities such as search product, place order, giving reviews. Buyer and seller portal
are completely separate from each other, for the ease of manage website Admin has
complete control on buyer and sellers.

v
Table of Contents
Chapter 1 INTRODUCTION ............................................... 1
1.1 Purpose of Project .............................................................................................................. 1
1.2 How it works....................................................................................................................... 1
1.3 Project Scope ...................................................................................................................... 1
1.3.1 Cost ............................................................................................................................... 2
1.3.2 Effort ............................................................................................................................ 2
1.3.3 Time.............................................................................................................................. 2
1.4 Project Planning ................................................................................................................. 2
1.5 Project Modules ................................................................................................................. 3
1.5.1 Admin Dashboard ....................................................................................................... 3
1.5.2 Easy Vendor Sign-Up and Login ............................................................................... 3
1.5.3 Separate Vendor Dashboard ...................................................................................... 3
1.5.4 Buyer Portal ................................................................................................................ 4
1.5.5 Seller portal ................................................................................................................. 4
1.5.6 Search Feature ............................................................................................................ 4
1.5.7 Responsive Behavior ................................................................................................... 4
Chapter 2 BACKGROUND and PROBLEM DEFINITION ............................................ 5
2.1 Background Research........................................................................................................ 5
2.2 Existing Technology ........................................................................................................... 5
2.3.1 Specifications ............................................................................................................... 5
2.3.1 Tools ............................................................................................................................. 5
2.4 Reason for the Project ....................................................................................................... 6
2.5 Objective of the Project ..................................................................................................... 6
2.6 Methodology ....................................................................................................................... 6
Chapter 3 SOFTWARE REQUIREMENT ANALYSIS .................................................. 8
3.1 System Requirement Specification ................................................................................... 8
3.2 Function requirements ...................................................................................................... 8
3.3 Non-functional requirements .......................................................................................... 10
3.3.1 User Friendly ............................................................................................................. 10
3.3.2 Ease to Use ................................................................................................................. 11
3.3.3 Performance .............................................................................................................. 11
3.3.4 Availability ................................................................................................................ 11
3.3.6 Privacy ....................................................................................................................... 11
3.3.7 Quality........................................................................................................................ 11
3.3.8 Security Requirements ............................................................................................. 11

vi
3.3.9 Longevity ................................................................................................................... 11
3.4 Interface Specifications ............................................................................................... 11
3.5 Software and Hardware Requirements ......................................................................... 12
3.5.1 Software Requirements ............................................................................................ 12
3.5.2 Hardware Requirements .......................................................................................... 12
Chapter 4 SYSTEM DESIGN ........................................................................................ 13
4.1 Use Case Diagram ............................................................................................................ 13
4.1.1 Admin Side ................................................................................................................ 13
4.1.2 Vendor Side ............................................................................................................... 13
4.1.3 Buyer Side .................................................................................................................. 14
4.2 System Sequence Diagram .............................................................................................. 18
4.2.1 Admin Side ................................................................................................................ 18
4.2.2 Buyer Side .................................................................................................................. 19
4.2.3 Vendor Side ............................................................................................................... 19
4.2.4 Vendor Visiting a Product............................................................................................ 20
4.4 ER Diagram ...................................................................................................................... 21
4.5 Data Flow Diagram .......................................................................................................... 22
Chapter 5 TESTING AND IMPLEMENTATION ..................................... 23
5.1 Testing Techniques .......................................................................................................... 24
5.1.1 Unit Testing ............................................................................................................... 24
5.1.2 Integration Testing.................................................................................................... 25
5.1.3 System Testing........................................................................................................... 25
5.1.4 Acceptance Testing ................................................................................................... 25
5.1.5 Black Box Testing ..................................................................................................... 25
5.1.6 White Box Testing ..................................................................................................... 25
5.1.7 Grey Box Testing....................................................................................................... 25
5.2 Test Approach .................................................................................................................. 26
5.2.1 Bottom-up Approach ................................................................................................ 26
5.2.2 Top-down approach .................................................................................................. 26
5.3 Test Cases ......................................................................................................................... 26
5.2.1 Test Case: Login........................................................................................................ 27
5.2.2 Test Case: Product posting form ............................................................................. 28
5.2.3 Test Case: Add Categories ....................................................................................... 29
5.2.4 Test Case: Registration Form .................................................................................. 30
5.4 Validation and Verification............................................................................................. 30
5.4.1 Software Validation .................................................................................................. 31

vii
5.4.2 From a testing perspective ....................................................................................... 31
Chapter 6 USER MANUAL ........................................................... 32
6.1 Login Page ........................................................................................................................ 32
6.2 Registration page ............................................................................................................. 33
6.4 Add to Cart ....................................................................................................................... 35
6.5 Sub-categories page ......................................................................................................... 37
6.6 Product Page .................................................................................................................... 38
6.7 Seller Portal ...................................................................................................................... 38
6.8 Admin Portal .................................................................................................................... 41

viii
List of Tables
Table 1 Admin Login................................................................................................................. 15
Table 2 Vendors Login .............................................................................................................. 16
Table 3 Buyers’ Login ............................................................................................................... 17
Table 4 Login ............................................................................................................................ 27
Table 5 Product Posting Form .................................................................................................. 28
Table 6 Add Categories ............................................................................................................ 29
Table 7 Registration Form ........................................................................................................ 30

ix
List of Figures
Figure 1 Software Development Life Cycle ................................................................................ 3
Figure 2 Waterfall Model ........................................................................................................... 6
Figure 3 Use Case Admin Side .................................................................................................. 13
Figure 4 Use Case Vendor Side ................................................................................................ 13
Figure 5 Use Case Buyer Side ................................................................................................... 14
Figure 6 SSD Admin Side .......................................................................................................... 18
Figure 7 SSD Buyer Side ........................................................................................................... 19
Figure 8 SSD Vendor Side ......................................................................................................... 19
Figure 9 SSD Vendor Visiting a Product ................................................................................... 20
Figure 10 ER Diagram ............................................................................................................... 21
Figure 11 Class Diagram ........................................................................................................... 22
Figure 12 Login Page ................................................................................................................ 32
Figure 13 Registration Page ..................................................................................................... 33
Figure 14 Home Page ............................................................................................................... 33
Figure 15 Home Categories...................................................................................................... 34
Figure 16 Posted Products ....................................................................................................... 34
Figure 17 Order Form............................................................................................................... 35
Figure 18 Add To Cart .............................................................................................................. 35
Figure 19 About Us................................................................................................................... 36
Figure 20 User Profile .............................................................................................................. 36
Figure 21 Search a Product ...................................................................................................... 37
Figure 22 Sub Categories Page................................................................................................. 37
Figure 23 Product Page ............................................................................................................ 38
Figure 24 Seller Portal .............................................................................................................. 38
Figure 25 Seller Manage Orders .............................................................................................. 39
Figure 26 Seller Add Product ................................................................................................... 39
Figure 27 Seller Posted Products ............................................................................................. 40
Figure 28 About Us In Seller Portal .......................................................................................... 41
Figure 29 Admin Portal ............................................................................................................ 41
Figure 30 Admin Manage Sub Categories ................................................................................ 42
Figure 31 Admin Add Categories ............................................................................................. 43
Figure 32 Admin Portal Manage Users .................................................................................... 44
Figure 33 Feedback Page ......................................................................................................... 44

x
Chapter 1 INTRODUCTION

1.1 Purpose of Project


The purpose of the Z-Cart Multivendor is to developed a strong relationship
between buyer and seller in the online business. This website has easy to use interface
for both buyer and seller this website is built according to the customer needs buyer can
easily find his product in just few steps. We are providing completely different interface
from other marketplace which is quit complex.

1.2 How it works


This project initially works on the Localhost, here we are using XAMPP server
to make our machine a localhost. We use PHP as server side programming language
and HTML, CSS and JS as client side programming language. First of all, when a user
wants to use this platform he/she should have a username and a password, without a
username and password he/she could not access this website. To get a username or
password one should register himself/herself to the website. Vendor register themselves
as a seller they have a separate portal to manage their stores. Admin of the website can
manage users’ product etc. using his/her separate portal.

1.3 Project Scope


Zcart Multi-vendor serves as a hub where there are millions of products,
relevant to a large number of categories sold by multiple sellers through their stores
which are provided by the Market Place. In current era there are the massive use of the
digital devices people use Smartphone, computers and many digital devices to assist
their regular life, in this era there is a need of such platform that provide facilitation in
human’s daily life style. The online multi-vendor market place is that type of platform
that provides facilitation in daily life. On this platform there are thousands of items
related to the daily life style of a human-being These items are just one click away from
the users. Peoples can visit the website, search for their relevant item, and place the
order.

1
1.3.1 Cost
The cost required in the purposed system is comparatively higher than the
existing systems. Because the previous system works manually.

1.3.2 Effort
Compared to the existing system, the proposed system will provide a better
work environment in which there will be cases of work and the effort required will be
comparatively less than the existing system.

1.3.3 Time
The time required to selling and buying old and new books will be
comparatively less than the existing systems.

1.4 Project Planning


The purpose of this project is to sell and buy old books and medical students
will be able to buy new books online.
This project is supported by Nimara Qayum and Saleha Ashraf and the
Supervisor Muhammad Majid our IT staff Member has supported us in fulfilling the
task of this project. They motivated us to do this project. The supervisor helped us to
develop this project more efficiently. Then we start to develop this project.
The goal of this section is to provide a set of recommendations that will help
you plan appropriately for a successful project. In this section, we use the life cycle
model employed broadly at Microsoft. This model is a combination of iterative and
waterfall life cycle models. In this model, there are five phases whose boundaries define
a sequential set of milestones for the project. The phases, in order of execution, are as
follows:

 Requirements: To make an atmosphere-friendly and user-friendly z-cart


multivendor website through which sellers and users can sell and buy their
goods and products and also able to buy new products.
 Design: Based on the functional requirements, physical design specifications
are created and prototyping is conducted to verify design ideas and investigate
the capabilities.
 Implementation: Using the design and functional specifications, the coding is
done.

2
 Verification: This is the process of testing the product to verify that it performs
according to the specifications.
 Release: After the product has been fully verified it is packed and prepared for
release to Customers.

Figure 1 Software Development Life Cycle

1.5 Project Modules

1.5.1 Admin Dashboard


Admin of the website manage vendors and customers accordingly admin can create
and delete users

1.5.2 Easy Vendor Sign-Up and Login


Website provides the facility to their user to easily sign-up and log-in to their
separate panels

1.5.3 Separate Vendor Dashboard


In the Zcart Multi-vendor Marketplace there are two main type of users first one is
buyers and the second type of the users is vendor who sell their product these both type
of user has different dashboard through which they manage their activities.

3
1.5.4 Buyer Portal
In the buyer portal there is a facility of Cart people search the product place
order and represent their reviews about a specific kind of product.

1.5.5 Seller portal


In the seller portal this is the responsibility of seller to provide the complete
description about a product their prices etc.

1.5.6 Search Feature


Search feature is providing to ease the buyer to search their relevant product.

1.5.7 Responsive Behavior


The intention to provide responsive behavior of the website is that user easily
access website even from there smart phone devices.

4
Chapter 2 BACKGROUND and PROBLEM DEFINITION

2.1 Background Research


There are many online multi-vendor e-commerce store like Daraz, Olx, Amazon whice
were designed using Html, css, php, Javascript, Bootstrap.Our team want to develop a
similar website using Html, css, php, Javascript, database.

ZCart Multi-Vendor is an online web application where the customer can purchase
anything which they want. Through a web browser the customer can search for a
product by its name and price, later can add it to shopping cart and purchase their
product while sitting at home. The user can login using his account details or new
customer can make an account very quickly. They should give the details of their name,
contact number, complete address, email, profile picture.

2.2 Existing Technology


Now a days custumer have to go to the market to buy any product related to
their needs.Sometime customer cannot get their desired product from shops, which
create a problem for customer. Through a zcart multi-vender the customer can buy
anything using his mobile phone, tablet, laptop while sitting at home.

2.3 Area of Study


This section is related to the description of the system specifications and the
tools that were used to design and develop the project.

2.3.1 Specifications
This is a software-based system and definitely, the system will run through a
web browser which must be able to run the system.

2.3.1 Tools
We have used many tools which we had used during the designing and
development of the system like:

 Html
 CSS
 Bootstrap
 Php

5
 Java Script
 Web Browser
 Xampp Server
 Ms. Word

2.4 Reason for the Project


This project is like an Olx website where customer can be bought from the
comfort of home through the Internet. An online Zcart Multivendor is an e-commerce
store on the Internet where customers can browse the catalog and select product of
interest related to their desired. At checkout time, the items in the shopping cart will be
presented as an order. At that time, more information will be needed to complete the
transaction. Users can select many products and those products stored in a cart.

2.5 Objective of the Project


The main objective of the project is to create an online store especially for
medical customer within a city which will allow users to search and purchase a product
based on the title. The selected product is displayed in the cart and the user can order
their product online. The Administrator will have additional functionalities when
compared to the common user.

2.6 Methodology
We have used the “Waterfall Model” for the development of our project.
Waterfall Model is a sequential model that divides software development into pre-
defined phases. Each phase must be completed before the next phase can begin with no
overlap between the phases. Each phase is designed for performing specific activities
during the SDLC phase. It was introduced in 1970 by Winston Royce.

Figure 2 Waterfall Model

6
The sequential phases in the Waterfall model are:

 Requirement Gathering and analysis: All possible requirements of the


system to be developed are captured in this phase and documented in a
requirement specification document.

 System Design: The requirement specifications from the first phase are studied
in this phase and the system design is prepared. This system design helps in
specifying hardware and system requirements and helps in defining the overall
system architecture.

 Implementation: With inputs from the system design, the system is first
developed in small programs called units, which are integrated into the next
phase. Each unit is developed and tested for its functionality, which is referred
to as Unit Testing.

 Integration and Testing: All the units developed in the implementation phase
are integrated into a system after testing each unit. Post integration the entire
system is tested for any faults and failures.

 Deployment of the system: Once the functional and non-functional testing is


done; the product is deployed in the customer environment or released into the
market.

 Maintenance: Some issues come up in the client environment. To fix those


issues, patches are released. Also to enhance the product some better versions
are released. Maintenance is done to deliver these changes in the customer
environment.

7
Chapter 3 SOFTWARE REQUIREMENT ANALYSIS

3.1 System Requirement Specification


System Requirements Specification (abbreviated SRS when need to be distinct
from a Software Requirements Specification SRS) is a structured collection of
information that embodies the requirements of a system.

A business analyst sometimes titled a system analyst is responsible for


analyzing the business needs of their clients and stakeholders to help identify business
problems and propose solutions. Within the systems development life cycle domain,
the BA typically performs a liaison function between the business side of an enterprise
and the information technology department or external service providers.

Software requirements specification establishes the basis for an agreement


between customers and contractors or suppliers (in market-driven projects, these roles
may be played by the marketing and development divisions) on what the software
product is to do as well as what is not expected to do. Software requirements
specification permits a rigorous assessment of requirements before design can begin
and reduces later redesign. It should also provide a realistic basis for estimating product
costs, risks, and schedules.

The software requirements specification document enlists enough and


requirements that are required for the project development. To derive the requirements,
we need to have a clear and thorough understanding of the products to be developed or
being developed. This is achieved and refined with detailed and continuous
communications with the project team and customer till the completion of the software.

3.2 Function requirements


A functional requirement is describing the behavior of the system as it relates
to the system's functionality.
Functional requirements are what the user expects from the software for
example if the application is a bank application that application should be able to create
a new account, update the account, delete an account, etc. functional requirements are
detailed and are specified in the system design. Functional Requirements: specify
the functionality of the system. (E.g. fields in a form).

8
A functional requirement describes what a software system should do Let
me elaborate. An example of a functional requirement would be that a system must send
an email whenever a certain condition is met (e.g. an order is placed, a customer’s sign
up).

 Responsive Behaviour
The goal of responsive design is to build web pages that detect
the visitor's screen size and orientation and change the layout accordingly.
 User Authentication and Password resets
Only the authorize user can access the website
 Runtime notifications through web interface (UI)
Notifications will be sent to all the type of users through email and
web interface (depending on the type of operation).
 Administrators Portal
In the online multi-vendor market place there is a main Admin portal
through which the admin of the website performs the following tasks
 Managing categories
 Managing Brands
 Managing users
 Managing Product Approval
 Buyers Portal
In the Z-cart Multi-Vendor Buyer have their own portal through
which they perform the following task
 Managing Profile
 Managing addresses
 Managing orders
 Managing favourite stores
 Managing Wish lists
 Managing cart
 Giving review for already bought products
 Sellers Portal
A web portal designed for sellers to perform the following tasks

9
 Checking insights of the store through home\dashboard page such as No.
of items,
 Managing Store
 Managing Profile
 Managing address
 Managing orders
 Managing Products
 Activate/Deactivate
 Soft Delete
 Edit Product
 Listing a product
o Product have the following information:
 Product Name
 Product Model
 Description
 Images
 Category
 Brand
 Price
 Quantity

3.3 Non-functional requirements


Typically, non-functional requirements fall into areas such as Non-functional
requirements, these come in two types:

 Performance constraints – what performance is required from the system e.g.


It will update all customer records overnight.
 Development constraints – what restrictions on development will apply e.g.
the system must be available by a certain date.
3.3.1 User Friendly
Our Website (Zcart multi-vendor) has a formal and decent look, does not have
any shocking colors each and every written thing is prominent and well-managed. The
instructions given are easy and have clear meaning. Form instruction is all about to
related form and only performs only that form.

10
3.3.2 Ease to Use
We provide the complete documentation of this project that is helpful for the
users of this project that how to use this product.

3.3.3 Performance
Using this Website in case of Buying/selling, system shall response fast and
relative to the content.

3.3.4 Availability
The system should be available at any time of use so that the users can use it at
any time without any difficulty

3.3.6 Privacy
We provide complete privacy to the contractors. Everything in the project is in
the privacy between the Patient and us. There is no problem with privacy for the Patient.

3.3.7 Quality
The quality of the project is so good everything in its full fill all the requirements
of the Owner of the website and the process is done in a good manner.

3.3.8 Security Requirements


It needs an authentic username and password to secure our system privacy. If
anyone wants to use it or hack it he/she will not allow using the system without an
authentic user name and password.

3.3.9 Longevity
We are using HTML and CSS with JAVASCRIPT and PHP for Database that
is easy, understandable and flexible tools so our system will perform its working for
maximum of its capacity.

3.4 Interface Specifications


The interface specification is a document that captures the details of the
software user interface into a written document. The specification covers all possible
actions that an end-user may perform and all visual, auditory, and other interactive
elements.

3.4.1 Software Quality Attributes


 The Quality of the System is maintained in such a way, that the system is made
user-friendly.

11
 The system quality attributes are assumed as under:
 Accurate and hence reliable.
 Secured.
 Fast speed.
 Compatibility.
3.5 Software and Hardware Requirements
3.5.1 Software Requirements
 Operating System : Windows 2000/XP/8.1/10
 Languages : HTML, PHP, CSS, JavaScript, JQuery
 Backend : MYSQL
 Browser : Opera, Mozilla Fire Fox, Google Chrome

3.5.2 Hardware Requirements


 PC : Pentium IV
 Processor : 1 GHz CPU
 RAM : 512 MB
 Hard Disk : 5 GB
 Internet : Compulsory

12
Chapter 4 SYSTEM DESIGN
4.1 Use Case Diagram
Use case Diagrams of our website are given below

4.1.1 Admin Side

Log-in

Manage categ ories

Manage users

Admin

Manage products

User product

Log-out

Figure 3 Use Case Admin Side

4.1.2 Vendor Side

sign-up

sign-in

manage profile

manage product

manage store
vendors
manage buyers

manage order

sign-out

Figure 4 Use Case Vendor Side

13
4.1.3 Buyer Side
Sign-Up

log-in

Manage profile

search products

buyers Place orders

Manage cats

Log-out

Figure 5 Use Case Buyer Side

14
4.1.4 Usage Scenarios
Table 1 Admin Login

Use Case Title Admin Login


Use Case Id 1
Requirement 4
Id
Description: this is a use case of admin portal an admin can manage the work
flow of the whole website through admin portal it can add/delete users, manage
products.

Pre-Conditions:
1. Admin must have a username and password to log-in to the portal
2. The database should be in online form to provide access
Task Sequence Exceptions
1. Admin login
2. Manage users
3. Manage categories
4. Manage products
5. Logout
Post Conditions: admin login successful
Unresolved issues:
Authority: administrator
Modification history: 1.0
Author: Nimra Qayum, Saleha Ashraf
Description:

15
Table 2 Vendors Login

Use Case Title Vendor Login


Use Case Id 2
Requirement 6
Id
Description: this is a use case of vendors login through the vendor portal vendor
can manage their stores, product, and buyers etc.
Pre-Conditions:
1. All must-required information about the new vendors should be available.
2. The database should be in online form to provide access
Task Sequence Exceptions
1. Vendor sign-up
2. Vendor log-in
3. Manage store
4. Manage products
5. Manage buyers
6. Log-out
Post Conditions: vendor login successful
Unresolved issues:
Authority: vendors
Modification history: 1.0
Author: Nimra Qayum, Saleha Ashraf
Description:

16
Table 3 Buyers’ Login

Use Case Title buyers Login


Use Case Id 3
Requirement 5
Id
Description: this is a use case of buyer portal through this portal the buyer search
the product, place order and manage their cart etc.
Pre-Conditions:
3. All must-required information about the new buyers should be available.
4. The database should be in online form to provide access
Task Sequence Exceptions
7. buyer sign-up
8. buyer log-in
9. Manage profile
10. Search products
11. Manage cart
12. Log-out
Post Conditions: buyers login successful
Unresolved issues:
Authority: buyers
Modification history: 1.0
Author: F190214B4F (MC180402525)
Description:

17
4.2 System Sequence Diagram
4.2.1 Admin Side

Figure 6 SSD Admin Side

18
4.2.2 Buyer Side

Figure 7 SSD Buyer Side


4.2.3 Vendor Side

Figure 8 SSD Vendor Side

19
4.2.4 Vendor Visiting a Product

Figure 9 SSD Vendor Visiting a Product

20
4.4 ER Diagram

Figure 10 ER Diagram

21
4.5 Data Flow Diagram

Figure 11 Class Diagram

22
Chapter 5 TESTING AND IMPLEMENTATION
Software testing is a critical element of software quality assurance and
represents the ultimate review of specification, design, and code generation. Testing is
an internal part of any system or project. If a system is implemented without being
tested it may lead to erroneous working and dissatisfaction on part of the customer. It
will also prove disastrous to the reputation of the organization or the person who
developed the system and lead to a loss in business.

Keeping all these things in view, we left no stone unturned in testing our
systems. It was tested keeping in view the different possibilities on part of the user. As
human beings are prone to commit errors under different working conditions, we had
to keep our vigil on different possibilities that can occur on part of the user. The system
was tested for validation, functional implementation, and navigation.

Validation Testing
The user must log in to the system with his/her unique login name and password.
The user must enter all mandatory fields. If he/she fails to do so then a warning message
is issued.

Functional Testing
The entire system was divided into sub-modules. Adding/Updating user
Information in the database is done.

Navigational Testing
The system was tested so that all the pages are properly accessible with their
respective links.

To uncover the errors in the system we have done testing as follows:

1. Input Checking
In this phase, we tested the validation process only. When users enter the data
in the given text box or grids, the proper input format is checked. If entry required
numeric data user is bounded to enter only numeric. If text (alphanumeric)data, then
the user is bounded to enter text data only also check for null values. Like this, all entries
of all input areas are tested.

23
2. Condition Testing
Condition testing is a method that exercises the logical condition contained in
the program module. All relational statements were individually examined and tested.
Extreme case values are given for testing.

3. Loop Testing
Loops are cornerstones for the vast majority of all implemented in software.
Each loop is examined separately. Its endpoint values were given and the terminating
condition each case tested.

4. Output Testing
The First step of testing is checking how friendly it is. Then its accuracy is
checked, that is whether it can be present all relevant information, it can report missing
less, data, etc.

5. Acceptance Testing
In this type, we run the system live data by the actual user.

5.1 Testing Techniques


Analyze the working of the developed system after implementation is known as
testing. There are few techniques we use they include:

 Unit Testing
 Integration Testing
 System Testing
 Acceptance Testing
 Black Box Testing
 White Box Testing
 Grey Box Testing

5.1.1 Unit Testing


It is a type of testing that may occur on the completion of every single module
of your system. We also test every single module stand-alone making sure the proper
working of the module.

24
5.1.2 Integration Testing
Integration testing is a type of testing that occurs when two or more modules
are combined. This is necessary because if two modules are not working properly
together then your system fails. Hence we test multiple probability modules for the
proper working of the system.

5.1.3 System Testing


Involves in-house testing of the entire system before delivery to the user. It aims
to satisfy the user the system meets all requirements of the client's specifications.

5.1.4 Acceptance Testing


It is pre-delivery testing in which the entire system is tested at the client's site
on real-world data to find errors.

5.1.5 Black Box Testing


The technique of testing without having any knowledge of the interior working
of the application is black-box testing. The tester is oblivious to the system architecture
and does not have access to the source code. Typically, when performing a black-box
test a tester will interact with the system user’s interface by providing inputs and
examining outputs without knowing how and where the inputs are worked upon.

5.1.6 White Box Testing


White box testing is the detailed investigation of the internal logic and structure
of the code. White box testing is also called glass testing or open box testing. To
perform white box testing on an application, the tester needs to possess knowledge of
the internal working of the code. The tester needs to have a look inside the source code
and find out which unit/chunk of the code is behaving inappropriately.

5.1.7 Grey Box Testing


Grey Box Testing is a technique to test the application with limited knowledge
of the internal workings of an application. In software testing, the term more you know
the better carries a lot of weight when testing an application.

Mastering the domain of a system always gives the tester an edge over someone
with limited domain knowledge. Unlike black-box testing, where the tester only tests
the application’s Customer interface, in Grey box testing, the tester has access to design

25
documents and the database. Having this knowledge, the tester can better prepare test
data and test scenarios when making the test plan.

5.2 Test Approach


Testing can be done in two ways:
5.2.1 Bottom-up Approach
Testing can be performed starting from the smallest and lowest level modules
and proceeding one at a time. For each module in bottom-up testing, a short program
executes the module and provides the needed data so that the module is asked to
perform the way it will when embedded within the larger system. When bottom-level
modules are tested attention turns to those on the next level that use the lower level ones
they are tested individually and then linked with the previously examined lower-level
modules.

5.2.2 Top-down approach


This type of testing starts from upper-level modules. Since the detailed activities
usually performed in the lower level routines are not provided stubs are written. A stub
is a module shell called by upper-level module and that when reached properly will
return a message to the calling module indicating that proper interaction occurred. No
attempt is made to verify the correctness of the lower-level module.

5.3 Test Cases


A test case is a set of test inputs, execution conditions, and expected results
developed for a particular objective, such as to exercise a particular program path or to
verify compliance with a specific requirement. A test case could simply be a question
that you ask of the program. The point of running the test is to gain information, for
example, whether the program will pass or fail the test. The test case is the cornerstone
of Quality Assurance whereas they are developed to verify the quality and behavior of
a product.

26
5.2 Test Cases
5.2.1 Test Case: Login
Table 4 Login

Test Case #: 1 Test Case Name: Login

System: Login Sub System: Login

Designed By: Nimra Qayum Design Date: 25/05/2021

Executed By: Saleha Ashraf Execution Date: 26/05/2021

Short Description: Enter username and password in the login form and press login
button.

Pre-Condition: Username and Password

Operating Windows 10 Professional Environment: Apache server


System:

Software Xampp Local Host server Chrome browser, SQL Database and Windows
Tools & Operating System.
Technologies
with version

S Strategy Action Input Actual Expected Status Remarks


t (Test-to Result / Result/ (Pass/Fail)
e Pass / System Expected
p (Test-to- Response System
s Fail) Response

1 T-T-P Username admin Successfully Successfully Pass Test is


and login login pass
admin
password

2 T-T-F Username admin Not login Not login Pass Test is


and pass
admiin
password

27
5.2.2 Test Case: Product posting form
Table 5 Product Posting Form

Test Case #: 2 Test Case Name: Product Posting form

System: Vendor Portal Sub System: Manage Product

Designed By: Saleha Ashraf Design Date: 16/06/2021

Executed By: Nimra Qayum Execution Date: 19/06/2021

Short Post product


Description:

Pre-Condition: Vendor is login.

Operating Windows 10 pro Environment: Apache server


System:

Software Tools & Xampp Local Host server Chrome browser, SQL Database and Windows
Technologies Operating System
with version

Steps Strategy Action Input Actual Expected Status Remarks


(Test-to- Result / Result/ (Pass /
Pass) / System Expected Fail)
(Test-to- Response System
Fail) Response

1 T-T-P Product Ads Successfully Successfully Pass Test is


Post Detail posted pass
Posted

2 T-T-F Product Ads Error Error Pass Test is


Post Details Message Message Pass

28
5.2.3 Test Case: Add Categories
Table 6 Add Categories

Test Case #: 3 Test Case Name: Add new Category

System: Admin Panel Sub System: Admin Panel

Designed By: Nimra Qayum Design Date: 21/06/2021

Executed By: Saleha Ashraf Execution Date: 22/06/2021

Short Description: Add new Categories in database.

Pre-Condition: Admin is login.

Operating System: Windows 10 pro Environment: Apache server

Software Tools & Xampp Local Host server Chrome browser, SQL Database and Windows
Technologies with Operating System.
version

Steps Strategy Acti Input Actual Expected Status Remarks


(Test-to- on Result / Result/ (Pass /
Pass) / System Expected
Fail)
(Test-to- Response System
Fail) Response

1 T-T-P Add Category Successfully Successfully Pass Test is


new Detail data enter. data enter. pass
Cate.

2 T-T-F Add Category Show error Error shown Pass Test is


new Detail pass
Cate.

29
5.2.4 Test Case: Registration Form
Table 7 Registration Form

Test Case #: 4 Test Case Name: Registration form

System: Registration Form Sub System: Registration Form

Designed By: Saleha Ashraf Design Date: 20/06/2021

Executed By: Nimra Qayum Execution Date: 21/06/2021

Short Description: Test Registration form

Operating System: Windows 10 pro Environment: Apache Server

Software Tools & Xampp Local Host server Chrome browser, SQL Database and Windows
Technologies with Operating System.
version

Steps Strategy Action Input Actual Result Expected Status Remarks


/System Result/ (Pass/Fail)
(Test-to-
Response Expected
Pass) /
System
(Test-to-
Response
Fail)

1 T-T-P User Detail Successful Successfully Pass Test is


Detail Reg. Reg. pass

1 T-T-P User Detail Not Reg. Not Reg. Pass Test is


Detail pass

5.4 Validation and Verification


The system has been tested and implemented successfully and thus ensured that all the
requirements as listed in the software requirements specification are completely
fulfilled. In case of erroneous input, corresponding error messages are displayed.

In software project management, software testing, and software engineering,


verification and validation (VandV) is the process of checking that a software system
meets specifications and that it fulfills its intended purpose. It may also be referred to

30
as software quality control. It is normally the responsibility of software testers as part
of the software development lifecycle.

Validation checks that the product design satisfies or fits the intended use (high-
level checking), i.e., the software meets the user requirements. This is done through
dynamic testing and other forms of review.

Verification and validation are not the same things, although they are often
confused. Boehm succinctly expressed the difference between

Verification: Are we building the product, right?

Validation: Are we building the right product?

According to the Capability Maturity Model (CMMI-SW v1.1),

Software Verification: The process of evaluating software to determine whether


the products of a given development phase satisfy the conditions imposed at the start of
that phase [IEEE-STD-610].

5.4.1 Software Validation


The process of evaluating software during or at the end of the development
process to determine whether it satisfies specified requirements [IEEE-STD-610].

In other words, software verification is ensuring that the product has been built
according to the requirements and design specifications, while software validation
ensures that the product meets the user's needs and that the specifications were correct
in the first place. Software verification ensures that "you built it right" Software
validation ensures that "you built the right thing". Software validation confirms that the
product, as provided, will fulfill its intended use.

5.4.2 From a testing perspective


 Fault – wrong or missing function in the code.
 Failure – the manifestation of a fault during execution.
 Malfunction – according to its specification the system does not meet its
specified functionality.

31
Chapter 6 USER MANUAL
6.1 Login Page
After entering all the required data click the register button to register. Now you
can log in to the Website. The login page is used to log in to the website.

The login page will appear as below.

Figure 12 Login Page

32
6.2 Registration page
If you are a new user, you can register using the registration page or if you are
already a user you can log in to purchase a product. A user should enter all the required
field information. If he didn’t fill all the fields he cannot create an account.

The register page will appear as below.

Figure 13 Registration Page

6.3 Homepage
When we run the Zcart multivendor Website first login page is displayed. If you
have an account, then you can login to the website otherwise you make an account for
login. After login the home page appear.

The home page will appear as below.

Figure 14 Home Page

33
The home page categories will appear as below.

Figure 15 Home Categories


The home page posted product page will appear as below.

Figure 16 Posted Products

34
The place order form will appear as below.

Figure 17 Order Form

6.4 Add to Cart


The user can add the product to a shopping cart by entering the quantity and
clicking the add to shopping cart button. The quantity value should always be positive.
The remove button is added so that if a user wants to remove a product user can remove
it easily.

The Add to cart page form will appear as below.

Figure 18 Add To Cart

35
The About us page will appear as below.

Figure 19 About Us
The Profile page will appear as below.

Figure 20 User Profile


To search for a product, the user can use the search option. By using the search box, a
user can search for new product.

36
Figure 21 Search a Product

6.5 Sub-categories page


Through this page the customer can select any categories from home page then
select sub-categories for search any product.

The Sub-categories page will appear as below.

Figure 22 Sub Categories Page

37
6.6 Product Page
After selecting any category from homepage then select any sub-category the
related products of categories show in this series.

The Product page will appear as below.

Figure 23 Product Page

6.7 Seller Portal


In seller portal the seller can sale anything through their store. They add product in their
store for sailing. The menu of seller portal is consist on home ,posted product ,about us, signout.

The Seller portal will appear as below.

Figure 24 Seller Portal

38
The Manage order page of homepage in seller portal will appear as below.

Figure 25 Seller Manage Orders


The Manage Product page of homepage in seller portal will appear as below.

Figure 26 Seller Add Product


The View review page of homepage in seller portal will appear as below.

39
The Posted product page in seller portal will appear as below.

Figure 27 Seller Posted Products


The About us page in seller portal will appear as below.

40
Figure 28 About Us In Seller Portal

6.8 Admin Portal


In admin the admin of this website can manage everything of seller and buyer
portal.

The menu of admin portal consist of Hompage, profile,about us,signout.

The Admin Portal will appear as below.

Figure 29 Admin Portal


The Manage sub-categories page in Admin portal will appear as below.

41
Figure 30 Admin Manage Sub Categories
The Manage categories page in Admin portal will appear as below

42
Figure 31 Admin Add Categories

The Manage-user page in Admin portal will appear as below

43
Figure 32 Admin Portal Manage Users
The View Feedback page in Admin portal will appear as below

Figure 33 Feedback Page

44

You might also like