Greedy Snake Game

Project Report of Minor Project

BACHELOR OF TECHNOLOGY

(COMPUTER SCIENCE AND ENGINEERING)

Session (2018-2022)

Submitted To: Submitted By:

Ms Varsha Mehta Riya Soni

Assist. Professor Roll No. 182904

CSE Department CSE Final Year

CH. DEVI LAL STATE INSTITUTE OF ENGINEERING

AND TECHNOLOGY PANNIWALAMOTA (SIRSA)

1
 CANDIDATE'S DECLARATION

I, hereby declare that the proposed work presented in this project synopsis entitled as "Snake
Game" Dr. Sanjay Dahiya, Head of Department and Miss. Varsha, Assistant Professor at the
Department of Computer Science and Engineering, Ch. Devi Lal State Institute of Engineering
and Technology, Panniwala Mota (Sirsa), Haryana, India – 125077. It is further certified that this
complete project has been checked by Plagiarism Software and after checked by plagiarism
software, the similarity index is as per University norms. It is also certified that no part of this
project work has been submitted, either in part or full for any other degree of Chaudhary Devi Lal
University, or any other University/Institution.

Riya Soni

Roll No. 182904

2
 CERTIFICATE FROM SUPERVISOR

This is to certify that the project entitled “Snake Game” being submitted by Riya Soni, Roll
No: 182904 in the partial fulfillment of the requirements for the award of degree of BACHELOR
OF TECHNOLOGY IN COMPUTER SCIENCE & ENGINEERING, Chaudhary Devi Lal
University, SIRSA has been carried out by her under my supervision. I wish her all success.

Date:

Place: Supervisor:

3
 Abstract

Snake game is a computer action game, whose goal is to control a snake to move and collect food
in a map. In this paper we develop a controller based on movement rating functions considering
smoothness, space, and food. Scores given by these functions are aggregated by linear weighted
sum, and the snake takes the action that leads to the highest score.

To find a set of good weight values, we apply an evolutionary algorithm. We examine several
algorithm variants of different crossover and environmental selection operators. Experimental
results show that our design method is able to generate smart controllers.

4
 ACKNOWLEDGEMENT

I am thankful to my faculty members for their proper guidance and valuable suggestions. I am
also greatly thankful to Dr. Sanjay Dahiya, the head of the Department of Computer Science and
Engineering, Miss. Varsha and the Director Principal for giving me an opportunity to learn and
do this project. If not for the above-mentioned people, my project would never have been
completed in such a successfully manner. I once again extend my sincere thanks to all of them.

Riya Soni(182904)

5
 TABLE OF CONTENTS

Page No.
Page Title........................................................................................................................................................1

Declaration.....................................................................................................................................................2

Certificate........................................................................................................................................................3

Abstract...........................................................................................................................................................4

Acknowledgement.......................................................................................................................................5

Requirements……………………………………………………………. 7

Technologies…………………………………………………………….. 8

Objectives of Project…………………………………………………….. 10

Aims and Scope of Project…………………………………………… …. 11

Project Introduction………………………………………………………. 12

Requirement Analysis of Project…………………………………………. 14

Data flow diagram………………………………………………………… 20

Coding………………………………………………………………… 22

Software Testing……………………………………………………… 27

Maintenance……………………………………………………………… 38

Conclusion………………………………………………………………… 39

References…………………………………………………………………. 40

Screenshots………………………………………………………………… 41

6
 REQUIREMENT OF PROJECT

HARDWARE REQUIREMENTS:-
• Intel Core i3 or latest Processors
• 2GB or 4GB RAM
• 1 Android Device
• 4GB Disk Space
• Monitor Resolution of 1024 x 768 or higher

SOFTWARE REQUIREMENTS:-
• Visual Studio IDE

LANGUAGES USED:-
• HTML5
• CSS3
• Java Script
OPERATING SYSTEM:-
• Windows 7, 8 or Latest x64 bit
• Mac OS
• Linux Ubuntu

VIRTUAL ENVIRONMENT:-
• PC Emulator on windows

