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

Edited index.md

parent e3656e42
No related branches found
No related tags found
1 merge request!7Resolve "Add documentation in pages"
Pipeline #13259 passed
...@@ -36,6 +36,7 @@ There are some implementation details developers must consider: ...@@ -36,6 +36,7 @@ There are some implementation details developers must consider:
- [Parameter Object](https://github.com/OAI/OpenAPI-Specification/blob/main/versions/3.0.3.md#parameterObject) - [Parameter Object](https://github.com/OAI/OpenAPI-Specification/blob/main/versions/3.0.3.md#parameterObject)
- following abstract node in JastAdd - following abstract node in JastAdd
``` ```
abstract ParameterOb; abstract ParameterOb;
ParameterReference : ParameterOb ::= <Ref> ...; ParameterReference : ParameterOb ::= <Ref> ...;
...@@ -60,24 +61,12 @@ Afterwards, `RandomRequestGenerator` knows which request needs which parameter t ...@@ -60,24 +61,12 @@ Afterwards, `RandomRequestGenerator` knows which request needs which parameter t
### <a name="ragoParamInf"></a>Parameter Inference ### <a name="ragoParamInf"></a>Parameter Inference
- Content in the bachelor thesis Most tests based on the simple randomizing techniques are not effective because of low coverages and unusual validations. To observe more concrete test results, `InferParameter` generates tests automatically using random test results of `RandomRequestGenerator`.
Random testing is a one of easiest way to test API and can be useful in some situations.
However, it is not effective in REST API testing, because the coverage of the tested Test results (responses) generated by `RandomRequestGenerator` are saved in a dictionary and utilized to infer parameters that might be usable in other requests.
API would be particularly low and random values are unusually valid[11]. During the
observation in Section 5.1, it was clear to see that random testing mostly produces
only requests that receive only 4xx HTTP stauts codes from commercial APIs. If there is a same schema set in a request and a response, parameters of them are inferred by following strategies:
To solve this problem, most of REST API testing approaches use a stateful process, - Case-insensitive
because it enables to analyze elements of APIs and infer inputs which are more appropriate than random inputs. There are several suggestions in Chapter 3. This framework - Id completion in a field name (e.g. if a property has a name "id", it gets an additional field name available in the specification)
investigates a inference of parameters with algorithms motivated by Specificationbased Approach [4] and RESTTESTGEN [18]. Generally, it collects all responses and \ No newline at end of file
inferences parameters contributing the same schema of a succesful response. If there
is a same schema set in a request and a response, parameters of them are inferred
by three strategies:
• Case insensitive
• 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)
• Stemming algorithm (e.g. pet and pets are considered as a same value.)
In the implementation of this work, case insensitive comparison and id completion
are utilized to create the basic functionality. Stemming algorithm can be also extended
in the future. The follwing code in Listng 5.3 and List 5.4 shows how the parameter
inference is compiled with predefined attributes:
\ No newline at end of file
0% Loading or .
You are about to add 0 people to the discussion. Proceed with caution.
Please register or to comment