-
Notifications
You must be signed in to change notification settings - Fork 0
Expand file tree
/
Copy pathTesting.html
More file actions
269 lines (249 loc) · 13.4 KB
/
Testing.html
File metadata and controls
269 lines (249 loc) · 13.4 KB
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
<!DOCTYPE HTML>
<!--
Editorial by HTML5 UP
html5up.net | @ajlkn
Free for personal and commercial use under the CCA 3.0 license (html5up.net/license)
-->
<html>
<head>
<title>UCL Systems Engineering Project: Team 2</title>
<meta charset="utf-8"/>
<meta name="viewport" content="width=device-width, initial-scale=1, user-scalable=no"/>
<!--[if lte IE 8]>
<script src="assets/js/ie/html5shiv.js"></script><![endif]-->
<link rel="stylesheet" href="assets/css/main.css"/>
<!--[if lte IE 9]>
<link rel="stylesheet" href="assets/css/ie9.css"/><![endif]-->
<!--[if lte IE 8]>
<link rel="stylesheet" href="assets/css/ie8.css"/><![endif]-->
<!-- Scripts -->
<script src="assets/js/jquery.min.js"></script>
<script src="assets/js/skel.min.js"></script>
<script src="assets/js/util.js"></script>
<!--[if lte IE 8]>
<script src="assets/js/ie/respond.min.js"></script><![endif]-->
<script src="assets/js/main.js"></script>
<script>
$(function () {
$("#sidebar1").load("Sidebar.html");
});
</script>
</head>
<body>
<!-- Wrapper -->
<div id="wrapper">
<!-- Main -->
<div id="main">
<div class="inner">
<!-- Header --><!--
<header id="header">
<a href="index.html" class="logo"><strong>COMP204P</strong></a>
</header> -->
<!-- Banner -->
<section id="banner">
<div class="content">
<header>
<h1>Testing</h1>
</header>
</div>
</section>
<section id="SpeedTests">
<h2>Speed Tests</h2>
<p>We have run several speed tests including reading data from different resources, generating chart
graphs in front-end and back-end, and so on. Below are the results we got from the speed tests.</p>
<b>Some terminology</b>
<ol>
<li>Random Sample: The random sample with a scalar is a method where we randomly select 1000 samples
and send this to the front end along with a scalar multiple so the number can be multiplied back
up to the real set.
</li>
<li>
JSON Splitting: This is where we split the string with delimiters and count the
resulting array. It happens to be the size of the set.
</li>
<li>Dictionary Size: This is the value of parsing the JSON
string into a Dictionary Object and returning the size of the Dictionary.
</li>
</ol>
<b>Other Information</b>
<ol>
<li>We were unable to obtain results from UDP but from <a
href="http://stackoverflow.com/questions/24648118/in-windows-azure-does-the-cloudblockblob-putblock-method-use-tcp-or-udp-as-the">research</a>
we managed to find that UDP/TCP
speeds were fairly similar. The data is also shown in Figure 5.
</li>
</ol>
<div align="center">
<div style="width: 451px" align="center">
<figure>
<img src="images/t2.png" width="450">
<figcaption>Figure 1: Time to generate charts using different methods against a database on
the
local machine.
</figcaption>
</figure>
<figure>
<img src="images/t3.png" width="450">
<figcaption>Figure 2: Time to generate charts using different methods against the Azure
blob before introduction of storing set sizes.
</figcaption>
</figure>
<figure>
<img src="images/t4.png" width="450">
<figcaption>Figure 3: Time to retrieve a set against the Azure blob using different
methods.
</figcaption>
<p></p>
</figure>
<figure>
<img src="images/t1.png" width="450">
<figcaption>Figure 4: Time comparison between Azure Blob and a local database using JSON
splitting.
</figcaption>
</figure>
<figure>
<img src="images/TcpUdpTest.png" width="450">
<figcaption>Figure 5: Time comparison between TCP and UDP.</figcaption>
</figure>
</div>
</div>
</section>
<section id="UnitTests">
<h2>Unit Tests</h2>
<ol>
<li>
<b>Set Engine</b>
<p>Due to the complexity of some of the functions in the Set Engine it was a bit difficult to
create
automated tests for the Set Engine. (e.g. some processes upload data to the blob which
should not
happen during a test). To overcome this problem we simply added an optimal test parameter to
the Set
Engine which when called will put the Set Engine into test mode.</p>
<figure align="middle">
<img src="images/UnitTest.png" width="700">
<figcaption>Figure 6: Screen shot showing unit tests being run on the Set Engine.
</figcaption>
</figure>
<br>
<p>When in test mode the Set Engine reads from a Test Database and the output is tested against
a set of
known output sets by
calling the CompareSets(TestSet, PredictedSet) function where 'TestSet' is the answer and
'PredictedSet' is the set generated by the Set Engine. Every single item in the Test and
Predicted
Set must match in order for the unit test to pass.</p>
</li>
<li>
<b>REST API</b>
<p>For the REST API we created a series of test for each controller to test against expected and
actual I/O. We retrieved the set in JSON and checked if the set was empty. If the set was
empty then the test case will fail.</p>
<figure align="middle">
<img src="images/APIScreenshots/UnitTests.png" width="600">
<figcaption>
Figure 7: Sample Unit Test for API Controller
</figcaption>
</figure>
</li>
</ol>
</section>
<section id="CompatibilityTests">
<h2>Compatibility Testing</h2>
<p>The Set Engine is meant to work with any relational database without knowing the structure of the
database. In order to test this out we decided to run the Set engine against several different mock
databases we created.<br></p>
<ol>
<li>
<b>Simple airline database (Figure 8)</b>
<figure>
<img src="images/SetEngine/CompatibilityTesting/airportTable.png" width="400">
<figcaption>
Figure 8: Basic database structure of airline company.
</figcaption>
</figure>
<p><br>After running the Set Engine on this database we observed the following database
structure on
the blob. Note that the green icons are sets that can retrieved by front end developers. The
cloud icons (leaf nodes on the tree) are an abstraction of the multiple subsets resulting
from the parent set (the non-leaf node that is green). Each parent set can have up to
hundreds of sub sets hence the cloud icon to represent multiple sets.<br></p>
<figure>
<img src="images/SetEngine/CompatibilityTesting/airportSchema.png" width="800">
<figcaption>
Figure 9: Output structure of the Set Engine on airline company mock database.
</figcaption>
</figure>
<br>
</li>
<li>
<b>Slightly more complex database of a hotel chain (Figure 9)</b>
<figure>
<img src="images/SetEngine/CompatibilityTesting/hotelSchema.png" width="400">
<figcaption>
Figure 10: Database schema of a mock hotel chain.
</figcaption>
</figure>
<p><br>This database is slightly more complex than the airliner database we made. The hotel
chain
database contains foreign keys that are usually used for one-to-many mappings, one-to-one
mappings and many-to-many mappings.<br></p>
<figure>
<img src="images/SetEngine/CompatibilityTesting/hotelBlob.png" width="800">
<figcaption>Figure 11: Output structure of Set Engine after a run on the mock hotel chain
database.
</figcaption>
</figure>
<br>
</li>
<li>
<b>Mock school management database (Figure 12)</b>
<figure>
<img src="images/SetEngine/CompatibilityTesting/schoolSchema.png" width="500">
<figcaption>
Figure 12: Database of school management system.
</figcaption>
</figure>
<p><br>Last but not least we had run our Set Engine against the main school database that we
were
working with. The resulting Blob structure shown in Figure 13.</p>
<figure>
<img src="images/SetEngine/CompatibilityTesting/schoolBlob.png" width="800">
<figcaption>
Figure 13: Structure of the set database created by the Set Engine after a run on a mock
school management database.
</figcaption>
</figure>
</li>
</ol>
</section>
<section id="userTesting">
<h2>User Testing</h2>
<h3>
Methodology
</h3>
<p>The main people using the Web API will be front end developers<br><br>As a result we decided to ask
several computer science students including members from Team 1 whom we were working closely with to
review several API calls on <a href="https://postcodes.io/docs">postcode.io</a> and then obtain
feedback regarding their experience. This was because postcode.io had roughly what we had in mind
and asking users what they liked about it would greatly help us find the best way to make our API as
friendly as possible<br><br>Some students had not used the REST API before so we
guided them on usage. We decided to conduct an open discussion session while the user used the API
as we believed that receiving
feedback while the user was using the product would be the most realistic feedback as it would
reflect closely to what developers were thinking while they were using the API.
</p>
<h3>Conclusion</h3>
<p>
We found that users found it easy to call REST requests from the address bar in their web browser.
More inexperienced users of REST APIs showed more interest in the URI approach whereas a handful of
experienced users used REST tools including Postman to call the REST requests. As a result we
decided to opt for the URI approach as this would be the easiest for beginners to learn.
</p>
</section>
</div>
</div>
<div id="sidebar1"></div>
</div>
</body>
</html>