Skip to content
Snippets Groups Projects

Resolve "Add documentation in pages"

Merged Jueun Park requested to merge 9-add-documentation-in-pages into main
1 file
+ 25
4
Compare changes
  • Side-by-side
  • Inline
+ 25
4
@@ -35,12 +35,12 @@ There are some implementation details developers must consider:
- In OAS, several objects can be replaced by [Reference Object](https://github.com/OAI/OpenAPI-Specification/blob/main/versions/3.0.3.md#referenceObject). In `RAGO`, we implemented this structure in an abstract node to every concerned object. e.g.
- [Parameter Object](https://github.com/OAI/OpenAPI-Specification/blob/main/versions/3.0.3.md#parameterObject)
- following abstract node in JastAdd
```
```
abstract ParameterOb;
ParameterReference : ParameterOb ::= <Ref> ...;
ParameterObject : ParameterOb ::= <Name> <In> ...;
```
```
- Most objects can be extended with `Extension` containing unfixed name and values. In JastAdd, this is also implemented in a tuple (AST-Node) `Extension ::= <Key> <Value:Object>;`
@@ -55,8 +55,29 @@ In this first version, this tool considers only two request types, `GET` and `PO
Random testing is based on the simple randomizer, `RandomRequestGenerator`. This generator reads an `OpenAPIObject` mapped by an OpenAPI documentation and checks all parameter types of operations existing in the `OpenAPIObject`.
`RandomRequestGenerator` knows which request needs which parameter type and generates random parameters for all requests and URLs appending these parameters.
Afterwards, `RandomRequestGenerator` knows which request needs which parameter type and generates random parameters for all requests and URLs appending these parameters.
### <a name="ragoParamInf"></a>Parameter Inference
- Content in the bachelor thesis
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
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.
To solve this problem, most of REST API testing approaches use a stateful process,
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
investigates a inference of parameters with algorithms motivated by Specificationbased Approach [4] and RESTTESTGEN [18]. Generally, it collects all responses and
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
Loading