format refined.

README.md

@@ -19,14 +19,14 @@ English, please click [here](./HELP.md)
     - 验证响应消息体结构：  
         - 简单数据类型仅验证返回的数据类型是否与 OPEN API 文件中预定义的类型匹配，不要求值匹配；
         - 复合数据类型 object，需要验证响应消息中是否包含所有的期望 key ，以及匹配 value 的数据类型是否匹配期望；
-        - 复合数据类型 array，需要验证响应消息中是否包含复合类型 object ？是，则需要验证 key 和数据类型；否则仅需要验证数据类型是否匹配期望。
+        - 复合数据类型 array，需要验证响应消息中是否包含复合类型 object ？是，则需要验证 key 和数据类型；否则仅需要验证数据类型是否匹配期望。  
    
 ##### 用例参考  
-   [点击此链接](/src/test/resources/features/sanitytest/backend.feature)
+   [点击此链接](/src/test/resources/features/sanitytest/backend.feature)  
 ##### 优点  
    无需测试人员手动编写测试脚本，测试框架全自动完成 OpenAPI 分析及 REST 消息的发送和结果验证。  
 ##### 局限性  
-   未考虑实际的业务需求；仅限于最基本的可行性验证。
+   未考虑实际的业务需求；仅限于最基本的可行性验证。  
 
 #### 1.1.2 编写符合实际业务需求的 API 测试用例（功能测试）
 ##### 测试方法  
@@ -40,15 +40,15 @@ English, please click [here](./HELP.md)
 2.  编写脚本将请求数据发送给指定目的微服务。
 3.  测试框架根据测试人员提供的接收响应数据，进行消息结果验证：
     -  符合预期，则测试通过；
-    -  否则打印错误断言，测试退出并标记为失败。
+    -  否则打印错误断言，测试退出并标记为失败。  
 ##### 用例参考  
-   [点击此链接](/src/test/resources/features/apitest/restful/user_management/user_register.feature)
+   [点击此链接](/src/test/resources/features/apitest/restful/user_management/user_register.feature)  
 ##### 优点  
    -  用例编写简单，核心测试脚本仅数行。  
    -  消息的发送、接收以及结果验证对用例编写人员透明。测试用例编写人员需要关心的只是产品业务需求。  
    -  测试数据与功能需求关联，支持复用。不同测试脚本(用例)可使用相同测试数据。   
 ##### 局限性  
-   更多需要讨论的是 API 测试本身的局限性，和本测试框架无关。
+   更多需要讨论的是 API 测试本身的局限性，和本测试框架无关。  
 
 #### 1.1.3 构造微服务 mock server，根据不同的请求返回不同的响应结果 (集成测试)