diff --git a/README.md b/README.md
index cc26bc3fac8aa0cc198672e6fd5e72ec15e2fc6f..56905261ee1b963f9dd7bc7a3ed450eb257a2003 100644
--- a/README.md
+++ b/README.md
@@ -38,7 +38,7 @@
#### 1.1.2 文档
##### 开发文档
-开发文档是描述软件开发过程，包括软件需求、软件设计、软件测试、保证软件质量的一类文档，开发文档也包括软件的详细技术描述、程序逻辑、程序间相互关系、数据格式和存储等。
+开发文档是描述软件开发和使用过程，包括软件需求、软件设计、软件测试、保证软件质量的一类文档，开发文档也包括软件的详细技术描述、程序逻辑、程序间相互关系、数据格式和存储等。
* 《可行性研究》
* 《项目任务书》
@@ -64,6 +64,9 @@
* 《实施方案》
##### 产品文档
+产品文档规定关于软件产品的使用、维护、增强、转换及传输的信息。
+
+作用：
为使用和运行软件产品的任何人规定培训和参考信息，促进软件产品的市场流通或提高可接受性。使得那些未参加开发本软件的程序员维护它。
* 《产品手册》
@@ -72,7 +75,7 @@
* 《软件支持手册》
#### 1.1.3 软件发展史
-1. 程序设计阶段：个体化生产、专用软件、规模小、功能单一、开发者即使用者。（软件 = 程序）
+1. 程序设计阶段：个体化生产、专用软件、规模小、功能单一、开发者即使用者。软件设计在人们的头脑中完成，形成了“软件 = 程序”的错误观点。
2. 程序系统阶段：多用户人机交互，实时系统和数据库管理系统。
3. 软件工程阶段：以软件的产品化、系列化、工程化和标准化为特征的软件产业发展起来，软件开发有了可以遵循的软件工程化的设计准则、方法和标准。
4. 多层分布结构，面向服务架构。
@@ -146,7 +149,7 @@
### 1.3 软件测试概述
#### 1.3.1 软件测试定义
软件测试的经典定义是：在规定的条件下对程序进行操作，以发现程序错误，衡量软件质量，并对其是否能满足设计要求进行评估的过程。
-IEEE:使用人工或自动手段来运行或测定某个软件系统的过程，其目的在于检测他是否满足规定的需求或弄清预期结果和实际结果的差别。
+IEEE:使用人工或自动手段来运行或测定某个软件系统的过程，其目的在于检测他是否满足规定的需求或弄清预期结果和实际结果直接的差别。
#### 1.3.2 测试发展历程
1. 1957年之前－调试为主(Debugging Oriented)
@@ -155,7 +158,7 @@ IEEE:使用人工或自动手段来运行或测定某个软件系统的过程，
2. 1957–1978－证明为主(Demonstration Oriented)
- 与调试区分开，这是软件测试史上一个重要的里程碑，主要目是确认软件是满足需求的。
+ 与调试区分开，这是软件测试史上一个重要的里程碑，主要目的是发现软件的缺陷。
3. 1979–1982－破坏为主(Destruction Oriented)
@@ -205,7 +208,7 @@ The process of executing a program with the intent of finding errors.
-强调将测试和开发同等重要，对于开发阶段都有与之对应的测试阶段。
+强调测试和开发同等重要，每个开发阶段都有与之对应的测试阶段。
**优点：**
@@ -223,7 +226,7 @@ The process of executing a program with the intent of finding errors.
**优点：**
-W 模型相对于 V 模型来说，测试更早的进入到开发阶段，与开发阶段是并行关系，更早的发现问题，能够及时解决问题，各个阶段分工明确，方便管理。
+W 模型相对于 V 模型来说，测试更早的进入到开发阶段，与开发阶段是并行关系，能够更早的发现问题，能够及时解决问题，各个阶段分工明确，方便管理。
**缺点：**
@@ -241,7 +244,7 @@ W 模型是顺序性的、不可逆的，需求的变更和调整，依旧不方
敏捷开发以用户的需求进化为核心，采用迭代、循序渐进的方法进行软件开发。专注于交付对客户有价值的软件（可以工作的)。
-强调以人为核心，程序员团队和业务专家之间的紧密联系，频繁交付新的软件版本，紧凑的自我组织型团队，更注重软件开发中人的作用。
+更注重软件开发中人的作用，强调以人为核心，注重程序员团队和业务专家之间的紧密联系，形成紧凑的自我组织型团队，能够频繁交付新的软件版本。
在敏捷开发中，软件项目在构建初期被切分成多个子项目，各个子项目的成果都经过测试，具备可视、可集成和可运行使用的特征。换言之，就是把一个大项目分为多个相互联系，但也可独立运行的小项目，并分别完成，在此过程中软件一直处于可使用状态。
@@ -263,25 +266,25 @@ W 模型是顺序性的、不可逆的，需求的变更和调整，依旧不方
* 个体和互动高于流程和工具
- 以人为本，没有比面对面交流更高效的沟通渠道了，基于互相信任的前提，敏捷提倡自治的全功能团队。
+ 以人为本，没有比面对面交流更高效的沟通渠道了，基于互相信任的前提，敏捷提倡自治的全功能团队。
- 在工作形式上，整个团队平时坐在一起工作，从物理空间上创造了更加便捷面对面的沟通机会。在团队职责上，团队内部具备完成软件交付的角色(能力)，团队所有人对软件的质量负责，开发过程由团队内部把控，业务价值团队内部快速流动，在任何环节都能及时获得反馈。同时，每个角色都更容易从全局视角去思考软件，避免了传统部门墙模式下的视角割裂和协作障碍。
+ 在工作形式上，整个团队平时坐在一起工作，从物理空间上创造了更加便捷面对面的沟通机会。在团队职责上，团队内部具备完成软件交付的角色(能力)，团队所有人对软件的质量负责，开发过程由团队内部把控，业务价值团队内部快速流动，在任何环节都能及时获得反馈。同时，每个角色都更容易从全局视角去思考软件，避免了传统部门墙模式下的视角割裂和协作障碍。
* 工作的软件高于详尽的文档
- 为客户交付可工作的软件是我们的核心目标，我们应该尽早交付可进行端到端测试的代码，该目标决定了我们不应该花过多精力在面面俱到的文档上，但这不代表我们要抵制任何文档。实践证明，轻量级的文档策略有助于团队高质量交付可工作的软件。
+ 为客户交付可工作的软件是我们的核心目标，我们应该尽早交付可进行端到端测试的代码，该目标决定了我们不应该花过多精力在面面俱到的文档上，但这不代表我们要抵制任何文档。实践证明，轻量级的文档策略有助于团队高质量交付可工作的软件。
* 客户合作高于合同谈判
- 主动拥抱变化，及时响应，持续交付。
+ 主动拥抱变化，及时响应，持续交付。
* 响应变化高于遵循计划
- 通过高效的协作，获取快速的反馈，从而尽早做出调整，减少浪费。
+ 通过高效的协作，获取快速的反馈，从而尽早做出调整，减少浪费。
**缺点:**
-由于其项目周期很长，所以很难保证开发的人员不更换，而缺少文档就会造成在交接的过程中出现很大的困难。
+ 由于其项目周期很长，所以很难保证开发的人员不更换，而缺少文档就会造成在交接的过程中出现很大的困难。
@@ -302,23 +305,23 @@ IEEE729-1983 (电气和电子工程师协会标准IEEE) 对缺陷有一个标准
4. 不全面或者没有复审。
#### 1.4.3 缺陷来源
-| 缺陷来源 | 描述 |
-| ------------ | -------------------------------- |
+| 缺陷来源 | 描述 |
+| ----------- | -------------------------------|
| 需求说明书 | 需求说明书错误或描述不清 |
| 设计文档 | 设计文档描述不准确，与需求不一致 |
-| 系统集成接口 | 各模块参数不匹配 |
+| 系统集成接口 | 各模块参数不匹配 |
| 数据流（库） | 数据字典、数据库中的错误 |
-| 程序代码 | 编码问题 |
+| 程序代码 | 编码问题 |
#### 1.4.4 缺陷类型
- | 缺陷类型 | 描述 |
- | -------- | ------------------------------------------------ |
+ | 缺陷类型 | 描述 |
+ | -------- | -------------------------------------------- |
| 功能 | 未达到规格说明书中规定的功能，影响系统使用 |
- | 用户界面 | 未按照原型设计，影响交互，如：显示格式，按钮位置 |
+ | 用户界面 | 未按照原型设计，影响交互，如：显示格式，按钮位置 |
| 文档 | 文档内容不完整或不正确，影响发布和维护 |
- | 软件包 | 由于软件配置库、变更管理或版本控制引发的错误 |
+ | 软件包 | 由于软件配置库、变更管理或版本控制引发的错误 |
| 性能 | 执行时间长、处理速度慢、负载高等方面 |
- | 接口 | 与其他模块参数不匹配 |
+ | 接口 | 与其他模块参数不匹配 |
#### 1.4.5 缺陷级别
**严重性：** 表示软件缺陷的恶劣程度，当用户碰到该缺陷时影响的可能性和程度。
@@ -336,19 +339,19 @@ IEEE729-1983 (电气和电子工程师协会标准IEEE) 对缺陷有一个标准
##### 优先级
-| 级别 | 名称 | 说明 |
-| :---: | :---: | ----------------------------------------------------------------------------- |
+| 级别 | 名称 | 说明 |
+| :---: | :---: | ------------------------------------------------------------------------- |
| P1 | 低 | 不影响整个系统的正常运行，一般指建议性的问题 |
-| P2 | 中 | 不影响继续测试，但也是必须要修改的，对功能的实现有所影响,如果时间允许应该修复 |
-| P3 | 高 | 影响整个测试的继续进行，要马上修改 |
-| P4 | 急 | 系统无法继续执行下去，必须立即修改 |
+| P2 | 中 | 不影响继续测试，但也是必须要修改的，对功能的实现有所影响,如果时间允许应该修复 |
+| P3 | 高 | 影响整个测试的继续进行，要马上修改 |
+| P4 | 急 | 系统无法继续执行下去，必须立即修改 |
严重性和优先级对于审查缺陷报告并决定哪些软件缺陷应该修复，以何种顺序修复的人员极为重要。如果一个程序员受命修复10个缺陷，他就应该先从严重性为1 、优先级为1这样的缺陷着手，而不是优先修复简单的，由简到难。
综合使用重要性等级和严重性双标准的优先顺序:
| | S1. 致命错误 | S2. 严重缺陷 | S3. 主要错误 | S4. 次要错误 | S5. 轻微缺陷 |
-| :----: | ------------------- | ------------------- | -------------------- | ------------------- | ------------------- |
+| :----: | ------------------ | ------------------ | -------------------- | ------------------ | ------------------ |
| P4. 急 | 立即修复
3小时内 | 第2修复
1天内 | 第4修复
2天内 | 第7修复
3天内 | 第11修复
4天内 |
| P3. 高 | 第3修复
1-2天内 | 第5修复
2-3天内 | 第8修复
3-4天内 | 第12修复
4-5天内 | 第15修复
5-6天内 |
| P2. 中 | 第6修复
3-4天内 | 第9修复
4-5天内 | 第13修复
5-6天内 | 第16修复
6-7天内 | 第18修复
2-3周内 |
@@ -365,15 +368,15 @@ IEEE729-1983 (电气和电子工程师协会标准IEEE) 对缺陷有一个标准
一个缺陷很可能会被反复打开→关闭。在日常工作过程中，由于开发修订其他缺陷影响、需求变更等因素缺陷可能会被反复打开→关闭。
-| 缺陷状态 | 描述 |
-| -------- | -------------------------------------------------- |
+| 缺陷状态 | 描述 |
+| -------- | ------------------------------------------------ |
| 打开 | 确认提交的缺陷，等待处理 |
| 已分配 | 分配开发人员进行修复 |
-| 已解决 | 经过开发人员修复，等待测试人员验证 |
+| 已解决 | 经过开发人员修复，等待测试人员验证 |
| 已验证 | 测试人员验证修复成功 |
| 已关闭 | 修复完成，确认测试通过 |
-| 重新打开 | 测试验证依然存在缺陷，等待开发修复 |
-| 推迟 | 暂不解决，可能在下一个版本修复 |
+| 重新打开 | 测试验证依然存在缺陷，等待开发修复 |
+| 推迟 | 暂不解决，可能在下一个版本修复 |
| 保留 | 条件不允许，不能修复 |
| 不能重现 | 开发不能复现这个缺陷，需要测试人员检查缺陷发现步骤 |
@@ -386,14 +389,14 @@ IEEE729-1983 (电气和电子工程师协会标准IEEE) 对缺陷有一个标准
6. bug描述：bug的产生环境、详细步骤、期望结果、实际结果。
7. 附件：包括但不仅限于截图、日志、录像、所用到的示例文件以及应用；同样是方便复现解决缺陷的。
-以上是上报bug、创建bug必须要做的，在后续我们还会对bug进行修复、复测等工作，那么为了记录后续工作，bug还应该包含：
+以上是上报bug，创建bug必须要做的，在后续我们还会对bug进行修复、复测等工作，那么为了记录后续工作，bug记录内容还应该包含：
-1. bug状态：开始、修复中、修复完成、提测、测试中、测试通过/失败、关闭等，后续bug周期中会讲到。
+1. bug状态：开始、修复中、修复完成、提测、测试中、测试通过/失败、关闭等，后续的bug周期中会讲到。
2. bug修订人：bug修订人员。
-3. bug复测人：通常是谁报的bug最后返回给谁测试，但是在某些情况下比如bug报告人任务积累太多/不在的情况下也会分给其他人，所以通常会记录bug复测责任人。
-4. bug修订说明：由bug修订人来写，说明bug产生原因，修改思路等。
-5. bug复测说明：由复测人员来写，说明复测过程，复测结果等。
-6. bug备注：备注，以便记录一些额外信息。
+3. bug复测人：通常是谁报的bug最后返回给谁测试，但是在某些情况下，比如bug报告人任务积累太多/不在的情况下也会分给其他人，所以通常会记录bug复测责任人。
+4. bug修订说明：由bug修订人来写，说明bug产生原因，修改思路，修订过程以及bug修订完成情况等。
+5. bug复测说明：由复测人员来写，说明复测过程，复测结果等。
+6. bug备注：备注，以便记录一些额外信息。
#### 1.4.8 缺陷预防
**差错**：人在理解和解决问题的思维和行为过程中出现的问题，沟通不当，理解错误。（产生根源）
@@ -915,6 +918,7 @@ IEEE729-1983 (电气和电子工程师协会标准IEEE) 对缺陷有一个标准
缺点:
1. 作为输入条件的原因和输出结果之间的因果关系，很难从规格说明书得到
2. 此方法得到的用例数量规模大
+
### 3.6 场景法
通过尝尽该描述的业务流程（业务逻辑）,设计用例来遍历场景（路径）,验证系统功能的正确性。
场景法重点是测试流程，因此每个流程用一个用例验证即可，流程测试没问题不代表系统功能没问题，还需要单步进行测试，结合前面的方法。