diff --git a/.DS_Store b/.DS_Store
index 16f2c801ede02ffbd9026f24a15df3b177bd5901..222777095b38cdba4aadd9b23541099770307eb0 100644
Binary files a/.DS_Store and b/.DS_Store differ
diff --git a/README.md b/README.md
index 5f3573f42536caef32c9fba0a140a1363cea5827..9cd88aaf17b7bf35e7f170d92c4353443b0f758a 100644
--- a/README.md
+++ b/README.md
@@ -103,12 +103,12 @@
 **输出：**《需求规格说明书》
 
 #### 1.2.4 评审  
-**描述：** 评审就是做审查，对这个阶段的工作进行审查，看是否偏离或者有遗漏（比如：设计和工厂的各个环节都有相关的审查，审查材料是否合格、设计是否符合规定、按照工人/设计出的材料需求是否足够或者多余等等，这些审查都是评审）；评审一般由相应工作人员来参与。    
+**描述：** 评审就是做审查，对这个阶段的工作进行审查，看是否偏离或者有遗漏（比如：设计和工厂的各个环节都有相关的审查，审查材料是否合格、设计是否符合规定、按照工人设计出的材料需求是否足够或者多余等等，这些审查都是评审）；评审一般由相应工作人员来参与。    
 
 **参与者：** 每个阶段的评审一般都是各职能部门内部审核，也可以申请其他相关人员审核，比如需求评审，一般是产品经理、项目经理、测试人员、开发人员一起评审；系统设计一般是项目经理、开发人员评审；测试策略评审一般是测试组内部评审。
 
 #### 1.2.5 设计  
-**描述：** 架构师根据需求确定产品或者项目的场景、特点，选择合适的框架，技术使项目实现最优化。在此基础上将系统进行概要设计，包括系统总体数据结构、数据库结构、模块结构以及它们之间的关系等。开发人员根据概要设计对具体模块进行详细设计，包括接口、参数等。此处设计会形成概要设计文档和详细设计文档。    
+**描述：** 架构师根据需求确定产品或者项目的场景、特点，选择合适的框架、技术使项目实现最优化。在此基础上将系统进行概要设计，包括系统总体数据结构、数据库结构、模块结构以及它们之间的关系等。开发人员根据概要设计对具体模块进行详细设计，包括接口、参数等。此处设计会形成概要设计文档和详细设计文档。    
 
 **参与者：** 项目经理、架构师、开发人员、测试人员
 
@@ -131,7 +131,7 @@
   - 测试评估
 #### 1.2.9 部署/发版  
 
-**描述：** 经过前面的各个阶段，产品已经可以出售或者面向大众了。配置管理人员进行封版、版本制作（针对产品来说）/部署上线（针对项目应用来说）。  
+**描述：** 经过前面的各个阶段，产品已经可以出售或者面向大众了。配置管理人员进行封版、版本制作（针对产品来说）、部署上线（针对项目应用来说）。  
 
 **参与人：** 配置管理人员、测试人员
 
@@ -144,7 +144,7 @@
 ### 1.3 软件测试概述
 #### 1.3.1 软件测试定义
 软件测试的经典定义是：在规定的条件下对程序进行操作，以发现程序错误，衡量软件质量，并对其是否能满足设计要求进行评估的过程。  
-IEEE（电气与电子工程师协会）：使用人工或自动手段来运行或测定某个软件系统的过程，其目的在于检测他是否满足规定的需求或弄清预期结果和实际结果的差别。  
+IEEE（电气与电子工程师协会）：使用人工或自动手段来运行或测定某个软件系统的过程，其目的在于检测它是否满足规定的需求或弄清预期结果和实际结果的差别。  
 
 #### 1.3.2 测试发展历程
 1. 1957年之前－调试为主(Debugging Oriented)  
@@ -198,6 +198,7 @@ The process of executing a program with the intent of finding errors.
 1. 单一流程，不可逆；
 2. 风险显露得晚，纠正机会少；
 3. 测试只是其中一个阶段，缺乏全过程测试思想。
+4. 客户往往很难清楚给出所有的需求，而改模型却要求如此。
 
 **V模型**  
 
@@ -235,6 +236,14 @@ W 模型是顺序性的、不可逆的，需求的变更和调整，依旧不方
 
 螺旋模型是一种演化软件开发过程模型，它兼顾了快速原型的迭代的特征以及瀑布模型的系统化与严格监控。螺旋模型最大的特点在于引入了其他模型不具备的风险分析，使软件在无法排除重大风险时有机会停止，以减小损失。同时，在每个迭代阶段构建原型是螺旋模型用以减小风险的途径。螺旋模型更适合大型的昂贵的系统级的软件应用。
 