7
 TECHNOLOGIES AND LANGUAGES

HTML:-

HTML stands for Hyper Text Markup Language. It is used to design web pages using markup
language. HTML is the combination of Hypertext and Markup language. Hypertext defines
the link between the web pages. Markup language is used to define the text document within
tag which defines the structure of web pages. HTML 5 is the fifth and current version of
HTML. It has improved the markup available for documents and has introduced application
programming interfaces(API) and Document Object Model(DOM).

Features:

• It has introduced new multimedia features which supports audio and video controls
by using <audio> and <video> tags.
• There are new graphics elements including vector graphics and tags.
• Enrich semantic content by including <header> <footer>, <article>, <section> and
<figure> are added.
• Drag and Drop- The user can grab an object and drag it further dropping it on a
new location.
• Geo-location services- It helps to locate the geographical location of a client.
• Web storage facility which provides web application methods to store data on web browser.
• Uses SQL database to store data offline.
• Allows to draw various shapes like triangle, rectangle, circle, etc.
• Capable of handling incorrect syntax.

CSS:-

CSS stands for Cascading Style Sheets. It is a style sheet language which is used to describe
the look and formatting of a document written in markup language. It provides an additional
feature to HTML. It is generally used with HTML to change the style of web pages and user
interfaces. It can also be used with any kind of XML documents including plain XML, SVG
and XUL. CSS is used along with HTML and JavaScript in most websites to create user
interfaces for web applications and user interfaces for many mobile applications.

FRAMEWORK:-
JavaScript:-

JavaScript (js) is a light-weight object-oriented programming language which is used by

several websites for scripting the webpages. It is an interpreted, full-fledged programming
language that enables dynamic interactivity on websites when applied to an HTML document.

8
It was introduced in the year 1995 for adding programs to the webpages in the Netscape Navigator
browser. Since then, it has been adopted by all other graphical web browsers. With JavaScript,
users can build modern web applications to interact directly without reloading the page every time.
The traditional website uses js to provide several forms of interactivity and simplicity.

9
 OBJECTIVES

The game is similar to snake on mobile phones (which is similar to a game played on Unix over 30
years ago), but with some ‘improvements’.

The game is played by one player, who has the objective of obtaining the highest score possible.
The player is in control of a snake which is constantly moving around a square field of cells.

The length of the snake is a whole number of cells. At any time, the snake moves in one of the 4
directions, parallel to a side of the square, and the player can change the direction using the 4 arrow
keys of the keyboard.

If the snake crashes into a side, or into itself, then it is dead, and the game stops. Also in the field is
a single piece of food.

When the head of the snake hits this, the food is eaten, and the snake becomes one cell longer. This
event increases the score of the player.

At the same time, a new piece of food is placed in a randomly chosen cell somewhere in the field,
which was previously clear (empty).

The game has a score message bar, informing the player what is the current score, and also a single
message which changes from time to time. For example, when food is eaten the player is informed
how much score was just obtained, and when the snake crashes a suitable message is shown.

10
 AIM OF THE PROJECT

This Project is developed to help me to learn about the framework JavaScript and designing
using XML and Js from their basic capabilities to build a complete working Game from scratch.
Further, it gives insight about how GUI interacts with user. Also this game is helpful to users by
this we can easily get rid from stress.

SCOPE OF THE PROJECT

Snake game is an interesting JavaScript project for beginners. Snake game is a single-player game,
which we’ve been playing for a very long time. The game mainly consists of two components –
snake and fruit.

And we just need to take our snake to the food so that it can eat and grow faster and as the number
of fruits eaten increases, the length of snake increases which makes the game more interesting.

While moving if the snake eats its own body, then the snake dies and the game ends. Now let’s see
how we can create this.

11
 INTRODUCTION OF PROJECT

The game is similar to snake on mobile phones (which is similar to a game played on Unix over 30
years ago), but with some ‘improvements’. The game is played by one player, who has the
objective of obtaining the highest score possible.

The player is in control of a snake which is constantly moving around a square field of cells. The
length of the snake is a whole number of cells.

