Testing

This page covers our testing strategies.

To make sure that the data anonymiser produces the correct results, we have used unit tests. We used multiple csv files containing sample data and created the same number of anonymised data sets by hand: replacing the unwanted information with asterixis.
We used these files in our unit tests. Each unit tests creates an automatically generated output file using our tool. The output is then compared with the anonymised dataset we created by hand. If the contents of the two files match, the unit test passes.
More unit tests can be easily added by using new datasets and anonymising them by hand and saving the handmade results in a file.

We tested the main functions of our system by using our tools and doing the tasks which the end users might do with our software.
We also checked for accessibility of our solution. One of the requirements was a high visibility mode for visually impaired users as well as a night mode. We also ran our anonymiser on multiple machines and operating systems to ensure that the majority of the end users will be able to use our tools.
Last, we ensured that our system produces correct error messages for the user in case exceptions happen. For example when our visualiser has no connection to the core analytics an error message is displayed.

We used system testing and black box testing to verify that the two parts of our system which we have developed were working as required. We replaced the core analytics system with a “black box” to simulate how it works, because developing the core analytics system was not the main goal of our project. We verified that the anonymiser produces a correct result. We then created another file which would come out of the core analytics system and sent it to our visualiser which created graphs as expected.

Usability testing: We tested our solution on multiple devices and operating systems to make sure that the end users will be able to use our software.

Stress testing is a type of non-functional testings where we tried to test the whole system beyond normal capacity. For this we used a very large csv file to run through our anonymiser.
After deploying our system on Azure we also sent a large number of automated requests to the core analytics system. We monitored the performance of the system in the Azure online web interface.

Our system seemed to remain fast and reliable, even under these conditions.
Although our systems worked correctly under our load, more stress testing needs to be done before the whole system is deployed in a production environment.

Once the server was fully deployed, tested for performance and system accuracy, we carried out security testing. Firstly, we began with port scanning of the virtual machine to check that only the necessary ports are opened to the public. By ensuring that only the required services are publicly available, attack vectors are reduced the the server is less likely to be compromised.

Next, we considered and carried out security testing of the open ports.

Firstly, with the ssh service, the latest version of the service on the package manager was being used (OpenSSH 7.2p2 Ubuntu 4ubuntu2.4 (Ubuntu Linux; protocol 2.0)) and by using ssh keys, brute force attempts are not feasibly possible. As a result, no additional testing was carried out on the ssh service.

With the HTTP service running on port 80 and the server being identified as PEACH, we ran a web penetration tool on this service and the results are below. With a medium risk level, the security vulnerabilities mainly related to this service are with the lack of TLS and some HTTP headers. As a result, it was decided that for the purposes of this protype, these vulnerabilities did not pose a big threat to the security of the system.

Next, with the another HTTP service, the Python Flask server running on port 5000. The vulnerabilities mainly relate to the lack of HTTPS, missing HTTP headers and software information leakage. Again, it was decided that for the purposes of this protype, these vulnerabilities did not pose a big threat to the security of the system.

Finally, we scanned the Kibana endpoint, which is avaiable on port 5601. With the lack of HTTPS, missing HTTP headers and software leakage, it was noted that for this project prototype, these security vulnerabilities would not impact the system's use.