diff --git a/README.md b/README.md
index 5bd826c9c43b575014ea9867c1585c0e1293c6a6..4346634e06cd9241440da405b5d1c7371e9ae592 100644
--- a/README.md
+++ b/README.md
@@ -14,8 +14,8 @@
 * 软件测试自动化
 * 软件测试管理
 ### 3 课程安排
-学时安排：72课时（理论36+实践36）    
-教材：清华大学出版社 《软件测试》(第2版) 周元哲 编著
+* 学时安排：72课时（理论36+实践36）    
+* 教材：清华大学出版社 《软件测试》(第2版) 周元哲 编著
 ### 4 课程资源
 * 课程内容文档 [gitee 课程地址](https://gitee.com/XiaFuXiangFei/software-testing)
 * 课程思维导图
@@ -71,13 +71,13 @@
 1. 程序设计阶段：个体化生产、专用软件、规模小、功能单一、开发者即使用者。软件 = 程序
 2. 程序系统阶段：多用户人机交互，实时系统和数据库管理系统。
 3. 软件工程阶段：以软件的产品化，系列化、工程化和标准化为特征的软件产业发展起来，软件开发有了可以遵循的软件工程化的设计准则、方法和标准。
-4. 多层分布结构，面向服务架构
+4. 多层分布结构，面向服务架构。
 
 #### 1.1.4 软件项目
 软件项目是一种特殊的项目，具有如下特点：
 1. 知识密集型，技术含量高
 2. 涉及多个专业领域，多种技术综合应用
-3. 项目范围和目标的灵活性
+3. 项目范围广和目标的灵活性高
 4. 风险大，收益大
 5. 客户化程度高
 6. 过程管理重要
@@ -128,7 +128,7 @@ IEEE:使用人工或自动手段来运行或测定某个软件系统的过程，
 1. 1957年之前－调试为主(Debugging Oriented)  
 软件规模小，复杂度低，开发人员承担需求分析、设计、开发、测试等所有工作，等同于调试。  
 2. 1957–1978－证明为主(Demonstration Oriented)  
-与调试区分开，这是软件测试史上一个重要的里程碑，主要目是确认软件是满足需求的。    
+与调试区分开，这是软件测试史上一个重要的里程碑，主要目的是确认软件是满足需求的。    
 3. 1979–1982－破坏为主(Destruction Oriented)  
 1979年，《软件测试的艺术》 (The Art of Software Testing)第一版问世，这本书是测试界的经典之作。书中给出了软件测试的经典定义： 
 
@@ -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，发现得越早，修复起来的成本越低，产生的风险也越小。  
 
@@ -155,7 +155,6 @@ The process of executing a program with the intent of finding errors.
 1. 各阶段划分清晰
 2. 强调计划与需求分析
 3. 适合需求稳定的产品开发
-
 **缺点:**   
 1. 单一流程，不可逆
 2. 风险显露得晚，纠正机会少
@@ -173,7 +172,7 @@ 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 模型来说，测试更早的进入到开发阶段，与开发阶段是并行关系，更早的发现问题，能够及时解决问题，各个阶段分工明确，方便管理。  
 **缺点：**
@@ -183,6 +182,7 @@ 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 +219,7 @@ W 模型是顺序性的、不可逆的，需求的变更和调整，依旧不方
 主动拥抱变化，及时响应，持续交付。
 
 * 响应变化高于遵循计划  
-通过高效的协作，获取快速的反馈，从而尽早做出调整，减少浪费
+通过高效的协作，获取快速的反馈，从而尽早做出调整，减少浪费。
 
 **缺点:**  
 由于其项目周期很长，所以很难保证开发的人员不更换，而缺少文档就会造成在交接的过程中出现很大的困难。
@@ -336,9 +336,9 @@ IEEE729-1983 对缺陷有一个标准的定义：从产品内部看，缺陷是
 6.  bug备注：备注，以便记录一些额外信息。
 
 #### 1.4.8 缺陷预防
-差错：人在理解和解决问题的思维和行为过程中出现的问题，沟通不当，理解错误。（产生根源）  
-错误：软件内部问题，设计错误、编码错误。（内部原因）  
-失效：软件系统运行时偏离了用户需求。（外部表现）  
+**差错：** 人在理解和解决问题的思维和行为过程中出现的问题，沟通不当，理解错误。（产生根源）  
+**错误：** 软件内部问题，设计错误、编码错误。（内部原因）  
+**失效：** 软件系统运行时偏离了用户需求。（外部表现）  
 
 ### 1.5 软件测试行业
 #### 1.5.1 行业现状
@@ -346,9 +346,9 @@ IEEE729-1983 对缺陷有一个标准的定义：从产品内部看，缺陷是
 
 我国软件测试行业起步较晚，发展较慢，直到21世纪初期，我国才逐步开始重视软件测试行业。但近年来，软件行业的快速发展为软件测试行业的发展提供了良好的基础，随着我国软件测试行业的发展，行业内企业向规模化发展将获得规模效应，可以有效降低企业的单位成本;而软件测试技术的不断发展，也将淘汰那些技术实力较弱的企业，促使行业内企业向专业化方向发展。  
 
-在软件业较发达的国家，软件测试产业已形成规模，比较发达，软件测试不仅早已成为软件开发的一个重要组成部分，而且在整个软件开发的系统工程中占据着相当大的比重。在微软公司内部，软件测试人员与软件开发人员的比例一般为1.5∶1到2.5∶1左右，即一个开发人员背后，有至少两位测试人员在工作，以保证软件产品的质量1。国外优秀的软件开发机构把40%的工作花在软件测试上，软件测试费用占软件开发总费用的30%至50%，对于一些要求高可靠性、高安全性的软件，测试费用甚至相当于整个软件项目开发所有费用的3至5倍。  
+在软件业较发达的国家，软件测试产业已形成规模，比较发达，软件测试不仅早已成为软件开发的一个重要组成部分，而且在整个软件开发的系统工程中占据着相当大的比重。在微软公司内部，软件测试人员与软件开发人员的比例一般为1.5∶1到2.5∶1左右，即一个开发人员背后，有至少两位测试人员在工作，以保证软件产品的质量。国外优秀的软件开发机构把40%的工作花在软件测试上，软件测试费用占软件开发总费用的30%至50%，对于一些要求高可靠性、高安全性的软件，测试费用甚至相当于整个软件项目开发所有费用的3至5倍。  
 
-从国内软件公司软件测试部门的独立性来看，多数软件企业没有专门的测试技术部门，软件测试程序也不太规范，多数企业也不懂测试，对测试的投入资金过少。大多数是在经过简单的测试之后，就认为是没有问题了，就交于用户了，让用户去“测试”。于是，软件产品在没有经过严格测试的情况下就发布了。对国内消费类软件而言，经常出现一些已经推向市场的产品由于被发现有严重缺陷而导致大量退货的现象。定制的行业软件，常出现一再返工、无限期的修改和维护的现象。
+从国内软件公司软件测试部门的独立性来看，多数软件企业没有专门的测试技术部门，软件测试程序也不太规范，多数企业也不懂测试，对测试的投入资金过少。大多数是在经过简单的测试之后，就认为是没有问题了，就交于用户了，让用户去“测试”。于是，软件产品在没有经过严格测试的情况下就发布了。对国内消费类软件而言，经常出现一些已经推向市场的产品由于被发现有严重缺陷而导致大量退货的现象；定制的行业软件，常出现一再返工、无限期的修改和维护的现象。
 
 当前国内软件测试行业主要存在以下问题：  
 1. 软件规模越来越大，功能越来越复杂，如何进行充分而有效的测试成为难题。
@@ -361,7 +361,7 @@ IEEE729-1983 对缺陷有一个标准的定义：从产品内部看，缺陷是
 8. 在软件开发基本完成后才进行测试，也缺乏软件测试的统一标准。
 9. 高校从师资储备到专业设置再到人才培养的机制薄弱。
 
-国内外软件测试差距
+国内外软件测试差距：
 1. 测试的理解认识
 2. 测试过程的管理
 3. 测试工具的使用
@@ -508,10 +508,10 @@ IEEE729-1983 对缺陷有一个标准的定义：从产品内部看，缺陷是
 **术语**  
 1. 测试编号：测试用例的编号
 2. 测试项：测试的功能点说明
-3. 前置条件：该测试用例的前提条件，比如测试wangdachui／dachui12345（用户名／密码）账户是否能正确登录进去，那前提wangdachui／dachui12345已定是注册过的
+3. 前置条件：该测试用例的前提条件，比如测试wangdachui／dachui12345（用户名／密码）账户是否能正确登录进去，那前提wangdachui／dachui12345一定是注册过的
 4. 测试步骤：就是测试的所有操作步骤，最好是每一个步骤应该对应一个期望结果，最少也得一个测试用例对应一个期望结果
 5. 期望结果：就是希望得到的结果（正确的结果）
-6. 测试结果：实际测试的结果，可选项有：通过、不通过、暂时挂起／锁定（就是暂时不测试）；
+6. 测试结果：实际测试的结果，可选项有：通过、不通过、暂时挂起／锁定（就是暂时不测试）
 7. 对应的bug：当期望结果与实际结果不符时测试不通过，此时需要上报bug（纪录缺陷），bug需要与测试用例对应
 8. 测试执行人：实际由谁来执行测试用例；也有任务分配人的选项，就是测试用例分配给哪个测试员来测试
 9. 备注：做一些备注或者测试的说明
@@ -537,7 +537,7 @@ IEEE729-1983 对缺陷有一个标准的定义：从产品内部看，缺陷是
 3. 使用特定的测试用例设计方法作为判断测试停止的基础
 4. 给出测试停止的要求
 5. 根据经单位时间内查出故障的数量决定是否停止测试
-6. 软件系统经过了单元、集成、系统测试，分别达到停止标准。通过验收测试，得出验收测试结论。
+6. 软件系统经过了单元、集成、系统测试，分别达到停止标准。通过验收测试，得出验收测试结论
 7. 软件项目暂停以进行调整，测试应随之暂停，并备份暂停点数据。或者软件项目开发生命周期内出现重大估算、进度偏差，需暂停或终止时，测试应随之暂停或终止，并备份数据
 #### 2.5.2 软件测试各阶段停止标准
 ##### 单元测试停止标准
@@ -574,7 +574,7 @@ IEEE729-1983 对缺陷有一个标准的定义：从产品内部看，缺陷是
 
 黑盒测试从用户的角度出发，以输入数据与输出数据的对应关系进行测试，数据驱动。
 
-黑盒测试注重测试软件的功能需求，主要视图发现下列几类错误
+黑盒测试注重测试软件的功能需求，主要视图发现下列几类错误：
 1. 功能不正确或遗漏
 2. 界面错误
 3. 数据库访问错误
@@ -592,7 +592,7 @@ IEEE729-1983 对缺陷有一个标准的定义：从产品内部看，缺陷是
 
 #### 3.2.1 划分原则
 1. 在输入条件规定了取值范围的情况下，可以确立一个有效等价类（在取值范围之内）和两个无效等价类（小于取值范围和大于取值范围）。
-2. 在输入条件规定了取回个数的情况下，可以确立一个有效等价类（在取值个数范围之内）和两个无效等价类（小于取值个数和大于取值个数）。
+2. 在输入条件规定了取值个数的情况下，可以确立一个有效等价类（在取值个数范围之内）和两个无效等价类（小于取值个数和大于取值个数）。
 3. 在输入条件规定了输入值的集合的情况下，可以确立一个有效等价类和一个无效等价类。
 4. 在输入条件规定了“必须如何”条件的情况下，可以确立一个有效等价类和一个无效等价类。
 5. 在输入条件是一个布尔值的情况下，可以确立一个有效等价类和一个无效等价类。
@@ -600,8 +600,8 @@ IEEE729-1983 对缺陷有一个标准的定义：从产品内部看，缺陷是
 7. 在规定了输入数据必须遵守规则的情况下，可以确立一个有效等价类（符合规则）和若干个无效等价类（从不同角度违反规则）。
 8. 在确知已划分的等价类中各元素在程序处理中的方式不同的情况下，则应再将改等价类进一步划分为更小的等价类。
 #### 3.2.2 设计测试用例步骤
-1. 形成等价类表，每一等价类规定一个唯一编号
-2. 设计测试用例，使其尽可能多的覆盖尚未覆盖的有效等价类
+1. 形成等价类表，每一等价类规定一个唯一编号。
+2. 设计测试用例，使其尽可能多的覆盖尚未覆盖的有效等价类。
 3. 设计一个新的测试用例，使其只覆盖一个无效等价类，重复这一步直到所有无效等价类均被覆盖。
 #### 3.2.3 等价类举例
 我们要测试学习成绩这一输入框（假设总成绩都是100），那么我们就可以如下图划分，有效的成绩是>=0且<=100的，无效的是<0和>100这两部分。
@@ -615,7 +615,7 @@ IEEE729-1983 对缺陷有一个标准的定义：从产品内部看，缺陷是
 2. 无效等价类1：小于0的负数，比如：-1；
 3. 无效等价类2：大于100的数，比如：121；
 4. 无效等价类3：其他任意非数字字符，比如：a、你、\；
-5. 无效等价类4：空字符
+5. 无效等价类4：空字符。
 
 **等价类最终必须是分割到最小单位，只有这样才能保障测试覆盖全面。**  
 非数字字符可以是包含英文字符、中文、特殊符号的字符串或者字符，所以其实它又可以分为三个无效等价类，分别是：
@@ -648,7 +648,7 @@ IEEE729-1983 对缺陷有一个标准的定义：从产品内部看，缺陷是
 ![健壮性边界值分析](https://gitee.com/XiaFuXiangFei/software-testing/raw/main/images/bianjiezhi2.jpg)
 
 #### 3.3.3 应用举例
-延伸上节的例子来说明：学生信息系统中有一个“考试成绩”的输入项，成绩的取值范围是0~100之间的整数，考试成绩及格的分数线是60，优秀的分数线是80。那么这个例子中的边界值数据是哪些呢：  
+延伸上节的例子来说明：学生信息系统中有一个“考试成绩”的输入项，成绩的取值范围是0~100之间的整数，考试成绩及格的分数线是60，优秀的分数线是80。那么这个例子中的边界值数据是哪些呢？  
 
 > 选取的边界值数据应该包括：
 > 
@@ -669,7 +669,7 @@ IEEE729-1983 对缺陷有一个标准的定义：从产品内部看，缺陷是
 边界值分析对布尔变量和逻辑变量没有多大意义。例如，布尔变量的极值是true和false，但是其余3个值不明确。
 
 ### 3.4 决策表
-等价类划分法和边界值分析法只是孤立地考虑各个输人数据的测试效果，没有考虑输入数据的组合及其相互制约关系，而决策表考虑了多种条件的组合情况。决策表又称为判定表，分析多种逻辑条件(if-else、switch-case等)与执行动之间的关系。  
+等价类划分法和边界值分析法只是孤立地考虑各个输入数据的测试效果，没有考虑输入数据的组合及其相互制约关系，而决策表考虑了多种条件的组合情况。决策表又称为判定表，分析多种逻辑条件(if-else、switch-case等)与执行之间的关系。  
 
 决策表由4部分组成：  
 1. 条件桩：列出了问题的所有条件，通常认为列出的条件次序无关紧要。
@@ -756,11 +756,10 @@ IEEE729-1983 对缺陷有一个标准的定义：从产品内部看，缺陷是
 4. 每当某一规则的条件已经满足，并确定要执行的操作后，不必检验别的规则。
 5. 如果某一规则得到满足要执行多个操作，这些操作的执行顺序无关紧要。
 
-
 这5个必要条件使得操作的执行完全依赖于条件的组合。对于不满足条件的判定表，可增加其他的测试用例。
 
 ### 3.5 因果图
-前面我们介绍的等价类划分法和边界值分析法都没有考虑到输入情况的组合。这样虽然各种输入条件可能出错的情况已经看到了，但是多个输入情况组合起来可能出错的情况却被忽视了
+前面我们介绍的等价类划分法和边界值分析法都没有考虑到输入情况的组合。这样虽然各种输入条件可能出错的情况已经看到了，但是多个输入情况组合起来可能出错的情况却被忽视了。
 >地铁自动充值机充值
 >
 >假设自动充值机每次只能投入面值50或者面值100的人民币，投入钱后会有充值50和充值100两个选项  
@@ -834,12 +833,12 @@ IEEE729-1983 对缺陷有一个标准的定义：从产品内部看，缺陷是
 |  TC5   | E、符、% |    3     | 提示L    |
 |  TC6   | F、特、@ | G、殊、* | 提示L和M |
 #### 3.5.4 优点和缺点
-优点:  
+**优点: **  
 1. 考虑多个输入之间的相互组合、相互制约的关系
 2. 指出需求规格说明书中存在的不完整性和二义性
 3. 帮助测试人员按照一定的步骤高效的开发测试用例
 
-缺点:  
+**缺点: **  
 1. 作为输入条件的原因和输出结果之间的因果关系，很难从规格说明书得到
 2. 此方法得到的用例数量规模大
 ### 3.6 场景法
@@ -877,7 +876,7 @@ IEEE729-1983 对缺陷有一个标准的定义：从产品内部看，缺陷是
 |  TC6   | 场景6：ATM无现金                | 合法卡 | 123456 |      0.00 |  5000.00 |      n/a | 提款选项不可用，用例结束 |
 |  TC7   | 场景7：金额错误                 | 合法卡 | 123456 |   2000.00 |  5000.00 |       20 | 提示错误，重新输入       |
 |  TC8   | 场景8：卡内余额不足             | 合法卡 | 123456 |   2000.00 |  5000.00 |      600 | 提示错误，重新输入       |
-|  TC9   | 场景9:ATM现金不足               | 合法卡 | 123456 |   2000.00 |  5000.00 |     2500 | 提示错误，重新输入       |
+|  TC9   | 场景9: ATM现金不足               | 合法卡 | 123456 |   2000.00 |  5000.00 |     2500 | 提示错误，重新输入       |
 
 ### 3.7 错误推测法
 #### 3.7.1 概念