Update

bibliography.bib

-@book{haddadin2013towards,
-  title={Towards safe robots: approaching Asimov’s 1st law},
-  author={Haddadin, Sami},
-  volume={90},
-  year={2013},
+@book{anirban2015software,
+author = {Basu, Anirban},
+year = {2015},
+pages = {},
+title = {Software Quality Assurance, Testing and Metrics},
+isbn = {978-81-203-5068-7}
+}
+
+@book{saleh2009software,
+  title={Software Engineering},
+  author={Saleh, K.A},
+  publisher={J. Ross},
+  pages={224-241},
+  year={2009}
+}
+
+@book{fielding2000architectural,
+  title={Architectural styles and the design of network-based software architectures},
+  author={Fielding, Roy Thomas},
+  year={2000},
+  publisher={University of California, Irvine}
+}
+
+@article{knuth1968semantics,
+  title={Semantics of context-free languages},
+  author={Knuth, Donald E},
+  journal={Mathematical systems theory},
+  volume={2},
+  number={2},
+  pages={127--145},
+  year={1968},
   publisher={Springer}
 }
 
-@book{goossens94,
-  author    = {Goossens, Michel and Mittelbach, Frank
-               and Samarin, Alexander},
-  title     = {The LaTeX Companion},
-  date      = {1994},
-  publisher = {Addison-Wesley},
-  location  = {Reading, Massachusetts},
-  language  = {english},
-}
-@book{knuth84,
-  author    = {Knuth, Donald E.},
-  title     = {The \TeX book},
-  date      = {1984},
-  maintitle = {Computers \& Typesetting},
-  volume    = {A},
-  publisher = {Addison-Wesley},
-  location  = {Reading, Massachusetts},
-  language  = {english},
-}
-@manual{hanisch14,
-  author    = {Hanisch, Falk},
-  title     = {Ein \LaTeX"=Bundle für Dokumente im neuen Corporate
-               Design der Technischen Universität Dresden},
-  date      = {2014},
-  subtitle  = {Benutzerhandbuch},
-  location  = {Dresden},
-  language  = {german},
+@article{hedin2000reference,
+  title={Reference attributed grammars},
+  author={Hedin, G{\"o}rel},
+  journal={Informatica (Slovenia)},
+  volume={24},
+  number={3},
+  pages={301--317},
+  year={2000}
+}
+
+@inproceedings{ed2018automatic,
+  title={Automatic generation of test cases for REST APIs: A specification-based approach},
+  author={Ed-Douibi, Hamza and Izquierdo, Javier Luis C{\'a}novas and Cabot, Jordi},
+  booktitle={2018 IEEE 22nd international enterprise distributed object computing conference (EDOC)},
+  pages={181--190},
+  year={2018},
+  organization={IEEE}
+}
+
+@inproceedings{karlsson2020quickrest,
+  title={QuickREST: Property-based test generation of OpenAPI-described RESTful APIs},
+  author={Karlsson, Stefan and {\v{C}}au{\v{s}}evi{\'c}, Adnan and Sundmark, Daniel},
+  booktitle={2020 IEEE 13th International Conference on Software Testing, Validation and Verification (ICST)},
+  pages={131--141},
+  year={2020},
+  organization={IEEE}
+}
+
+@inproceedings{martin2020restest,
+  title={RESTest: Black-box constraint-based testing of RESTful Web APIs},
+  author={Martin-Lopez, Alberto and Segura, Sergio and Ruiz-Cort{\'e}s, Antonio},
+  booktitle={International Conference on Service-Oriented Computing},
+  pages={459--475},
+  year={2020},
+  organization={Springer}
+}
+
+@inproceedings{viglianisi2020resttestgen,
+  title={RestTestGen: automated black-box testing of RESTful APIs},
+  author={Viglianisi, Emanuele and Dallago, Michael and Ceccato, Mariano},
+  booktitle={2020 IEEE 13th International Conference on Software Testing, Validation and Verification (ICST)},
+  pages={142--152},
+  year={2020},
+  organization={IEEE}
+}
+
+@inproceedings{atlidakis2019restler,
+  title={Restler: Stateful rest api fuzzing},
+  author={Atlidakis, Vaggelis and Godefroid, Patrice and Polishchuk, Marina},
+  booktitle={2019 IEEE/ACM 41st International Conference on Software Engineering (ICSE)},
+  pages={748--758},
+  year={2019},
+  organization={IEEE}
+}
+
+@article{arcuri2019restful,
+  title={RESTful API automated test case generation with EvoMaster},
+  author={Arcuri, Andrea},
+  journal={ACM Transactions on Software Engineering and Methodology (TOSEM)},
+  volume={28},
+  number={1},
+  pages={1--37},
+  year={2019},
+  publisher={ACM New York, NY, USA}
+}
+
+@inproceedings{hedin2009introductory,
+  title={An introductory tutorial on JastAdd attribute grammars},
+  author={Hedin, G{\"o}rel},
+  booktitle={International Summer School on Generative and Transformational Techniques in Software Engineering},
+  pages={166--200},
+  year={2009},
+  organization={Springer}
 }
\ No newline at end of file

sections/introduction.tex

 \chapter{Introduction}\label{ch:introduction}
-Automated testing is one type of software testing which is expected to review, validate software products and find errors in these products. Compared to manual testing, it has a huge benefit in execution of test cases, while test cases are automatically generated. \\
-Also, it might be a meaningful approach to raise the security and quality in web-based software architectures using REST interfaces. \cite{knuth84}, \cite{goossens94}
+Automated testing is one type of software testing which is expected to review, validate software products and find errors in these products. Compared to manual testing, it has a huge benefit in execution of test cases, while test cases are automatically generated. Also, it might be a meaningful approach to raise the security and quality in web-based software architectures using REST interfaces.
 
 % example with [2]
-One kind of testing such architectures is to validate REST interfaces and check if there are errors in them. \\
-In the last years, the OpenAPI Specification\footnote{\url{https://swagger.io/specification}} has become the common way to document the communication endpoints and exchanged data structures. This is useful to test REST interfaces, because it enables the black-box testing approach.
+One kind of testing such architectures is to validate REST interfaces and check if there are errors in them. In the last years, the OpenAPI Specification\footnote{\url{https://swagger.io/specification}} has become the common way to document the communication endpoints and exchanged data structures. This is useful to test REST interfaces, because it enables the black-box testing approach.
 OpenAPI specifications are described as JSON or YAML documents and are defined by a semi-formal specification describing permitted and required elements as well as their semantics. While there is no formal definition of the full OpenAPI language, a meta-schema exists for the JSON Schema parts of the language.
 
 % abstract 
-This paper investigates how such specifications can be used to test interfaces described by them. Since these specifications are tree-shaped, the investigation focuses on a grammar-based analysis approach, reference attribute grammars (RAGs). 
+This paper investigates how such specifications can be used to test interfaces described by them. Since these specifications are tree-shaped, the investigation focuses on a grammar-based analysis approach, reference attribute grammars (RAGs) \cite{hedin2000reference}. 
 This paper also compares already presented REST API automatic testing approaches and examines whether these can also be implemented in RAGs, whether this implementation makes sense at all and whether RAG improves at implementing REST API automated testing. \\
 To sum up, following three questions are formulated as research questions:
 

sections/openapi.tex

@@ -6,8 +6,8 @@ An OpenAPI document with its specification is written in a structured JSON or YA
 OpenAPI specification does not hold on strict definitions and has a tree-shaped structure, which facilitates to use and extend in more than 25 programming languages, while JSON schema is available in them. An example of an OpenAPI document is shown in Listing 2.1.
 
 %Testing OpenAPI (Black-Box)
-This specification is relevant to automated testing of REST APIs, because it enables black-box testing. There are already many interesting approaches [2], [3], [4], [5], [6], more concrete explanations to separate approaches are in section 3. \\
-Black-box testing needs the specification of the REST API (in our case, OpenAPI specification) and generates test cases automatically. OpenAPI specifications are defined semi-formal, so test generations could generate unrealistic or invalid inputs. Nonetheleoss it is a meaningful way to test APIs automatically, because it does not require access to the source code and is available for every API regardless of in which programming language it is implemented or whether it is locally or remotely deployed [7]. \\
+This specification is relevant to automated testing of REST APIs, because it enables black-box testing. There are already many interesting approaches \cite{atlidakis2019restler}, \cite{ed2018automatic}, \cite{karlsson2020quickrest}, \cite{martin2020restest}, \cite{viglianisi2020resttestgen}, more concrete explanations to separate approaches are in \cref{ch:curr-appr}. \\
+Black-box testing needs the specification of the REST API (in our case, OpenAPI specification) and generates test cases automatically. OpenAPI specifications are defined semi-formal, so test generations could generate unrealistic or invalid inputs. Nonetheleoss it is a meaningful way to test APIs automatically, because it does not require access to the source code and is available for every API regardless of in which programming language it is implemented or whether it is locally or remotely deployed \cite{arcuri2019restful}. \\
 
 \begin{lstlisting}[style=unboxed, caption={Example OpenAPI}]
 {

sections/rag.tex

@@ -5,11 +5,11 @@ RAG is an extension of Attribute Grammars (AG) while AG is an extension to conte
 \begin{figure}
 \centering
 \includegraphics[width=\textwidth,height=\textheight,keepaspectratio]{ast}
-\caption{Example AST, motivated by [10]}\label{fig:ast}
+\caption{Example AST, motivated by \cite{hedin2009introductory}}\label{fig:ast}
 \end{figure}
 
 %Attribute Grammar
-The concept of AG was introduced by Knuth [8] as a solution of problems with context-free grammars.
+The concept of AG was introduced by Knuth \cite{knuth1968semantics} as a solution of problems with context-free grammars.
 Context-free grammars (e.g. EBNF, BNF) can only specify syntax with terminal, non-terminal symbols and production rules, but in computer programs it is necessary to define the meaning of semantic rules, data types and values while AGs allow this possible. \\
 In AGs terminal and non-terminal symbols are characterized as attributes and have semantic information and their own values.
 The whole structure of a AG is described in an abstract syntax tree (AST) and every attribute is a node of this AST.
@@ -20,7 +20,7 @@ This situation leads to problems in terms complexity of analysis and extension.
 
 
 %RAG
-In 2000 Hedin has proposed RAG as an object-oriented extension of AG to solve these problems [9].
+In 2000 Hedin has proposed RAG as an object-oriented extension of AG to solve these problems \cite{hedin2000reference}.
 This approach enables the references of attributes as a node in an AST and every property of structured attributes (i.e. sets, dictionaries, lists) can also be references. \\
 If there is a reference attribute stored in an AST, it represents a direct connection from an any node that is freely distant (non-local) and to itself. The value of the referred node is directly usable in the referring node without accessing any other nodes in the AST. An example of an AST in RAG compared to a traditional AST without RAG is shown in Figure 2.1. \\
 Such features of RAG represent advantages over AG, largely in efficiency. It is not necessary to duplicate a same value of a node to another node and semantic functions in a complex data structure can be split into smaller functions which are completely describable in RAG. Consequently, RAG can extend existing grammars and give them more functionalities.
@@ -32,9 +32,9 @@ Such features of RAG represent advantages over AG, largely in efficiency. It is
 \end{figure}
 
 %JastAdd
-An extensible system producing language-based compilers and tools is called, JastAdd. It enables to generate modules and tools based on RAG, where properties of AST to be programmed declaratively. There are already several tools implemented and extended with JastAdd (e.g. ExtendJ, JModelica.org, abc, Soot, McLab, Palacom, etc.(a)) \\
+An extensible system producing language-based compilers and tools is called, JastAdd. It enables to generate modules and tools based on RAG, where properties of AST to be programmed declaratively. There are already several tools implemented and extended with JastAdd (e.g. ExtendJ, JModelica.org, abc, Soot, McLab, Palacom, etc.\footnote{\url{https://jastadd.cs.lth.se/web/applications.php}}) \\
 Generally, JastAdd needs two input data to generate classes written in Java. One input data is a file in ast file where AST nodes are described. With this input a class for every non-terminal node is generated and constructed using defined attributes. Other input data is one of more declarative definitions of corresponding attributes and methods. A graphical model of JastAdd is described in Figure 2.2\\
-Examples are in Listing 2.2 and 2.3 implementing basic arithmetic operations. Listing 2.2 shows how separate AST nodes can be defined in RAG and Listing 2.3 explains a case of how attributes can be implemented, especially synthesized attributes by eq (equation).
+Examples are in Listing 2.2 and 2.3 implementing basic arithmetic operations. Listing 2.2 shows how separate AST nodes can be defined in RAG and Listing 2.3 explains a case of how attributes can be implemented, especially synthesized attributes by eq (equation). \\ \\
 
 \begin{lstlisting}[language=AST,label={lst:example-ast},caption={Example of an AST}]
 Root ::= Def* Exp ;

sections/relatedwork.tex

-\chapter{Current Approaches}\label{ch:curr-appr}
+\chapter{Current Approaches for OpenAPI Testing}\label{ch:curr-appr}
 
-There are already many approaches suggesting to test REST APIs with OpenAPI specifications automatically. Mostly, they are black-box approaches where an access to a source code is irrelevant and use Fuzzing [2] - [6]. Fuzzing is sending unexpected, random data or data providing errors into input interfaces and observing if interfaces are stable and provide expected responses. There is also a white box approach [11] which is not the main research target of this paper, but still an interesting way. \\ This section introduces which approaches have been released so far, how they work and which did they achieve. 
+There are already many approaches suggesting to test REST APIs with OpenAPI specifications automatically. Mostly, they are black-box approaches where an access to a source code is irrelevant \cite{atlidakis2019restler}, \cite{ed2018automatic}, \cite{karlsson2020quickrest}, \cite{martin2020restest}, \cite{viglianisi2020resttestgen}. There is also a white box approach \cite{arcuri2019restful} which is not the main research target of this paper, but still an interesting way. \\ This section introduces which approaches have been released so far, how they work and which did they achieve. 
 
 
 \input{sections/specBasedAppr}

sections/restapi.tex

@@ -2,7 +2,7 @@
 
 %General
 REST API is an API (Application Programming Interface) that conforms the common architectural style for web services, REST (REpresentational State Transfer). \\
-The concept of REST has been proposed by Roy Fielding in 2000 and become the most popular design of modern Web APIs[1].
+The concept of REST has been proposed by Roy Fielding in 2000 \cite{fielding2000architectural}.
 %Constraints
 It offers constraints to increase simplicity, performance, visibility, modifiability, portability and reliability of APIs. \\
 Constraints defined in REST are following: 

sections/testing.tex

 \section{Software Testing}
 
 To understand what this paper is about, it is required to know what is software testing. Software testing is a method to see whether a software product works with its expected functionality and is defect free. The problem without testing is that bugs are expensive or also critical in terms of security. Solving this problem brings the software huge advantages (e.g. effectiveness, stronger security, robust software quality). \\
-There are several classifications in software testing. One classification is related to goals of testing: testing if a software does not have critical bugs (Functional Testing), testing if a software is effective enough (Non-Functional Testing) and modifying an existent software product to correct appeared bugs (Regression Testing) [2]. 
+There are several classifications in software testing. One classification is related to goals of testing: testing if a software does not have critical bugs (Functional Testing), testing if a software is effective enough (Non-Functional Testing) and modifying an existent software product to correct appeared bugs (Regression Testing) \cite{anirban2015software}. 
 If a software product is implemented small enough, it is commonly better to test manually and a tester individually defines test cases. But, in most industrial softwares, like REST APIs, it is necessary to automate tests, because the products are too big and manual testing is too difficult at this point.
 
 %2
-Afterwards, there is a box approach to divide software testing into three categories, black and white Box Testing [1]. Black box tests are developed without knowledge of the internal structure of the system to be tested, but on the basis of development documents. In practice, black box tests are usually not processed by developers of a target software, but by technically oriented testers or by special test departments or test teams. White box tests are developed on the basis of knowledge about the internal structure of the component to be tested. \\
+Afterwards, there is a box approach to divide software testing into three categories, black and white Box Testing \cite{saleh2009software}. Black box tests are developed without knowledge of the internal structure of the system to be tested, but on the basis of development documents. In practice, black box tests are usually not processed by developers of a target software, but by technically oriented testers or by special test departments or test teams. White box tests are developed on the basis of knowledge about the internal structure of the component to be tested. \\
 This paper focuses on automated testing with a black box approach. In section 2.3 the selection of the approach is explained.
 
 

thesis.tex

@@ -13,7 +13,7 @@
 
 \usepackage[
     style=numeric-comp,
-    backend=biber,
+    backend=bibtex,
     url=false,
     doi=false,
     isbn=false,
@@ -132,7 +132,6 @@
 \input{sections/experimentresults}
 \input{sections/conclusion}
 
-
 \printbibliography[heading=bibintoc]\label{sec:bibliography}
 
 %\appendix