View
8
Download
2
Category
Preview:
DESCRIPTION
Software Engineering project paper (Lecture)
Citation preview
Software Engineering : TDB 2163 2015
LABORATORY AUTOMATION SYSTEM Page 0
TDB 2163 SOFTWARE ENGINEERING
PROJECT DOCUMENTATION
LABORATORY AUTOMATION SYSTEM
Date: 14th August 2015
Members:
1. AFIQ AIMAN BIN ZAMRI 19071
2. MUHAMMAD NAZMI BIN MAT ASRI 19103
3. AMELIA ASYIQIN BINTI MOHAMAD 18856
4. KHALIDA ADEEBA BINTI MOHD ZAILAN 19271
5. WAN NOR SUHAILI BINTI WAN ZAHARI 19141
Software Engineering : TDB 2163 2015
LABORATORY AUTOMATION SYSTEM Page 1
OVERVIEW
This idea came up when we notice that there are quite some time it happened that the
laboratory door is not open and the students have to wait until the lecturer came because only
the lecturer or security department (control room) have the access to the door. This project is
to create a system for laboratory door as well light which can control the behaviour of those
particular appliances. The system can be controlled from a distance and the controller will be
included in the system as well. The controller is a web that will be associated with the
system and use Wi-Fi as connection medium. The concept that we are going to implement is
Internet of Things (IOT), which allow the specific user to have control over the appliances
from far, as long as the connection to the internet is accessible. We will be providing a small
scale project in order to show how it is work in a real time (working prototype).
Name given for the system is Laboratory Automation System. This system created
because of few observations were made especially during the day at 8.00am lab where the
labs were locked and students and lecturers or tutors have to wait for the security to open it.
Instead of coming over to open the lab, we create this system which can be controlled by the
one in charged in the control room. This is less time consuming rather than coming over to
lab and to open the lab for the students and lecturers.
The group consist of 5 members, named as Muhammad Nazmi bin Mat Asri as the
group leader, Afiq Aiman bin Zamri, Amelia Asyiqin Binti Mohamad, Khalida Adeeba binti
Mohd Zailan and Wan Nor Suhaili binti Wan Zahari. Tasks were given accordingly to each
members in order to complete this project and documentations.
Software Engineering : TDB 2163 2015
LABORATORY AUTOMATION SYSTEM Page 2
CONTENT
I OVERVIEW 1
II SOFTWARE PROJECT MANAGEMENT PLAN (SPMP) 5
1.0 INTRODUCTION 7
1.1 Project Overview 7
1.2 Project Deliverables 7
2.0 PROJECT ORGANISATION
2.1 Software Process Model 8
2.2 Roles and responsibilities 9
2.3 Tools and Techniques 10
3.0 PROJECT MANAGEMENT PLAN 11
3.1 Tasks
3.1.1 Task 11
3.1.1.1 Description 11
3.1.1.2 Deliverables and Milestones 11
3.1.1.3 Resources Needed 12
3.1.1.4 Dependencies and Constraints 12
3.1.1.5 Risks and Contingencies 13
Software Engineering : TDB 2163 2015
LABORATORY AUTOMATION SYSTEM Page 3
III SOFTWARE REQUIREMENTS SPECIFICATION (SRS)
1.0 INDTRODUCTION 19
1.1. Product overview 19
1.2 Scope 19
2.0 SPECIFIC REQUIREMENT 20
2.1. External Interface Requirement 20
2.2. Software System Attributes 21
ADDITIONAL MATERIAL 24
IV SOFTWARE DESIGN DESCRIPTION (SDD) 30
1.0 INTRODUCTION 32
2.0 SYSTEM ARCHITECTURAL DESIGN 33
2.1 Chosen System Architecture 33
3.0 DETAILED DESCIPTION OF COMPONENTS 43
3.1 Physical arrangement of devices and Communication and installed software
components on devices 37
4.0 USER INTERFACE DESIGN 44
4.1. Screen Images 45
4.2 Objects and Action 47
Software Engineering : TDB 2163 2015
LABORATORY AUTOMATION SYSTEM Page 4
V SOFTWARE TESTING DOCUMENTATION (STD)
1.0 INTRODUCTION 50
1.1. System Overview 50
1.2. Testing Approach 51
2.0 TEST PLAN
2.1 Features to be tested 52
2.2 Features not to be tested 52
2.3 Testing Tools and Environment 53
3.0 TEST CASES 65
4.0 ADDITIONAL MATERIAL (TEST LOGS) 67
VI REFERENCES 69
Software Engineering : TDB 2163 2015
LABORATORY AUTOMATION SYSTEM Page 5
Software Project Management Plan
LABORATORY AUTOMATION SYSTEM
Final version
13th
August 2015
Universiti Teknologi PETRONAS
Software Engineering : TDB 2163 2015
LABORATORY AUTOMATION SYSTEM Page 6
Software Project Management Plan (SPMP)
Table of Contents
1 INTRODUCTION
1.1 Project Overview 7
1.2 Project Deliverables 7
2 PROJECT ORGANISATIONS
2.1 Software Process Model 8
2.2 Roles and Responsibilities 9
2.3 Tools and Techniques 10
3 PROJECT MANAGEMENT PLAN
3.1 Tasks
3.1.1 Task
3.1.1.1 Description 11
3.1.1.2 Deliverables and Milestones 11
3.1.1.3 Resources Needed 12
3.1.1.4 Dependencies and Constraints 12
3.1.1.5 Risks and Contingencies 13
3.2 Assignments 14
3.3 Timetable 15
Software Engineering : TDB 2163 2015
LABORATORY AUTOMATION SYSTEM Page 7
1 INTRODUCTION
1.1 Project Overview
This idea came up when we notice that there are quite some time it happened that the
laboratory door is not open and the students have to wait until the lecturer came because only
the lecturer or security department (control room) have the access to the door. This project is
to create a system for laboratory door as well light which can control the behavior of those
particular appliances. The system can be controlled from a distance and the controller will be
included in the system as well. The controller is a web that will be associated with the
system and use Wi-Fi as connection medium. The concept that we are going to implement is
Internet of Things (IOT), which allow the specific user to have control over the appliances
from far, as long as the connection to the internet is accessible. When you access the
webserver from your browser of choice, you will have a big button that triggers the
laboratory door via a relay. We will wire a very basic circuit to the Pi's GPIO pins and upload
a website that triggers the circuit. When the relay is triggered, it closes the circuit hooked up
to the laboratory door motor and opens the door.
1.2 Project Deliverables
This project will be used for our targeted group that is our security department, for them to
easily open the door and lighting from far. We must buy the breadboard, relay, raspberry pi,
wire and laboratory motor. Then, we will combine the apparatus and we will use HTML, CSS
and JavaScript for the. While for the raspberry pi will use Webiopi application in the
Raspberry pi to control the GPIO pin inside the pi. Lastly, to connect the pi and the web using
HTML and REST API. The cost for this project is less than RM 50.00 for small scale project.
This project will be tested using prototype. The due for this project is the end of this August
Software Engineering : TDB 2163 2015
LABORATORY AUTOMATION SYSTEM Page 8
2015, that‟s mean our timeline for our projects is about 3 months that starting from June 2015
until August 2015.
2 PROJECT ORGANISATIONS
2.1 Software process model
Our project will follow an incremental and an iterative development model for its
deliverables. The development will be done in several phases and each phase will represent a
complete development cycle, with certain functionality of the system delivered at the end of
each phase. Additionally, the project phases with start, finish dated and goals for each phase
are outlined in table below.
Phase Start and finish date Phase goals
Project startup 26 / 05/ 2015 – 30 / 05/ 2015 - Strategy planning
- Learning about the existing
technologies regarding
automation system
Requirement 01/ 06/ 2015 – 15/ 06/ 2015 - Become familiar with the
requirement
- Design the prototype
- Start searching tools for the
prototype
Phase 1 16/ 06/ 2015 – 17/ 07/ 2015 - Start doing the prototype
- Component characterization
format
Phase 2 18/ 07/ 2015 – 31/ 07/ 2015 - Constraint checker
Software Engineering : TDB 2163 2015
LABORATORY AUTOMATION SYSTEM Page 9
Phase 3 01/ 08/ 2015 – 10/ 08/ 2015 - Final touch up
Each of the team members will create a list of tasks to be completed for the upcoming phase
of the project. Then the time for each task will be allocated, followed by the workload
balancing of the tasks. At the completion of each phase a postmortem analysis will be done to
analyze the previous phase. All tasks that we not completed during a phase will be recorded
and scheduled for completion in the upcoming phase.
2.2 Roles and responsibilities
The team structure is hierarchical. There is a team leader, and the rest of the roles are
assigned to the other tasks. All team members have their own area of responsibility and
everyone is expected to contribute equally to the project. The team will engage in regular
monthly meetings. Additionally team members will communicate by Facebook for the
compilation of documents and WhatsApp as our main communication medium. Personal
communication between team members is strongly encouraged.
Roles List of responsibilities
Team leader - Motivate the team members to perform their task
- Help the team in allocating the tasks and resolving
issues
Development manager - Producing the development strategy
- Producing the design specification
- Implement the product
- Developing the build, integration and system test plan
- Developing the test materials and running the tests
Planning manager - Lead in producing the task plan for next phase
Software Engineering : TDB 2163 2015
LABORATORY AUTOMATION SYSTEM Page 10
- Lead in producing the schedule for the next phase
- Track the team progress against the plan
Process manager - Lead in producing and tracking the quality plan
- -alerts the team to quality problem
- Lead in defining and documenting its processes and in
maintaining the process improvement process
- Establish and maintain the team‟s development
standards
Support manager - Lead in determining its support needs and in obtaining
the needed tools and facilities
- Maintain the team‟s issue and risk tracking system
- Manage the configuration management system
2.3 tools and technique
Additional tools that will be used are: breadboard, relay, raspberry pi , wire and laboratory
motor. Then, we will combine the apparatus and we will used HTML , CSS and JavaScript
for the. While for the raspberry pi will use Webiopi application in the Raspberry pi to control
the GPIO pin inside the pi. Lastly, to connect the pi and the web using HTML and REST
API.
Software Engineering : TDB 2163 2015
LABORATORY AUTOMATION SYSTEM Page 11
3 PROJECT MANAGEMENT PLAN
3.1 Task
3.1.1 Task -1
3.1.1.1 Description
The aim of this project is to help the Security department to create a system for
laboratory which can control the behavior of those particular appliances. The system can be
controlled from a distance and the controller will be included in the system as well. There are
a lot of risks and constraints that need to overview about the production so that it is inclined
with what we want to achieve.
3.1.1.2 Deliverables milestones
Milestone Date Description
Complete gathering
requirements
15/ 06/ 2015 All requirement for the security to
detect which want to be opened
Complete design the
prototype
17/ 07/ 2015 Design the system prototype and
its functionality
Complete coding the
prototype
31/ 07/ 2015 All coding completed resulting in
software prototype
Complete testing and
debugging the
prototype
10/ 08/ 2015 All functionality had been tested
and identified errors corrected
Complete production Complete the prototype and
Software Engineering : TDB 2163 2015
LABORATORY AUTOMATION SYSTEM Page 12
of the prototype documentation transitioned to
operations group to begin
production
3.1.1.3 Resources needed
Hardware: breadboard, relay, raspberry pi ,wire and laboratory motor
Software: HTML, CSS, JavaScript, Webiopi and REST API
3.1.1.4 Dependencies and constraints
There are constraints that may arise along the way of our project because of resources needed
for the project that cannot be obtained and maintained.
Firstly, time constraints. The time given from end of May until early August 2015.
Actually we only given 2 months to complete this project with our 18 credit hour this sem.
We also rarely manage to meet the client because of time constraints and unavailability of
both parties. So this will make there possibilities for us to not meet client‟s requirement or
misunderstanding from the client‟s requirement.
Next, the limitation of UI or design on the web itself. It is because the CSS code
hardly or cannot overwrite and need to built it in CSS application of Webiopi that was the
software for the pi. Webiopi is a component that will interact the pi with the HTML code
from the web. So we need to have Webiopi application.
Software Engineering : TDB 2163 2015
LABORATORY AUTOMATION SYSTEM Page 13
3.1.1.5 Risk and contingencies
There are a lot of risks need to be taken note when seeing the clients or any stakeholder.
Firstly, when we use an electrical apparatus, we have to take note the voltage used. If
the voltage used or output voltage is higher from input voltage, the raspberry pi will crash or
broken and not working. So to prevent our hardware easily crash, we must take care all about
that. This also one way how we want to make our project more productive and prevent for
wastage in term of buying extra things because of the experiment was not going well.
Then, project management process. We have to well plan our project so that
everything within the time frame given and will not delay. This is the important of team
leader to make sure everything is in the right places to prevent from delay of the project. We
also can make a Gantt chart to make our schedule more visible and revisable for everyone.
We also must make a correct budget and allocate correctly within our budget as a student.
Software Engineering : TDB 2163 2015
LABORATORY AUTOMATION SYSTEM Page 14
3.2 Assignments
Nazmi Asri is assigned as the Project Manager who will do the technical part of
preparing materials for the prototype. The rest of the team acts as System Analysts, as
required at the current level of development of the system. Under Nazmi‟s
supervision, Khalida Adeeba leads the estimation of project size, effort and schedule
in the project management area. Amelia designed the work plan and developed the
Gantt chart which is approved by the project manager and the team members. Afiq
gathers the requirements mostly via the observations of the current system. From the
substances gathered, Suhaili leads the process of preparing the requirement definition
document. The review of the system is finally prepared by Afiq based on the
planning, analysis and design of the system that has been made and approved by
Nazmi Asri.
Software Engineering : TDB 2163 2015
LABORATORY AUTOMATION SYSTEM Page 15
3.3 Project Timetable
In order to finish this project on time, we had prepared a timetable allocating each member
with their particular job. Allocation of jobs is important as we know what to do first before
one another. This help to ease the flow of our project. We managed to clear out our project in
time of 2 Months and 18 days.
Name Job scopes Time
Nazmi Gather material for prototype 1 Week
Afiq Gather requirements for the project 4 Days
Adeeba System Project Management Plan 1 Week
Suhaili System Requirement Specification 1 Week
Amelia System Design Description 1 Week
Nazmi
Afiq
System Testing Development 2 Weeks
Nazmi Monitor the workflow All the time
ALL Implementing the system and Working Prototype 1 Month
Software Engineering : TDB 2163 2015
LABORATORY AUTOMATION SYSTEM Page 16
Software Requirements Specification
LABORATORY AUTOMATION SYSTEM
Final version
13th
August 2015
Universiti Teknologi PETRONAS
Table of Contents
Software Engineering : TDB 2163 2015
LABORATORY AUTOMATION SYSTEM Page 17
1. INTRODUCTION 19
1.1 Overview 19
1.2 Scope 19
2. SPECIFIC REQUIREMENTS 20
2.1 External Interface Requirements 20
2.1.1 User Interfaces 20
2.1.2 Hardware Interfaces 20
2.1.3 Software Interfaces 21
2.1.4 Communications Protocols 21
2.2 Software Product Features 21
2.3 Software System Attributes 21
2.3.1 Reliability 22
2.3.2 Availability 22
2.3.3 Security 22
2.3.4 Maintainability 22
2.3.5 Portability 23
2.3.6 Performance 23
3. ADDITIONAL MATERIAL 24
Software Engineering : TDB 2163 2015
LABORATORY AUTOMATION SYSTEM Page 18
Appendix A: Use Case 24
Appendix B: Sequence Diagram 25
Software Engineering : TDB 2163 2015
LABORATORY AUTOMATION SYSTEM Page 19
1. INTRODUCTION
1.1 Purpose
The purpose of this SRS is to provide details about the workings of the Laboratory
Automation System. The details are to be sufficient enough that the system (including the
components) to be built. It is intended to be readable by the developer team involved. This
document provides the description of the system, laying out the functional and non-functional
requirements and use cases that describe the interactions the users will have with the
software.
1.2 Scope
The product to be produced is a Laboratory Automation System. This system will basically
allow the behavior of particular appliances to be controlled from a distance. Basic properties
and features will be described, which include the concept, medium of connection and
controller as well as the components, the actions it is suggested to, and shall perform. The
system is aimed to help security department to easily control the particular appliances‟
behavior and reduce time consumption in order to move from one to another laboratory in
comparison to a conventional manual door.
Software Engineering : TDB 2163 2015
LABORATORY AUTOMATION SYSTEM Page 20
2. SPECIFIC REQUIREMENTS
2.1 External Interface Requirements
This section shall describe the interface requirement for the laboratory automation
system. They specify the way the user shall interact with the system as well as define
the necessary hardware interfaces and communication interfaces required by the
software to support the main function.
2.1.1 User Interfaces
The user interface shall follow basic Window style and functionality
conventions. The interface has two buttons on the screen with necessary
description to be provided on how to use the system. User need to login using
the given username and password before making any command. One button
will represent light and another one for door. The color of the button means;
green for on and red for off. Each click of the button will trigger the behavior
of the appliances thus perform the desired action. For example, when the user
click on the button light (in color of red), the button will trigger the light in the
laboratory room to be turned on. Thus the color of the button will change to
green, means the light is on.
2.1.2 Hardware Interfaces
The system will be using a controller which can control the appliances from a
distance. This controller will be connected through Wi-Fi connection and
perform action received by webserver using basic networking protocols.
Software Engineering : TDB 2163 2015
LABORATORY AUTOMATION SYSTEM Page 21
2.1.3 Software Interfaces
The system is using the concept of Internet of Thing (IoT) which control the
behavior of things using the medium of Internet connection. The webserver
shall be able to be accessed from any type of operating system as long as there
is web browser. The web should be able to be accessed from anywhere and
anytime. The webserver can be open using mobile android or web.
2.1.4 Communications Protocols
The button feature in the webserver shall perform it function based on the
desired outcome. The green button shall only be able to be activated when the
door is locked and vice versa. The security system must be ensured by
providing the security department with a proper login username and password
to prohibit ant unauthorized access.
2.2 Software Product Features
The main features of the system will be:
Button for light and door
Different button color code control
Contact detail
Description on usage
Software Engineering : TDB 2163 2015
LABORATORY AUTOMATION SYSTEM Page 22
Wi-Fi connector and receiver
Login access for authentication
Lock or unlock door
Turn on or off light
2.3 Software System Attributes
2.3.1 Reliability
The system is expected to be reliable to use over time and not sensitive that
prone to cause failure. 2.3.2 Availability
The system can be accessed anytime depending on the availability of
Wi-Fi connection
2.3.3 Security
Only authorized people especially from security department can access
the webserver and gain the login information
Fail authentication login more than 3 times should be blocked and alert
notification will be sent to main control room
2.3.4 Maintainability
The system uses a single page webpage which is not complex and
eases the maintenance.
Software Engineering : TDB 2163 2015
LABORATORY AUTOMATION SYSTEM Page 23
2.3.5 Portability
The webpage can be opened in any operating system available along as
there is web browser.
Both web and mobile android can be used as a platform
2.3.6 Performance
The system should respond to action made by user with no delay more
than 20 seconds
Software Engineering : TDB 2163 2015
LABORATORY AUTOMATION SYSTEM Page 24
3. ADDITIONAL MATERIAL
Appendix A: Use Case Diagram
Software Engineering : TDB 2163 2015
LABORATORY AUTOMATION SYSTEM Page 25
Appendix B: Sequence Diagram
Software Engineering : TDB 2163 2015
LABORATORY AUTOMATION SYSTEM Page 26
Software Engineering : TDB 2163 2015
LABORATORY AUTOMATION SYSTEM Page 27
Software Engineering : TDB 2163 2015
LABORATORY AUTOMATION SYSTEM Page 28
Software Engineering : TDB 2163 2015
LABORATORY AUTOMATION SYSTEM Page 29
Software Engineering : TDB 2163 2015
LABORATORY AUTOMATION SYSTEM Page 30
SOFTWARE DESIGN DESCRIPTION
LABORATORY AUTOMATION SYSTEM
Final Version
13th
August 2015
Universiti Teknologi PETRONAS
Software Engineering : TDB 2163 2015
LABORATORY AUTOMATION SYSTEM Page 31
Table of Content
1. INTRODUCTION 32
1.1 Design Overview 32
2. SYSTEM ARCHITECTURAL DESIGN 33
2.1 Chosen System Architecture 33
3. DETAILED DESCRIPTION OF COMPONENTS 43
3.1 Component 43
4. USER INTERFACE DESIGN 44
4.1 Description of the User Interface 44
4.1.1 Screen Images 45
4.1.2 Objects and Action 47
Software Engineering : TDB 2163 2015
LABORATORY AUTOMATION SYSTEM Page 32
INTRODUCTION
1.1 Design Overview
The software system being produced called “Laboratory Automation System”. It is
being produced to ease the student to get access to any laboratory door via the Internet. They
do not have to wait for the lecturer or security to come and open the door using their card.
This system is designed to “provide automation support” for the process of operating the door
and light in the particular laboratory. This system is largely cross-platform and is available to
any student who has a stable Internet connection. The system will be run on a central server
with each user will instruct them by a click on a particular instruction interface through a web
browser. The Laboratory Automation System will allow every verified student to have access
with web server. This project mainly focus on the problem faced by most of the student by
initiating the automating and standardizing automation system, providing the most effective
way to overcome the problem. Our project is design to ease everyone that may want to use
the room. This project will enable user to have control at any time as long as they are verified
use to use our website. Our project enable people to log in and choose which ever option
either door or light that they want to turn it on or off.
Software Engineering : TDB 2163 2015
LABORATORY AUTOMATION SYSTEM Page 33
2. SYSTEM ARCHITECTURAL DESIGN
2.1 Chosen System Architecture
• This system works anywhere as long as there is internet access, it is a web based so it
is applicable for mobile phones as well as personal computer. This idea came up when we
notice that there are quite some time it happened that the laboratory door is not open and the
students have to wait until the lecturer came because only the lecturer have the access to the
door. This project is to create a system for laboratory door which can control the behaviour
of those particular appliances. The system can be controlled from a distance and the
controller will be included in the system as well. The controller is a web or a mobile
application that will be associated with the system and use Wi-Fi as connection medium. The
concept that we are going to implement is Internet of Things (IOT), which allow the specific
user to have control over the appliances from far, as long as the connection to the internet is
accessible. The platform that we are using is web, the code is written in html and JavaScript
and using mobile using Android for the security easily access everywhere and anytime. We
also used Raspberry Pi as the controller which is easy for us access that is connect through
Wi-Fi. When you access the webserver from your browser of choice, you will have a big
button that triggers the laboratory door via a relay. We will wire a very basic circuit to the
Pi's GPIO pins and upload a website that triggers the circuit. When the relay is triggered, it
closes the circuit hooked up to the laboratory door motor and opens the door.
Software Engineering : TDB 2163 2015
LABORATORY AUTOMATION SYSTEM Page 34
Use Case Diagram
Software Engineering : TDB 2163 2015
LABORATORY AUTOMATION SYSTEM Page 35
Activity Diagram
Figure 2.1.2: Login
Software Engineering : TDB 2163 2015
LABORATORY AUTOMATION SYSTEM Page 36
Figure 2.1.3: Verify user
Software Engineering : TDB 2163 2015
LABORATORY AUTOMATION SYSTEM Page 37
Figure 2.1.4: Browse page
Software Engineering : TDB 2163 2015
LABORATORY AUTOMATION SYSTEM Page 38
Figure 2.1.5: logout
Software Engineering : TDB 2163 2015
LABORATORY AUTOMATION SYSTEM Page 39
Sequence Diagram
Software Engineering : TDB 2163 2015
LABORATORY AUTOMATION SYSTEM Page 40
Software Engineering : TDB 2163 2015
LABORATORY AUTOMATION SYSTEM Page 41
Software Engineering : TDB 2163 2015
LABORATORY AUTOMATION SYSTEM Page 42
Software Engineering : TDB 2163 2015
LABORATORY AUTOMATION SYSTEM Page 43
3. DETAILED DESCRIPTIONS OF COMPONENTS
3.1 Component
Raspberry Pi
- The Raspberry Pi is a low cost, credit-card sized computer that plugs into a
computer monitor or TV, and uses a standard keyboard and mouse. It is a capable
little device that enables people of all ages to explore computing, and to learn how
to program in languages like Scratch and Python.
- We use application webiopi in raspberry pi to control GPIO pin in raspberry pi for
general purpose input and output.
We also use HTML, CSS, and JavaScript for the website.
To connect website and raspberry pi we did apply HTML and REST API.
Software Engineering : TDB 2163 2015
LABORATORY AUTOMATION SYSTEM Page 44
4 USER INTERFACE DESIGN
4.1 Description of the User Interface
The user interface shall follow basic Window style and functionality
conventions. The interface has two buttons on the screen with necessary
description to be provided on how to use the system. User need to login using
the given username and password before making any command. One button
will represent light and another one for door. The colour of the button means;
green for on and red for off. Each click of the button will trigger the behaviour
of the appliances thus perform the desired action. For example, when the user
click on the button light (in color of red), the button will trigger the light in the
laboratory room to be turned on. Thus the color of the button will change to
green, means the light is on. The button feature in the webserver shall perform
it function based on the desired outcome. The green button shall only be able
to be activated when the door is locked and vice versa. The security system
must be ensured by providing the security department with a proper login
username and password to prohibit ant unauthorized access.
Software Engineering : TDB 2163 2015
LABORATORY AUTOMATION SYSTEM Page 45
4.1.1 Screen Images
Figure 1 & 2: Login interface
Software Engineering : TDB 2163 2015
LABORATORY AUTOMATION SYSTEM Page 46
Figure 3: Main Page interface
Software Engineering : TDB 2163 2015
LABORATORY AUTOMATION SYSTEM Page 47
4.1.2 Object and Action
There are some object on screen which are :
* Button for light and door
* Different button color code control
* Contact detail
* Description on usage
* Wi-Fi connector and receiver
* Login access for authentication
* Lock or unlock door
* Turn on or off light
The action needed to access this server is that login and then choose option either
door or light and then set it to or off.
Software Engineering : TDB 2163 2015
LABORATORY AUTOMATION SYSTEM Page 48
Software Test Documentation
LABORATORY AUTOMATION SYSTEM
Final version
13th
August 2015
Universiti Teknologi PETRONAS
Software Engineering : TDB 2163 2015
LABORATORY AUTOMATION SYSTEM Page 49
1 INTRODUCTION
1.1 System Overview 50
1.2 Test Approach 51
2 TEST PLAN
2.1 Features to be Tested 52
2.2 Features not to be Tested 52
2.3 Testing Tools and Environment 53
2.3.1 Testing tools (Development Testing) 54
2.3.2 Testing Tools (Interface Testing) 54
2.3.3 Testing Tools (Functionality Testing) 55
2.3.4 Testing Tools (HTML and CSS) 56
2.3.5 Testing Tools (Compatibility Testing) 57
2.3.6 Testing Tools (Performance Testing ) 58
2.3.7 Testing Tools (Usability Testing) 59
2.3.8 Testing Tools (Security Testing) 60
2.3.9 Testing Tools (White Box Testing) 62
3 TEST CASES
3.1 Case 1 65
3.1.1 Purpose
3.1.2 Inputs
3.1.3 Expected Outputs & Pass/Fail criteria
3.1.4 Test Procedure
Software Engineering : TDB 2163 2015
LABORATORY AUTOMATION SYSTEM Page 50
3.2 Case 2 66
3.2.1 Purpose
3.2.2 Inputs
3.2.3 Expected Outputs & Pass/Fail Criteria
3.2.4 Test Procedue
4 ADDITIONAL MATERIAL (including appendix A)
APPENDIX A. TEST LOGS
4.1 Log for test case 1 67
4.2 Log for test case 2 68
Software Engineering : TDB 2163 2015
LABORATORY AUTOMATION SYSTEM Page 51
1. INTRODUCTION
1.1 SYSTEM OVERVIEW
This project is to create a system for laboratory door as well light which can control
the behaviour of those particular appliances. The system can be controlled from a distance
and the controller will be included in the system as well. The controller is a web that will
be associated with the system and use Wi-Fi as connection medium. The concept that we
are going to implement is Internet of Things (IOT), which allow the specific user to have
control over the appliances from far, as long as the connection to the internet is
accessible. When you access the webserver from your browser of choice, you will have a
big button that triggers the laboratory door via a relay. We will wire a very basic circuit to
the Pi's GPIO pins and upload a website that triggers the circuit. When the relay is
triggered, it closes the circuit hooked up to the laboratory door motor and opens the door.
Testing the Lab Auto System is intended to show that this system is working and
functioning well. We are referring the Authorities here is Security Department members
who are working in the Control Room to monitor the campus including controlling the
doors and lights. Furthermore, testing will enable us to detect the errors from the system.
When we test the software, we execute a program using artificial data. We check the
results of the test run for errors, anomalies or information about the systems‟ non-
functional attributes. The goal of this testing stage is;
• To demonstrate on how to use the system to the authorities like in this case is the
security department.
• To discover situations in which the behaviour of the software is incorrect, undesirable
or does not conform to its specification.
Software Engineering : TDB 2163 2015
LABORATORY AUTOMATION SYSTEM Page 52
1.2 TEST APPROACH
We are calling all the guards for demonstrating the usage of the Lab Auto System.
After being explained the steps, we took their photographs as we are using face
recognition for them to unlock the door and lights for labs. A few references have been
listed below for testing purposes:
# Document Identifier Document Title
[Ref1] ID Authorities‟ ID
[Ref2] Password Authorities‟ Password
[Ref3] Light Button to switch on the Lights
[Ref4] Door Button to open the door
Standard and Regulatory Reference
# Document Identifier Document Title
[STD1] Password This password for guards are important for them to unlock
the door and switch on the lights
Software Engineering : TDB 2163 2015
LABORATORY AUTOMATION SYSTEM Page 53
2 TEST PLAN
2.1 Features to be tested
For Lab Auto System, the guards will need their ID number and password in
order for them to have the accessibility to the system. Only one computer can operates
the system at one time. This is to avoid from misuse from any party that trying to play
around with the system and to maintain the level of security at the lab. Whenever the
guards are login, they will proceed to a webpage that consist a simple buttons of lights
and doors. That buttons have 2 different colors; red and green. Red color indicates the
switch is OFF while green in color indicate the switch is ON.
2.2 Features not to be tested
As our concern, due to time constraint and limited funding, the face
recognition is unable to be tested as we can‟t get the right time to meet the guards for
a proper photograph session as it will be used for the face recognizing. Moreover, due
to limited time we also unable to find a cheap IP camera and suitable for our project.
Software Engineering : TDB 2163 2015
LABORATORY AUTOMATION SYSTEM Page 54
2.3.1 Testing tools (Development Testing)
2.3.1.1 Hardware preparation
2.3.1.1 This system can run in some devices only such desktop and
laptop. We cannot use the system in mobile phone or smartphone since
it is not a mobile friendly system.
2.3.1.2 Software preparation
2.3.2.1 The system is compatible with any kind of browser for desktop
such as Internet Explorer, Google Chrome, Mozilla Firefox,
Safari and Opera
2.3.1.3 Safety, security and privacy precautions
2.3.3.1 For safety, security and privacy precautions, we use login
system before anyone can use the system.
2.3.2 Testing Tools (Interface Testing)
2.3.2.1 Objectives are to detect faults due to interface errors or invalid
assumptions about interfaces. This testing is applicable during the
login. The interfaces of the system are same before the login but
different because it will show another screen that display the buttons of
Door and Light.
Software Engineering : TDB 2163 2015
LABORATORY AUTOMATION SYSTEM Page 55
2.3.3 Testing Tools (Functionality Testing)
2.3.3.1 The objective of this test is to check if the system is as per the
specifications the customer intended for it as well as the functional
requirements that have been showed in the development
documentation.
2.3.3.3.1 Testing activities are included:
2.3.3.3.1.1 Outgoing links
2.3.3.3.1.2 Internal links
2.3.3.3.1.3 Anchor links
2.3.3.3.2 Test cookies are working as expected.
2.3.3.3.2.1 Cookies are used by websites to remember
active user sessions so the user does not need to
re-login every time the user use the website
2.3.3.3.2.2 Testing cookies are deleted when expired
2.3.3.3.2.3 Testing cookies received when user login
2.3.3.3.2.4 Tools that can be used: IBM Rational, Selenium
Software Engineering : TDB 2163 2015
LABORATORY AUTOMATION SYSTEM Page 56
2.3.4 Testing Tools (HTML and CSS)
2.3.4.1 To ensure that search engines can crawl your site easily. This will
include
2.3.4.1.1 Checking for syntax errors
2.3.4.1.2 Readable colour schemas
2.3.4.1.3 Standard compliance. Ensure standards such W3C,
OASIS, IETF, ISO, ECMA, or WS-I are followed.
2.3.4.2 Functional Test Scenarios:
2.3.4.2.1 Test the system should not display the error message for
optional fields.
2.3.4.2.2 Test the functionality of the buttons available
2.3.4.2.3 Test the java script is properly working in different
browsers (IE, Firefox, Chrome, safari and Opera).
2.3.4.2.4 Test to see what happens if a user deletes cookies while
in the site.
2.3.4.2.5 Test to see what happens if a user deletes cookies after
visiting a site.
Software Engineering : TDB 2163 2015
LABORATORY AUTOMATION SYSTEM Page 57
2.3.5 Testing Tools (Compatibility Testing)
2.3.5.1 Ensures that your web application displays correctly across different
devices.
2.3.5.1.1 Browser Compatibility Test: Same website in different
browsers will display differently. You need to test if
your web application is being displayed correctly across
browsers, JavaScript, AJAX and authentication is
working fine.
2.3.5.1.2 To determine if the software is compatible with other
elements of a system with which it should operate, e.g.
Browsers, Operating Systems, or hardware.
2.3.5.1.3Compatibility Test Scenarios:
2.3.5.1.1 Test the website in different browsers (IE,
Firefox, and Chrome) and ensure the website is
displaying properly.
2.3.5.1.3.2 Test the HTML version being used is
compatible with appropriate browser versions.
2.3.5.1.3 Test the images display correctly in different
browsers.
2.3.5.1.4 Test the fonts are usable in different browsers.
Test the java script code is usable in different
browsers.
Software Engineering : TDB 2163 2015
LABORATORY AUTOMATION SYSTEM Page 58
2.3.6 Testing Tools (Performance Testing)
2.3.6.1 Ensure site works under all loads. Testing activities will include
but not limited to;
2.3.6.1.1 Website application response times at different
connection speeds
2.3.6.1.2 Load test your web application to determine its
behavior under normal and peak loads
2.3.6.1.3 Stress tests your web site to determine its break
point when pushed to beyond normal loads at
peak time.
2.3.6.1.4 Test if a crash occurs due to peak load, how
does the site recover from such an event
2.3.6.2 Performance testing is conducted to evaluate the compliance of
a system or component with specified performance
requirements.
2.3.6.2.1 To determine the performance, stability and
scalability of an application under different load
conditions.
2.3.6.2.2 To evaluate product and/or hardware to
determine if it can handle projected load
volumes.
Software Engineering : TDB 2163 2015
LABORATORY AUTOMATION SYSTEM Page 59
2.3.6.2.3 To determine if the current architecture can
support the application at peak user levels.
2.3.7 Testing Tools (Usability Testing)
2.3.7.1 Usability testing has now become a vital part of any web based
project. It can be carried out by testers by our team or a small
focus group of authorities of the web application.
2.3.7.1.1 Test the site Navigation:
2.3.7.1.1.1 Buttons or Links to different pages on your site
should be easily visible and consistent on all
webpages
2.3.7.1.2 Test the Content:
2.3.7.1.2.1 Content should be legible with no spelling or
grammatical errors.
2.3.7.1.2.2 Images if present should contain an "alt" text
2.3.7.2 Usability Test Scenarios:
2.3.7.2.1 Web page content should be correct without any
spelling or grammatical errors
2.3.7.2.2 All the text should be properly aligned.
2.3.7.2.3 All the buttons should be in a standard format and size.
2.3.7.2.4 Check the end user can run the system without
frustration.
Software Engineering : TDB 2163 2015
LABORATORY AUTOMATION SYSTEM Page 60
2.3.7.2.5 Check the site on different resolutions (640 x 480,
600x800)
2.3.7.2.6 Check for broken links and images.
2.3.8 Testing Tools (Security Testing)
2.3.8.1 Security testing is vital for control room usage website that controls the
safety of the labs (doors and lights).
2.3.8.2 Test unauthorized access to secure pages should not be permitted
Figure 1: Username and password are needed to login into the page
Software Engineering : TDB 2163 2015
LABORATORY AUTOMATION SYSTEM Page 61
Figure 2: The user will enter the username and password
Software Engineering : TDB 2163 2015
LABORATORY AUTOMATION SYSTEM Page 62
2.3.9 Testing Tools (White Box Testing)
2.3.9.1 Codes for functioning buttons (door & light)
2.3.9.2 White box testing are involves the testing of the software/system code
for the following:
2.3.9.2.1 Internal security holes
2.3.9.2.2 Broken or poorly structured paths in the coding process
2.3.9.2.3 The flow of specific inputs through the code
2.3.9.2.4 Expected output
2.3.9.2.5The functionality of conditional loops
Software Engineering : TDB 2163 2015
LABORATORY AUTOMATION SYSTEM Page 63
2.3.9.2.6 Testing of each statement, object and function on an individual
basis
2.3.9.3 The way that we do the white box testing are:
2.3.9.3.1 Understand the source code
2.3.9.3.1.1 The first thing a tester will often do is learn and
understand the source code of the application
2.8.3.1.1.2 Since the white box testing involves the testing of the
inner workings of an application, the tester must be very
knowledgeable in the programming languages used in
the applications they are testing, in our case is HTML,
CSS, Javascript, JQuery, AJAX and WebioPi coding.
2.3.9.3.2 Create test cases and execute
2.3.9.3.2.1 The second basis step to white box testing involves
testing the application‟s source code for the proper flow
and structure.
2.3.9.3.2.2 One way is writing more code to test the application‟s
source code.
2.3.9.3.2.3 The tester will develop little tests for each process or
series of processes in the application.
Software Engineering : TDB 2163 2015
LABORATORY AUTOMATION SYSTEM Page 64
2.3.9.3.4 This requires that the tester must have intimate
knowledge of the code and is often done by the
developer.
2.3.9.3.5 Other methods of testing are manual testing, try and
error listing.
Software Engineering : TDB 2163 2015
LABORATORY AUTOMATION SYSTEM Page 65
3.0 TEST CASES
3.1 Test Case 1 – Login Page (user=Security)
3.1.1 Purpose
To test the login page usability
3.1.2 Inputs
Security‟s username
Security‟s password.
3.1.3 Expected Outputs and Pass/Fail Criteria
Security should be able to login successfully and the system will display the
home screen back.
The process failed if the security are not able login (not because of wrong
username or password)
3.1.4 Test Procedure
Navigate to the login page
Provide valid username and password
Press „enter‟
Software Engineering : TDB 2163 2015
LABORATORY AUTOMATION SYSTEM Page 66
3.2 Test Case 2 – Login Page (user=Security Venue: Office (Outside the control room))
3.2.1 Purpose
To test the login page usability
3.2.2 Inputs
Security‟s Username
Security‟s password.
3.2.3 Expected Outputs and Pass/Fail Criteria
Security should be able to login successfully and the system will display the
home page back.
The process failed if the Security are not able to login (not because of wrong
username or password)
3.2.4 Test Procedure
Navigate to the login page
Provide valid username and password
Press „enter‟
Software Engineering : TDB 2163 2015
LABORATORY AUTOMATION SYSTEM Page 67
4.0 ADDITIONAL MATERIAL (TEST LOGS)
4.1 Logs for Test Case 1 – Login Page
4.1.1 Test Results
The purpose is to test the login page usability by having security as the user. Several
Security members‟ sample input data was inserted. Below are the test results:
Input Data Expected Result Actual
Result
Comment
Username= webiopi
Password=rahimi432
Successfully
logged in into the
system
Passed -
Username= webiopi
Password=tingtang143
Unsuccessfully
logged in into the
system
FAILED Only one user can
have the access at a
time to prevent the
misuse of the buttons
and ruin the system.
Software Engineering : TDB 2163 2015
LABORATORY AUTOMATION SYSTEM Page 68
4.0 ADDITIONAL MATERIAL (TEST LOGS)
4.2 Logs for Test Case 2 – Login Page (different place)
4.2.1 Test Results
The purpose is to test the login page usability by having Security as the user. Security‟s
sample input data was used. Below are the test results:
Input Data Expected Result Actual
Result
Comment
Username=webiopi
Password=rahimi432
Unsuccessfully
logged in into the
system
FAILED Couldn‟t log in
because it only
functions at control
room. One of the ways
to prevent misuse of
the system.
Software Engineering : TDB 2163 2015
LABORATORY AUTOMATION SYSTEM Page 69
VI REFERENCES
1) http://www.guru99.com/web-application-testing.html
2) http://www.guru99.com/white-box-testing.html
3) http://www.guru99.com/complete-web-application-testing-chec…
4) http://www.softwaretestinghelp.com/web-application-testing/
5) http://www.tutorialspoint.com/s…/web_application_testing.htm
6) https://code.google.com/p/webiopi/wiki/INSTALL?tm=6
7) https://code.google.com/p/webiopi/wiki/CONFIGURATION
Recommended