diff --git a/bibliography.bib b/bibliography.bib
index f7dd294535f377937ab515beb258aad36f878f26..4a6abf8012b38c3b9ce02d57936fd1eb2e1601fa 100644
--- a/bibliography.bib
+++ b/bibliography.bib
@@ -115,3 +115,41 @@ isbn = {978-81-203-5068-7}
year={2018}
}
+@article{mey2020reusing,
+ title={Reusing Static Analysis across Different Domain-Specific Languages using Reference Attribute Grammars},
+ author={Mey, Johannes and K{\"u}hn, Thomas and Sch{\"o}ne, Ren{\'e} and Assmann, Uwe},
+ journal={arXiv preprint arXiv:2002.06187},
+ year={2020}
+}
+
+@inproceedings{ekman2007jastadd,
+ title={The jastadd extensible java compiler},
+ author={Ekman, Torbj{\"o}rn and Hedin, G{\"o}rel},
+ booktitle={Proceedings of the 22nd annual ACM SIGPLAN conference on Object-oriented programming systems, languages and applications},
+ pages={1--18},
+ year={2007}
+}
+
+@inproceedings{fors2020principles,
+ title={Principles and patterns of JastAdd-style reference attribute grammars},
+ author={Fors, Niklas and S{\"o}derberg, Emma and Hedin, G{\"o}rel},
+ booktitle={Proceedings of the 13th ACM SIGPLAN International Conference on Software Language Engineering},
+ pages={86--100},
+ year={2020}
+}
+
+@inproceedings{mey2018continuous,
+ title={Continuous model validation using reference attribute grammars},
+ author={Mey, Johannes and Sch{\"o}ne, Ren{\'e} and Hedin, G{\"o}rel and S{\"o}derberg, Emma and K{\"u}hn, Thomas and Fors, Niklas and {\"O}qvist, Jesper and A{\ss}mann, Uwe},
+ booktitle={Proceedings of the 11th ACM SIGPLAN International Conference on Software Language Engineering},
+ pages={70--82},
+ year={2018}
+}
+
+@inproceedings{schone2020connecting,
+ title={Connecting conceptual models using relational reference attribute grammars},
+ author={Sch{\"o}ne, Ren{\'e} and Mey, Johannes and Ebert, Sebastian and A{\ss}mann, Uwe},
+ booktitle={Proceedings of the 23rd ACM/IEEE International Conference on Model Driven Engineering Languages and Systems: Companion Proceedings},
+ pages={1--11},
+ year={2020}
+}
diff --git a/images/ast.pdf b/images/ast.pdf
deleted file mode 100644
index 8e3efd11ebde0d48cc86bc446ee4255ab908f2b0..0000000000000000000000000000000000000000
Binary files a/images/ast.pdf and /dev/null differ
diff --git a/images/astimage.png b/images/astimage.png
new file mode 100644
index 0000000000000000000000000000000000000000..bd5548ed3024a3995d34a8962ff686f8060efa13
Binary files /dev/null and b/images/astimage.png differ
diff --git a/lst.tex b/lst.tex
index 58a67e44fee8d052560af69581eca06407809fb9..c2baae6da663bd8479d7fc373e0d117d144ae1f7 100644
--- a/lst.tex
+++ b/lst.tex
@@ -1,6 +1,15 @@
\usepackage{listings}
\usepackage{inconsolata}
+
+\usepackage{bera}% optional: just to have a nice mono-spaced font
+\usepackage{listings}
+
+\colorlet{punct}{red!60!black}
+\definecolor{background}{HTML}{EEEEEE}
+\definecolor{delim}{RGB}{20,105,176}
+\colorlet{numb}{magenta!60!black}
+
\lstdefinestyle{common-style}{
basicstyle=\small\ttfamily, % the size of the fonts that are used for the code
showspaces=false, % show spaces adding particular underscores
@@ -13,6 +22,87 @@
breakatwhitespace=true, % sets if automatic breaks should only happen at whitespace
keywordstyle={\color{blue}\textbf}, % keywords are blue
commentstyle={\color{gray}}, % comments
+ backgroundcolor=\color{background},
+ literate={\$}{{{\$}}}1,
+ basewidth=0.5em,
+ breakindent=40pt,
+ breakautoindent=true,
+ escapechar=\&,
+ aboveskip={0.1\baselineskip}
+}
+
+\lstdefinestyle{get-style}{
+ basicstyle=\small\ttfamily, % the size of the fonts that are used for the code
+ showspaces=false, % show spaces adding particular underscores
+ showstringspaces=false, % underline spaces within strings
+ showtabs=false, % show tabs within strings adding particular underscores
+% frame=tlrb, % adds a frame around the code
+ framexleftmargin=1em, % space between left part of frame and listing
+ tabsize=2, % sets default tabsize to 2 spacesz
+ breaklines=true, % sets automatic line breaking
+ breakatwhitespace=true, % sets if automatic breaks should only happen at whitespace
+ keywordstyle={\color{blue}\textbf}, % keywords are blue
+ commentstyle={\color{gray}}, % comments
+ literate={\$}{{{\$}}}1,
+ basewidth=0.5em,
+ breakindent=40pt,
+ breakautoindent=true,
+ escapechar=\&,
+ aboveskip={0.1\baselineskip}
+}
+
+\lstdefinestyle{post-style}{
+ basicstyle=\small\ttfamily, % the size of the fonts that are used for the code
+ showspaces=false, % show spaces adding particular underscores
+ showstringspaces=false, % underline spaces within strings
+ showtabs=false, % show tabs within strings adding particular underscores
+% frame=tlrb, % adds a frame around the code
+ framexleftmargin=1em, % space between left part of frame and listing
+ tabsize=2, % sets default tabsize to 2 spacesz
+ breaklines=true, % sets automatic line breaking
+ breakatwhitespace=true, % sets if automatic breaks should only happen at whitespace
+ keywordstyle={\color{olive}\textbf}, % keywords are blue
+ commentstyle={\color{gray}}, % comments
+ literate={\$}{{{\$}}}1,
+ basewidth=0.5em,
+ breakindent=40pt,
+ breakautoindent=true,
+ escapechar=\&,
+ aboveskip={0.1\baselineskip}
+}
+
+\lstdefinestyle{delete-style}{
+ basicstyle=\small\ttfamily, % the size of the fonts that are used for the code
+ showspaces=false, % show spaces adding particular underscores
+ showstringspaces=false, % underline spaces within strings
+ showtabs=false, % show tabs within strings adding particular underscores
+% frame=tlrb, % adds a frame around the code
+ framexleftmargin=1em, % space between left part of frame and listing
+ tabsize=2, % sets default tabsize to 2 spaces
+ breaklines=true, % sets automatic line breaking
+ breakatwhitespace=true, % sets if automatic breaks should only happen at whitespace
+ keywordstyle={\color{red}\textbf}, % keywords are blue
+ commentstyle={\color{gray}}, % comments
+ literate={\$}{{{\$}}}1,
+ basewidth=0.5em,
+ breakindent=40pt,
+ breakautoindent=true,
+ escapechar=\&,
+ aboveskip={0.1\baselineskip}
+}
+
+\lstdefinestyle{put-style}{
+ basicstyle=\small\ttfamily, % the size of the fonts that are used for the code
+ showspaces=false, % show spaces adding particular underscores
+ showstringspaces=false, % underline spaces within strings
+ showtabs=false, % show tabs within strings adding particular underscores
+% frame=tlrb, % adds a frame around the code
+ framexleftmargin=1em, % space between left part of frame and listing
+ tabsize=2, % sets default tabsize to 2 spaces
+ breaklines=true, % sets automatic line breaking
+ breakatwhitespace=true, % sets if automatic breaks should only happen at whitespace
+ keywordstyle={\color{orange}\textbf}, % keywords are orange
+ commentstyle={\color{gray}}, % comments
literate={\$}{{{\$}}}1,
basewidth=0.5em,
breakindent=40pt,
@@ -59,3 +149,69 @@
\lstdefinestyle{AST} { language=AST,style=common-style }
\lstdefinestyle{JRAG} { language=JRAG,style=common-style }
\lstdefinestyle{Java} { language=Java,style=common-style }
+
+\lstdefinelanguage{GET}{
+ style=get-style,
+ morekeywords={GET},
+ otherkeywords={::=,->,<,>},
+ morecomment=[l]{//}, morecomment=[s]{/*}{*/},
+}
+
+\lstdefinelanguage{POST}{
+ style=post-style,
+ morekeywords={POST},
+ otherkeywords={::=,->,<,>},
+ morecomment=[l]{//}, morecomment=[s]{/*}{*/},
+}
+
+\lstdefinelanguage{DELETE}{
+ style=delete-style,
+ morekeywords={DELETE},
+ otherkeywords={::=,->,<,>},
+ morecomment=[l]{//}, morecomment=[s]{/*}{*/},
+}
+
+\lstdefinelanguage{PUT}{
+ style=put-style,
+ morekeywords={PUT},
+ otherkeywords={::=,->,<,>},
+ morecomment=[l]{//}, morecomment=[s]{/*}{*/},
+}
+
+\lstdefinelanguage{json}{
+ basicstyle=\small\ttfamily,
+ breaklines=true,
+ frame=lines,
+ backgroundcolor=\color{background},
+ literate=
+ *{0}{{{\color{numb}0}}}{1}
+ {1}{{{\color{numb}1}}}{1}
+ {2}{{{\color{numb}2}}}{1}
+ {3}{{{\color{numb}3}}}{1}
+ {4}{{{\color{numb}4}}}{1}
+ {5}{{{\color{numb}5}}}{1}
+ {6}{{{\color{numb}6}}}{1}
+ {7}{{{\color{numb}7}}}{1}
+ {8}{{{\color{numb}8}}}{1}
+ {9}{{{\color{numb}9}}}{1}
+ {:}{{{\color{punct}{:}}}}{1}
+ {,}{{{\color{punct}{,}}}}{1}
+ {\{}{{{\color{delim}{\{}}}}{1}
+ {\}}{{{\color{delim}{\}}}}}{1}
+ {[}{{{\color{delim}{[}}}}{1}
+ {]}{{{\color{delim}{]}}}}{1},
+}
+
+\lstdefinestyle{rest}{
+ breaklines=true,
+ frame=lines,
+ backgroundcolor=\color{background},
+ emptylines=1,
+ breaklines=true,
+ basicstyle=\ttfamily\color{black},
+ moredelim=**[is][\color{violet}]{@}{@},
+ moredelim=**[is][\color{orange}]{~}{~},
+ moredelim=**[is][\color{cyan}]{<}{>},
+ moredelim=**[is][\color{brown}]{ABCD}{ABCD},
+ moredelim=**[is][\color{olive}]{V}{V},
+}
\ No newline at end of file
diff --git a/sections/background.tex b/sections/background.tex
index d06a2d41d16b6def4a0da4db3743f271fb966a7e..1d6029fc4f63cc4b7c23401bbb3868ef6d4af679 100644
--- a/sections/background.tex
+++ b/sections/background.tex
@@ -1,5 +1,5 @@
\chapter{Background}\label{ch:background}
-In this Chapter, concepts and technologies related and used as the basis of this work are presented.
+In this Chapter, we present basis concepts and technologies of this work to understand the following contents after this chapter.
\input{sections/testing}
\input{sections/restapi}
diff --git a/sections/benefits.tex b/sections/benefits.tex
index d78b70dacbd85be019d45a5a485cd90b91ed5fb8..4f37096ee23f2398c9d455cb11373300c85ec1b9 100644
--- a/sections/benefits.tex
+++ b/sections/benefits.tex
@@ -4,14 +4,12 @@
\item{\textbf{RQ3 : Which advantages can RAG provide with its features at expressing testing approaches?}}
\end{description}
-% General
-
% Helpful attributes (Collection, inherited, easier return with =)
During the implementation phase of parameter inference, RAG was beneficial at writing codes. At writing codes for parser and back-transformation, attributes could not be applied, because the functional parts change the structure of AST, which conflicts to the definition of attribute and also in JastAdd. So, it could not be realized that attributes can be practical. But, following attributes and features of JastAdd were helpful to construct the generators and implement them:
\begin{itemize}
-\item As long as a returning value can be called or storable by an AST node, the syntax in RAG is reduced with an equals sign and simpler than in common programming language. Therefore, the source codes are compact. To compare how RAG could be implemented effectively, see the implementation of an attribute in this work in Listing~\ref{lst:attribute-infParam} and how this attribute is defined in common Java description in Listing~\ref{lst:java-infParam}.
-\item To iterate all paths available in OpenAPI, an inherited attribute facilitated the writing effort. Paths Objects are child nodes of OpenAPI Object, so, all that should have been done was only two lines of code instead of writing an extra for loop. See Listing~\ref{lst:inherited}.
+\item As long as a returning value can be called or storable by an AST node, the syntax in RAG is reduced with an equals sign and simpler than in common programming language. Therefore, the source codes are compact. To compare how RAG could be implemented effectively, see the implementation of an attribute in this work in Listing~\ref{lst:attribute-infParam} and how it is defined in common Java description in Listing~\ref{lst:java-infParam}.
+\item To iterate all elements available in a node, an inherited attribute facilitated the writing effort. Paths Objects are child nodes of an OpenAPI Object, so, all that should have been done was only two lines of code instead of writing an extra for-loop. See Listing~\ref{lst:inherited}.
\item Nodes described as References could refer objects with a collection attribute. Listing~\ref{lst:rago-ast} shows how attributes for such purpose look like.
\end{itemize}
@@ -37,6 +35,7 @@ eq OpenAPIObject.getPathsObject(int i).inferUrl(){
\end{lstlisting}
% Extension
+Additionally, JastAdd frameworks developed so far could improve testing methods in RAGs. Improvements with those extensions are huge advantages of RAG. ExtendJ, previously JastAddJ, is a Java compiler extended with JastAdd \cite{ekman2007jastadd}. It improves Java compliance, compilation speed, specification size and the support for non-trivial extensions compared to other extensible Java compilers. Analyses suggested in RAG \cite{fors2020principles}, e.g. Name Analysis, Type Analysis, might also be usable at parameter inference, which the name inference in this paper uses the similar pattern as Name Analysis (Lookup). Relational Reference Attribute Grammars \cite{mey2018continuous} could improve problems with references and enable to build a new test model and connect it to the OpenAPI model implemented in this paper, parallel to \cite{gotz2018jastadd}, \cite{mey2020reusing}. A recently invented framework, RagConnect, enables to connect RAG-based models to models with other basis \cite{schone2020connecting}. Since version 0.2.1, it has a new model connection with REST and might help at generating test cases, because test cases are based on requests and responses of REST APIs. All of these extensions are open topics, so, it must be worthful to discuss and research how they can be used into OpenAPI Testing to suggest tests with a better quality.
\begin{comment}
> To evaulate how well-suited RAGs are for API testing, we revisit the research questions...
@@ -46,4 +45,14 @@ eq OpenAPIObject.getPathsObject(int i).inferUrl(){
- erweiterbarkeit von RAGs
- https://programming-journal.org/2020/4/15/
- https://scholar.google.de/scholar?hl=de&as_sdt=0%2C5&q=exstensible+java+compiler+hedin&btnG=
+
+ExtendJ - The JastAdd Extensible Java Compiler -> enables static analysis and quality better
+
+relational RAGs (referenzen verbessern, verschiedene ASTs verbinden -> testbeschriebungs-modell und OAPI modell),
+
+RagConnect (https://jastadd.pages.st.inf.tu-dresden.de/ragconnect/use_cases/) - erweiterung für verbindung mit laufzeitumgebungen (weil ein testsystem ja auch ein laufzeitsystem ist, könnte es helfen, mit openapi requests und responses umzugehen. hier könnte der experimentelle REST support helfen):
+
+Design and patterns
+ Lookup (P1) : name analysis for parameter inference
+Expected Type (P3) : type analysis for parameter inference
\end{comment}
\ No newline at end of file
diff --git a/sections/conclusion.tex b/sections/conclusion.tex
index 8713f54ce1c918470bad09d72d784d03cb4002a2..79c984c862ea56f3a97cb66ed419cb196441c259 100644
--- a/sections/conclusion.tex
+++ b/sections/conclusion.tex
@@ -1 +1,9 @@
-\chapter{Conclusion}\label{ch:conclusion}
\ No newline at end of file
+\chapter{Conclusion}\label{ch:conclusion}
+
+In this paper, we have firstly researched which approaches to test REST APIs documented by OpenAPI are developed so far. Most of approaches are based on Fuzzing and use concepts e.g. Parameter Inference, Operation Dependency Inference, Model Transformations, Stateful Dynamic Analysis, etc. to get more sensible results than results in random testing.
+
+% 2
+RAGO API is a first framework that configures OpenAPIs in RAG generates random test requests of an API descriebed in OpenAPI and infers parameters by responses in the API. The OpenAPI model is validated by \textbf{974 APIs} selected in the repository of apis.guru\footref{apis-guru}. This OpenAPI model could be the basis of published testing approaches introduced in this paper or any other test methods and be extended with JastAdd frameworks released already publicly. We have presented an example of an Fuzzing approach and usage of RAGs in attributes. Especially, collection attributes were the most helpful attributes in this work, because it simplified the implementation of references of OpenAPI structures used for grammar and parameter inference.
+
+% 3
+Finally, we have presented several suggestions to extend this tool intended to improve basic functionalities e.g. references with \cite{mey2018continuous} and also to develop new approaches e.g. model transformation with \cite{gotz2018jastadd}, \cite{mey2020reusing}, \cite{schone2020connecting}
\ No newline at end of file
diff --git a/sections/feasibility.tex b/sections/feasibility.tex
index bdcbfd9c0ad5fbe3c79db39c008ae68b5baa0f50..53cedf9154924bb221bf7777733298958eee312c 100644
--- a/sections/feasibility.tex
+++ b/sections/feasibility.tex
@@ -17,4 +17,4 @@ Several of them inference parameters or operations or use test model generation.
To determine an answer of this question, we have constructed a data structure for OpenAPI specification in \Cref{ch:rago} to parse OpenAPI documents and validated the parser with 98 commercial APIs, i.e. the parser taken an OpenAPI document returns the same elements except elements with empty values and sibling elements of references in an OpenAPI document. The input and output documents still semantically are same. In \Cref{ch:stm}, we have also implemented two Fuzzing approaches (Random Testing, Parameter Inference). Parameter Inference is motivated by Specification-based Approach\cite{ed2018automatic} and RESTTESTGEN\cite{viglianisi2020resttestgen}, where seperate properties of responses are collected and used as inputs in a parameter with the same schema of a response.
% 3
-Several approaches are based on their own metamodels. It is not clear yet, whether such model-based approaches could be developed in RAGs. For implementing metamodel generations of approaches in RAGs, a JastAdd- and ILP-based framework \cite{gotz2018jastadd} could be helpful to analyze and solve model problems, because it gives an optimized model solution for a problem described in AST model. Particularly, the OpenAPI structure implemented in this work is much smaller than models denied in \cite{gotz2018jastadd}. So, it could produce an interesting result for model problems in OpenAPI testing.
\ No newline at end of file
+Several approaches are based on their own metamodels. It is not clear yet, whether such model-based approaches could be developed in RAGs. For implementing metamodel generations of approaches in RAGs, JastAdd frameworks \cite{gotz2018jastadd}, \cite{mey2020reusing} could be helpful to transform a model to another model. It is worthful to discuss and research how such frameworks developed already could be applied to those model-based approaches, because it would save an enormous amount of effort at implementing.
\ No newline at end of file
diff --git a/sections/introduction.tex b/sections/introduction.tex
index ded930db55b354e989add1d3d90f527909ebba96..448b2e1e478b93267c0eea194785aafb8971dcd1 100644
--- a/sections/introduction.tex
+++ b/sections/introduction.tex
@@ -16,7 +16,7 @@ To sum up, following three questions are formulated as research questions:
\item{\textbf{RQ3 : Which advantages can RAG provide with its features at expressing testing approaches?}}
\end{description}
-\textbf{RQ1} is intended to investigate which approaches might be able to implement in RAG. Corresponding literatures are introduced in \Cref{ch:curr-appr}. \\ \textbf{RQ2} focuses on the implementation the data structure and testing methods in RAG and is answered in \Cref{ch:rago} and \Cref{ch:stm}. \\ In \Cref{ch:suitability}, Results for \textbf{RQ3} shows concretely which features of RAG are usable and which benefits exist at this point.
+\textbf{RQ1} is intended to investigate which approaches might be able to implement in RAG. Corresponding literatures are introduced in \Cref{ch:curr-appr}. \textbf{RQ2} focuses on the implementation the data structure and testing methods in RAG and is answered in \Cref{ch:rago} and \Cref{ch:stm}. In \Cref{ch:suitability}, Results for \textbf{RQ3} shows concretely which features of RAG are usable and which benefits exist at this point.
% [1] https://swagger.io/specification/
% [2] Basu, Anirban (2015). Software Quality Assurance, Testing and Metrics. PHI Learning. ISBN 978-81-203-5068-7.
\ No newline at end of file
diff --git a/sections/openapi.tex b/sections/openapi.tex
index 639d4b58a862821d8f89e90c0c747afe8a039ffe..dca9a6741c3f41e9d9bff9d423c0f364b78214b6 100644
--- a/sections/openapi.tex
+++ b/sections/openapi.tex
@@ -9,7 +9,7 @@ OpenAPI specification does not hold on strict definitions and has a tree-shaped
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}, label={lst:openapi}]
+\begin{lstlisting}[language=json, caption={Example OpenAPI}, label={lst:openapi}]
{
"openapi" : "3.0.0",
"info" : {
diff --git a/sections/rag.tex b/sections/rag.tex
index f4c79ea55c8e06738556e3c19b434aa8b1e49815..38bbcb0f083c99f5ffe9ed31a9d84a52a29fd0fe 100644
--- a/sections/rag.tex
+++ b/sections/rag.tex
@@ -21,7 +21,7 @@ Such features of RAG represent advantages over AG, largely in efficiency. It is
\begin{figure}
\centering
-\includegraphics[width=\textwidth,height=\textheight,keepaspectratio]{ast}
+\includegraphics[width=\textwidth,height=\textheight,keepaspectratio]{astimage.png}
\caption{Example AST, motivated by \cite{hedin2009introductory}}\label{fig:ast}
\end{figure}
@@ -45,8 +45,6 @@ DivExp:BinExp ;
MinusExp:BinExp ;
\end{lstlisting}
-\newpage
-
\begin{lstlisting}[language=JRAG,label={lst:example-attributes},caption={Example of synthesized attributes}]
aspect Printing{
syn String ASTNode.print();
diff --git a/sections/ragoGram.tex b/sections/ragoGram.tex
index 691d2e0cb8cf805be3215feb2e93859063416da6..70362e13518cef271476c7a47b623c1ea387e895 100644
--- a/sections/ragoGram.tex
+++ b/sections/ragoGram.tex
@@ -31,6 +31,25 @@ eq ParameterReference.parameterObject() {
During transferring the structure from OpenAPI to RAG, several properties of JastAdd were detectable:
\begin{description}
-\item JastAdd does not support any map structure. So, nodes derived from maps in OpenAPI must be configured in tuples (List of a named tuple containing a key and a value).
-\item Extensions which are properties of an object class in OpenAPI are also defined in nodes.
-\end{description}
\ No newline at end of file
+\item \textbf{JastAdd does not support any map structure. So, nodes derived from maps in OpenAPI must be configured in tuples (List of a named tuple containing a key and a value).}
+\end{description}
+
+For instance, elements of Components Object are defined as maps\footnote{\url{https://github.com/OAI/OpenAPI-Specification/blob/main/versions/3.0.0.md\#componentsObject}}.
+JastAdd has only AST classes: ASTNode, List and Opt. This problem is solved with construction of a node saving two child nodes in itself. See an example in Listing~\ref{lst:grammar-one}
+
+\begin{lstlisting}[language=AST, label={lst:grammar-one}, caption={Solution of Map Problem}]
+ComponentsObject ::= SchemaTuple* ResponseTuple* ... ;
+SchemaTuple ::= <Key> SchemaOb;
+ResponseTuple ::= <Key> ResponseOb;
+\end{lstlisting}
+
+\begin{description}
+\item \textbf{Extensions which are properties of an object class in OpenAPI are also defined in nodes.}
+\end{description}
+
+Extensions with unfixed name and value in Objects of OpenAPI are also solved with such tuples explained in the previous solution.
+
+\begin{lstlisting}[language=AST, label={lst:grammar-two}, caption={Solution of Extension}]
+ResponseObject : ResponseOb ::= <Description> ... Extension*;
+Extension ::= <Key> <Value:Object>;
+\end{lstlisting}
\ No newline at end of file
diff --git a/sections/ragoProcess.tex b/sections/ragoProcess.tex
index d34ca920c883091262340f38183e2e74099b679d..83d1548a13e578eaef6766080801f890062e724e 100644
--- a/sections/ragoProcess.tex
+++ b/sections/ragoProcess.tex
@@ -13,8 +13,6 @@ Before working with attribute definitions, an input specification in JSON or YAM
%Parse Java -> RAG
The next step of processing this framework is transferring parsed objects in java into AST nodes. This step is done with attribute definitions in jrag file. A small definition example of Parameter Object is in Listing~\ref{lst:parser}.
-
-\newpage
\begin{lstlisting}[language=JRAG,label={lst:parser},caption={Parser for Parameter Object}]
{ ...
diff --git a/sections/ragoTest.tex b/sections/ragoTest.tex
index d3c409172df116791d5d8db1baec6a6bd3a81d46..908e05d8bbfd2fcaba8c4a5bc6ecfe9f0b1f9d4f 100644
--- a/sections/ragoTest.tex
+++ b/sections/ragoTest.tex
@@ -1,7 +1,7 @@
\section{Validation} \label{sec:ragotest}
% General
-For correct (re-)constructions, objects after the processing phase must be the same before. In that sense, a generated JSON or YAML must be equivalent to the given OpenAPI document. Thankfully, there are several practical libraries to compare two JSONs (JsonNode, JsonDiff, JsonPath) and conditions for the assertion were uncomplicated. As a result, we have validated the functionality of the structure transfer, while 100 APIs from apis.guru\footnote{\url{https://apis.guru/}} are constructed in RAG and reconstructed in openapi4j.
+For correct (re-)constructions, objects after the processing phase must be the same before. In that sense, a generated JSON or YAML must be equivalent to the given OpenAPI document. Thankfully, there are several practical libraries to compare two JSONs (JsonNode, JsonDiff, JsonPath) and conditions for the assertion were uncomplicated.
% Differences
In the validation, differences with empty values and differences in Reference Objects are excluded. After the observation of OpenAPI documents, we have noticed that every author has an individual implementing behavior (i.e. description parts are always initialized in some APIs or nodes with empty values do not exist in others). Sibling elements of references do not provide semantical differences. So, it was not sensible to generate strictly equivalent values\footnote{\url{https://swagger.io/docs/specification/using-ref/}}. Its implementation is shown in Listing~\ref{lst:validation}.
@@ -27,5 +27,8 @@ if (diff.size() != 0) {
Firstly, it takes a JSON node which is expected after processing phase and an other node which is actually created as inputs. A path shows only which file is concerned. Then, nodes are compared with JsonDiff. It returns an ArrayNode, "diff" describing which differences they have and where the differences have appeared. Unfortunately, it does not have a filter with empty values. So, the validation method tries to get a value of a path in "diff" and checks if it is empty. The differences with empty values are removed from this ArrayNode. Afterwards, it executes an assertion with a text comparison, if "diff" has an element. A text comparison gives a concreter but bigger overview than JsonDiff. As described in the comment, it is not necessary to verify nodes twice.
+% Result
+As a result, we have validated the functionality of the structure transfer, while \textbf{974 APIs} from the repository of apis.guru\footnote{\url{https://github.com/APIs-guru/openapi-directory}\label{apis-guru}} are constructed in RAG and reconstructed in openapi4j. APIs involving validation or null pointer errors at openapi4j were excluded. This significant amount of validations presents that this grammar parses and transforms OpenAPI documents which are reliably semantically equivalent to their inputs.
+
% ^{3} : api.guru
% ^{4} : https://swagger.io/docs/specification/using-ref/
\ No newline at end of file
diff --git a/sections/relatedwork.tex b/sections/relatedwork.tex
index 6195bff51abf57b2215050ecb1012b7bfef57643..53d224cd9082b75d1a59733df2a045507024402b 100644
--- a/sections/relatedwork.tex
+++ b/sections/relatedwork.tex
@@ -7,4 +7,5 @@ There are already many approaches suggesting to test REST APIs with OpenAPI spec
\input{sections/propBasedAppr}
\input{sections/ConstBasedAppr}
\input{sections/ODGAppr}
-\input{sections/restler}
\ No newline at end of file
+\input{sections/restler}
+\input{sections/summary}
\ No newline at end of file
diff --git a/sections/restapi.tex b/sections/restapi.tex
index 7a6a0847c7c05fc7fa68c51cc0200f6734dbad45..56d0dfb717316b1e44528d2f7433f190a478ee66 100644
--- a/sections/restapi.tex
+++ b/sections/restapi.tex
@@ -7,12 +7,12 @@ The concept of REST has been proposed by Roy Fielding in 2000 \cite{fielding2000
It offers constraints to increase simplicity, performance, visibility, modifiability, portability and reliability of APIs. \\
Constraints defined in REST are following:
\begin{description}
-\item Client-Server: API must be a connection in a client-server architecture.
-\item Stateless: Every request must be stateless (i.e. independent of other requests).
-\item Cache: Data in API must be cacheable.
-\item Layered System: Several servers are able to use in one API.
-\item Code on Demand: Responses might be an executable code (optional).
-\item Uniform Interface: API holds on four additional constraints to be consistent
+\item \textbf{Client-Server}: API must be a connection in a client-server architecture.
+\item \textbf{Stateless}: Every request must be stateless (i.e. independent of other requests).
+\item \textbf{Cache}: Data in API must be cacheable.
+\item \textbf{Layered System}: Several servers are able to use in one API.
+\item \textbf{Code on Demand}: Responses might be an executable code (optional).
+\item \textbf{Uniform Interface}: API holds on four additional constraints to be consistent
\begin{itemize}
\item Resources in requests are identified by URI
\item Client should hold the representation of a resource that has enough information to modify or delete the resource.
@@ -25,25 +25,46 @@ Constraints defined in REST are following:
With this set of constraints system resources are characterized by URIs, sent as requests and modified with CRUD operations (Create, Read, Update, Delete), that are mapped to the HTTP methods (POST, GET, PUT, DELETE). Additionally, URIs, header and body objects are modified by parameters (Query, Path, Body, Header, Form). To change URIs and call an operation with variables, parameters in Query and Path are used. \\
An example for a web service with REST API might be a web service of a pet store. Example operations for this REST API could be: \\
\begin{description}
-\item GET /pets (returns all pet information)
-\item GET /pets/findByStatus?k1=v1\&k2=v2 (returns information of users with Query parameters k1 = v1 and k2 = v2 )
-\item GET /users/\{id\} (returns information of an user with the given Path parameter, id)
-\item POST /users (creates a new user)
-\item PUT /users/\{id\} (updates information of an user with the given Path parameter, id)
-\item DELETE /users/\{id\} (removes an user with the given Path parameter, id)
+\item \lstinline[{language=GET}]|GET /pets| \\ (returns all pet information)
+\item \lstinline[{language=GET}]|GET /pets/findByStatus?k1=v1&k2=v2| \\ (returns information of users with Query parameters k1 = v1 and k2 = v2 )
+\item \lstinline[{language=GET}]|GET /users/{id}| \\ (returns information of an user with the given Path parameter, id)
+\item \lstinline[{language=POST}]|POST /users| \\ (creates a new user)
+\item \lstinline[{language=PUT}]|PUT /users/{id}| \\ (updates information of an user with the given Path parameter, id)
+\item \lstinline[{language=DELETE}]|DELETE /users/{id}| \\ (removes an user with the given Path parameter, id)
\end{description}
%Process
-When a client request is made via a REST API, it transmits a representation of the resource status to the client or endpoint. \\ This representation or information is provided in mostly JSON or XML. JSON is the most popular programming language because it is language-agnostic despite its name and can be read by both humans and machines. \\
+When a client request is made via a REST API, it transmits a representation of the resource status to the client or endpoint. \\ This representation or information is provided in mostly JSON or XML. An example of a request in pet store we used for researches is following:
+
+\begin{lstlisting}[style=rest, caption={Example of Request}, label={lst:exp-request}]
+@POST@ ~/v2/pet~ @HTTP/1.1@
+<Host:> ABCDpetstore.swagger.ioABCD
+<Accept:> ABCDapplication/jsonABCD
+<Content-Type:> ABCDapplication/jsonABCD
+<Content-Length:> ABCD215ABCD
+
+{ "id": 0, ... }
+\end{lstlisting}
+
After a client sends a HTTP request, a corresponding server is going to send back a HTTP response with headers and optionally a payload (data pack for a GET request). Additionally, a numeric status code will be a part of this response as well. Staus codes are specified in one of five categories:
\begin{description}
-\item 1xx : Informational provisional responses
-\item 2xx : Request is successfully processed
-\item 3xx : Request requires more information to complete the request
-\item 4xx : Client error (invalid request, non-existent resource, client not authenticated or authorized)
-\item 5xx : Server error (Server can not supply a valid response)
+\item \textbf{1xx} : Informational provisional responses
+\item \textbf{2xx} : Request is successfully processed
+\item \textbf{3xx} : Request requires more information to complete the request
+\item \textbf{4xx} : Client error (invalid request, non-existent resource, client not authenticated or authorized)
+\item \textbf{5xx} : Server error (Server can not supply a valid response)
\end{description}
-HTTP status code is an important component to this work, because it provides to test REST APIs and find out errors (e.g. requests expected as valid return 4xx status code or requests expected as invalid return 2xx status code).
+HTTP status code is an important component to this work, because it provides to test REST APIs and find out errors (e.g. requests expected as valid return 4xx status code or requests expected as invalid return 2xx status code). A response by the request shown above is in Listing~\ref{lst:exp-respnse}.
+
+\begin{lstlisting}[style=rest, caption={Example of Response}, label={lst:exp-respnse}]
+@HTTP/1.1@ V200V OK
+<Date>: ABCDSat, 1 Jan 2000 00:00:00 GMTABCD
+<Content-Type>: ABCDapplication/jsonABCD
+<Connection>: ABCDkeep-aliveABCD
+<Server>: ABCD...ABCD
+
+{ "id": 0, ... }
+\end{lstlisting}
% [1] Roy Fielding in 2000
\ No newline at end of file
diff --git a/sections/stm1.tex b/sections/stm1.tex
index 5d2f5f0008bcc61ad06ecba036da607d3ea8c26e..e48e9eabe2f21e1d2e579351c00fea95a01db7ec 100644
--- a/sections/stm1.tex
+++ b/sections/stm1.tex
@@ -1,13 +1,13 @@
\section{Random Testing} \label{sec:stm1}
-OpenAPI defines a parameter in an operation in four types, Query, Path, Header and Cookie\footnote{\url{https://swagger.io/docs/specification/describing-parameters}}. In this work, only Query and Path parameters are considered to research the functionality of the Fuzzing prototype in RAG. These parameters are clearly describable in String values and also comfortably testable, because they target only variable URIs. \\
-For the experiments, the OpenAPI document of a Pet Store is mainly used\footnote{\url{https://petstore.swagger.io}}. Additionally, only GET and POST operations are tested to research basic functionality firstly.
+OpenAPI defines a parameter in an operation in four types, Path, Query, Header and Cookie\footnote{\url{https://swagger.io/docs/specification/describing-parameters}}. In this work, only Path and Query parameters are considered to research the functionality of the Fuzzing prototype in RAG. These parameters are clearly describable in String values and also comfortably testable, because they target only variable URIs. \\
+For the experiments, the OpenAPI document of a Pet Store\footnote{\url{https://petstore.swagger.io}\label{petstore}} is mainly used. Additionally, only GET and POST operations are tested to research basic functionality firstly.
% Process
The main code at random testing is following:
\begin{lstlisting}[language=JRAG,label={lst:random-testing},caption={Random Testing}]
-String Uri;
+String Uri = getServerUrl();
for (ParameterOb o : operationObject.getParameterObs()) {
ParameterObject p = o.parameterObject();
if (p.getIn().equals("path"))
@@ -17,11 +17,17 @@ for (ParameterOb o : operationObject.getParameterObs()) {
}
connect(Uri);
\end{lstlisting}
-Initially, the generator for random testing computes a list of parameter objects stored in RAG and iterates all elements in this list (Line 2). Subsequently, each iteration examines in which type the parameter is and produces a random URI. This URI is saved in a String variable (Line 4-7). Finally, the test generator sends a request
-with the generated URI (Line 9).
+
+\begin{lstlisting}[language=JRAG, label={lst:rt-attribute}, caption={Attribute for Random Parameters}]
+syn String ParameterObject.randomPathParameter(String uri); // Generate random Path and save in URI
+
+syn String ParameterObject.randomQueryParameter(String uri); // Generate random Query and save in URI
+\end{lstlisting}
+Initially, the generator for random testing computes a list of parameter objects stored in RAG and iterates all elements in this list (Line 2, Listing~\ref{lst:random-testing}). Subsequently, each iteration examines in which type the parameter is and produces a random URI with synthesized attributes (Listing~\ref{lst:rt-attribute}). This URI is saved in a String variable (Line 4-7, Listing~\ref{lst:random-testing}). Finally, the test generator sends a request
+with the generated URI (Line 9, Listing~\ref{lst:random-testing}).
% Result
-Besides operations with requirements of request bodies, results of this implementation made possible to observe that parameters based on the specification were successfully randomized and they produced documented status codes in their operations. For future work, constraints of schema (minItems, maxItems, minLengths, maxLengths, etc.) can be completely extended. In this approach, the generator considers only the existence of enums.
+Besides operations with requirements of request bodies, \textbf{results of this implementation made possible to observe that parameters were successfully randomized and they produced documented status codes in Pet store\footref{petstore} (200, 400, 404, 405 status codes).} For future work, constraints of schema (minItems, maxItems, minLengths, maxLengths, etc.) can be completely extended. In this approach, the generator considers only the existence of enums.
% ^5 : https://swagger.io/docs/specification/describing-parameters/
% ^6 : https://petstore.swagger.io
\ No newline at end of file
diff --git a/sections/stm2.tex b/sections/stm2.tex
index 1268f196d203dc973cd782054bfb326619f54312..9b8e105042411e41f34d2c9fbd06afb986409ea8 100644
--- a/sections/stm2.tex
+++ b/sections/stm2.tex
@@ -3,11 +3,10 @@ Random testing is a one of easiest way to test API and can be useful in some sit
% General
To solve this problem, most of REST API testing approaches use a stateful process, because it enables to analyze properties of APIs and infer inputs which are more appropriate than random inputs. There are several suggestions in \Cref{ch:curr-appr}, this framework investigates a inference of parameters with operation dependency motivated by Specification-based Approach \cite{ed2018automatic} and RESTTESTGEN \cite{viglianisi2020resttestgen}. Generally, it collects all responses and inferences parameters contributing the same schema of a succesful response. If there is a schema set in a request and a response, parameters of them are inferred by three strategies:
-
\begin{itemize}
-\item Case insensitive
-\item Id completion in a field name (e.g. if a property is named with "id", it gets an additional field name available in the specification)
-\item Stemming algorithm (e.g. pet and pets are considered as a same value.)
+\item \textbf{Case insensitive}
+\item \textbf{Id completion} in a field name (e.g. if a property is named with "id", it gets an additional field name available in the specification)
+\item \textbf{Stemming algorithm} (e.g. pet and pets are considered as a same value.)
\end{itemize}
% Process
@@ -39,7 +38,6 @@ for (String path : paths)
\end{lstlisting}
\begin{lstlisting}[language=JRAG,label={lst:parameter-dict},caption={Attribute writeDictionary}]
-
syn String OperationObject.writeDictionary(SchemaOb schema, String resp) {
...
return inferredParameter;
@@ -66,7 +64,7 @@ syn List<String> ParameterObject.addinfPathParameters(String pathRef,List<String
}
\end{lstlisting}
-Before it starts with the parameter inference, the random testing generator of \Cref{sec:stm1} is executed first (Line 1, Listing~\ref{lst:parameter-inference}). During this execution, the status code of a response is checked if it is a successful response with 200 status code (Line 4, Listing~\ref{lst:parameter-inference}). Afterwards, the response schema of returned values is also checked. If it is in type array, the function "writeDictionary" is iterated, otherwise it only executed once (Listing~\ref{lst:parameter-dict}). The attribute "writeDictionary" saves the returend values of a successful response in seperate properties and write them in a dictionary (e.g. properties "id" and "name" are seperately stored with their value in the dictionary). If the schema of a response provides a reference of a schema object, the field name gets a name of a reference as prefix. Subsequently, this implementation does the similar way of execution in random testing at the generation phase. Firstly, it iterates all parameter objects (Line 14, Listing~\ref{lst:parameter-inference}) and examines whether the parameter type is Path or Query (Line 15-18, Listing~\ref{lst:parameter-inference}). Both attributes return URIs with parameter values inferred by the dictionary and case insensitive comparison (Line 4, Listing~\ref{lst:parameter-case}). Generated URIs are put in a list. Lastly, the generator attribute sends requests with the URIs and starts with observation (Line 20-21, Listing~\ref{lst:parameter-inference}).
+Before it starts with the parameter inference, random tests of \Cref{sec:stm1} are generated first (Line 1, Listing~\ref{lst:parameter-inference}). During this execution, the status code of a response is checked if it is a successful response with 200 status code (Line 4, Listing~\ref{lst:parameter-inference}). Afterwards, the response schema of returned values is also checked. If it is in type array, the function "writeDictionary" is iterated, otherwise it only executed once (Listing~\ref{lst:parameter-dict}). The attribute "writeDictionary" saves the returend values of a successful response in seperate properties and write them in a dictionary (e.g. properties "id" and "name" are seperately stored with their value in the dictionary). If the schema of a response provides a reference of a schema object, the field name gets a name of a reference as prefix. Subsequently, this implementation does the similar way of execution in random testing at the generation phase. Firstly, it iterates all parameter objects (Line 14, Listing~\ref{lst:parameter-inference}) and examines whether the parameter type is Path or Query (Line 15-18, Listing~\ref{lst:parameter-inference}). Both attributes return URIs with parameter values inferred by the dictionary and case insensitive comparison (Line 4, Listing~\ref{lst:parameter-case}). Generated URIs are put in a list. Lastly, the generator attribute sends requests with the URIs and starts with observation (Line 20-21, Listing~\ref{lst:parameter-inference}).
% Result
-As results, the test case generator with parameter inference implemented in this framework could create maximum over 300 acceptable URIs for the parameter petId in the selected API, pet store, at the operation getPetById. It generated also numerous requests denied by the server. After the observation of several execution iterations, it can be assumed that the API with this operation sends 200 or 404 status codes randomly or according to some rules, because a same URI provided status codes in that way.
\ No newline at end of file
+As results, \textbf{the test case generator with parameter inference implemented in this framework could create maximum over 300 acceptable URIs for the parameter petId in the selected API, pet store\footref{petstore}, at the operation getPetById.} It generated also numerous requests denied by the server. After the observation of several execution iterations, it can be assumed that the API with this operation sends 200 or 404 status codes randomly or according to some rules, because a same URI provided status codes in that way.
\ No newline at end of file
diff --git a/sections/summary.tex b/sections/summary.tex
new file mode 100644
index 0000000000000000000000000000000000000000..2f3e57f08b1ffad40c57c78644027d86b80b5a8d
--- /dev/null
+++ b/sections/summary.tex
@@ -0,0 +1,46 @@
+\section{Summary} \label{sec:sum}
+
+\newcolumntype{Y}{>{\hspace{0pt}}X}
+\newcolumntype{D}{>{\raggedright}Y}
+\newcolumntype{E}{>{\centering}Y}
+\newcolumntype{F}{>{\raggedleft}Y}
+
+\begin{table}
+\fontsize{7}{9}\selectfont
+\begin{tabularx}{\textwidth}{@{}D|E|E|E|E@{}}
+\toprule
+ & \textbf{Type of Errors} & \textbf{Type of Process} & \textbf{Type of Inference} & \textbf{Results} \tabularnewline\midrule
+Specification-based Approach & Nominal Test Cases : \textbf{4xx/500 Status Codes, Schema Errors} \newline Faulty Test Cases : \textbf{500, 200 Status Codes} &
+Stateful &
+Parameter Inference &
+Bugs found in 37 experimented APIs of 91
+\tabularnewline \hline
+Property-based Approach &
+\textbf{500 Status Codes} &
+Stateless/Stateful &
+Inference of Failure Area &
+In Average, 9.84\% Probability of Error Occurrence in GitLab
+\tabularnewline \hline
+Constraint-based Approach &
+\textbf{5XX Status Codes, OpenAPI Schema Errors, 2XX Related to Parameters, 2XX Related to Parameter Dependencies, 4XX Status Codes} &
+Stateful &
+Inference of Parameter Dependency by IDLReasoner\footnote{\url{https://github.com/isa-group/IDLReasoner}} &
+Over 2000 Bugs found in 6 commercial APIs
+\tabularnewline \hline
+Operation Dependency Graph Approach &
+Nominal Cases : \textbf{5xx Status Codes or Validation Error of Response} \newline Error Cases : \textbf{2xx or 5xx Status Codes} &
+Stateful &
+Inference of Operation Dependency &
+Errors found in 87 selected APIs.
+\tabularnewline \hline
+Stateful REST API Fuzzer &
+\textbf{500 Status Codes} &
+Stateful &
+Inference of Request Dependency &
+28 Bugs in GitLab and several Bugs in Microsoft Azure and Office365 cloud services
+\tabularnewline\bottomrule
+\end{tabularx}
+\caption{Overview of Approaches in Table}\label{tab:sum}
+\end{table}
+
+In this work, we found that most current testing approaches using OpenAPI are based on Fuzzing. HTTP status codes were mostly the basis of test oracles, Specification-based, Constraint-based and Operation Dependency Graph Approaches collect also schema validation errors. All of the approaches considered 500 status codes as bugs and several of them expects only 200 status codes by valid test cases and 4xx status codes by error test cases. To result more precisely, they all suggest to inference data of a server or dependency between requests or requests and responses. This usage of inferences requires the stateful process which means requests depend on previous sequences (i.e. requests, responses). The simplified explanantion of current researches is in \Cref{tab:sum}
\ No newline at end of file
diff --git a/sections/testing.tex b/sections/testing.tex
index fcb984539865ce159d45cbb9e21d1fde1bd713e6..ed872e9f44b6d49c20f647859293faa0cb715e50 100644
--- a/sections/testing.tex
+++ b/sections/testing.tex
@@ -1,12 +1,12 @@
\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). \\
+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) \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 \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.
+This paper focuses on automated testing with a black box approach. In \Cref{sec:openapi} the selection of the approach is explained.
% [1] Saleh, K.A. (2009). Software Engineering. J. Ross Publishing. pp. 224–41.
diff --git a/thesis.tex b/thesis.tex
index f7fa1b37bc45baf7b28ead96756fedb03e459a7c..48c82f3ff2ae101aac3da9dd599dcfbdb25f7ba7 100644
--- a/thesis.tex
+++ b/thesis.tex
@@ -2,7 +2,7 @@
%\RequirePackage[ngerman=ngerman-x-latest]{hyphsubst}
% change to english for english theses
-\documentclass[english,BCOR=1.5cm,twoside]{tudscrreprt}
+\documentclass[english,BCOR=1.5cm,twoside,xcolor={dvipsnames}]{tudscrreprt}
\usepackage[T1]{fontenc}
\usepackage[utf8]{inputenc}
@@ -47,7 +47,6 @@
\usepackage{csquotes}
-
\usepackage{caption}
\captionsetup{font=sf,labelfont=bf,labelsep=space}
\usepackage{floatrow}