DIT085 Ed 2016 Practical Phase 3 - Revision history

Ceres at 14:27, 19 February 2016

2016-02-19T14:27:05Z

Ceres at 12:27, 19 February 2016

2016-02-19T12:27:29Z

Ceres at 07:42, 19 February 2016

2016-02-19T07:42:27Z

Ceres at 07:41, 19 February 2016

2016-02-19T07:41:24Z

Ceres at 07:41, 19 February 2016

2016-02-19T07:41:12Z

Ceres at 07:40, 19 February 2016

2016-02-19T07:40:50Z

Ceres at 07:40, 19 February 2016

2016-02-19T07:40:32Z

Ceres at 07:40, 19 February 2016

2016-02-19T07:40:20Z

Ceres: Created page with "==Objectives== This phase of the project is designed to apply UI testing as well as formal (mathematical) modelling and verification techniques to a small case study: *..."

2016-02-19T07:16:00Z

Created page with "==Objectives== This phase of the project is designed to apply UI testing as well as formal (mathematical) modelling and verification techniques to a small case study: *..."

New page

==Objectives==

This phase of the project is designed to apply UI testing as well as formal (mathematical) modelling and verification techniques to a small case study:

* apply mathematical modelling to capture the core behavior of a concurrency scenario in accessing a shared communication channel,

* apply simulation to gain insight on some of its basic behavior,

* specify some of its correctness properties in a temporal logic,

* apply model checking to verify the properties of the modelled behavior, and

* apply Visual GUI testing to the Arduino-Odroid example.

==General Description==
We separate two activities in this phase:

* Model Checking: In the first activity, we focus on a model of two concurrent threads accessing a shared USB channel.
Each thread would like to communicate two integer values (each ranging from 0 to 2) using the shared USB channel.
The USB channel may be disconnected at any point and the information may not be communicated, in which case the thread
will have to attempt the transmission of the same value again.
Each of the threads and the communication channel should be modeled as a separate automata and
use of global shared variables is not allowed.

* Visual GUI Testing: In the second activity, you specify a few scenarios for testing the GUI of the your application from phase 2.
Note that on the Odroid side,
Then, Visual GUI testing using [http://www.sikuli.org/ Sikuli] (or any comparable tool) has to be performed in order to test the main functionality of the system in terms of a few scenarios.

= Deliverables =

There are three main deliverables for this phase:

* a single pdf file documenting the outcome of each and every of the following steps,
* a .zip file containing the source code of the software implemented in different parts, and
* a self evaluation of your own effort and the effort by each and every member.

The first two deliverables are sent as a group using GUL.
The last deliverable is sent by email by each member individually to both supervisors.

==Model Checking==
Specify the network of timed automata representing the concurrent threads and the USB channel.
Specify 3 possible scenarios of interaction in the system (in plain English or using a sequence diagram) and simulate them in UPPAAL.
Subsequently, formulate 3 correctness criteria for your design and model-check them in UPPAAL.

==Visual GUI Testing==
Design at least 5 scenarios of interaction between the client and the server (e.g., login unsuccessful, login successful plus add successful, etc.) and
code them as scripts in Sikuli.
You can use the emulator for Android cell phones (e.g., available through the Android Eclipse plugin) to test your GUIs.
Run the tests and make sure that all of them run successfully.
Perform debugging if necessary.

@@ Line 15: / Line 15: @@
 ==General Description==
-We separate two activities in this phase:
+We separate two activities in this phase; the second activity is optional, but it is necessary to get a VG:
 * Model Checking: In the first activity, we focus on a model of two concurrent threads accessing a shared USB channel.  Each thread would like to communicate two integer values (each ranging from 0 to 2) using the shared USB channel.  The USB channel may be disconnected at any point and the information may not be communicated, in which case the thread will have to attempt the transmission of the same value again.  Each of the  threads and the communication channel should be modelled as a separate automata and use of global shared variables is not allowed.

← Older revision		Revision as of 12:27, 19 February 2016
Line 44:		Line 44:
	Run the tests and make sure that all of them run successfully.		Run the tests and make sure that all of them run successfully.
	Perform debugging if necessary.		Perform debugging if necessary.
		+
		+
		+	=[[DIT085 Ed 2016\|Back to DIT085, Edition 2016]]=

@@ Line 19: / Line 19: @@
 * Model Checking: In the first activity, we focus on a model of two concurrent threads accessing a shared USB channel.  Each thread would like to communicate two integer values (each ranging from 0 to 2) using the shared USB channel.  The USB channel may be disconnected at any point and the information may not be communicated, in which case the thread will have to attempt the transmission of the same value again.  Each of the  threads and the communication channel should be modelled as a separate automata and use of global shared variables is not allowed.
-* Visual GUI Testing: In the second activity, you specify a few scenarios for testing the GUI of the your application from phase 2.  Note that on the Odroid side,
+* Visual GUI Testing: In the second activity, you specify a few scenarios for testing the GUI of the your application from phase 2.  Note that you may have to extend the UI from phase  to make some of the testing scenarios possible (e.g., to disconnect the USB connection while testing).  Then, perform Visual GUI testing using [http://www.sikuli.org/ Sikuli] (or any comparable tool) in order to test the main functionality of the system in terms of a few scenarios.
-Then, Visual GUI testing using [http://www.sikuli.org/ Sikuli] (or any comparable tool) has to be performed in order to test the main functionality of the system in terms of a few scenarios.
 = Deliverables =

@@ Line 27: / Line 27: @@
 Note that on the Odroid side,
 Then, Visual GUI testing using [http://www.sikuli.org/ Sikuli] (or any comparable tool) has to be performed in order to test the main functionality of the system in terms of a few scenarios.
 = Deliverables =
@@ Line 48: / Line 45: @@
 While model-checking, if you notice mistakes in your initial model,
 please mention them and the process of correcting your model.
 ==Visual GUI Testing==

@@ Line 4: / Line 4: @@
 This phase of the project is designed to apply UI testing as well as formal (mathematical) modelling and verification techniques to a small case study:
 * apply mathematical modelling to capture the core behavior of a concurrency scenario in accessing a shared communication channel,
@@ Line 36: / Line 35: @@
 There are three main deliverables for this phase:
-* a single pdf file documenting the outcome of each and every of the following steps,
+* a single pdf file documenting the outcome of each and every of the following activities,
-* a .zip file containing the source code of the  software implemented in different parts, and
+* a .zip file containing the source code of the models (e.g., automata and queries) and the software implemented in different parts, and
 * a self evaluation of your  own effort and the effort by each and every member.
@@ Line 47: / Line 46: @@
 Specify 3 possible scenarios of interaction in the system (in plain English or using a sequence diagram) and simulate them in UPPAAL.
 Subsequently, formulate 3 correctness criteria for your design and model-check them in UPPAAL.
 ==Visual GUI Testing==
-Design at least 5 scenarios of interaction between the client and the server (e.g., login unsuccessful, login successful plus add successful, etc.) and
+Design at least 5 scenarios of interaction  (e.g., communication of ordinary values for different period lengths, attempt to enter out of range values in the GUI, and disconnecting USB channel during communication) and
 code them as scripts in Sikuli.
 Run the tests and make sure that all of them run successfully.
 Perform debugging if necessary.