Skip to content
Snippets Groups Projects
Commit 85a0bd8b authored by Jueun Park's avatar Jueun Park
Browse files

Update

parent 68da3990
No related branches found
No related tags found
No related merge requests found
Pipeline #11544 passed with warnings
......@@ -11,7 +11,7 @@ RQ1 RQ2
- different additions:
- inference
- test model
- this can be solved with the RAG tool presented in \cref{chap:RAGO}
- this can be solved with the RAG tool presented in \cref{chap:rago}
- in \cref{sec:inf} we show how inference can be done
- \cite{ttc-rag-von-ceur} for test model/model connections
- http://ceur-ws.org/Vol-2310/ A JastAdd- and ILP-based Solution to the Software-Selection and Hardware-Mapping-Problem at the TTC 2018
......
......@@ -4,11 +4,11 @@ Also, it might be a meaningful approach to raise the security and quality in web
% 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 has become the common way to document the communication endpoints and exchanged data structures [1]. This is useful to test REST interfaces, because it enables the black-box testing approach.
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 itself 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).
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:
......
\section{Random Testing}
OpenAPI defines a parameter in an operation in four types, Query, Path, Header and Cookie$^{5}$. \footnote{this is described at \url{http://test.com}} 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$^{6}$. Additionally, only GET and POST operations are tested to research basic functionality firstly.
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.
% Process
The main code at random testing is following:
......@@ -23,14 +23,5 @@ with the generated URI (Line 9).
% 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.
\begin{comment}
- Type of Parameters: Path,Query, Header\\
- Only Path,Query\\
- Reasons of selecting only path, query\\
- Process\\
- Results\\
\end{comment}
% ^5 : https://swagger.io/docs/specification/describing-parameters/
% ^6 : https://petstore.swagger.io
\ No newline at end of file
......@@ -133,7 +133,7 @@
\input{sections/conclusion}
%\printbibliography[heading=bibintoc]\label{sec:bibliography}%
\printbibliography[heading=bibintoc]\label{sec:bibliography}
%\appendix
%\input{sections/appendix}
......
0% Loading or .
You are about to add 0 people to the discussion. Proceed with caution.
Please register or to comment