diff --git a/README.md b/README.md
index d68eefc60dea4ff7e0ac2f9b5ecbadf0fd147914..a42bd12423064f2a78e29a5818078db2ab4dc536 100644
--- a/README.md
+++ b/README.md
@@ -196,7 +196,7 @@ The process of executing a program with the intent of finding errors.
 **缺点：**   
 
 1. 单一流程，不可逆；
-2. 风险显露得晚，纠正机会少；
+2. 风险显露的晚，纠正机会少；
 3. 测试只是其中一个阶段，缺乏全过程测试思想。
 4. 客户往往很难清楚给出所有的需求，而改模型却要求如此。
 
@@ -376,7 +376,7 @@ IEEE729-1983 (电气和电子工程师协会标准IEEE) 对缺陷有一个标准
 5. 测试员确认已修复；
 6. 测试员关闭缺陷报告，此时缺陷状态是关闭（closed state）。
 
-一个缺陷很可能会被反复打开→关闭。在日常工作过程中，由于开发修订其他缺陷影响、需求变更等因素缺陷可能会被反复打开→关闭。
+一个缺陷很可能会被反复打开→关闭。在日常工作过程中，由于开发修订其他缺陷影响、需求变更等因素，缺陷可能会被反复打开→关闭。
 
 | 缺陷状态 | 描述                                               |
 | -------- | -------------------------------------------------- |
@@ -413,13 +413,13 @@ IEEE729-1983 (电气和电子工程师协会标准IEEE) 对缺陷有一个标准
 6. bug备注：备注，以便记录一些额外信息。截图、视频、log。
 
 #### 1.4.8 缺陷预防
-**差错：**人在理解和解决问题的思维和行为过程中出现的问题，沟通不当，理解错误；（产生根源）  
+**差错：**人在理解和解决问题的思维和行为过程中出现的问题，比如沟通不当，理解错误等；（产生根源）  
 **错误：**软件内部问题，设计错误、编码错误；（内部原因）  
 **失效：**软件系统运行时偏离了用户需求。（外部表现）  
 
 ### 1.5 软件测试行业
 #### 1.5.1 行业现状
-软件系统越来越复杂，一个软件不能够由单独的软件工程师单独编写，而是由团队进行配合，每个人可能只负责一个模块，对于全局没有过多的了解，这时如果运行软件就会容易产生很多的错误。在行业内将这些错误叫做BUG。并且每一个软件工程师都会有思维的死角，自己不容易发现自己编写出来的错误。所以这个时候就需要专门的软件测试工程师用专业的测试方式来检查软件。检查该软件是否符合客户要求的产品设计，是否能够符合大多数用户的使用习惯，如果发现异常状态及时进行处理。软件市场虽然远远没有达到饱和但是各种各样功能的软件也层出不穷竞争激烈，对软件开发的质量要求也是日益增高。    
+软件系统越来越复杂，一个软件不能够由单独的软件工程师单独编写，而是由团队进行配合，每个人可能只负责一个模块，由于对全局没有过多的了解，这时如果运行软件就会容易产生很多的错误。在行业内将这些错误叫做BUG。并且每一个软件工程师都会有思维的死角，自己不容易发现自己编写出来的错误。所以这个时候就需要专门的软件测试工程师用专业的测试方式来检查软件。检查该软件是否符合客户要求的产品设计，是否能够符合大多数用户的使用习惯，如果发现异常状态及时进行处理。软件市场虽然远远没有达到饱和但是各种各样功能的软件也层出不穷竞争激烈，对软件开发的质量要求也是日益增高。    
 
 我国软件测试行业起步较晚，发展较慢，直到21世纪初期，我国才逐步开始重视软件测试行业。但近年来，软件行业的快速发展为软件测试行业的发展提供了良好的基础，随着我国软件测试行业的发展，行业内企业向规模化发展将获得规模效应，可以有效降低企业的单位成本;而软件测试技术的不断发展，也将淘汰那些技术实力较弱的企业，促使行业内企业向专业化方向发展。  
 
@@ -566,13 +566,13 @@ IEEE729-1983 (电气和电子工程师协会标准IEEE) 对缺陷有一个标准
 
 ### 2.2 测试的目的和原则
 #### 2.2.1 测试的目的 
-1. 测试不仅仅是找出错误。通过分析错误产生的原因和错误的发展趋势，可以帮助项目管理者发现当前软件开发过程中的缺陷，以便即时改进；
+1. 测试不仅仅是找出错误，通过分析错误产生的原因和错误的发展趋势，可以帮助项目管理者发现当前软件开发过程中的缺陷，以便即时改进；
 2. 检测产品是否符合用户要求；
 3. 没有发现错误的测试也是有价值的，完整的测试是评定软件质量的一种方法；
 4. 提升用户体验。
 
 #### 2.2.2 测试的原则
-1. 软件测试是证伪而非证实；
+1. 软件测试是证伪而非证真；
 2. 尽早地、不断地进行测试；
 3. 重视无效数据和非预期的测试；
 4. 应当对每一个测试结果做全面的检查；
@@ -604,7 +604,7 @@ IEEE729-1983 (电气和电子工程师协会标准IEEE) 对缺陷有一个标准
 1. 白盒测试
 2. 黑盒测试
 3. 灰盒测试
-#### 2.3.4 按照执行主体划分
+#### 2.3.4 按照执行主题划分
 1. α测试
 2. β测试
 3. 第三方测试
@@ -657,7 +657,7 @@ IEEE729-1983 (电气和电子工程师协会标准IEEE) 对缺陷有一个标准
 1. 产品特性没变：漏测或者环境变更，这个时候版本没变，测试用例增加和修改均可；
 2. 原有特性变化：功能变化，只能新增，不能修改，还要兼容老版本；
 3. 原有功能取消：测试用例在新版本上置为“空”标志或者“无效状态”，对于先前版本有效；
-4. 新增功能：新增用例，对应新版本标志。
+4. 新增功能：新增用例，对应新测试用例。
 
 **测试用例组成：**  
 1. 用例编号：产品名-测试阶段-测试项-XX功能模块缩写加数字
@@ -686,7 +686,7 @@ IEEE729-1983 (电气和电子工程师协会标准IEEE) 对缺陷有一个标准
 2. 执行了所有的测试用例，并没有发现故障；
 3. 使用特定的测试用例设计方法作为判断测试停止的基础；
 4. 给出测试停止的要求；
-5. 根据经单位时间内查出故障的数量决定是否停止测试；
+5. 根据单位时间内查出故障的数量决定是否停止测试；
 6. 软件系统经过了单元、集成、系统测试，分别达到停止标准。通过验收测试，得出验收测试结论；
 7. 软件项目暂停以进行调整，测试应随之暂停，并备份暂停点数据。或者软件项目开发生命周期内出现重大估算、进度偏差，需暂停或终止时，测试应随之暂停或终止，并备份数据。
 #### 2.5.2 软件测试各阶段停止标准
@@ -749,7 +749,7 @@ IEEE729-1983 (电气和电子工程师协会标准IEEE) 对缺陷有一个标准
 
 **要注意的是，在进行等价类划分的过程中，我们不仅要考虑有效等价类划分，也要考虑无效等价类划分。**
 
-有效等价类：是指输入完全符合程序规格说明的数据集合。利用有效等价类可以测试程序是否满足规格说明书规定的功能和性能。
+有效等价类：是指对程序的规格说明合理的，有意义的输入的数据集合。利用有效等价类可以测试程序是否满足规格说明书规定的功能和性能。
 
 无效等价类：和有效等价类相反，是指对程序的规格说明无意义、不合理的输入数据构成的集合。