firstly commit.

README.md

 English, please click [here](./HELP.md)
 
-# 一款实用的API和Java SDK自动化测试框架
+# 一款完备实用的API自动化测试框架
 
 ## 目录
-* <a href="#chapter1">1. API自动化测试</a>
-    * <a href="#chapter1.1">1.1 REST API的自动化测试</a>
-        * <a href="#chapter1.1.1">1.1.1 验证所有发布的 API 是否都能工作（冒烟测试）</a>
-        * <a href="#chapter1.1.2">1.1.2 编写符合实际业务需求的 API 测试用例（功能测试）</a>
-        * <a href="#chapter1.1.3">1.1.3 构造微服务 mock server，根据不同的请求返回不同的响应指定结果 (集成测试)]</a>
-    * <a href="#chapter1.2">1.2 RPC API的自动化测试</a>
-        * <a href="#chapter1.2.1">1.2.1 json-RPC API的自动化测试</a>
-        * <a href="#chapter1.2.2">1.2.2 gRPC API的自动化测试</a>
-        * <a href="#chapter1.2.3">1.2.3 适用于 json-RPC API 的 mock server</a>
-        * <a href="#chapter1.2.4">1.2.4 适用于 gRPC API 的 mock server</a>
-* <a href="#chapter2">2. SDK自动化测试</a>
-
-
-## <a id="chapter1">1. API自动化测试</a>
-```text
-微服务时代，API的主要实现方式有 REST 和 RPC 两种。不同的接口形式，理所当然需要对应不同的测试方法。
+* <a href="#chapter1">1 REST API的自动化测试</a>
+    * <a href="#chapter1.1">1.1 验证所有发布的 API 是否都能工作（冒烟测试）</a>
+    * <a href="#chapter1.2">1.2 编写符合实际业务需求的 API 测试用例（功能测试）</a>
+    * <a href="#chapter1.3">1.3 构造微服务 mock server，根据不同的请求返回不同的响应指定结果 (集成测试)]</a>
+* <a href="#chapter2">2 RPC API的自动化测试</a>
+    * <a href="#chapter2.1">2.1 json-RPC API的自动化测试</a>
+    * <a href="#chapter2.2">2.2 gRPC API的自动化测试</a>
+    * <a href="#chapter2.3">2.3 适用于 json-RPC API 的 mock server</a>
+    * <a href="#chapter2.4">2.4 适用于 gRPC API 的 mock server</a>
+* <a href="#chapter3">3 SDK自动化测试></a>
+
+
+
+```text
+微服务时代，API的主要实现方式有 REST, RPC 以及近来比较流行的SDK三种。不同的接口形式，理所当然需要对应不同的测试方法。
 ```
-### <a id="chapter1.1">1.1 REST API的自动化测试</a>
+### <a id="chapter1">1 REST API的自动化测试</a>
 
-#### <a id="chapter1.1.1">1.1.1 验证所有发布的 API 是否都能工作（冒烟测试）</a>
+#### <a id="chapter1.1">1.1 验证所有发布的 API 是否都能工作（冒烟测试）</a>
 ##### 测试方法
 ```text
 1.  根据微服务提供的 OPEN API 文件，得到其对外提供的所有 REST API 列表(包括路径、方法、请求消息体结构和接收消息体结构等) 