At any time, the snake moves in one of the 4 directions, parallel to a side of the square, and the
player can change the direction using the 4 arrow keys of the keyboard.

If the snake crashes into a side, or into itself, then it is dead, and the game stops. Also in the field is
a single piece of food. When the head of the snake hits this, the food is eaten, and the snake
becomes one cell longer.

This event increases the score of the player. At 2 the same time, a new piece of food is placed in a
randomly chosen cell somewhere in the field, which was previously clear (empty).

The game has a score message bar, informing the player what is the current score, and also a single
message which changes from time to time.

For example, when food is eaten the player is informed how much score was just obtained, and
when the snake crashes a suitable message is shown. The player can make the game go slower or
faster, and can alter the speed during the game, by pressing ‘s’ to slow down and ‘f’ to speed up.

The score obtained when a piece of food is eaten is proportional to the speed setting. The game can
also be paused and resumed by pressing ‘p’ and ‘r’ respectively. The game will be in a paused state
when it starts.

The speed controller can be placed in interactive mode by the player pressing ‘i’ – this enables the
player to see the current speed and also alter it via buttons.

At any time, the player can end the game and start a new one, simply by pressing ‘a’ on the
keyboard. The most common use of this will be after the snake has crashed, so as to continue
playing with a new game.

When the snake is dead, the player has the option to ‘cheat’ by making it come back to life so play
can continue.

However, this costs the player half of his or her score. The cheat feature is invoked when the player
presses ‘c’ on the keyboard.

12
The player has the option of enabling trees to appear in the field. This feature is toggled on and off
by pressing ‘t’ on the keyboard.

When trees become enabled, a single tree appears in a randomly chosen clear cell. Then, each time
the food is eaten, another tree appears somewhere, and so on. This makes the game more
interesting, because the snake will die if it crashes into a tree.

The game is thus more difficult, and so if trees are enabled when the food is eaten, the score
obtained is multiplied by the number of trees in the field at the time.

When the trees feature is toggled off, all the trees vanish. Each time the snake crashes into
something, it will not die immediately. Instead, a ‘crash countdown’ begins, and reduces by one
each move time of the game.

The player sees this count down via the score message bar. If the snake is moved away before the
count down reaches zero, it has escaped death.

13
 REQUIREMENT ANALYSIS AND FEASIBILITY STUDY

Requirement analysis is significant and essential activity after elicitation. We analyze, refine, and
scrutinize the gathered requirements to make consistent and unambiguous requirements. This
activity reviews all requirements and may provide a graphical view of the entire system. After
the completion of the analysis, it is expected that the understandability of the project may
improve significantly. Here, we may also use the interaction with the customer to clarify points
of confusion and to understand which requirements are more important than others.

The various steps of requirement analysis are shown in fig:

Why is system analysis necessary?

System analysis is an important activity that takes place when we are building new information
systems or changing existing ones. But why are special activities (such as system analysis)
needed to build good information systems? Why don’t these things happen as matter of course in
an organization? To answer these questions you have to consider what must be done to build
complex computer-based information systems. Basically, it is necessary to set up right
procedures to ensure that all the organization’s personnel have all the data needed for. To do this,
there are numerous things to be done. Equipment must be chosen and new procedures designed.

14
Programs must be written to support these procedures on the equipment. The systems are often
made up many interrelated tasks. Changes to any one of these tasks or additions of new tasks can
affect existing ones. It is therefore necessary to spend considerable time to understand the system
and its problems properly. Only after developing a good understanding does it becomes possible
to propose useful.
The investigation into system operation and possible changes to the system is called system
analysis. Once system analysis is completed, system design commences. System analysts use the
understanding of the existing system and its problem to design eventually build a better system.
In addition, systems analysts must also determine what users may require of a new system. Thus
during analysis they may make enquires.

Feasibility is defined as the practical extent to which a project can be performed successfully.
To evaluate feasibility, a feasibility study is performed, which determines whether the solution
considered to accomplish the requirements is practical and workable in the software.

