diff --git a/README.md b/README.md
index 1540bcb632af7ca5a4320a25ee3646aff2ccb3be..0a20b3e9032322c620619d210991722bff256dc5 100644
--- a/README.md
+++ b/README.md
@@ -197,7 +197,7 @@ The process of executing a program with the intent of finding errors.
 
 1. 单一流程，不可逆；
 2. 风险显露得晚，纠正机会少；
-3. 测试只是其中一个阶段，缺乏全过程测试思想。
+3. 测试只是其中一个阶段，缺乏全过程测试思想;
 4. 客户往往很难清楚给出所有的需求，而改模型却要求如此。
 
 **V模型**  
@@ -248,7 +248,7 @@ W 模型是顺序性的、不可逆的，需求的变更和调整，依旧不方
 
 ![敏捷模型](https://gitee.com/XiaFuXiangFei/software-testing/raw/main/images/mj-model.png)
 
-敏捷开发以用户的需求进化为核心，采用迭代、循序渐进的方法进行软件开发。专注于交付对客户有价值的软件（可以工作的)。  
+敏捷开发以用户的需求进化为核心，采用迭代、循序渐进的方法进行软件开发,专注于交付对客户有价值的软件（可以工作的)。  
 
 强调以人为核心，程序员团队和业务专家之间的紧密联系，频繁交付新的软件版本，紧凑的自我组织型团队，更注重软件开发中人的作用。  
 
@@ -274,7 +274,7 @@ W 模型是顺序性的、不可逆的，需求的变更和调整，依旧不方
 
   以人为本，没有比面对面交流更高效的沟通渠道了，基于互相信任的前提，敏捷提倡自治的全功能团队。
 
-  在工作形式上，整个团队平时坐在一起工作，从物理空间上创造了更加便捷面对面的沟通机会。在团队职责上，团队内部具备完成软件交付的角色(能力)，团队所有人对软件的质量负责，开发过程由团队内部把控，业务价值团队内部快速流动，在任何环节都能及时获得反馈。同时，每个角色都更容易从全局视角去思考软件，避免了传统部门墙模式下的视角割裂和协作障碍。
+  在工作形式上，整个团队平时坐在一起工作，从物理空间上创造了面对面更加便捷的沟通机会。在团队职责上，团队内部具备完成软件交付的角色(能力)，团队所有人对软件的质量负责，开发过程由团队内部把控，业务价值团队内部快速流动，在任何环节都能及时获得反馈。同时，每个角色都更容易从全局视角去思考软件，避免了传统部门墙模式下的视角割裂和协作障碍。
 
 * 工作的软件高于详尽的文档  
 
@@ -306,11 +306,11 @@ IEEE729-1983 (电气和电子工程师协会标准IEEE) 对缺陷有一个标准
 1. 软件未达到规格说明书中规定的功能；
 2. 软件出现了产品说明书中指明的不会出现的错误；
 3. 软件功能超出了产品说明书中指明的范围；
-4. 软件难于理解，不易使用，运行速度慢，或者最终用户认为软件使用效果不好。
+4. 软件难于理解、不易使用、运行速度慢，或者最终用户认为软件使用效果不好。
 
 #### 1.4.2 产生原因
 1. 软件本身复杂性，产生大量不确定因素；
-2. 成本、时间限制，导致流程不够完善，文档缺失，缺乏严谨的评审；
+2. 成本、时间限制，导致流程缺乏不够完善，文档缺失，缺乏严谨的评审；
 3. 人员本身技能水平限制、责任心不够、交流沟通不顺畅；
 4. 审查不全面或者没有复审。
 
@@ -409,7 +409,7 @@ IEEE729-1983 (电气和电子工程师协会标准IEEE) 对缺陷有一个标准
 6. bug备注：备注，以便记录一些额外信息。
 
 #### 1.4.8 缺陷预防
-**差错：**人在理解和解决问题的思维和行为过程中出现的问题，沟通不当，理解错误；（产生根源）  
+**差错：**人在理解和解决问题的思维及行为过程中出现的问题，沟通不当，理解错误；（产生根源）  
 **错误：**软件内部问题，设计错误、编码错误；（内部原因）  
 **失效：**软件系统运行时偏离了用户需求。（外部表现）