@@ -52,7 +51,7 @@ English, please click [here](./HELP.md)
 - 未考虑实际的业务需求；仅限于最基本的可行性验证。
 - 返回失败的请求需要人工二次校验其准确性（如果事先把测试数据准备好，则可规避此问题，但需要付出更多的人力）。
 ```
-#### <a id="chapter1.1.2">1.1.2 编写符合实际业务需求的 API 测试用例（功能测试）</a>
+#### <a id="chapter1.2">1.2 编写符合实际业务需求的 API 测试用例（功能测试）</a>
 ##### 测试方法
 
 1.  准备json格式的测试数据，包括：
@@ -81,7 +80,7 @@ English, please click [here](./HELP.md)
 ```text
 - 更多需要讨论的是 API 测试本身的局限性，和本测试框架无关。  
 ```
-#### <a id="chapter1.1.3">1.1.3 构造微服务 mock server，根据不同的请求返回不同的响应指定结果 (集成测试)</a>
+#### <a id="chapter1.3">1.3 构造微服务 mock server，根据不同的请求返回不同的响应指定结果 (集成测试)</a>
 ##### 测试方法
 ```text
 mock server既可以与具体的测试用例集成，也可以被部署为一个真实服务供客户端服务(在开发中的测试服务对象)调用；
@@ -122,11 +121,11 @@ mock server既可以与具体的测试用例集成，也可以被部署为一个
 1.  需要支持插件等形式，对响应数据进行用户/请求差别化地动态修改（如，变量替换，实时算法调用等）
 ```
 
-### <a id="chapter1.2">1.2 RPC API的自动化测试</a>
+### <a id="chapter2">2 RPC API的自动化测试</a>
 ```text
 RPC形式的API，又以 gRPC 和 json-RPC 两种实现方式居多。
 ```
-#### <a id="chapter1.2.1">1.2.1 [json-RPC](https://www.jsonrpc.org/specification) API的自动化测试</a>
+#### <a id="chapter2.1">2.1 [json-RPC](https://www.jsonrpc.org/specification) API的自动化测试</a>
 ```text
 从 json-RPC 的规范我们可以知道，相比较于 REST ，jsonRPC 消息有如下几个特点：  
   -  净荷消息由 HTTP1.1 承载；
@@ -139,7 +138,7 @@ RPC形式的API，又以 gRPC 和 json-RPC 两种实现方式居多。
 由此可见，json-RPC API的测试方法，和 REST API 的测试方法基本相同。     
 ```  
 
-#### <a id="chapter1.2.2">1.2.2 [gRPC](https://grpc.io/) API的自动化测试</a>
+#### <a id="chapter2.2">2.2 [gRPC](https://grpc.io/) API的自动化测试</a>
 ##### 测试方法
 
 1.  获取 gRPC 接口定义的 [proto](https://developers.google.com/protocol-buffers/docs/proto3)文件，存放在对应测试版本的测试数据文件夹下([参考存放路径](/src/test/resources/testdatacollection/chain33/))。
@@ -167,10 +166,10 @@ RPC形式的API，又以 gRPC 和 json-RPC 两种实现方式居多。
 -  需要找寻一个通用的解决方案去实现：测试数据与实际发送数据类型的自动转换机制。
 ```
 
-#### <a id="chapter1.2.3">1.2.3 适用于 json-RPC API 的 mock server</a>
+#### <a id="chapter2.3">2.3 适用于 json-RPC API 的 mock server</a>
 [参考 1.1.3 实现](#a-idchapter113113--mock-server-a)
 
-#### <a id="chapter1.2.4">1.2.4 适用于 gRPC API 的 mock server</a>
+#### <a id="chapter2.4">2.4 适用于 gRPC API 的 mock server</a>
 ##### 测试方法
 与 [1.1.3](#a-idchapter113113--mock-server-a) 方法大体相同，但仍然存在如下区别:
 ```text
@@ -188,7 +187,7 @@ RPC形式的API，又以 gRPC 和 json-RPC 两种实现方式居多。
 需要找寻一个通用的解决方案去实现：测试数据与实际发送数据类型的自动转换机制。从而减少业务代码的编写，测试人员需要关心的只是测试数据和业务流程验证。
 ```  
 
-## <a id="chapter2">2. SDK自动化测试</a>
+## <a id="chapter3">3. SDK自动化测试</a>
 ```text
-
+SDK（Software Development Kit）是为第三方开发者提供的软件开发工具包，包括SDK接口、开发文档和Demo示例等。
 ```
\ No newline at end of file