Information such as resource availability, cost estimation for software development, benefits of
the software to the organization after it is developed and cost to be incurred on its maintenance
are considered during the feasibility study.
The objective of the feasibility study is to establish the reasons for developing the software that
is acceptable to users, adaptable to change and conformable to established standards. Various
other objectives of feasibility study are listed below.

• To analyze whether the software will meet organizational requirements.

• To determine whether the software can be implemented using the current technology and
within the specified budget and schedule
To determine whether the software can be integrated with other existing software.

15
 Feasibility Study Process

Feasibility study comprises the following steps:-

• Information assessment: Identifies information about whether the system helps in achieving
the objectives of the organization. It also verifies that the system can be implemented using new
technology and within the budget and whether the system can be integrated with the existing
system.

Information collection: Specifies the sources from where information about software can be
obtained. Generally, these sources include users (who will operate the software), organization
(where the software will be used), and the software development team (which understands user
requirements and knows how to fulfill them in software).

Report writing: Uses a feasibility report, which is the conclusion of the feasibility study by the
software development team. It includes the recommendations whether the software
development should continue. This report may also include information about changes in the
software scope, budget, and schedule and suggestions of any requirements in the system.

General information: Describes the purpose and scope of feasibility study. It also describes
system overview, project references, acronyms and abbreviations, and points of contact to be
used. System overview provides description about the name of the organization responsible for
the software development, system name or title, system category, operational status, and so on.

Management summary: Provides the following information.

• Environment: Identifies the individuals responsible for software development. It provides
information about input and output requirements, processing requirements of the software and
the interaction of the software with other software. It also identifies system security
requirements and the system’s processing requirements
• Current functional procedures: Describes the current functional procedures of the existing
system, whether automated or manual. It also includes the data-flow of the current system and
the number of team members required to operate and maintain the software.
• Functional objective: Provides information about functions of the system such as new
services, increased capacity, and so on.

16
 • Performance objective: Provides information about performance objectives such as reduced
staff and equipment costs, increased processing speeds of software, and improved controls.

Types of Feasibility:-

Various types of feasibility that are commonly considered include technical feasibility,
operational feasibility, and economic feasibility.

SYSTEM DESIGN

The design phase focuses on the detailed implementation of the system recommended in the
feasibility study. Emphasis is on translating performance specifications into design specifications.
The design phase is a transition from a user-oriented document (system proposal) to a document
oriented to the programmers or database personnel System design phase follows system analysis
phase. Design is maintaining record proof design divisions and providing a blue print or the
implementation phase. Design is the bridge between system analysis and system implementation.
The design is the solution, a “how to “approach to the creation of a new system. This is composed
of several steps. It provides the understanding and procedural details necessary for implementing
the system recommended in the feasibility study. Design goes thru logical and physical stages of
development; logical design reviews the present physical system, prepares input and output

17
specifications, details the implementation plan and prepares a logical design walk-through.
During this phase the analyst does the following:

• Schedules design activities.

• Determine the data inputs.
• Draws a model of the new system using data flow.
• Defines the data requirements with a data dictionary.
• Writes program specifications.
• Identifies and orders any hardware or software that the system design
phase would need.

Objectives of Design
System design is like a blue print for a building, it specifies all the features that are to be in the
finished product. Design states how to accomplish objectives determine in the analysis phase.
The major objectives of system design are to develop the best possible design as per the
requirements and working environment for operating the system:
• Completeness
• Correctness
• Efficiency
• Consistency
• Maintainability
• Cost
• Security
•
Process of Design
The design phase focuses on the implementation of the system recommended in the
feasibility study. System design can be of two types:
• Logical Design
• Physical Design

18
Logical Design
Logical design concerns with the specifications of major features of the system that would
meet the objectives. The main components of logical design are: The logical design includes:

• Reviews the current system.

• Prepares output Specification.
• Prepare input Specification.
• File Specification.
• Procedure Specification.
• Control Specification.
• Specifies the implementation plans.
• Prepares a logical design walkthrough.
• Review benefits, costs, target dates, and system constraint.

Physical Design

