Embed Size (px)
Citation preview
Test plan and report of RUTO SNS prototype
CONTENTS
1. Test Plan ......................................................................................................................... 2
1.1 Black box testing plan ...................................................................................................... 2
1.2 White box testing plan .................................................................................................... 4
1.3 Security and robustness testing plan .............................................................................. 5
2. Progress Report ..................................................................................................................... 6
2.1 Unit testing report ........................................................................................................... 6
2.2 Code inspection report .................................................................................................. 13
2.3 Fixing previous defects .................................................................................................. 18
3. Stress Testing Report ........................................................................................................... 19
3.1 Shoe Test ....................................................................................................................... 19
3.2 Attack Plan ..................................................................................................................... 19
3.3 Scalability Test Plan ....................................................................................................... 21
4. Defect Log ............................................................................................................................ 24
5. Response to Demo Concerns....................................................................................... 25
Test plan and report of RUTO SNS prototype
Prepared by:
Rongxin Du ([email protected]) Qiang Deng([email protected])
Chao Song ([email protected]) Jen-Po Cheng ([email protected])
1. Test Plan
1.1 Black box testing plan
Black box testing attempts to force behavior (outcome) that doesn't match specification.
However, sometimes in practice, we probably need to adopt the concept of Grey-box and look at
code to implement test harness. Generally, we plan to test if our complete and save user
information component (CompleteInfo.jsp and SaveUserInfo.java) can correctly save user data
into database and also handle various invalid input values. To put it in detail, we mainly focus on
the checkError() function module as the testing unit here, on which, we perform all the black box
and white box testing cases. Besides, we agree to apply the Equivalence partitioning, Boundary
value analysis and Metamorphic testing criterions to generating different test cases.
We planned to use Junit and Clover to conduct the black box testing.
Firstly, with respect to equivalence partitioning, we divided our input into several
equivalence classes, any of which was composed of a set of carefully chosen valid or invalid
values or states and represented a typical input situation. Correspondingly, we also had the related
output equivalence classes, which covered the expected and unexpected results. There are mainly
3 categories of input types, which are classified according to html component, 1) input text box:
string, number, date; 2) radio button as input; 3) pull down menu as input. Based on these 3
categories, we can generate a series of test cases that can cover as many input possibilities as
possible.
Input Equivalence Classes Partition
Class 1: All the options on the Complete Information page are filled in with valid values;
Class 2: All the options on the Complete Information page are left blank;
Class 3: Some of the options on the Complete Information page are filled in with valid values,
some are left blank, while, some are filled in with invalid values.
Class 4: All the input text boxes are filled in with valid values, while all the radio button groups
and check boxes are left unchosen;
Class 5: All the input text boxes are filled in with valid values, all the radio button groups are
chosen, while all the check boxes are left unchosen.
…… just name a few cases here ……
Range boundary values Test
In this section, we plan to focus on the range boundary of the length of input string, the size
and format of input zipcode and birthday. Under this goal, we generate the following testing cases:
1) length range of input string: English letters, Chinese characters, null string, normal length
string(1-254), long string(255-999), extremely long string(>1000);
2) size and format of input zipcode: assume that we narrow down our users to American citizens,
the standard zipcode in the US is 5-digit and without letters. For size range test, input 0-digit, [1,
5]-digit, and >5-digit zipcode respectively. For format testing, input invalid zipcode that contains
letters or strange characters other than digits.
3) size and format of input date/birthday: we define the input date/birthday format as mm/dd/yyyy
and we expect our users to input a length-10 date like this. The size and format testing cases here
are similar to those in part 2).
Output Equivalence Classes Partition
Class 1: Expected and meaningful output;
Class 2: Expected and meaningless output;
Class 3: Unexpected and meaningful output;
Class 4: Unexpected and meaningless output;
Class 5: SQL exception or database error.
Metamorphic Properties
Suppose that we have 10 options O1, O2, O3, O4, O5, O6, O7, O8, O9, O10 to fill in on the
complete information page, the metamorphic properties here will be:
1. (O1, O2, O3, O4, O5, O6, O7, O8, O9, O10) = (O1, O2)+O3+(O4, O5)+(O6, O7, O8)+( O9,
O10)
The left of the above equation means that we complete all the options at one time, while the
right of the above equation means that we might complete the options (basic personal details,
location, hobbies, etc) in several steps or times. That is to say, we might input (O1, O2) for the
first time, O3 for the second time, (O4, O5) for the 3rd time, and so on. Accordingly, the expected
output(information saved in back-end database) should be same, whether a user chooses to
complete his/her personal information once for all or in several times.
2. (O1, O2, O3, O4, O5, O6, O7, O8, O9, O10) = (O1, O2)+(O2, O3)+(O4, O5, O6, O7)+(O6, O7,
O8, O9)+( O9, O10)
Equation 2 means that a user might edit some options he/she filled in for last time, but this
doesn‟t have any effects on the final result.
3. (O1, O2, O3, O4, O5, O6, O7, O8, O9, O10) = (O6, O7, O8, O9, O10, O1, O2, O3, O4, O5)
Equation 3 means that the order by which a user choose to fill in all the options has no impact
on the final result.
1.2 White box testing plan
For white box unit testing, we planned to check which lines of code are not covered by black
box unit testing. And we planned to add more cases to cover those statements. To design
additional test cases for white box unit testing, we read through the code of that unit carefully and
try to figure out which part of code is not covered by test cases yet. In order to make sure that the
test cases can cover all the statements, the paths, and the branches, we planned to use the Clover
plugin to Eclipse and test the code coverage of checkErrror() module in Eclipse IDE.
White box testing is generated by reviewing the code and also the code coverage percentage
of black-box testing. For example, if the black box test unit cases never trigger the following
statement:
if (gender == null) {
gender = "";
}
Or the code coverage percentage is very low (less than 90%), then it will become necessary
to add more test cases which leave gender to be null to test this branch. The basic principle is that
the white box testing should cover all the loops, try and catch blocks, if-else blocks and other
non-trivial blocks except for some error handle exception.
1.3 Security and robustness testing plan
A safe and robust software should not cause physical or economic damage in the event of
system failure. Malicious users should not be able to access or damage the system. (cited from the
textbook)
We perform the security and robustness testing plan in the following aspects:
1) malicious Java script injection. (">", "<", "#", "%");
2) direct access via inputting URL; (e.g: input http://localhost:8080/RUTOdemo-war/AdminPage
to try to access the admin account , http://localhost:8080/RUTOdemo-war/Login to try to access
the login servlet without inputting required email and password, input
http://localhost:8080/RUTOdemo-war/CompleteInfo.jsp to directly complete user information
without log in at first)
3) inject " or ' to affect SQL query;
4) log in the admin console of glassfish to break the whole application;
5) use loading/scalability testing software (such as SmartBear and Jmeter) to simulate very large
numbers of accesses simultaneously.
2. Progress Report
2.1 Unit testing report
The unit we choose to apply unit testing is the input validation unit of completeUserInfo
module. This unit validates the input and returns the number of input errors. A return value of 0
means the input are all valid. We narrow down the scope of original unit mentioned in the last
report from completeUserInfo module to saveUserInfo module. Because the prior unit covers too
many functions, including input validation, comparison between current information and old
information, insert entries to database and remove entries from database, the entire
completeUserInfo module is too big to be considered as a unit. As a result, we turn to test
saveUserInfo module which contains a list of inputs as follows.
Name Type
First Name Text Box
Last Name Text Box
Choose Your State Drop Down List
City Text Box
Address1 Text Box
Address2 Text Box
Input your zipcode Text Box
Birthday Text Box
Gender Radio Button
Relationship status Radio Button
Other Text Box
Choose Your School Drop Down List
According to their different input type and different characteristics, we divide them into 5
categories. They are:
1) 1st Category: input String
Name Type
First Name Text Box
Last Name Text Box
City Text Box
Address1 Text Box
Address2 Text Box
Other Text Box
2) 2nd Category: input number
Name Type
Zip code Text Box
3) 3nd Category: input date
Name Type
Birthday Text Box
4) 4th Category: pull down menu as input
Name Type
Choose Your State Drop Down List
Choose Your School Drop Down List
5) 5th Category: radio button as input
Name Type
Gender Radio Button
Relationship status Radio Button
Input Equivalence Class Partition
For each of the 5 categories, we have different equivalence class partitions.
For the first category, all of them requires strings. So the equivalence class partition is as follow:
Class 1: string length over 255
Class 2: string contains “<” or ”>”
Class 3: other strings considered as valid.
For the 2nd category, the input is zipcode. So the equivalence class partition is:
Class 1: string length not equal to 5
Class 2: string contains not only numbers
Class 3: other strings considered as valid
For the 3rd category, the input is birthday. So the equivalence class partition is:
Class 1: string follow format mm/dd/yyyy where m,d,y are digits are considered as valid
Class 2: other strings.
For the 4th category, the input are drop down lists. So the equivalence class partition is:
Class 1: Leave empty
Class 2: A row is selected
For the 5th category, the input are radio buttons. So the equivalence class partition is:
Class 1: Leave none selected
Class 2: A option is selected
Since our input validation only check strings, there are no obvious boundary values for our
input. However, we think we can treat the boundary between different partition classes as
boundary values. Thus, for example, for the 1st category, one boundary value could be string with
exact length of 255. Another boundary value could be a string contains a „<‟, since by having this
„<‟ in the string, the string goes from valid to invalid. This same method of determining boundary
values may apply to all the other categories we defined.
Here is a list of our test cases and expected output. We test each of our categories separately.
When one category is tested, all the other categories‟ value are default values.
1) 1st Category Testing cases
Test
Case ID
First Name Last
Name
City Address1 Address2 other Output
1 (empty) (empty) (empty) (empty) (empty) (empty) 12
2 First Name (empty) (empty) (empty) (empty) (empty) 11
3 (empty) Last (empty) (empty) (empty) (empty) 11
Name
4 (empty) (empty) City (empty) (empty) (empty) 11
5 (empty) (empty) (empty) Address1 (empty) (empty) 11
6 (empty) (empty) (empty) (empty) Address2 (empty) 11
7 (empty) (empty) (empty) (empty) (empty) other 11
8 Chao Song (empty) (empty) (empty) (empty) 10
9 (empty) (empty) NYC 362 Riverside
Drive
#4B10 (empty) 9
10 (empty) (empty) (empty) (empty) (empty) CS 11
11 <alert> (empty) (empty) (empty) (empty) (empty) 12
12 aaa...(long
string)
(empty) (empty) (empty) (empty) (empty) 12
2) 2nd Category Testing cases
Test
Case ID
Zip code Output
1 10025 11
2 100025 12
3 zipcode 12
4 (empty) 12
5 111...(long string) 12
3) 3rd Category Testing cases
Test
Case ID
Birthday Output
1 11/11/2011 11
2 2011-11-11 12
3 birthday 12
4 (empty) 12
5 111...(long string) 12
4) 4th Category Testing cases
Test
Case ID
Choose Your State Choose Your School OutPut
1 Choose Your State Choose Your School 12
2 New York Choose Your School 11
3 Choose Your State Columbia University 11
4 New York Columbia University 10
5) 5th Category Testing cases
Test
Case ID
Gender Relationship status Output
1 Leave Empty Leave Empty 12
2 Male Leave Empty 11
3 Leave Empty Single 11
4 Female Married 10
Metamorphic property
One Metamorphic property of our test unit is that you can do permutation and combination of
our original test cases and generate new test cases. The result could be calculate as
12-(12-ret1)-(12-ret2). For example, in one test case the output is 11, in another test case the
output is also 11, then the combination of these two cases could generate another test case, whose
output is 10.
Here is the list of the actual extra test cases we tested which are generated from metamorphic
property.
P
art 1
Part 2 Part 3 Part 4 Part 5 Output
1 4 4 1 1 12
9 1 1 4 4 3
11 1 1 4 4 6
12 4 1 4 4 7
8 1 5 4 4 5
7 3 2 4 3 8
So far all the above testing is considered as the Black Box testing. There may be some cases
we failed to consider, and thereby we must apply the White Box testing in order to ensure that all
cases have been covered. Prior to doing the White box testing, we turn to use the eclipse combined
with Clover to test the code coverage of our unit testing. As the figure shown below, we can see
the result of our Black Box testing have covered the saveUserInfo module about 96.6%.
After the above testing, we know the else part as below in the saveUserInfo module is
marked in red automatically using Clover.
if (zipcode.length() != 5) {
numError++;
} else {
try {
Integer.parseInt(zipcode);
} catch (NumberFormatException e) {
numError++;
}
}
This is the case that the length zip code is five, however, it can not be converted into proper
numbers. We have added two extra test cases to cover this issues: SimpleTest_37.java and
SimpleTest_38.java. For example, in SimpleTest_37, we let the zipcode = "zipco" to trigger the
else part of the above codes.
public class SimpleTest_37 {
...
public SimpleTest_37() {
}
@Test
public void test(){
SaveUserInfo tttt = new SaveUserInfo();
String firstname = "";
String lastname = "";
String gender = "";
String Rs = "Single";
String Eb = "Columbia University";
String address1 = "";
String address2 = "";
String city = "";
String zipcode = "zipco";
String state = "New York";
String other = "other";
String birthday = "2011-11-11";
assertEquals("Result", 8, tttt.checkError(firstname, lastname, gender, Rs, Eb, address1,
address2, city, zipcode, state, other, birthday));
}
We make a final coverage test and then have a result of 100% coverage in SaveUserInfo
module eventually.
2.2 Code inspection report
The code inspection was held at 2:30 pm on December 1st in 6LE1 of CEPSR. It lasted
approximately 30 minutes. All team members including Rongxin Du, Qiang Deng, Chao Song and
Jen-Po Cheng and our TA Mayank Talwar were present. Documentation was done following the
inspection.
The code inspection task was done by a group of five members going through the same piece
of code. Each individual took down notes and the flaws were later fixed by the original
programmer of that code. In the meeting, Chao Song acted as reader, Qiang Deng was recorder.
Rongxin Du and Jenpo Cheng were inspector. Mayank was moderator.
First, the reader gave a brief overview of the work accomplished and a general introduction
to the function and organization of the unit been tested. Then code was analyzed line by line
followed the code inspection checklist we implemented in the second iteration plan. During the
process, all the members came up with their suggestions and questions in order to find out errors
or flaws.
Not too many defects were found in the code. Most of the issues were due to insufficient
exception handling process. Generally the code were comment fine, class, function and parameters
were named readable and logical design was fine. No part of the code needed to be re-written due
to logical errors. The biggest problem lies in the exception handling process. Exception handling
should be added when update, delete and other action were taken.
The unit mainly implements the function of recommending friends based on their personal
information.
The checklist was used during the whole process of code inspection. We followed the defined
checklist to view the code and exam the logic and grammar design. The detailed information are
listed below.
Code Inspection Checklist
1. Unit Design
Is the functionality described in the concept plan fully implemented by the code?
Yes. The unit fully realized recommending friends function as we previously designed in the
concept plan. The RUTO system can compute the similarity base on users‟ hobbies, location,
education background and other personal information. Also, the system could list out the
recommended friends in a decreasing order of similarity.
Does the code conform to the java coding standard?
Basically yes, but some syntax errors were found during code inspection. For example, we had a
session bean called RUTObeingFacade. When this session bean was called, Netbeans
automatically name the session bean as rUTObeingFacade while according to the java convention,
it should be named as RUTOBeingFacade.
2. Initialization and Declarations
Are variables and class members of the correct type?
Yes. All the variables and class members were claimed in the right place and in the correct type.
For example, the variables to store user‟s email and gender were defined as email (String) and
gender (String) respectively. The function of initiating variables was named initiate(). The
function of getting current user‟s information was named getCurrentUserInfo.
Are all object initialized?
Yes. All objects were initialized. We implemented a function to initiate variables and objects that
were global.
Do the name of variables and functions in a uniform style and convey correct meaning?
Yes. Our variables and functions were named by a uniform style like educationBackground,
labelMatch(), locationMatch(). The name also convey meaningful and readable message which
clearly indicated the function of the variable and function.
3. Call Function
Are parameters used correctly?
Yes. All the parameters were used in the right way. The parameters were in correct type when
calling a function. For example, the function labelMatch (RUTObeing pairuser, UserPriority up)
was called in this way: labelMatch (pairuser, up).
Is the correct method being called?
Yes. By calling the correct method, the system worked properly. For example, when we want to
get the current user‟s information, we called getCurrentUserInfo. When the system computes the
label similarity of the pair user, it calls labelMatch.
Do the methods return proper values?
This unit contains functions that are all void type. There‟s no return of these functions.
Are all objects (including Strings) compared with "equals" and not "=="?
Yes. We carefully handled the situation when two objects were required to compare. For instance,
when we compare the email of two users our code is like: email.equals(tmp.getUseremail()).
4. Output Correction
Is output easy to understand and free of spelling errors?
Yes. We output the information in a way that is easy to understand by users. For instance, we
output the similarity between two users‟ similarity score, email address and other personal
information. After examining, there‟s no spelling error.
Are error messages comprehensive and provide guidance as to how to correct the problem?
This is one of the main drawbacks found in the code inspection. The system only catches errors at
places like IO operation and throws system exception. We didn‟t provide sufficient function to
catch errors and therefore, lack of comprehensive error message provided. In order to fix the
problem, we will implement exception handling procedure in the places that the system may crush
or when deleting, updating and other action are taken. Moreover, we will also develop our own
exception class to improve efficiency.
5. Computation, Comparisons and Assignments
Are all denominators of a division prevented from being zero?
Yes. We eliminate the possibility that the division may be zero. One of the examples is
item.getPriority() * 100 / (fullscore + 5).
Is integer arithmetic, especially division, used appropriately to avoid causing unexpected
truncation/rounding?
Yes. We paid attention to handle the numeric computing and ensure the variables are in correct
type.
Are the comparison and Boolean operators correct?
Yes. The comparison and Boolean operators act important in the system when the function decides
when to end the loop or other places. For example, in the similarity sorting function, we
implemented a comparison method: return ((p1.getPriority() < p2.getPriority()) ? 1 : 0);
6. Exceptions
Are all relevant exceptions caught?
This is one of the main drawbacks found in the code inspection. The system only catches errors at
places like IO operation and throws system exception. We didn‟t provide function to catch errors
at the proper place. In order to fix the problem, we will implement exception handling procedure
in the places that the system may crush or when deleting, updating and other action are taken.
Moreover, we will also develop our own exception class to improve efficiency.
Is the appropriate action taken for each catch block?
The system catches errors at places like IO operation and throws system exception messages. But
there are some more places should add catch error block. As stated above, we will fix the problem
by developing our own exception class and implementing it in the right places.
7. Flow of Control
Do all loops have appropriate initialization, increment and termination expressions?
Yes. All the loops take correct action in initialization, increment and termination expressions. For
example, we recursively read all the users in the database using: for (Iterator it =
RUTObeing.iterator(); it.hasNext();). The loop will end when all users’ information are read.
8. Logic of Algorithms
Is there any logic problem in this unit?
No. The unit is well designed in the logic. Firstly we read the current user‟s information. Then we
recursively derive all users‟ information from the database and compare with current user in order
to compute the similarity between them. After that, the system output the result.
9. EJB Framework
Does the session bean collaborate with the right entity bean?
Yes. We called the right session bean when we want to use the database in the corresponded entity
bean. For example, private LabelFacade labelFacade; private LocationFacade locationFacade;
private RUTObeingFacade rUTObeingFacade. These session beans are called in this unit in order
to get information from label, location and RUTO database.
Does the entity bean connect with the right database?
Yes. The entity beans are called by the session beans and therefore connect with the right database.
LabelFacade labelFacade, LocationFacade locationFacade, RUTObeingFacade rUTObeingFacade
called label, location and RUTO database respectively.
2.3 Fixing previous defects
1. Very long string: Non-logic problem
The problem has been handled. We limited the length of input up to 255 characters. So that
transaction errors in saving long input into our back-end derby server could be avoided.
2. Malicious input: Non-logic problem
This problem has been fixed. We verified whether the input involved the characters such as >, %,
and < etc, which could be used as keywords of java script.
3. Invalid Zip code: Non-logic problem
This problem has been fixed. We checked the input string and the input type. Input string should
be exactly 5 characters. Input type should be numbers.
4. Variable definition: Non-logic problem
The problem has been fixed. Variable definition are now clarified with private, public or protected.
5. Name conventions: Non-logic problem
The problem has been fixed. Variables and function are named should follow the java name
conventions. We tried to present meaningful information in the names.
6. Variable definition: Non-logic problem
This problem has been handled. Irrelevant comments have been removed.
7. String initiation: Non-logic problem
This problem has been fixed. All string type variables are initiated as NULL.
8. Exception handling: Non-logic problem
The problem has been fixed. Places that may cause system failure are caught with exception
handling.
3. Stress Testing Report
3.1 Shoe Test
We did some sort of shoe test by input tens of thousands of characters to one single text box.
At last, the browser hangs.
3.2 Attack Plan
1) malicious Java script injection. (">", "<"); For example, register a username as <img
src="hello.gif" />.
During this test, we inserted each input text field with JSP <img
src="http://www.google.com/intl/en_com/images/srpr/logo3w.png" /> to see if it is accepted.
2) direct access via inputting URL; (e.g: input http://localhost:8080/RUTOdemo-war/AdminPage
to try to access the admin account , http://localhost:8080/RUTOdemo-war/Login to try to access
the login servlet without inputting required email and password, input
http://localhost:8080/RUTOdemo-war/CompleteInfo.jsp to directly complete user information
without log in at first)
In our test, we tried to access every page and servlet directly via inputting URL. Some of the
URLs we input in the broswer address field are listed as follows:
http://localhost:8080/RUTOdemo-war/AdminPage
http://localhost:8080/RUTOdemo-war/CreateAcount
http://localhost:8080/RUTOdemo-war/DeleteActivity
http://localhost:8080/RUTOdemo-war/Join
http://localhost:8080/RUTOdemo-war/Login
http://localhost:8080/RUTOdemo-war/Activity.jsp
http://localhost:8080/RUTOdemo-war/Answer.jsp
http://localhost:8080/RUTOdemo-war/CompleteInfo.jsp{+}|http://localhost:8080/RUTOdemo-wa
r/CompleteInfo.jsp
3) inject " or ' to affect SQL query; For example, input the following SQL query as a hobby:
'SELECT * FROM USER'
During this test, we inserted each input text field with SQL query 'SELECT * FROM
RUTObeing' to see if it is accepted.
4) log in the admin console of glassfish (port 4848) to break the whole application;
In this test, we would try to login the glassfish admin console, which is on port 4848. We
would try if we have the permission to change server settings.
5) Use Firefox browser plugin Tamper to edit request sent from forms. For example, when
changing the password, before sending the request to the server, use Tamper to edit the content of
the request.
In this test, for each page in which we need to complete forms, we will pause the request and
change the values contained in that request and see if it causes error.
3.3 Scalability Test Plan
We conducted our load test in JMeter. We developed two situations, one is visit our web site
by only login and logout, and the other one is going through a complete visit of our system
including post activity, visit activity, join activity, visit friends and leave message.
The load test was doing under remote wireless internet connection, so the results vary time to
time. Thus, we also compare the time needed to complete the load test in different connections.
visit our web site by only login and logout:
initialize 10 users at the same time
initialize 50 users at the same time
initialize 100 users at the same time
initialize 500 users at the same time
initialize 1000 users at the same time
a complete visit:
initialize 10 users at the same time
initialize 50 users at the same time
initialize 100 users at the same time
initialize 500 users at the same time
initialize 1000 users at the same time
Test results (only informative pictures are included):
A complete visit:
The visit time range:
When there are 1000 users visiting the website, the first user connect would be 1693 ms and
the first 25 users are below 2000 ms ( which is a tolerable to users):
When the testing connection between the server and client is good enough, the first user
connect would be much better:
When there are 1000 users visiting the website, the connect time from 76 to 100 is much
higher:When there are 1000 users visiting the website, the connect time from 76 to 100 is much
higher:
When the connection is good, users could get response in around 5000 ms even there are 200
users:
Typically, when more than 300 users in the system, the response time will exceed 10 seconds:
As we can see from the test results above, the system works well under different situations.
Generally, the response time for users are good enough if the number of users are less than 25 or
50. The response time are acceptable when there are less than 100 users regardless of the condition
of internet connection. While the response time gets much slower if the user number exceeds 200.
4. Defect Log
Bugs found in stress testing including the following aspect:
1) Shoe test fails. After we typed in tens of thousands of characters, the browser hung. We fixed
this problem by restricting the maximum number of characters that can be typed in in a text box to
250.
2) We were able to access a page directly by entering URL. We fixed this problem by adding
authentication check at the beginning of each Page/Servlet.
3) We were able to connect to glassfish admin console and do whatever we wanted. We fixed this
problem by using a firewall to block the network communication of port 4848.
4) We were able to use Tamper to fake a http request and get access to another user‟s data. Due to
limited amount of time, we could not manage to fix it before the deadline.
5. Response to Demo Concerns
During the demo, three questions has been asked.
Firstly, Mayank asked whether we had done any load testing. At that time, we did not have
the time to do a comprehensive load testing. But now we have quite a lot of load testing results.
Secondly, Jon asked us why he completed the form correctly but still got “invalid input” error.
The problem is that the education background field is not completed. The reason why this field is
important is that in our RUTO system, education background is an important information to for
people to find like-minded friends.
Finally, Prof. Kaiser asked us whether we did semantic checking for input values. The answer
is no. Because we do not have enough time and knowledge to do that. For example, in order to
match address with zip code, we will need to know a lot of new techniques, introducing new
dataset. That is a lot of work.
