Resolve "Add documentation in pages"

Closes #9 (closed)

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