The physical design, which follows the logical design, produces actual program software, files
and a working system. The physical design produces the working system by defining the design
specifications that tell programmers exactly what the proposed system must do. The physical
design includes:
• Specify the Input /Output media.
• Design the data base.
• Design the programs.
• Specify backup procedures.
• Make a test plan.
• Specify any new hardware/software.
• Specify implementation plan.
• Prepare a conversion schedule and a target date.

19
 Data Flow Diagrams:

The DFD takes an input-process-output view of a system i.e. data objects flow into the software,
are transformed by processing elements, and resultant data objects flow out of the software. Data
objects represented by labeled arrows and transformation are represented by circles also called as
bubbles. DFD is presented in a hierarchical fashion i.e. the first data flow model represents the
system as a whole. Subsequent DFD refine the context diagram (level 0 DFD), providing
increasing details with each subsequent level.
The DFD enables the software engineer to develop models of the information domain &
functional domain at the same time. As the DFD is refined into greater levels of details, the
analyst performs an implicit functional decomposition of the system. At the same time, the DFD
refinement results in a corresponding refinement of the data as it moves through the process that
embodies the applications.
A context-level DFD for the system the primary external entities produce information for use by
the system and consume information generated by the system. The labeled arrow represents data
objects or object hierarchy.

20
 Rules For DFD

• Fix the scope of the system by means of context diagrams.

• Organize the DFD so that the main sequence of the actions
• Reads left to right and top to bottom.
• Identify all inputs and outputs.
• Identify and label each process internal to the system with Rounded circles.
• A process is required for all the data transformation and Transfers. Therefore, never
connect a data store to a data Source or the destinations or another data store with just
a Data flow arrow.
• Do not indicate hardware and ignore control information.
• Make sure the names of the processes accurately convey everything the process
is done.
• There must not be unnamed process.
• Indicate external sources and destinations of the data, with Squares.
• Number each occurrence of repeated external entities.
• Identify all data flows for each process step, except simple Record retrievals.

21
 CODING

The goal of coding phase is to translate the design of the system into a code in a given
programming language. Hence during coding, the focus should be on developing programs that
are easy to read and understand, and not simply on developing programs that are easy to write.
Due to security purpose, it’s not allowed that we can show off the coding, so we are not
authorized to include coding in our project.
Coding Conventions

This means program construction with procedural specification has finished and the coding for
the program begin:
• Once the design phase was over, coding connected.
• Coding is natural consequence of design.
• Coding steps translate a detail design representation of the software into a programming
language realization.
• Main emphasis while coding was on style so that the end result was an optimized code.

Coding Style

The structured programming method was used in all the modules of the project. It
incorporated the following features:
• The code has been written so that the definition and implementation of each function
is contained in one file.
• A group of related function was clubbed together in one file to include it when needed
and save us from the labor of writing it again and again.

22
23
24
25
26
27
28
 SOFTWARE TESTING

Software testing is an investigation conducted to provide information about the quality of the
product or service under test. Software testing also provides an objective, independent view of
the software to allow the business to appreciate and understand the risks of software
implementation. Test techniques include, but are not limited to, the process of executing a
program or application with the intent of finding software bugs (errors or other defects).Software
Testing can also be stated as the process of validating and verifying that a software
program/product:
• Meets the business and technical requirements that guided its design and development.
• Works as expected.
Testing objective

The objective of software testing is to check:

Whether the application is working as expected without any errors or bugs (Functionality)
• Whether the application is working as expected without any errors or bugs (Functionality)
• Whether the performance of the application is as expected & meets the need.

Scope

A primary purpose of testing is to detect software failures so that defects may be discovered and
corrected. Testing cannot establish that a product functions properly under all conditions but can
only establish that it does not function properly under specific conditions.

The scope of software testing often includes examination of code as well as execution of that
code in various environments and conditions as well as examining the aspects of code: does it do
what it is supposed to do and do what it needs to do. In the current culture of software
development, a testing organization may be separate from the development team. There are
various roles for testing team members.

Information derived from software testing may be used to correct the process by which software
is developed.
29
Functional & Non-Functional Testing

Functional testing refers to activities that verify a specific action or function of the code. These
are usually found in the code requirements documentation, although some development
methodologies work from use cases or user stories. Functional tests tend to answer the question.

of “can the user do this “or “does this particular feature work”. It attempts to find the error in the
following categories:
• Incorrect or missing function.
• Interface errors.
• Errors in data structures or external database access.
• Performance errors.
• Initialization and termination error.
Non-functional testing refers to aspects of the software that may not be related to a specific
function or user action, such as scalability or other performance, behavior under certain
constraints, or security. Non-functional requirements tend to be those that reflect the quality of
the product, particularly in the context of the suitability perspective of its users. It attempts to
find errors in the following categories:
• Internal logic of the program.
• Status of the program.
• Static & Dynamic Testing
There are many approaches to software testing. Reviews, walkthroughs, or inspections are
considered as static testing, whereas actually executing programmed code with a given set of test
cases is referred to as dynamic testing. Static testing can be omitted.

Dynamic testing takes place when the program itself is used for the first time. Dynamic testing
may begin before the program is 100% complete in order to test particular sections of code.
Typical techniques for this are either using stubs/drivers or execution from a debugger
environment.

For example, spreadsheet programs are, by their very nature, tested to a large extent
interactively, with results displayed immediately after each calculation or text manipulation.
30
Software Verification and Validation

• Verification: Have we built the software right? (i.e., does it match the specification).
• Validation : Have we built the right software? (i.e., is this what the customer wants)
Verification is the process of evaluating a system or component to determine whether the
products of a given development phase satisfy the conditions imposed at the start of that
phase. Validation is the process of evaluating a system or component during or at the end
of the development process to determine whether it satisfies specified requirements.
Hence, testing includes both verification and validation.

Testing= Verification + Validation. Both are important and complementary to each other.
Verification minimizes the errors and their impact in the early phases of development. If we find
more errors before execution (due to verification of the program), validation may be
comparatively easy.

What do we test?

First, test what’s important. Focus on he core functionality - the parts that are critical or popular
– before looking at the ‘nice to have’ features. Concentrate on the application’s capabilities in
common usage situations before going on to unlikely situations.

– For example, if the application retrieves data and performance are important, test reasonable
queries with a normal load on the server before going on to unlikely ones at peak usage times.
It’s worth saying again: focus on what’s important.

– Good business requirements will tell you what’s important. The value of software testing is
that it goes far beyond testing the underlying code. It also examines the functional behavior of
the application. Behavior is a function of the code, but it doesn’t always follow that if the
behavior is “bad” then the code is bad. It’s entirely possible that the code is solid but the
requirements were inaccurately or incompletely collected and communicated.

– It’s entirely possible that the application can be doing exactly what we’re telling it to do but
we’re not telling it to do the right thing. Testing can involve some or all of the following factors.
31
The more, the better:

• Business requirements
• Functional design requirement
• Technical design requirement
• Regulatory requirements
• Programmer code
• Systems administration standards and restrictions
• Corporate standards
• Professional or trade association best practices
• Hardware configuration
• Cultural issues and language differences

What does the testing?

Software testing is not a one person job. It takes a team, but the team may be larger or smaller
depending on the size and complexity of the application being tested. The programmer(s) who
wrote the application should have a reduced role in the testing if possible.

The concern here is that they’re already so intimately involved with the product and “know” that
it works that they may not be able to take an unbiased look at the results of their labors. Testers
must be cautions, curious, critical but non-judgmental, and good communicators.

One part of their job is to ask questions that the developers might find not be able to ask
themselves or are awkward , irritating, insulting or even threatening to the developers.

How well does it work?

What does it mean to you that “it works”?
How do you know it works?
What evidence do you have? In what ways could it seem to work but still have something
wrong?

32
Testing Methods

Software testing methods are traditionally divided into white-box and black-box testing. These
two approaches are used to describe the point of view that a test engineer takes when designing
test cases.

White Box Testing

