diff --git a/README.md b/README.md
index 5bd826c9c43b575014ea9867c1585c0e1293c6a6..6c48ebdde214aeee183eaab6305876345c80010d 100644
--- a/README.md
+++ b/README.md
@@ -95,7 +95,7 @@
 **输出：**《需求规格说明书》
 #### 1.2.4 评审  
 **描述：** 评审就是做审查，对这个阶段的工作进行审查，看是否偏离或者有遗漏（比如：设计和工厂的各个环节都有相关的审查，审查材料是否合格、设计是否符合规定、按照工人/设计出的材料需求是否足够或者多余等等，这些审查都是评审）；评审一般由相应工作人员来参与。    
-**参与者：** 每个阶段的评审一般都是各职能部门内部审核，也可以申请其他相关人员审核，比如需求评审，一般是产品经理、项目经理、测试、开发一起评审；系统设计一般是项目经理、开发评审；测试策略评审一般是测试组内部评审等等
+**参与者：** 每个阶段的评审一般都是各职能部门内部审核，也可以申请其他相关人员审核，比如需求评审，一般是产品经理、项目经理、测试、开发一起评审；系统设计一般是项目经理、开发评审；测试策略评审一般是测试组内部评审等等。
 #### 1.2.5 设计  
 **描述：** 架构师根据需求确定产品或者项目的场景、特点，选择合适的框架，技术使项目实现最优化。在此基础上将系统进行概要设计，包括系统总体数据结构、数据库结构、模块结构以及它们之间的关系等。开发人员根据概要设计对具体模块进行详细设计，包括接口、参数等。此处设计会形成概要设计文档和详细设计文档。    
 **参与者：** 项目经理、架构师、开发、测试
@@ -140,7 +140,7 @@ The process of executing a program with the intent of finding errors.
 这个观点较之前证明为主的思路，是一个很大的进步。我们不仅要证明软件做了该做的事情，也要保证它没做不该做的事情，这会使测试更加全面，更容易发现问题。
     
 4. 1983–1987－评估为主(Evaluation Oriented)  
-软件行业进入了大发展时期，软件趋向大型化、复杂度，质量越来越重要。软件测试的基础理论和实用技术开始形成。提出了在软件生命周期中使用分析、评审、测试来评估产品的理论。  
+软件行业进入了大发展时期，软件趋向大型化、复杂化，软件质量越来越重要。软件测试的基础理论和实用技术开始形成。提出了在软件生命周期中使用分析、评审、测试来评估产品的理论。  
 5. 1988–至今－预防为主(Prevention Oriented)  
 尽量早的介入，尽量早的发现这些明显的或隐藏的bug，发现得越早，修复起来的成本越低，产生的风险也越小。  
 
