rename validators to validate

docs/extraction-and-validation.md

@@ -24,7 +24,7 @@ Suppose we get the following HTTP response.
 }
 ```
 
-In `extract` and `validators`, we can do chain operation to extract data field in HTTP response.
+In `extract` and `validate`, we can do chain operation to extract data field in HTTP response.
 
 For instance, if we want to get `Content-Type` in response headers, then we can specify `headers.content-type`; if we want to get `first_name` in response content, we can specify `content.person.name.first_name`.
 
@@ -49,7 +49,7 @@ content.person.cities.1
 extract:
     - content_type: headers.content-type
     - first_name: content.person.name.first_name
-validators:
+validate:
     - {"check": "status_code", "comparator": "eq", "expected": 200}
     - {"check": "headers.content-type", "expected": "application/json"}
     - {"check": "headers.content-length", "comparator": "gt", "expected": 40}

docs/quickstart.md

@@ -65,7 +65,7 @@ Open your favorite text editor and you can write test cases like this.
         json:
             name: "user1"
             password: "123456"
-    validators:
+    validate:
         - {"check": "status_code", "comparator": "eq", "expected": 201}
         - {"check": "content.success", "comparator": "eq", "expected": true}
 ```
@@ -122,7 +122,7 @@ To fix this problem, we should correlate `token` field in the second API test ca
             sign: 19067cf712265eb5426db8d3664026c1ccea02b9
     extract:
         - token: content.token
-    validators:
+    validate:
         - {"check": "status_code", "comparator": "eq", "expected": 200}
         - {"check": "content.token", "comparator": "len_eq", "expected": 16}
 
@@ -137,7 +137,7 @@ To fix this problem, we should correlate `token` field in the second API test ca
         json:
             name: "user1"
             password: "123456"
-    validators:
+    validate:
         - {"check": "status_code", "comparator": "eq", "expected": 201}
         - {"check": "content.success", "comparator": "eq", "expected": true}
 ```
@@ -204,7 +204,7 @@ And then, we can revise our demo test case and reference the functions. Suppose
             sign: ${get_sign($user_agent, $device_sn, $os_platform, $app_version)}
     extract:
         - token: content.token
-    validators:
+    validate:
         - {"check": "status_code", "comparator": "eq", "expected": 200}
         - {"check": "content.token", "comparator": "len_eq", "expected": 16}
 
@@ -219,7 +219,7 @@ And then, we can revise our demo test case and reference the functions. Suppose
         json:
             name: "user1"
             password: "123456"
-    validators:
+    validate:
         - {"check": "status_code", "comparator": "eq", "expected": 201}
         - {"check": "content.success", "comparator": "eq", "expected": true}
 ```
@@ -268,7 +268,7 @@ To handle this case, overall `config` block is supported in `ApiTestEngine`. If
             sign: ${get_sign($user_agent, $device_sn, $os_platform, $app_version)}
     extract:
         - token: content.token
-    validators:
+    validate:
         - {"check": "status_code", "comparator": "eq", "expected": 200}
         - {"check": "content.token", "comparator": "len_eq", "expected": 16}
 
@@ -282,7 +282,7 @@ To handle this case, overall `config` block is supported in `ApiTestEngine`. If
         json:
             name: "user1"
             password: "123456"
-    validators:
+    validate:
         - {"check": "status_code", "comparator": "eq", "expected": 201}
         - {"check": "content.success", "comparator": "eq", "expected": true}
 ```