diff --git a/README.md b/README.md
index 41e5c9d..4b7efa0 100644
--- a/README.md
+++ b/README.md
@@ -178,7 +178,7 @@ Hi, 欢迎来到 ElemeFE, 如标题所示本教程的目的是教你如何通过
 * [`[Basic]` 集成测试](sections/test.md#集成测试)
 * [`[Basic]` 基准测试](sections/test.md#基准测试)
 * [`[Basic]` 压力测试](sections/test.md#压力测试)
-* [`[Doc]` Assert (断言)](sections/test.md#断言)
+* [`[Doc]` Assert (断言)](sections/test.md#assert)
 
 ### 常见问题
 
diff --git a/sections/test.md b/sections/test.md
index 80b30f1..7a6f343 100644
--- a/sections/test.md
+++ b/sections/test.md
@@ -1,11 +1,11 @@
 # 测试
 
-* `[Basic]` 测试方法
-* `[Basic]` 单元测试
-* `[Basic]` 基准测试
-* `[Basic]` 集成测试
-* `[Basic]` 压力测试
-* `[Doc]` Assert (断言)
+* [`[Basic]` 测试方法](#测试方法)
+* [`[Basic]` 单元测试](#单元测试)
+* [`[Basic]` 基准测试](#集成测试)
+* [`[Basic]` 集成测试](#基准测试)
+* [`[Basic]` 压力测试](#压力测试)
+* [`[Doc]` Assert (断言)](#assert)
 
 ## 简述
 
@@ -29,13 +29,13 @@ C
 D
 ```
 
-如上述情况, ABCD 是逻辑层, EFGH 等是更低一次层 (比如工具层等), 当你为了功能 A 的 BUG 修改了 H 的代码, 那么实际受影响的功能除了 A 之外还有 BC, 如果你有针对每一个逻辑的测试, 那么修改了 H 的代码之后, 跑一遍测试即可保证对 H 的修改不会影响到 BC.
+如上述情况, ABCD 是逻辑层, EFGH 等是更低一次层 (比如工具层等), 当你为了功能 A 的 BUG 修改了 H 的代码, 那么实际受影响的功能除了 A 之外还有 BC, 如果你有针对每一个逻辑的测试, 那么修改了 H 的代码之后, 跑一遍测试即可保证对 H 的修改不会影响到 BC (如果有影响, 那么相应的测试会报错). 利用这种特性, 你还可以基于测试去做重构, 在通过原有测试的情况下, 即表明新的重构版本可以替代原有的版本.
 
 而这样的效果, 只有当覆盖率达到了一定程度 (通常是 80% 以上, 90% 以上为最理想) 才能实现, 如果测试的覆盖率低, 无法覆盖到多种情况, 那么测试对你的项目可能是没有用甚至起到反作用的 (让你误以为你的修改没问题而发布等).
 
-写测试是否会拖累开发进度, 这要视具体情况而定. 这里需要考虑开发进度需要包含功能和品质两个方面, 单纯的代码速度不能完全代表开发进度. 测试在适当的情况下可以保证项目的品质从而得到更好的开发进度.
+写测试是否会拖累开发进度要视具体情况而定. 需要考虑到, 开发进度包含功能和品质两个方面, 单纯写代码的速度不能完全代表开发进度. 测试在适当的情况下可以保证项目的品质从而得到更好的开发进度.
 
-如上述的例子, 在修改功能 A 的 BUG 的时候, 如果你不知道 H 会影响到 BC 又没有测试的话, 那么开发 BC 的同学可能会出现 **"昨天还好好的, 今天怎么就不能用了?"** 的情况. 
+如上述的例子, 在修改功能 A 的 BUG 的时候, 如果你不知道 H 会影响到 BC 又没有测试的话, 那么开发 BC 的同学可能会出现十分经典的 **"昨天还好好的, 今天怎么就不能用了?"** 的情况. 
 
 当然写测试拖累开发进度的情况也是客观存在的, 通常是有以下几种情况:
 
@@ -49,13 +49,13 @@ D
 你可以通过测试来避免坑爹的同事在某些逻辑中写出死循环, 在通常的测试中加上超时的时间, 在覆盖率足够的情况下, 就可以通过跑出超时的测试来排查出现死循环以及低性能的情况.
 
 
-### 测试方法
+## 测试方法
 
-#### 黑盒测试
+### 黑盒测试
 
 黑盒测试 (Black-box Testing), 测试应用程序的功能, 而不是其内部结构或运作. 测试者不需了解代码、内部结构等, 只需知道什么是应用应该做的事, 即当键入特定的输入, 可得到一定的输出. 测试者通过选择`有效输入`和`无效输入`来验证是否正确的输出. 此测试方法可适合大部分的软件测试, 例如集成测试 (Integration Testing) 以及系统测试 (System Testing).
 
-#### 白盒测试
+### 白盒测试
 
 白盒测试 (White-box Testing) 测试应用程序的内部结构或运作, 而不是测试应用程序的功能 (即黑盒测试). 在白盒测试时, 以编程语言的角度来设计测试案例. 白盒测试可以应用于单元测试 (Unit Testing)、集成测试 (Integration Testing) 和系统的软件测试流程, 可测试在集成过程中每一单元之间的路径, 或者主系统跟子系统中的测试.
 
@@ -79,7 +79,7 @@ D
 
 常用的测试覆盖率框架 [istanbul](https://github.com/gotwarlost/istanbul).
 
-当然覆盖率并不完全是由单元测试贡献, 在单元测试之上还有集成测试等. 更多关于覆盖率的内容可以看看这里----[测试覆盖（率）到底有什么用?](http://www.infoq.com/cn/articles/test-coverage-rate-role).
+当然覆盖率并不完全是由单元测试贡献, 在单元测试之上还有集成测试等. 更多关于覆盖率的内容可以参见[测试覆盖（率）到底有什么用?](http://www.infoq.com/cn/articles/test-coverage-rate-role)
 
 ### Mock
 
@@ -101,6 +101,8 @@ Mock 与 Stub 的区别参见: [Mocks Aren't Stubs](https://martinfowler.com/art
 
 集成测试也称综合测试、组装测试、联合测试, 将程序模块采用适当的集成策略组装起来, 对系统的接口及集成后的功能进行正确性检测的测试工作. 集成测试可以是黑盒的, 也可以是白盒的, 其主要目的是检查软件单位之间的接口是否正确, 而集成测试的对象是**已经经过单元测试的模块**.
 
+例如你可以在本地将项目中的 web app 启动, 并模拟接口调用:
+
 ```javascript
 describe('Path API', () => {
   // ...
@@ -175,7 +177,7 @@ suite.add('RegExp#test', function() {
 ab -n 100 -c 10 https://ele.me/
 ```
 
-可以看到一些数据:
+可以得到如下的详细数据:
 
 ```
 Server Software:        Tengine/2.1.1
@@ -217,7 +219,7 @@ Percentage of the requests served within a certain time (ms)
  100%    491 (longest request)
 ```
 
-可以设置规模以及并发情况. 在比规模不大/需求不复杂的情况下, ab 以及 wrk 也可以用于做压力测试.
+与前者相比, ab 等工具可以设置规模以及并发情况. 在比规模不大/需求不复杂的情况下, ab 以及 wrk 也可以用于做压力测试.
 
 
 ## 压力测试
@@ -245,7 +247,7 @@ assert(!condition, 'Sth wrong');
 
 等等情况的一种简化. 并且提供了丰富了 `equal` 判断, 对于对象类型也有深度/严格判断等情况支持.
 
-Node.js 中内置的 `assert` 模块也是属于断言模块的一种, 但是官方在文档中有注明, 该内置模块主要是用于内置代码编写时的基本断言需求, 并不是一个通用的断言库 (***not intended to be used as a general purpose assertion library**)
+Node.js 中内置的 `assert` 模块也是属于断言模块的一种, 但是官方在文档中有注明, 该内置模块主要是用于内置代码编写时的基本断言需求, 并不是一个通用的断言库 (**not intended to be used as a general purpose assertion library**)
 
 ### 常见断言工具