@@ -173,16 +173,18 @@ The process of executing a program with the intent of finding errors.
 **W模型(双V模型)**  
 ![W模型](https://gitee.com/XiaFuXiangFei/software-testing/raw/main/images/w-model.png)
 
-明确表示出了测试与开发的并行关系  
+明确表示出了测试与开发的并行关系。  
 **优点：**  
 W 模型相对于 V 模型来说，测试更早的进入到开发阶段，与开发阶段是并行关系，更早的发现问题，能够及时解决问题，各个阶段分工明确，方便管理。  
 **缺点：**
+
 W 模型是顺序性的、不可逆的，需求的变更和调整，依旧不方便。  
 
 **螺旋模型**  
 ![螺旋模型](https://gitee.com/XiaFuXiangFei/software-testing/raw/main/images/lx-model.png)
 
 大型软件项目通常有很多不确定性和风险，如果采用瀑布式线性过程模型，失败风险很大，因此需要采取一种渐进式的演化过程模型。将产品分解成增量版本，每个版本单独测试。
+
 **敏捷模型**  
 ![敏捷模型](https://gitee.com/XiaFuXiangFei/software-testing/raw/main/images/mj-model.png)
 
@@ -219,7 +221,7 @@ W 模型是顺序性的、不可逆的，需求的变更和调整，依旧不方
 主动拥抱变化，及时响应，持续交付。
 
 * 响应变化高于遵循计划  
-通过高效的协作，获取快速的反馈，从而尽早做出调整，减少浪费
+通过高效的协作，获取快速的反馈，从而尽早做出调整，减少浪费。
 
 **缺点:**  
 由于其项目周期很长，所以很难保证开发的人员不更换，而缺少文档就会造成在交接的过程中出现很大的困难。
@@ -362,17 +364,17 @@ IEEE729-1983 对缺陷有一个标准的定义：从产品内部看，缺陷是
 9. 高校从师资储备到专业设置再到人才培养的机制薄弱。
 
 国内外软件测试差距
-1. 测试的理解认识
-2. 测试过程的管理
-3. 测试工具的使用
-4. 测试人员的培养
+1. 测试的理解认识；
+2. 测试过程的管理；
+3. 测试工具的使用；
+4. 测试人员的培养。
 
 #### 1.5.2 未来趋势
-1. 以软件为代表的计算机行业正在以一种井喷式的趋势发展
-2. 人才缺口大
-3. 女性员工受到青睐
-4. 未来发展空间大
-5. 外包为主
+1. 以软件为代表的计算机行业正在以一种井喷式的趋势发展；
+2. 人才缺口大；
+3. 女性员工受到青睐；
+4. 未来发展空间大；
+5. 外包为主。
 
 #### 1.5.3 软件测试职业发展
 1. 技术方向
@@ -398,22 +400,22 @@ IEEE729-1983 对缺陷有一个标准的定义：从产品内部看，缺陷是
 6. 发散思维方式
 
 ### 1.6 测试认识的误区
-1. 使用了测试工具，就进行了有效的测试
-2. 存在太多无法测试的东西
-3. 软件开发完成后才进行测试
-4. 软件发布后发现质量问题，是测试人员的问题
-5. 软件测试很简单，就是点点点，是个人就能做
-6. 软件测试没有前途，只有程序员才是软件高手
-7. 软件测试是测试人员的事情和程序员无关
-8. 项目进度吃紧时少做测试，时间多时多做测试
-9. 测试要进行穷尽测试
-10. 采样是随机抽取过程
-11. 测试和开发是对头
-12. 测试少报bug开发就会高兴点，报告也会好看点
-13. 自动化测试终会取代手工测试
-14. 规范化软件测试是增加项目成本
-15. 越多测试越有效
-16. 软件测试工作只负责项目上线/产品发布之前的部分
+1. 使用了测试工具，就进行了有效的测试；
+2. 存在太多无法测试的东西；
+3. 软件开发完成后才进行测试；
+4. 软件发布后发现质量问题，是测试人员的问题；
+5. 软件测试很简单，就是点点点，是个人就能做；
+6. 软件测试没有前途，只有程序员才是软件高手；
+7. 软件测试是测试人员的事情和程序员无关；
+8. 项目进度吃紧时少做测试，时间多时多做测试；
+9. 测试要进行穷尽测试；
+10. 采样是随机抽取过程；
+11. 测试和开发是对头；
+12. 测试少报bug开发就会高兴点，报告也会好看点；
+13. 自动化测试终会取代手工测试；
+14. 规范化软件测试是增加项目成本；
+15. 越多测试越有效；
+16. 软件测试工作只负责项目上线/产品发布之前的部分。
 ### 1.7 知识点总结
 
 ## 第2章 软件测试基础知识
@@ -492,10 +494,10 @@ IEEE729-1983 对缺陷有一个标准的定义：从产品内部看，缺陷是
 选择测试用例是软件测试员最重要的一项任务，不正确的选择可能导致测试量过大或者过小，甚至测试目标不对。准确评估风险，把无穷尽的可能性减少到可以控制的范围是软件测试成功的诀窍。  
 
 #### 2.4.2 测试用例的作用
-1. 指导测试的实施
-2. 评估测试结果的度量基准
-3. 保证软件的可维护性和可复用性
-4. 分析缺陷的标准
+1. 指导测试的实施；
+2. 评估测试结果的度量基准；
+3. 保证软件的可维护性和可复用性；
+4. 分析缺陷的标准。
 
 #### 2.4.3 测试用例设计准则
 1. 有效性
@@ -506,63 +508,63 @@ IEEE729-1983 对缺陷有一个标准的定义：从产品内部看，缺陷是
 
 #### 2.4.4 测试用例维护
 **术语**  
-1. 测试编号：测试用例的编号
-2. 测试项：测试的功能点说明
-3. 前置条件：该测试用例的前提条件，比如测试wangdachui／dachui12345（用户名／密码）账户是否能正确登录进去，那前提wangdachui／dachui12345已定是注册过的
-4. 测试步骤：就是测试的所有操作步骤，最好是每一个步骤应该对应一个期望结果，最少也得一个测试用例对应一个期望结果
-5. 期望结果：就是希望得到的结果（正确的结果）
-6. 测试结果：实际测试的结果，可选项有：通过、不通过、暂时挂起／锁定（就是暂时不测试）；
-7. 对应的bug：当期望结果与实际结果不符时测试不通过，此时需要上报bug（纪录缺陷），bug需要与测试用例对应
-8. 测试执行人：实际由谁来执行测试用例；也有任务分配人的选项，就是测试用例分配给哪个测试员来测试
-9. 备注：做一些备注或者测试的说明
-10. 合法用户：就是已经注册过的用户
-11. 非法用户：没有注册过；注册过但是用户名／密码不匹配的；本文特指未注册过的用户
+1. 测试编号：测试用例的编号。
+2. 测试项：测试的功能点说明。
+3. 前置条件：该测试用例的前提条件，比如测试wangdachui／dachui12345（用户名／密码）账户是否能正确登录进去，那前提wangdachui／dachui12345已定是注册过的。
+4. 测试步骤：就是测试的所有操作步骤，最好是每一个步骤应该对应一个期望结果，最少也得一个测试用例对应一个期望结果。
+5. 期望结果：就是希望得到的结果（正确的结果）。
+6. 测试结果：实际测试的结果，可选项有：通过、不通过、暂时挂起／锁定（就是暂时不测试）。
+7. 对应的bug：当期望结果与实际结果不符时测试不通过，此时需要上报bug（纪录缺陷），bug需要与测试用例对应。
+8. 测试执行人：实际由谁来执行测试用例；也有任务分配人的选项，就是测试用例分配给哪个测试员来测试。
+9. 备注：做一些备注或者测试的说明。
+10. 合法用户：就是已经注册过的用户。
+11. 非法用户：没有注册过；注册过但是用户名／密码不匹配的；本文特指未注册过的用户。
 
 测试用例维护一般分为以下几种情况：  
-1. 产品特性没变：漏测或者环境变更，这个时候版本没变，测试用例增加和修改均可
-2. 原有特性变化：功能变化，只能新增，不能修改，还要兼容老版本
-3. 原有功能取消：测试用例在新版本上置为“空”标志或者“无效状态”，对于先前版本有效
-4. 新增功能：新增用例，对应新版本标志
+1. 产品特性没变：漏测或者环境变更，这个时候版本没变，测试用例增加和修改均可。
+2. 原有特性变化：功能变化，只能新增，不能修改，还要兼容老版本。
+3. 原有功能取消：测试用例在新版本上置为“空”标志或者“无效状态”，对于先前版本有效。
+4. 新增功能：新增用例，对应新版本标志。
 
 #### 2.4.5 测试用例设计误区
-1. 测试用例设计等同于测试输入数据设计
-2. 测试用例设计越详细越好
-3. 追求测试用例设计“一步到位”
-4. 将多个测试条件混在一个用例中
+1. 测试用例设计等同于测试输入数据设计；
+2. 测试用例设计越详细越好；
+3. 追求测试用例设计“一步到位”；
+4. 将多个测试条件混在一个用例中。
 
 ### 2.5 测试停止标准
 #### 2.5.1 软件测试停止总体标准
-1. 测试超过了预定时间
-2. 执行了所有的测试用例，并没有发现故障
-3. 使用特定的测试用例设计方法作为判断测试停止的基础
-4. 给出测试停止的要求
-5. 根据经单位时间内查出故障的数量决定是否停止测试
+1. 测试超过了预定时间。
+2. 执行了所有的测试用例，并没有发现故障。
+3. 使用特定的测试用例设计方法作为判断测试停止的基础。
+4. 给出测试停止的要求。
+5. 根据经单位时间内查出故障的数量决定是否停止测试。
 6. 软件系统经过了单元、集成、系统测试，分别达到停止标准。通过验收测试，得出验收测试结论。
-7. 软件项目暂停以进行调整，测试应随之暂停，并备份暂停点数据。或者软件项目开发生命周期内出现重大估算、进度偏差，需暂停或终止时，测试应随之暂停或终止，并备份数据
+7. 软件项目暂停以进行调整，测试应随之暂停，并备份暂停点数据。或者软件项目开发生命周期内出现重大估算、进度偏差，需暂停或终止时，测试应随之暂停或终止，并备份数据。
 #### 2.5.2 软件测试各阶段停止标准
 ##### 单元测试停止标准
-1. 单元测试用例已经通过评审
-2. 按照单元测试计划完成了所有规定单元测试
-3. 达到了测试计划中关于单元测试所规定的覆盖率要求
-4. 被测试的单元每千行代码必须发现至少3个错误
-5. 软件单元功能与设计一致
-6. 单元测试中发现的错误已经得到修改，各级缺陷修复率达到标准
+1. 单元测试用例已经通过评审。
+2. 按照单元测试计划完成了所有规定单元测试。
+3. 达到了测试计划中关于单元测试所规定的覆盖率要求。
+4. 被测试的单元每千行代码必须发现至少3个错误。
+5. 软件单元功能与设计一致。
+6. 单元测试中发现的错误已经得到修改，各级缺陷修复率达到标准。
 
 ##### 集成测试停止标准
-1. 集成测试用例已经通过评审
-2. 按照集成测试计划和增量集成策略完成了整个系统的集成测试
-3. 达到了测试计划中关于集成测试所规定的覆盖率要求
-4. 被测试的集成工作版本每千行代码必须发现至少2个错误
-5. 集成工作版本满足设计定义的各项功能、性能要求
-6. 在集成测试中发现的错误已经得到修改，各级缺陷修复率达到标准
+1. 集成测试用例已经通过评审。
+2. 按照集成测试计划和增量集成策略完成了整个系统的集成测试。
+3. 达到了测试计划中关于集成测试所规定的覆盖率要求。
+4. 被测试的集成工作版本每千行代码必须发现至少2个错误。
+5. 集成工作版本满足设计定义的各项功能、性能要求。
+6. 在集成测试中发现的错误已经得到修改，各级缺陷修复率达到标准。
 
 ##### 系统测试停止标准
-1. 系统测试用例已经通过评审
-2. 按照系统测试计划完成了系统测试
-3. 达到了测试计划中关于系统测试所规定的覆盖率要求
-4. 被测试的系统每千行代码必须发现至少1个错误
-5. 系统测试满足设计需求规格说明书要求
-6. 在系统测试中发现的错误已经得到修改，各级缺陷修复率达到标准
+1. 系统测试用例已经通过评审。
+2. 按照系统测试计划完成了系统测试。
+3. 达到了测试计划中关于系统测试所规定的覆盖率要求。
+4. 被测试的系统每千行代码必须发现至少1个错误。
+5. 系统测试满足设计需求规格说明书要求。
+6. 在系统测试中发现的错误已经得到修改，各级缺陷修复率达到标准。
 
 ### 2.6 知识点总结
 
@@ -575,11 +577,11 @@ IEEE729-1983 对缺陷有一个标准的定义：从产品内部看，缺陷是
 黑盒测试从用户的角度出发，以输入数据与输出数据的对应关系进行测试，数据驱动。
 
 黑盒测试注重测试软件的功能需求，主要视图发现下列几类错误
-1. 功能不正确或遗漏
-2. 界面错误
-3. 数据库访问错误
-4. 性能错误
-5. 初始化和终值错误
+1. 功能不正确或遗漏；
+2. 界面错误；
+3. 数据库访问错误；
+4. 性能错误；
+5. 初始化和终值错误。
 
 ### 3.2 等价类划分
 等价类是指某个输入域的子集合。在该子集合中，测试某等价类的代表值就等于对这类其他值的测试，对于揭露程序的错误是等效的。
@@ -600,8 +602,8 @@ IEEE729-1983 对缺陷有一个标准的定义：从产品内部看，缺陷是
 7. 在规定了输入数据必须遵守规则的情况下，可以确立一个有效等价类（符合规则）和若干个无效等价类（从不同角度违反规则）。
 8. 在确知已划分的等价类中各元素在程序处理中的方式不同的情况下，则应再将改等价类进一步划分为更小的等价类。
 #### 3.2.2 设计测试用例步骤
-1. 形成等价类表，每一等价类规定一个唯一编号
-2. 设计测试用例，使其尽可能多的覆盖尚未覆盖的有效等价类
+1. 形成等价类表，每一等价类规定一个唯一编号。
+2. 设计测试用例，使其尽可能多的覆盖尚未覆盖的有效等价类。
 3. 设计一个新的测试用例，使其只覆盖一个无效等价类，重复这一步直到所有无效等价类均被覆盖。
 #### 3.2.3 等价类举例
 我们要测试学习成绩这一输入框（假设总成绩都是100），那么我们就可以如下图划分，有效的成绩是>=0且<=100的，无效的是<0和>100这两部分。
@@ -615,7 +617,7 @@ IEEE729-1983 对缺陷有一个标准的定义：从产品内部看，缺陷是
 2. 无效等价类1：小于0的负数，比如：-1；
 3. 无效等价类2：大于100的数，比如：121；
 4. 无效等价类3：其他任意非数字字符，比如：a、你、\；
-5. 无效等价类4：空字符
+5. 无效等价类4：空字符。
 
 **等价类最终必须是分割到最小单位，只有这样才能保障测试覆盖全面。**  
 非数字字符可以是包含英文字符、中文、特殊符号的字符串或者字符，所以其实它又可以分为三个无效等价类，分别是：
@@ -760,10 +762,10 @@ IEEE729-1983 对缺陷有一个标准的定义：从产品内部看，缺陷是
 这5个必要条件使得操作的执行完全依赖于条件的组合。对于不满足条件的判定表，可增加其他的测试用例。
 
 ### 3.5 因果图
-前面我们介绍的等价类划分法和边界值分析法都没有考虑到输入情况的组合。这样虽然各种输入条件可能出错的情况已经看到了，但是多个输入情况组合起来可能出错的情况却被忽视了
+前面我们介绍的等价类划分法和边界值分析法都没有考虑到输入情况的组合。这样虽然各种输入条件可能出错的情况已经看到了，但是多个输入情况组合起来可能出错的情况却被忽视了。
 >地铁自动充值机充值
 >
->假设自动充值机每次只能投入面值50或者面值100的人民币，投入钱后会有充值50和充值100两个选项  
+>假设自动充值机每次只能投入面值50或者面值100的人民币，投入钱后会有充值50和充值100两个选项 。 
 
 等价类划分法和边界值分析法可能不会测试到投入面值50的人民币，然后点击充值100这种异常情况；因此，当程序的输入条件有多个的话，就需要用到因果图法来设计测试用例了。
 
@@ -785,11 +787,11 @@ IEEE729-1983 对缺陷有一个标准的定义：从产品内部看，缺陷是
 
 ![约束图](https://gitee.com/XiaFuXiangFei/software-testing/raw/main/images/yueshutu.png)
 
-* E(互斥)：原因不会同时成立，最多1个成立,可以都不成立
-* I(包含)：原因中至少一个成立,不能同时为0
-* O(唯一)：原因中有且只有一个成立
-* R(要求)：原因中a出现，b必须出现,a=1则b=1,a=0的话，b随便。QQ登录的例子a为自动登录，b是记住密码
-* M(屏蔽)：a为1时，b必须是0,a=1,则b=0，如果a=0，b随便
+* E(互斥)：原因不会同时成立，最多1个成立,可以都不成立。
+* I(包含)：原因中至少一个成立,不能同时为0。
+* O(唯一)：原因中有且只有一个成立。
+* R(要求)：原因中a出现，b必须出现,a=1则b=1,a=0的话，b随便。QQ登录的例子a为自动登录，b是记住密码。
+* M(屏蔽)：a为1时，b必须是0,a=1,则b=0，如果a=0，b随便。
 
 #### 3.5.2 设计因果图测试用例步骤
 1. 分析软件规格说明，哪些是原因(即输入条件或输入条件的等价类)，哪些是结果(即输出条件)，给每个原因和结果赋予标识符。
@@ -799,7 +801,7 @@ IEEE729-1983 对缺陷有一个标准的定义：从产品内部看，缺陷是
 
 对于逻辑结构复杂软件，先用因果图进行图形分析，再用判定表进行统计，最后设计测试用例。当然，对于比较简单的测试对象，可以忽略因果图，直接使用决策表。
 #### 3.5.3 应用举例
-需求：第一列字符必须是A或者B，第二列为数字，才允许进行文件修改。如果第一列字符不正确，输出提示L，第二列不是数字，输出提示M,采用因果图设计测试用例
+需求：第一列字符必须是A或者B，第二列为数字，才允许进行文件修改。如果第一列字符不正确，输出提示L，第二列不是数字，输出提示M,采用因果图设计测试用例。
 
 原因：
 1. 第一列是A
@@ -835,13 +837,13 @@ IEEE729-1983 对缺陷有一个标准的定义：从产品内部看，缺陷是
 |  TC6   | F、特、@ | G、殊、* | 提示L和M |
 #### 3.5.4 优点和缺点
 优点:  
-1. 考虑多个输入之间的相互组合、相互制约的关系
-2. 指出需求规格说明书中存在的不完整性和二义性
-3. 帮助测试人员按照一定的步骤高效的开发测试用例
+1. 考虑多个输入之间的相互组合、相互制约的关系。
+2. 指出需求规格说明书中存在的不完整性和二义性。
+3. 帮助测试人员按照一定的步骤高效的开发测试用例。
 
 缺点:  
-1. 作为输入条件的原因和输出结果之间的因果关系，很难从规格说明书得到
-2. 此方法得到的用例数量规模大
+1. 作为输入条件的原因和输出结果之间的因果关系，很难从规格说明书得到。
+2. 此方法得到的用例数量规模大。
 ### 3.6 场景法
 通过尝尽该描述的业务流程（业务逻辑）,设计用例来遍历场景（路径）,验证系统功能的正确性。
 场景法重点是测试流程，因此每个流程用一个用例验证即可，流程测试没问题不代表系统功能没问题，还需要单步进行测试，结合前面的方法。
@@ -905,23 +907,23 @@ IEEE729-1983 对缺陷有一个标准的定义：从产品内部看，缺陷是
 
 #### 3.7.3 常见错误
 1. 页面规范相关部分（跟公司甚至项目需求有关系）
-  - 命名、注释、字体、颜色、缩进等
-  - 文本框长度/范围限制
-  - 支持的浏览器、操作系统、jdk等做兼容性测试
+  - 命名、注释、字体、颜色、缩进等；
+  - 文本框长度/范围限制；
+  - 支持的浏览器、操作系统、jdk等做兼容性测试。
 2. 常识性问题
-  - 密码用密文
-  - 手机号码是11位，且是特定三位数开头
-  - 文本框自动忽略前后空格
-  - 支持模糊查询
+  - 密码用密文；
+  - 手机号码是11位，且是特定三位数开头；
+  - 文本框自动忽略前后空格；
+  - 支持模糊查询。
 3. 常见的异常测试情况
-  - 输入框不输入任何内容（为空）或者输入空格的情况
-  - 输入框输入非法字符
-  - 用户注销后，是否仍然能操作；再登录是否能成功
-  - 断电重连后是否能继续使用且信息未丢失
+  - 输入框不输入任何内容（为空）或者输入空格的情况；
+  - 输入框输入非法字符；
+  - 用户注销后，是否仍然能操作；再登录是否能成功；
+  - 断电重连后是否能继续使用且信息未丢失。
 4. 功能相关的常见异常问题
-  - C++软件的内存泄漏、内存分配
-  - web程序的session失效问题
-  - JavaScript字符转义
+  - C++软件的内存泄漏、内存分配；
+  - web程序的session失效问题；
+  - JavaScript字符转义。
 ### 3.8 综合策略
 黑盒测试方法有等价类划分、边界值分析、决策表、因果图、场景法、错误推测法等，每种测试方法都有其各自的特点和适用场合。  
 软件测试专家Myers给出了黑盒测试方法中各种测试方法的使用策略: