diff --git a/pages/docs/index.md b/pages/docs/index.md index 598c843ddc2ca729b420facabdb3feabe058728d..0ac584114fbd8867461e761a085dd369f26c0cd9 100644 --- a/pages/docs/index.md +++ b/pages/docs/index.md @@ -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