diff --git a/README.md b/README.md
index d65a5f078b549bf68013acdc46620bc36be4000b..df4f470805a2c605d253e3c6d75f5b8fdc0c99e8 100644
--- a/README.md
+++ b/README.md
@@ -406,7 +406,7 @@ IEEE729-1983 (电气和电子工程师协会标准IEEE) 对缺陷有一个标准
 
 我国软件测试行业起步较晚，发展较慢，直到21世纪初期，我国才逐步开始重视软件测试行业。但近年来，软件行业的快速发展为软件测试行业的发展提供了良好的基础，随着我国软件测试行业的发展，行业内企业向规模化发展将获得规模效应，可以有效降低企业的单位成本;而软件测试技术的不断发展，也将淘汰那些技术实力较弱的企业，促使行业内企业向专业化方向发展。  
 
-在软件业较发达的国家，软件测试产业已形成规模，比较发达，软件测试不仅早已成为软件开发的一个重要组成部分，而且在整个软件开发的系统工程中占据着相当大的比重。在微软公司内部，软件测试人员与软件开发人员的比例一般为1.5∶1到2.5∶1左右，即一个开发人员背后，有至少两位测试人员在工作，以保证软件产品的质量。国外优秀的软件开发机构把40%的工作花在软件测试上，软件测试费用占软件开发总费用的30%至50%，对于一些要求高可靠性、高安全性的软件，测试费用甚至相当于整个软件项目开发所有费用的3至5倍。  
+在软件业较发达的国家，软件测试产业已形成规模，比较发达，软件测试不仅早已成为软件开发的一个重要组成部分，而且在整个软件开发的系统工程中占据着相当大的比重。在微软公司内部，软件测试人员与软件开发人员的比例一般为1.5∶1到2.5∶1，即一个开发人员背后，有至少两位测试人员在工作，以保证软件产品的质量。国外优秀的软件开发机构把40%的工作花在软件测试上，软件测试费用占软件开发总费用的30%至50%，对于一些要求高可靠性、高安全性的软件，测试费用甚至相当于整个软件项目开发所有费用的3至5倍。  
 
 从国内软件公司软件测试部门的独立性来看，多数软件企业没有专门的测试技术部门，软件测试程序也不太规范，多数企业也不懂测试，对测试的投入资金过少。大多数是在经过简单地测试之后，就认为没有问题了，就交于用户了，让用户去“测试”。于是，软件产品在没有经过严格测试的情况下就发布了。对国内消费类软件而言，经常出现一些已经推向市场的产品由于被发现有严重缺陷而导致大量退货的现象。定制的行业软件，常出现一再返工、无限期的修改和维护的现象。
 
@@ -651,10 +651,10 @@ IEEE729-1983 (电气和电子工程师协会标准IEEE) 对缺陷有一个标准
 ### 2.5 测试停止标准
 #### 2.5.1 软件测试停止总体标准
 1. 测试超过了预定时间；
-2. 执行了所有的测试用例，并没有发现故障；
+2. 执行了所有的测试用例，但并没有发现故障；
 3. 使用特定的测试用例设计方法作为判断测试停止的基础；
 4. 给出测试停止的要求；
-5. 根据经单位时间内查出故障的数量决定是否停止测试；
+5. 根据单位时间内查出故障的数量决定是否停止测试；
 6. 软件系统经过了单元、集成、系统测试，分别达到停止标准。通过验收测试，得出验收测试结论；
 7. 软件项目暂停以进行调整，测试应随之暂停，并备份暂停点数据。或者软件项目开发生命周期内出现重大估算、进度偏差，需暂停或终止时，测试应随之暂停或终止，并备份数据。
 #### 2.5.2 软件测试各阶段停止标准
@@ -679,7 +679,7 @@ IEEE729-1983 (电气和电子工程师协会标准IEEE) 对缺陷有一个标准
 2. 按照系统测试计划完成了系统测试；
 3. 达到了测试计划中关于系统测试所规定的覆盖率要求；
 4. 被测试的系统每千行代码必须发现至少1个错误；
-5. 系统测试满足设计需求规格说明书要求；
+5. 系统测试满足设计需求和规格说明书要求；
 6. 在系统测试中发现的错误已经得到修改，各级缺陷修复率达到标准。
 
 ### 2.6 知识点总结
@@ -751,7 +751,7 @@ IEEE729-1983 (电气和电子工程师协会标准IEEE) 对缺陷有一个标准
 边界值分析法是等价类划分法的补充。顾名思义，边界值分析法是对输入的边界值进行测试。从实践中我们可以发现，人们无论是在生活中还是在工作中往往会忽略边界值的条件，所以在输入或者输出的边界上会发生大量的错误。因此，在测试用例设计中，需要对输入的条件进行分析并且提取其中的边界值条件，通过对这些边界值的测试来查出更多的错误。  
 
 常见的边界值：  