+**优点：**  
+
+螺旋模型将风险分析扩展到各个阶段中，大幅度降低了软件开发的风险。
+
+**缺点：**
+
+螺旋模型的控制和管理较为复杂，可操作性不强，对项目管理人员的要求较高。
+
 **敏捷模型**  
 
 ![敏捷模型](https://gitee.com/XiaFuXiangFei/software-testing/raw/main/images/mj-model.png)
@@ -279,9 +288,13 @@ W 模型是顺序性的、不可逆的，需求的变更和调整，依旧不方
 
   通过高效的协作，获取快速的反馈，从而尽早做出调整，减少浪费。
 
-**缺点:**  
+**优点：**  
+
+敏捷模型持续关注卓越的技术和良好的设计，定期适应变化的环境，即使是最新的需求变化也受到欢迎。
+
+**缺点：**
 
-由于其项目周期很长，所以很难保证开发的人员不更换，而缺少文档就会造成在交接的过程中出现很大的困难。
+敏捷模型缺乏对必要的设计和文件的重视，由于其项目周期很长，所以很难保证开发的人员不更换，而缺少文档就会造成在交接的过程中出现很大的困难。只有高级程序员才能在开发过程中做出所需的决策，因此，除非与经验丰富的资源相结合，否则对于新手程序员来说，他没有立足之地。
 
 ![敏捷开发流程](https://gitee.com/XiaFuXiangFei/software-testing/raw/main/images/mj-process.png)
 
@@ -357,11 +370,11 @@ IEEE729-1983 (电气和电子工程师协会标准IEEE) 对缺陷有一个标准
 #### 1.4.6 跟踪流程
 最优化、最简单的生命周期是：（理想情况）
 1. 测试员发现缺陷并记录缺陷报告；
-2. 缺陷报告交给程序员，此时缺陷状态是打开；（open state）
-3. 程序员修改缺陷，此时缺陷状态是解决；（resolved state）
+2. 缺陷报告交给程序员，此时缺陷状态是打开（open state）；
+3. 程序员修改缺陷，此时缺陷状态是解决（resolved state）；
 4. 缺陷报告交还测试员；
 5. 测试员确认已修复；
-6. 测试员关闭缺陷报告，此时缺陷状态是关闭。（closed state）
+6. 测试员关闭缺陷报告，此时缺陷状态是关闭（closed state）。
 
 一个缺陷很可能会被反复打开→关闭。在日常工作过程中，由于开发修订其他缺陷影响、需求变更等因素缺陷可能会被反复打开→关闭。
 
@@ -380,20 +393,24 @@ IEEE729-1983 (电气和电子工程师协会标准IEEE) 对缺陷有一个标准
 #### 1.4.7 缺陷记录内容
 1. bug编号：bug的唯一id，以方便尽快找到此bug；
 2. bug标题：bug摘要，阐述bug大体内容；
-3. bug严重级别，优先级：作为缺陷是否修复以及缺陷修复优先级的决定性因素；
-4. bug产生的模块：记录bug所属模块，方便开发定位问题；
-5. bug对应的版本：bug对应的软件版本，方便后续的统计归档以及开发定位问题；
-6. bug描述：bug的产生环境、详细步骤、期望结果、实际结果；
-7. 附件：包括但不仅限于截图、日志、录像、所用到的示例文件以及应用；同样是方便复现解决缺陷的。
+3. bug类型：功能、用户界面、软件包、文档、性能或接口问题；
+4. bug严重级别:作为缺陷是否修复以及缺陷修复优先级的决定性因素；
+5. bug优先级：作为缺陷是否修复以及缺陷修复优先级的决定性因素；
+6. bug产生的模块：记录bug所属模块，方便开发定位问题；
+7. bug对应的版本：bug对应的软件版本，方便后续的统计归档以及开发定位问题；
+8. bug描述：bug的产生环境、详细步骤、期望结果、实际结果；
+9. bug发现者：谁上报的bug；
+10. bug发现时间：可以自动生成；
+11. 附件：包括但不仅限于截图、日志、录像、所用到的示例文件以及应用；同样是方便复现解决缺陷的。
 
 以上是上报bug、创建bug必须要做的，在后续我们还会对bug进行修复、复测等工作，那么为了记录后续工作，bug还应该包含：
 
 1. bug状态：开始、修复中、修复完成、提测、测试中、测试通过/失败、关闭等，后续bug周期中会讲到；
-2. bug修订人：bug修订人员；
-3. bug复测人：通常是谁报的bug最后返回给谁测试，但是在某些情况下比如bug报告人任务积累太多/不在的情况下也会分给其他人，所以通常会记录bug复测责任人；
-4. bug修订说明：由bug修订人来写，说明bug产生原因，修改思路等；
+2. bug修订人：修改bug的开发人员；
+3. bug修订说明：由bug修订人来写，说明bug产生原因，修改思路等；
+4. bug复测人：通常是谁报的bug最后返回给谁测试，但是在某些情况下比如bug报告人任务积累太多/不在的情况下也会分给其他人，所以通常会记录bug复测责任人；
 5. bug复测说明：由复测人员来写，说明复测过程，复测结果等；
-6. bug备注：备注，以便记录一些额外信息。
+6. bug备注：备注，以便记录一些额外信息。截图、视频、log。
 
 #### 1.4.8 缺陷预防
 **差错：**人在理解和解决问题的思维和行为过程中出现的问题，沟通不当，理解错误；（产生根源）  
@@ -471,7 +488,7 @@ IEEE729-1983 (电气和电子工程师协会标准IEEE) 对缺陷有一个标准
 > 这种错误的认识非常伤害软件测试人员的积极性。软件中的错误可能来自软件项目中的各个过程，软件测试只能确认软件存在错误，不能保证软件没有错误，因此从根本上讲，软件测试不可能发现全部错误。从软件开发的角度看，软件的高质量不是软件测试人员测出来的，是靠软件生命周期的各个过程中设计出来的。如果出现软件错误，不能简单地归结为某一个人的责任，有些错误可能是技术原因，也可能是混乱的管理所致。因此，应该分析软件项目的各个过程，从过程改进方面寻找产生错误的原因和改进的措施。
 
 5. 软件测试很简单，就是点点点，是个人就能做；
-> 随着软件工程学的发展和软件项目管理经验的提高，软件测试已经形成了一个独立的技术学科，演变成一个具有巨大市场需求的行业。软件测试技术不断更新和完善，新工具、新流程、新方法都在不断出现，因此，软件测试需要学习很多测试知识，更需要不断的实践经验和学习精神。
+> 随着软件工程学的发展和软件项目管理经验的提高，软件测试已经形成了一个独立的技术学科，演变成一个具有巨大市场需求的行业。软件测试技术不断更新和完善，新工具、新流程、新方法都在不断出现，因此，软件测试需要学习很多测试知识，更需要不断的实践和学习。
 
 6. 软件测试没有前途，只有程序员才是软件高手；
 > 随着市场对软件质量要求的不断提高，软件测试将变得越来越重要，对测试人员的要求也越来越高。测试人员不仅要懂得如何测试，还要懂得被测软件的业务知识和专业知识.而开发人员往往只需要对自己开发的模块了解比较深，对算法掌握的程度要求高一些，所以，软件测试和开发人员只是工作的侧重点不同，并不存在水平差异的问题。
@@ -623,7 +640,7 @@ IEEE729-1983 (电气和电子工程师协会标准IEEE) 对缺陷有一个标准
 5. 可再现性
 
 #### 2.4.4 测试用例维护
-**术语**  
+**术语：**  
 1. 测试编号：测试用例的编号
 2. 测试项：测试的功能点说明
 3. 前置条件：该测试用例的前提条件，比如测试wangdachui／dachui12345（用户名／密码）账户是否能正确登录进去，那前提wangdachui／dachui12345一定是注册过的
@@ -642,6 +659,21 @@ IEEE729-1983 (电气和电子工程师协会标准IEEE) 对缺陷有一个标准
 3. 原有功能取消：测试用例在新版本上置为“空”标志或者“无效状态”，对于先前版本有效；
 4. 新增功能：新增用例，对应新版本标志。
 
+**测试用例组成：**  
+1. 用例编号：产品名-测试阶段-测试项-XX功能模块缩写加数字
+2. 版本：产品版本号
+3. 功能模块：对应的功能模块（细分）
+4. 测试标题(测试项)：测试点描述
+5. 重要级别(优先级)：高、中、低
+6. 预置条件：需要满足的前提条件
+7. 测试数据：输入数据
+8. 操作步骤：明确的给出操作步骤，执行人员可以根据步骤执行
+9. 预期结果：根据预期输出对比实际结果，来判断测试对象是否符合需求(结果必须唯一)
+10. 设计者：设计测试用例的人，前面8条都是设计者填入
+11. 实际结果：实际测试的结果
+12. 执行者：测试用例执行者
+13. 备注：以上没包含的信息
+
 #### 2.4.5 测试用例设计误区
 1. 测试用例设计等同于测试输入数据设计；
 2. 测试用例设计越详细越好；
@@ -791,9 +823,9 @@ eg. 变量命名
 
 
 等价类表：  
-| 输入 | 约束 | 有效等价类 | 编号 | 无效等价类 | 编号 |
+| 输入条件 | 约束 | 有效等价类 | 编号 | 无效等价类 | 编号 |
 | ---- | ---- | ---------- | ---- | ---------- | ---- |
-|      |      |            |      |            |      |
+|  有效长度    |  0<L<255    |       长度在范围内     |1      |        长度为0    |      |
 
 **编号：有效到无效顺序的排号**
 
@@ -928,6 +960,13 @@ eg. 变量命名
 |  TC7   | 4   | 3   | 3   | 等腰三角形   |
 |  TC8   | 3   | 4   | 5   | 不等边三角形 |
 
+练习：  
+工资结算系统：  
+1. 工资分为年薪和月薪
+2. 错误程度分为普通和严重
+3. 年薪员工普通错误扣工资2%，严重扣4%
+4. 月薪员工普通错误扣工资4%，严重扣8%
+
 #### 3.4.2 优点和缺点
 决策表把复杂问题的各种可能情况一一列出，易于理解。但是，决策表不能表达重复执行动作的缺点。 
 
@@ -1371,11 +1410,11 @@ MC/DC具有如下优点:
 它是借助于往被测程序中插入操作来实现测试目的的方法，即向源程序中添加一些语句，实现对程序语句的执行、变量的变化等情况进行检查。
 
 #### 4.8.1 插桩位置 
-插桩位置主要解决的是在哪儿插的问题，为此将程序按“块”划分，探针主要插桩在其“路口”的位置，主要考虑以下4种位置：
-1. 程序的开始，即程序块的第1个可执行语句之前;
-2. for、do、do-while、do until 等循环语句开始、结束处。
-3. if、else if、else及end if等条件语句各分支开始、结束处。
-4. 函数、过程、子程序调用语句之后，
+插桩位置主要解决的是在哪儿插的问题，为此将程序按“块”划分，探针主要插桩在其“路口”的位置，主要考虑以下5种位置：
+1. 程序的开始，即程序块的第1个可执行语句之前；
+2. for、do、do-while、do until 等循环语句开始、结束处；
+3. if、else if、else及end if等条件语句各分支开始、结束处；
+4. 函数、过程、子程序调用语句之后；
 5. 程序的出口，return、call之后。
 
 #### 4.8.2 插桩策略
@@ -1413,7 +1452,7 @@ MC/DC具有如下优点:
 长时间的运行系统将导致系统失败，揭示系统中隐含的问题或冲突，进行调整，优化系统性能。
 
 #### 5.1.1 响应时间
-应时间是指应用系统从请求发出开始到客户端接收到数据所消耗的时间，响应时间分解为网络传输时间、应用延迟时间、数据库延迟时间和呈现时间等。
+响应时间是指应用系统从请求发出开始到客户端接收到数据所消耗的时间，响应时间分解为网络传输时间、应用延迟时间、数据库延迟时间和呈现时间等。
 
 #### 5.1.2 并发用户数
 多个用户对系统发出了请求或进行了操作，其请求或者操作可以是相同的，也可以是不同的，下面给出估算并发用户数的公式:
@@ -1462,7 +1501,7 @@ T：性能测试所用的时间。
 
 ### 5.2 性能测试分类
 #### 5.2.1 负载测试
-负载测试(Lond Testing)是测试系统在资源超负荷情况下的表现，以发现设计上的错误或验证系统的负载能力，评估测试对象在不同工作量条件下的性能行为，以及持续正常运行的能力，负载测试的目标是确定并确保系统在超出最大预期工作量的情况下仍能正常运行。此外，负载测试还要评估性能特征，例如，响应时间、事务处理速率和其他与时间相关方面的特征。
+负载测试(Load Testing)是测试系统在资源超负荷情况下的表现，以发现设计上的错误或验证系统的负载能力，评估测试对象在不同工作量条件下的性能行为，以及持续正常运行的能力，负载测试的目标是确定并确保系统在超出最大预期工作量的情况下仍能正常运行。此外，负载测试还要评估性能特征，例如，响应时间、事务处理速率和其他与时间相关方面的特征。
 
 负载测试通过大量重复的行为、模拟不断增加的用户数量等方式观察不同负载下系统的响应时间和数据吞吐量、系统占用的资源(如CPU、内存)等，检验系统特性，发现系统可能存在的性能瓶颈、内存泄露等问题。
 
@@ -1479,7 +1518,7 @@ T：性能测试所用的时间。
 由随机算法自动生成某个数量范围内变化的、动态的负载，这种方式可能是和实际情况最为接近的一种负载方式。虽然不容易模拟系统运行出现的瞬时高峰期，但可以模拟系统长时间高位运行过程的状态。
 
 #### 5.2.2 压力测试
-压力测试(Stress Test)也称强度测试，是在强负载(大数据量、大量并发用户等)下的测试，通过查看应用系统在峰值使用情况下的状态发现系统的某项功能隐思、系统是否具有良好的容错能力和可恢复能力。压力测试涉及时间因素，用来测试那些负载不定的，或交互式的，实时的以及过程控制等程序。压力测试分为高负载下的长时间(如24小时以上)的稳定性压力测试和极限负载情况下导致系统崩溃的破坏性压力测试。
+压力测试(Stress Test)也称强度测试，是在强负载(大数据量、大量并发用户等)下的测试，通过查看应用系统在峰值使用情况下的状态发现系统的某项功能隐患、系统是否具有良好的容错能力和可恢复能力。压力测试涉及时间因素，用来测试那些负载不定的，或交互式的，实时的以及过程控制等程序。压力测试分为高负载下的长时间(如24小时以上)的稳定性压力测试和极限负载情况下导致系统崩溃的破坏性压力测试。
 
 压力测试也被看作是负载测试的一种特殊情况，即高负载下的负载测试，或者说压力测试采用负载测试技术。
 
@@ -1489,7 +1528,7 @@ T：性能测试所用的时间。
 可靠性测试一般伴随着强壮性测试，是评估软件在运行时的可靠性，通过测试确认平均无故障时间、故障发生前的平均工作时间或因故障而停机的时间在一年中应不超过多少时间。可靠性测试强调随机输入，并通过模拟系统实现，很难通过实际系统的运行来实现。
 
 #### 5.2.4 数据库测试
-数据库测试一般包括数据库的完整测试和数据库容量测试。
+数据库测试一般包括数据库的完整测试和数据库容量测试。数据库测试一般包括数据库的完整测试和数据库容量测试。
 
 1. 数据库完整测试
 数据库完整测试是指测试关系型数据库中的数据是否完整，用于防止对数据库的意外破坏，提高了完整性检测的效率。
@@ -1506,9 +1545,9 @@ T：性能测试所用的时间。
 数据库容量测试是指数据库是否能存储数据量的极限，还用于确定在给定时间内能够持续处理的最大负载。
 
 #### 5.2.5 安全性测试
-安全性测试是测试系统在应付非授权的内部/外部访问、非法侵入或故意的损块时的系统防护能力，检验系统是否有能力使可能存在的内/外部伤害或损害的风险限制在可接变的水平内，可靠性通常包括安全性，但是软件的可靠性不能完全取代软件的安全性，安全性还涉及数据加密、保密、存取权限等多个方面。
+安全性测试是测试系统在应付非授权的内部/外部访问、非法侵入或故意的损坏时的系统防护能力，检验系统是否有能力使可能存在的内/外部伤害或损害的风险限制在可接受的水平内，可靠性通常包括安全性，但是软件的可靠性不能完全取代软件的安全性，安全性还涉及数据加密、保密、存取权限等多个方面。
 
-进行安全性测试时，需要设计一些试图突破系统安全保密带施的测试用例，检验系统是否有安全保密漏洞，验证系统的保护机制是否能够在实际中不受到非法侵入，安全性测试采用建立整体的威胁模型，测试盟出漏洞、信息泄露、错误处理、身份验证和授权错误等。
+进行安全性测试时，需要设计一些试图突破系统安全保密措施的测试用例，检验系统是否有安全保密漏洞，验证系统的保护机制是否能够在实际中不受到非法侵入，安全性测试采用建立整体的威胁模型，测试盟出漏洞、信息泄露、错误处理、身份验证和授权错误等。
 
 在安全测试过程中，测试者扮演攻击系统的角色，一般采用如下方法：
 1. 尝试截取、破译、获取系统密码。
@@ -1516,7 +1555,7 @@ T：性能测试所用的时间。
 3. 试图浏览保密的数据，检验系统是否有安全保密的漏洞。
 
 #### 5.2.6 兼容性测试
-兼容性是指某个软件能够稳定地工作在某个操作系统/平台之中，就说这个软件对这个操作系统/平台是兼容的；其次，在多任务操作系统中，几个同时运行的软件之间如果能够稳定地工作，就认为这几个软件之间兼容性较好，否则就是兼容性不好；另外，就是软件数据的共享，几个软件之间无须复杂的转换，即可方便地共享相互之间的数据，也称为兼容。
+兼容性是指某个软件能够稳定地工作在某个操作系统/平台之中，就说这个软件对这个操作系统/平台是兼容的；其次，在多任务操作系统中，几个同时运行的软件之间如果能够稳定地工作，就认为这几个软件之间兼容性较好，否则就是兼容性不好；另外，就是软件数据的共享，几个软件之间无需复杂的转换，即可方便地共享相互之间的数据，也称为兼容。
 
 软件兼容性测试要检查软件能否在不同组合的环境下正常运行，或者软件之间能否正常交互和共享信息。作为衡量软件好环的重要指标之一，软件兼容性用于保证软件在不同环境中都能按照用户期望的方式进行交互。
 
@@ -1534,7 +1573,7 @@ T：性能测试所用的时间。
 可用性 = 平均正常工作时间 / (平均正常工作时间 + 平均修复时间)
 ```
 
-影响可用性的因素有如下几方面。
+影响可用性的因素有如下几方面：  
 1. 不充分的测试。
 2. 更改管理问题。
 3. 缺少在线监视和分析。
@@ -1554,7 +1593,7 @@ T：性能测试所用的时间。
 网络负载平衡通过检测某服务器失败后，自动将通信量重新分发给仍然运行的服务器。
 
 3. 使用服务级别协议
-定义期望的服务级别。可用性指标一般要求达到4个或5个“9”，例如，“该应用程序应每周运行7天，每天24小时，年可用性为99.99%”是指全年不能正常工作的时间仅仪只有52分钟，不足1个小时。
+定义期望的服务级别。可用性指标一般要求达到4个或5个“9”，例如，“该应用程序应每周运行7天，每天24小时，年可用性为99.99%”是指全年不能正常工作的时间仅仅只有52分钟，不足1个小时。
 
 4. 提供实时的监视
 连续监视操作工作负荷和失败数据，对于发现趋势和改善服务至关重要。
@@ -1625,7 +1664,7 @@ T：性能测试所用的时间。
 (2) Web系统的主要部分是否可通过主页存取？  
 (3) Web系统是否需要站点地图、搜索引擎或其他的导航帮助？  
 (4) Web应用系统的页面结构、导航、菜单、连接的风格是否一致？  
-(5) 确保用户凭直党就知道Web应用系统里面是否还有内容，内容在什么地方  
+(5) 确保用户凭直觉就知道Web应用系统里面是否还有内容，内容在什么地方  
 
 2. 图形测试  
 在Web应用系统中，适当的图形不但能起到广告宣传的作用，而且具有美化页面的功能。一个Web应用系统的图形包括图片、动画、边框、颜色、字体、背景、按钮等。  
@@ -1677,7 +1716,7 @@ Cookies通常用来存储用户信息，是让网站服务器把少量数据储
 市场上有很多操作系统，例如Windows、Unix、Macintosh、Linux等。Web应用系统的最终用户究竟使用哪一种操作系统，取决于用户系统的配置。这样就可能会发生兼容性问题。即，同一个应用在某些操作系统下能正常运行，但在另外一些操作系统下可能会运行失败。因此，在Web系统发布之前，需要在各种操作系统下对Web系统进行兼容性测试。
 
 2. 浏览器兼容性测试  
-浏览器是Web客户端的核心构件，来自不同厂商的浏览器对Java、JavaScript、ActiveX有不同的支持。例如，Active X是Microsoft的产品，是为IE而设计的.JavaScript是Netscape的产品，Java是Sun的产品等等。不同的浏览器对安全性的设置不一样。网页的框架和层次结构风格在不同的浏览器中也有不同的显示，甚至根本不显示。
+浏览器是Web客户端的核心构件，来自不同厂商的浏览器对Java、JavaScript、ActiveX有不同的支持。例如，Active X是Microsoft的产品，是为IE而设计的。JavaScript是Netscape的产品，Java是Sun的产品等等。不同的浏览器对安全性的设置不一样。网页的框架和层次结构风格在不同的浏览器中也有不同的显示，甚至根本不显示。
 
 3. 分辨率兼容性测试  
 分辨率的测试是为了页面版在不同的分辨率模式下能正常显示，字体符合要求而进行的测试。现在常见的分辨率是1280×1024、1027×768、800×600。对于常见的分辨率，测试必须保证测试通过，对于其他分辨率，根据具体情况进行取舍。
@@ -1775,7 +1814,7 @@ Web应用系统是否有超时的限制，也就是说，用户登录后在一
 
 ![软件测试流程](https://gitee.com/XiaFuXiangFei/software-testing/raw/main/images/ceshiliucheng.jpg)
 
-1. **测试计划：** 根据用户需求报告中关于功能要求和性能指标的规格说明书，定义相应的测试需求告，使得随后所有测试工作都围绕着测试需求来进行。同时适当选择测试内容，合理安非测试人员、测试时间及测试资源等。
+1. **测试计划：** 根据用户需求报告中关于功能要求和性能指标的规格说明书，定义相应的测试需求告，使得随后所有测试工作都围绕着测试需求来进行。同时适当选择测试内容，合理安排测试人员、测试时间及测试资源等。
 2. **测试设计：** 测试设计是指将测试计划阶段制定的测试需求分解、细化为若干个可执行的测试过，并为每个测试过程选择适当的测试用例，保证测试结果的有效性。
 3. **测试执行：** 执行测试开发阶段建立的自动测试过程，并对所发现的缺陷进行跟踪管理。测试执行一般由单元测试、集成测试、系统测试、验收测试以及回归测试等步骤组成。
 4. **测试评估：** 根据缺陷跟踪报告，对软件的质量和开发团队的工作进度及效率进行评价。
@@ -1785,7 +1824,7 @@ Web应用系统是否有超时的限制，也就是说，用户登录后在一
 
 **软件需求：** 需求是产品必须完成的功能以及必须具备的品质。它详细定义了信息流和界面，功能需求，设计要求和限制，测试准则和质量保证要求。
 
-需求包括：功能性需求、非功能性需求和限制条件。
+需求包括：功能性需求、非功能性需求和限制条件。比如：性能需求，质量标准，或者设计限制。
 
 非功能性需求：界面、软件环境和硬件环境等。
 
@@ -1853,7 +1892,7 @@ eg. 登录功能描述
 
 
 ### 6.3 测试计划
-测试计划以测试需求为基础，分析产品的总体测试策略，输出《产品总体测试策略)等报告。
+测试计划以测试需求为基础，分析产品的总体测试策略，输出《产品总体测试策略》等报告。
 
 **参与者：** 测试组长   
 
@@ -1888,7 +1927,7 @@ eg. 登录功能描述
 根据项目组提供的需求说明书、界面原型、开发计划等文档，了解项目需求，明确本次测试的任务。
 
 2. 制定测试策略
-测试的策略包括宏观的测试策略和微观的测试策略战术,为了设计出好的测试策略，需要了解软件的结构、功能分布、各模块对用户的重要程度等，从而决定测试的重点、优先次序、测试的覆盖方式等。设计测试用例时，应尽可能用最少的测试用例发现最多的缺陷，尽可能用精简的测试用例覆盖最广泛的状态空间，还要考虑哪些测试用例使用自动化的方式实现，哪些使用人工方式验证等。
+测试的策略包括宏观的测试策略和微观的测试策略战术，为了设计出好的测试策略，需要了解软件的结构、功能分布、各模块对用户的重要程度等，从而决定测试的重点、优先次序、测试的覆盖方式等。设计测试用例时，应尽可能用最少的测试用例发现最多的缺陷，尽可能用精简的测试用例覆盖最广泛的状态空间，还要考虑哪些测试用例使用自动化的方式实现，哪些使用人工方式验证等。
 
 3. 确定资源
 确定测试所需的人力资源、硬件、软件、工具等资源。
@@ -1897,7 +1936,7 @@ eg. 登录功能描述
 测试的进度安排需要结合项目的开发计划、产品的整体计划进行考虑，还要考虑测试本身的各项活动进行安排。把测试用例的设计、测试环境的搭建、测试报告的编写等活动列入进度安排表。
 
 5. 估计计划风险
-般可能碰到的风险是项目计划变更、测试资源不能及时到位等问题。制定测试计划时应根据项目的实际情况进行评估，并制定出合理、有效的应对策略，对于项目计划的变更，可以考虑建立更加流畅的沟通渠道，让测试人员能及时了解到变更的情况，以及变更的影响，从而可以做出相应的改变。
+一般可能碰到的风险是项目计划变更、测试资源不能及时到位等问题。制定测试计划时应根据项目的实际情况进行评估，并制定出合理、有效的应对策略，对于项目计划的变更，可以考虑建立更加流畅的沟通渠道，让测试人员能及时了解到变更的情况，以及变更的影响，从而可以做出相应的改变。
 
 #### 6.3.3 测试计划的5W1H
 1. What - 对象
@@ -1942,8 +1981,8 @@ eg. 登录功能描述
 5. 根据所选择的测试平台以及测试用例所要求的特定环境，进行服务器、网络等测试环境的设计。
 
 软件测试设计中，需要考虑如下要点。
-1. 所设计的测试技术方案是否可行、是否有效、是否能达到预期的测试目标;
-2. 所设计的测试用例是否完整、边界条件是否考虑、其覆盖率能达到的百分比;
+1. 所设计的测试技术方案是否可行、是否有效、是否能达到预期的测试目标；
+2. 所设计的测试用例是否完整、边界条件是否考虑、其覆盖率能达到的百分比；
 3. 所设计的测试环境是否和用户的实际使用环境比较接近。
 
 #### 6.4.2 测试用例属性
@@ -1985,7 +2024,7 @@ eg. 登录功能描述
 * 测试方法：白盒测试
 * 测试内容：模块接口测试、局部数据结构测试、路径测试、错误处理测试、边界测试
 
-单元测试针对模块进行测试,主要有一下5个任务：
+单元测试针对模块进行测试,主要有以下5个任务：
 * 模块接口：全局量定义一致性，调用参数
 * 局部数据结构:数据的定义和使用
 * 边界条件：循环边界和输入边界
@@ -2056,7 +2095,7 @@ eg. 登录功能描述
 
 但是，在实际交付给用户之后，开发人员是无法预测该软件用户在实际运用过程中是如何使用该程序的，所以从用户的角度出发，测试人员还应进行α测试或β测试这两种情形的测试。α测试是在软件开发环境下由用户进行的测试，或者模拟实际操作环境进而进行的测试。α测试主要是对软件产品的功能、局域化、界面、可使用性以及性能等等方面进行评价。而β测试是在实际环境中由多个用户对其进行测试，并将在测试过程中发现的错误有效反馈给软件开发者。所以在测试过程中用户必须定期将所遇到的问题反馈给开发者。
 
-验收测试是部署软件之前的最后一个测试操作。它是技术测试的最后一个阶段，也称为交付测试。验收测试的目的是确保软件准备就绪，按照项目合同、任务书、双方约定的验收依据文档，向软件购买都展示该软件系统满足原始需求。
+验收测试是部署软件之前的最后一个测试操作。它是技术测试的最后一个阶段，也称为交付测试。验收测试的目的是确保软件准备就绪，按照项目合同、任务书、双方约定的验收依据文档，向软件购买方展示该软件系统满足原始需求。
 
 * 测试阶段：系统测试通过之后
 * 测试对象：整个系统（包括软硬件）。
@@ -2076,9 +2115,9 @@ eg. 登录功能描述
 只有当α测试达到一定的可靠程度时，才能开始β测试。与α测试不同，开发者通常不在测试现场，在β测试中，由用户记下遇到的所有缺陷，向开发者报告。测试着重于产品的支持性测试，包括文档、客户培训等。
 
 α测试与β测试的区别：  
-1. 测试的场所不同：α测试是指把用户请到开发方的场所来测试,β测试是指在一个或多个用户的场所进行的测试。
-2. 测试的环境不同：α测试的环境是受开发方控制的,用户的数量相对比较少,时间比较集中。β测试的环境是不受开发方控制的,用户数量相对比较多,时间不集中。
-3. 测试的时间不同：α测试先于β测试执行。通用的软件产品需要较大规模的β测试,测试周期比较长。
+1. 测试的场所不同：α测试是指把用户请到开发方的场所来测试，β测试是指在一个或多个用户的场所进行的测试。
+2. 测试的环境不同：α测试的环境是受开发方控制的，用户的数量相对比较少，时间比较集中。β测试的环境是不受开发方控制的，用户数量相对比较多，时间不集中。
+3. 测试的时间不同：α测试先于β测试执行。通用的软件产品需要较大规模的β测试，测试周期比较长。
 
 当软件通过最后阶段的测试 - 验收测试或质量全面评估测试，从研发阶段来看，工程发布(Engineering Release，ER)将作为一个里程碑，随后将软件推向市场。进行α测试后，到达了有限可用(Limited Available，LA)里程碑(LA是指由于测试覆盖率不能达到100%，软件功能并不能全部使用)。LA之后所发现的缺陷，再通过β测试，到达全面可用(General Available，GA)里程碑，此时所有功能可以全部使用。
 
@@ -2265,7 +2304,7 @@ eg. 登录功能描述
 引入能力成熟度模型后，不同的自动测试等级成为测试能力的一个衡量依据。
 
 ### 7.3 测试成熟度模型
-测试成熟度模置(Tetine Matnty Mold，TMM) 描述了测试的过程，分为初始级、定义级、集成级、管理和测量级和优化、预防缺陷和质量控制级五个等级。
+测试成熟度模型(Testing Maturity Model，TMM) 描述了测试的过程，分为初始级、定义级、集成级、管理和测量级和优化、预防缺陷和质量控制级五个等级。
 
 #### 7.3.1 初始级
 TMM初始级软件测试过程的特点是测试过程无序，有时甚至是混乱的，几乎没有妥善定义的。在初始级中，软件测试与调试常常被混为一谈，软件开发过程中缺乏测试资源、工具以及训练有素的测试人员，初始级的软件测试过程没有定义成熟度目标。
@@ -2297,7 +2336,7 @@ TNM的定义级中需实现的3个成熟度目标：制定测试与调试目标
 
 3. 制度化基本的测试技术和方法  
     应用基本的测试技术和方法，并说明何时和怎样使用这些技术、方法和支持工具，基本的测试技术和方法的制度化有如下两个子目标：  
-    (1) 在组织范围内成立测试技术组，研究、评价和推荐基本的测试技术和测试方法，推荐支持这些技术与万法的基本工具。  
+    (1) 在组织范围内成立测试技术组，研究、评价和推荐基本的测试技术和测试方法，推荐支持这些技术与方法的基本工具。  
     (2) 制定管理方针，以保证在全组织范围内一致使用所推荐的技术和方法。  
 
 #### 7.3.3 集成级
@@ -2349,7 +2388,7 @@ TNM的定义级中需实现的3个成熟度目标：制定测试与调试目标
 1. 建立组织范围内的评审程序  
     软件组织应在软件生命周期的各阶段实施评审，以便尽早有效地识别，分类和消除软件中的缺陷。
 
-    建立评审程序有以下4个子目标:  
+    建立评审程序有以下3个子目标:  
     (1)管理层要制定评审政策，支持评审过程。  
     (2)测试组和软件质量保证组要确定并文档化整个软件生命周期中的评审目标、评审计划、评审步骤以及评审记录机制。  
     (3)评审项由上层组织指定。培训参加评审的人员，使他们理解和遵循机的评政策、评审步骤。  
@@ -2473,7 +2512,7 @@ Postman是谷歌的一款接口测试插件，它使用简单，支持用例管
 5. Siege：一款开源的压力和指标测试工具。
 
 #### 7.5.4 白盒测试工具
-目前的白盒测试工具主要支持C、Visual C++、Java、VisualJ++等程序开发语言。白盒测试工具一般针对被测源程序进行测试，测试所发行的故障可以定位到代码级。
+目前的白盒测试工具主要支持C、Visual C++、Java、Visual J++等程序开发语言。白盒测试工具一般针对被测源程序进行测试，测试所发行的故障可以定位到代码级。
 
 根据测试工具工作原理的不同，白盒测试工具分为静态分析工具和动态测试工具。
 
@@ -2658,7 +2697,7 @@ postman.setGlobalVariable("username", "tester");
 
 #### 7.8.9 关联需求
 1. 在关联需求的时候，可以按照优先级进行排序。
-2. **关联的需求状态必须是激活的（评审通过，不能是草稿）**
+2. **关联的需求状态必须是激活的（评审通过，不能是草稿）
 
 #### 7.8.10 分解任务
 设置了团队之后，下一步操作就是创建任务。
@@ -2726,7 +2765,7 @@ Bug处理流程：
 2. WBS工作分解结构
     针对复杂的项目，往往需要工作分解结构(Work BreakDown Structure,WBS).工作分解结构是将一个软件测试项目分解成易于管理的更多部分或细目，所有这些细目构成了整个软件测试项目的工作范围。
 
-    工作分解结构是测试项目团队在项目期间要完成或生产出的最终细目的等级树，组织并定义了整个测试项目的范围。
+    工作分解结构是测试项目团队在项目期间要完成或生产出的最终项目的等级树，组织并定义了整个测试项目的范围。
 
 #### 8.1.2 测试管理主要功能
 1. 测试对象管理