A mobile application is typically divided into two sides that communicate with each other: the front-end (i.e. what the user can see and interact with on the phone) and the back-end (the hidden ”server” side, which processes requests from the front-end). Ways to improve their production cycle are constantly investigated by corporations such as Applidium, which is a French startup company specialized in mobile applications. For instance, the firm often has to deal with external back-ends that are not properly documented, which makes the development of products intricate. Furthermore, test and documentation files for certain parts of projects are manually written, which is time consuming, and are all largely based on the same information (back-end descriptions). Hence, this information frequently finds itself scattered in different files, sometimes in different versions. Having identified issues that most regularly disrupt the work of the company’s employees, a certain number of goals to solve these are set, such as, notably, centralizing all back-end-related information into one authoritative source, and automatizing the generation of test and documentation files. A tool (in the form of a web application) allowing users to describe back-ends, called Pericles, is then proposed as the outcome of the master thesis, to deal with the described problems and materialize the defined objectives. Finally, a qualitative evaluation is performed through a questionnaire designed to assess how users feel the tool helps them in their work, which constitutes the metric for this project. The evaluation suggests that the implemented tool is relevant with respect to the fixed goals, and allows to infer its propensity to help Applidium’s developers and project managers by making the development and validation of projects easier.

NoSQL databases are becoming increasingly more popular due to their undeniable advantages in the context of storing and processing big data, mainly horizontal scala- bility and the lack of a requirement to define a data schema upfront. In the absence of explicit schema, however, an implicit schema inherent to the stored data still exists and can be inferred. Once inferred, a schema is of great value to the stakeholders and database maintainers. Nevertheless, the problem of schema inference is non-trivial and is still the subject of ongoing research. We explore the many aspects of NoSQL schema inference and data modeling, analyze a number of existing schema inference solutions in terms of their inner workings and capabilities, point out their shortcomings, and devise (1) a novel horizontally scalable approach based on the Apache Spark platform and (2) a new NoSQL Schema metamodel capable of modeling i.a. inter-entity referential relation- ships and deeply nested JSON constructs. We then experimentally evaluate the newly designed approach along with the preexisting solutions with respect to their functional and performance capabilities. 1

Táto práca sa zaoberá fuzz testovaním REST API. Po prezentovaní prehľadu techník používaných pri fuzz testovaní a posúdení aktuálnych nástrojov a výskumu zameraného na REST API fuzz testovanie, sme pristúpili k návrhu a implementácii nášho REST API fuzzeru. Základom nášho riešenia je odvodzovanie závislostí z OpenAPI formátu popisu REST API, umožňujúce stavové testovanie aplikácie. Náš fuzzer minimalizuje počet po sebe nasledujúcich 404 odpovedí od aplikácie a testuje aplikáciu viac do hĺbky. Problém prehľadávania dostupných stavov aplikácie je riešený pomocou usporiadania závislostí tak, aby sa maximalizovala pravdepodobnosť získania potrebných vstupných dát pre povinné parametre, v kombinácii s rozhodovaním, ktoré povinné parametre môžu využívať aj náhodne generované hodnoty. Implementácia je rozšírením Schemathesis projektu, ktorý generuje vstupy za pomoci Hypothesis knižnice. Implementovaný fuzzer je použitý na testovanie Red Hat Insights aplikácie, kde našiel 32 chýb, z čoho jednu chybu je možné reprodukovať len za pomoci stavového testovania.