-1. 文本框接受字符个数，比如用户名长度、密码长度等；
+1. 文本框接受字符的个数，比如用户名长度、密码长度等；
 2. 报表的第1行和最后1行；
 3. 数组元素的第1个和最后1个；
 4. 循环的第1次、第2次和倒数第1次、最后1次。
@@ -789,7 +789,7 @@ IEEE729-1983 (电气和电子工程师协会标准IEEE) 对缺陷有一个标准
 |  位置  | 上下左右里面一点<br>外面一点       | 按钮，四边内四点，外四点                                         |
 
 #### 3.3.4 局限性
-如果被测程序是多个独立变量的函数，这些变量受物理量的限制，则较适合采用边界值分析。这里的关键是 **“独立”的“物理量”** 。例如，Date是3个变量(年、月、日)的函数，对其采用边界分析测试用例，就会发现测试用例是不充分的，例如，没强调2月和闰年。其存在问题是因为没有考虑月份、日期和年变量之间存在的依赖关系。由于边界值分析假设变量是完全独立的，因此边界值分析测试用例是对物理量的边界独立导出变量极值，不考虑函数的性质，也不考虑变量的语义含义。
+如果被测程序是多个独立变量的函数，这些变量受物理量的限制，则较适合采用边界值分析。这里的关键是 **“独立”的“物理量”** 。例如，Date是3个变量(年、月、日)的函数，对其采用边界分析测试用例，就会发现测试用例是不充分的，例如，没强调2月和闰年。其存在问题是因为没有考虑月份、日期和年变量之间存在的依赖关系。由于边界值分析假设变量是完全独立的，因此边界值分析测试用例是对物理量的边界独立导出变量极值，不考虑函数的性质，也不考虑变量的语义和含义。
 边界值分析对布尔变量和逻辑变量没有多大意义。例如，布尔变量的极值是true和false，但是其余3个值不明确。
 
 ### 3.4 决策表
@@ -874,7 +874,7 @@ IEEE729-1983 (电气和电子工程师协会标准IEEE) 对缺陷有一个标准
 决策表把复杂问题的各种可能情况一一列出，易于理解。但是，决策表不能表达重复执行动作的缺点。 
 
 使用判定表设计测试用例的条件如下：  
-1. 规格说明以判定表形式给出，或很容易转换成判定表；
+1. 规格说明以判定表的形式给出，或很容易转换成判定表；
 2. 条件的排列顺序不会也不影响执行哪些操作；
 3. 规则的排列顺序不会也不影响执行哪些操作；
 4. 每当某一规则的条件已经满足，并确定要执行的操作后，不必检验别的规则；
@@ -969,8 +969,8 @@ IEEE729-1983 (电气和电子工程师协会标准IEEE) 对缺陷有一个标准
 1. 作为输入条件的原因和输出结果之间的因果关系，很难从规格说明书得到；
 2. 此方法得到的用例数量规模大。
 ### 3.6 场景法
-通过尝尽该描述的业务流程（业务逻辑），设计用例来遍历场景（路径），验证系统功能的正确性。
-场景法重点是测试流程，因此每个流程用一个用例验证即可，流程测试没问题不代表系统功能没问题，还需要单步进行测试，结合前面的方法。
+通过尝试尽该描述的业务流程（业务逻辑），设计用例来遍历场景（路径），验证系统功能的正确性。
+场景法重点是测试流程，因此每个流程用一个用例验证即可，流程测试没问题并不代表系统功能没问题，还需要单步进行测试，结合前面的方法。
 
 流程图：
 * 矩形：步骤
@@ -1022,7 +1022,7 @@ IEEE729-1983 (电气和电子工程师协会标准IEEE) 对缺陷有一个标准
 
 #### 3.7.2 优点和缺点
 **优点：**    
-1. 不用设计等价类的测试用例，将多个等价类的测试合成一个随机测试，可以以较少代码实现测试代码的编写；
+1. 不用设计等价类的测试用例，将多个等价类的测试合成一个随机测试，可以用较少代码实现测试代码的编写；
 2. 当等价类设计不确切或不完全时，测试会产生遗漏，而使用错误推测法则是按照概率进行等价类覆盖。不论存在多少个等价类，只要随机数据个数足够，就能保证各个等价类被覆盖的概率足够高，能够有效弥补等价类分法设计不充分的缺陷；
 3. 采用错误推测法进行测试，每次执行测试时，测试的样本数据可能都不相同，执行次数愈多，错误暴露的概率愈大。