“White box” testing examines the internal structure (data structures and algorithms) of the
program. This method of testing exposes both errors: error of omission (errors due to neglected
specification) and also error of commission (something not defined by the specification).

Let us look at a specification of a simple file handling program. “The program has to read
student’s detail such as student id, name, date of admission and department as input from the
user, create a file of student and display the records sorted in the order of student ids.

Examples for errors of omission: Omission of Display module, display of records not in sorted
order of student id‘s file created with fewer fields etc.

Examples of errors of commission: Additional lines of code deleting some arbitrary records from
the created file.

Black Box Testing

“Black box” testing treats the software as a “black box” – without any knowledge of internal
implementation. Black box testing methods include: equivalence partitioning, boundary value
analysis, and specification-based testing.

If the testing component is viewed as a “black box”, the inputs have to be given to observe the
behavior (output) of the program. In this case, it makes sense to give both valid and invalid
inputs. The observed output is then matched with expected result (from specification). The
advantage of this approach is that the tester need not worry about the internal structure of the
program. However, it is impossible to find all errors using this approach.

33
For instance, if one tried three equilateral triangle test cases for the triangle program, we cannot
be sure whether the program will detect all equilateral triangles. The program may contain a hard
coded display of ‘scalene triangle’ for values (300,300,300).

To exhaustively test the triangle program, we need to create test cases for all valid triangles up to
MAXIMUM integer size. This is an astronomical task - but still not exhaustive (why?) To be
sure of finding all possible errors, we not only test with valid inputs but all possible inputs
(including invalid ones like characters, float, negative integers, etc.

Levels of Testing

In developing a large system, testing usually involves several stages:

• Unit Testing
• Integration Testing
• System Testing
• Regression Testing
• Acceptance Testing
• Alpha Testing
• Beta Testing

Unit Testing

A series of stand-alone tests are conducted during Unit Testing. Each test examines an individual
component that is new or has been modified. A unit test is also called a module test because it
tests the individual units of code that comprise the application.

Each test validates a single module that is based on the technical design documents, was built to
perform a certain task with the expectation that it will behave in a specific way or produce
specific results.
Unit tests focus on functionality and reliability, and the entry and exit criteria can be the same for

34
each module.
Unit testing is done in a test environment prior to system integration. If a defect is discovered
during a unit test, the severity of the defect will dictate whether or not it will be fixed before the
module is approved.
These types of tests are usually written by developers as they work on code (white-box style), to
ensure that the specific function is working as expected. One function might have multiple tests.

Unit testing alone cannot verify the functionality of a piece of software, but rather is used to
assure that the building blocks the software uses work independently of each other. For unit
testing, test cases are designed to locate error because of incorrect computations, wrong
comparisons and incorrect control flow. Following are few reasons for occurrences of errors in
the module:

• Incorrect use of if-then-else

• Incorrect use of do-while construct
• Incorrect use of do-until
• Incorrect use of switch-case
• Incorrect initialization
• Incorrect loop termination
• Precision inaccuracy

Integration Testing

During Integration testing, individually tested units are added to make a complete system. Group
of independent units must be tested prior to integration testing. Smaller units can be considered
as the black box that allows integration of units and testing of their interfaces. The objective of
integration testing is to test that each unit performs appropriately with the control structure and
interfaces of components are correct.

System Testing

The purpose of system testing is to compare the program or a system with its original objectives.

35
System testing is the process of demonstrating how the program as a whole does not meet its
objectives. System testing is done with respect to the measurable objectives of the product or the
system.

When we look for inconsistencies between a program and its objectives, we focus on errors
related to translation that are made during the process of designing external specification. These
are the reasons why system testing is the most vital process, in terms of product, number of
errors and severity of these errors.

Regression Testing

Regression testing is the process of running a subset of previously executed integration and
function tests to ensure that program changes have not degraded the system. The regression
phase concerns the effect of newly introduced changes on all the previously integrated code.
Regression testing may be conducted manually or using automated tools.

The basic regression testing approach is to incorporate selected test cases into a regression
bucket that is run periodically to find regression problems. In many organizations regression
testing consists of running al the functional tests every few months. This generally delays the
regression problem detection and results in significant rework after every regression run.

Acceptance Testing

Acceptance testing is the process of comparing the program to its initial requirements and the
present needs of its end users. It is a natural type of test which is usually performed by the
program’s customer or end user and in general is not considered the responsibility of the
development organization. In the case of a contracted program, the contracting (user)
organization performs the acceptance test by comparing the program’s operation to the original
contract.

As is the case for other types of testing, the best way to do this is to devise test cases that attempt
to show that the program does not meet the contract; if these test cases fail, the program is
accepted.
36
In the case of a program product, such as a computer’s manufacturer’s operating system, the
sensible customer first performs an acceptance test to determine whether the product satisfies its
requirements.

Alpha Testing

Alpha testing is simulated or actual operational testing by potential users/customers or an

independent test team at the developer’s site. Alpha testing is often employed for off-the-shelf as
a form of internal acceptance testing, before the software goes to beta testing.

Beta Testing

Beta testing comes after alpha testing and can be considered as a form of external user
acceptance testing. Versions of the software, known as beta versions, are released to a limited
audience outside of the programming team. The software is released to groups of people so that
further testing can ensure the product has few faults or bugs.

37
 MAINTENANCE

“Software maintenance is the process of modifying a software system or component after

delivery to correct faults, improve performances or other attributes, or adapt to a changed
environment.” If the system is not properly maintained, it may fail too. Therefore, generally
more than 50% of total software development time is spent in maintaining the system.
Maintenance is actually the implementation of post implementation review plan. As important as
it is, many programmers and analysts are reluctant to perform or identify themselves with the
maintenance effort. There are psychological, personality and professional reasons for this. In any
case, a first class effort must be made to ensure that software changes are made properly and in
time to keep the system in tune with user specifications.

38
 CONCLUSION

Apart from the class you will write, we have now completed the development of our program. It
consists of a total of 10 classes plus the one you will write. Ignoring comments and documentation
in the code, those 10 classes consists of around 1300 lines of spaced out code.

My sample answer for the part you will write, including the optional extras, consists of
approximately 500 lines, making a total of approximately 1800 lines. Before we finish, we ought to
say something about the order of development we saw here. The choice we made, of considering
the classes in a bottom up order, was more motivated by the wish for you to be able to follow it,
than a realistic reconstruction of a real development experience. In reality, when we develop
programs, we usually have to work on several classes at once.

So, for example, if we try to follow a bottom up order after having had a top down high level
analysis, we typically need to go back to classes we have already developed in order to add new
features or modify existing ones, as we traverse up the dependencies towards the top.

This is less necessary in the top down development approach, but instead we initially need to make
stubs of our lower level classes. Finally, we should address an obvious question, which you may
well have been already asking yourself. Why did we not divide the Game class into separate classes
such as, Field, Food, Tree, GameSnake, and so on? The short answer is this: you are the one that
will be looking at that part of the program, in your laboratory exercise! However, in that exercise
you are requested to develop the Game class without dividing it up, and then ask yourself whether
it would be a good idea to, and what are the pros and cons.

39
 REFERENCES

[1] L. Hauck, A. Kiss, and B. Pecarero, Blockcade. Gremlin, 1976.

[2] S. Lisberger and B. MacBird, Tron. Walt Disney Pictures, 1987.

[3] T. Armanto, Snake. Nokia, 1997.

[4] L. J. P. d. Araujo, M. Charikova, J. E. Sales, V. Smirnov, and A. Thapaliya, “Towards a game-

independent model and data-structures in digital board games: an overview of the state-of-the-art,”
in Proceedings of the 14th International Conference on the Foundations of Digital Games, 2019,
pp. 1–8.

[5] The Joint Task Force on Computing Curricula Association for Computing Machinery (ACM)
and IEEE Computer Society, “Computer science curricula 2013: Curriculum guidelines for
undergraduate degree programs in computer science,” Tech. Rep. 999133, December 2013

40
SCREENSHOTS

41
42