diff --git a/README.md b/README.md
index 5bd826c9c43b575014ea9867c1585c0e1293c6a6..4b161f63f7dfc86466d3e369ae562bf2dccd7d1f 100644
--- a/README.md
+++ b/README.md
@@ -69,9 +69,10 @@
 
 #### 1.1.3 软件发展史
 1. 程序设计阶段：个体化生产、专用软件、规模小、功能单一、开发者即使用者。软件 = 程序
-2. 程序系统阶段：多用户人机交互，实时系统和数据库管理系统。
-3. 软件工程阶段：以软件的产品化，系列化、工程化和标准化为特征的软件产业发展起来，软件开发有了可以遵循的软件工程化的设计准则、方法和标准。
-4. 多层分布结构，面向服务架构
+2. 设计阶段软件设计阶段:出现在1956年～1970年。此阶段的特点是：硬件环境相对稳定，出现了“软件作坊”的开发组
+3. 程序系统阶段：多用户人机交互，实时系统和数据库管理系统。
+4. 软件工程阶段：以软件的产品化，系列化、工程化和标准化为特征的软件产业发展起来，软件开发有了可以遵循的软件工程化的设计准则、方法和标准。
+5. 多层分布结构，面向服务架构
 
 #### 1.1.4 软件项目
 软件项目是一种特殊的项目，具有如下特点：
@@ -81,6 +82,7 @@
 4. 风险大，收益大
 5. 客户化程度高
 6. 过程管理重要
+7. 完全没有物理属性
 
 ### 1.2 软件生命周期
 #### 1.2.1 需求定义  
@@ -93,6 +95,12 @@
 **描述：** 需求分析其实是在做需求细化，按照任务说明书中的任务内容和指标具体细化各个点，细化到每个输入框、每个按钮的样式，输入输出等各项值。     
 **参与者：** 产品经理、架构师、项目经理、测试/质量管理员(很多公司把这个统称为QA)、开发    
 **输出：**《需求规格说明书》
+
+**编码**
+
+**软件测试**
+
+**运行与维护**
 #### 1.2.4 评审  
 **描述：** 评审就是做审查，对这个阶段的工作进行审查，看是否偏离或者有遗漏（比如：设计和工厂的各个环节都有相关的审查，审查材料是否合格、设计是否符合规定、按照工人/设计出的材料需求是否足够或者多余等等，这些审查都是评审）；评审一般由相应工作人员来参与。    
 **参与者：** 每个阶段的评审一般都是各职能部门内部审核，也可以申请其他相关人员审核，比如需求评审，一般是产品经理、项目经理、测试、开发一起评审；系统设计一般是项目经理、开发评审；测试策略评审一般是测试组内部评审等等
@@ -106,12 +114,12 @@
 **描述：** 开发人员完成一个小迭代/小功能，且完成自测(开发编码完成后，一般都会自己检测下)，于是向测试部门发起提测，一般以邮件方式或者任务管理工具的任务流方式向测试部门通知xxx模块/功能可以测试。    
 **参与者：** 任务责任人（开发）、测试
 #### 1.2.8 测试  
-    - 测试需求
-    - 测试计划
-    - 测试设计
-    - 测试执行
-    - 回归测试
-    - 测试评估
+  - 测试需求
+  - 测试计划
+  - 测试设计
+  - 测试执行
+  - 回归测试
+  - 测试评估
 #### 1.2.9  部署/发版  
 **描述：** 经过前面的各个阶段，产品已经可以出售或者面向大众了。配置管理人员进行封版、版本制作（针对产品来说）/部署上线（针对项目应用来说）。  
 **参与人：** 配置管理人员、测试
@@ -235,6 +243,7 @@ IEEE729-1983 对缺陷有一个标准的定义：从产品内部看，缺陷是
 2. 软件出现了产品说明数中指明的不会出现的错误。
 3. 软件功能超出了产品说明书中指明的范围。
 4. 软件难于理解，不易使用，运行速度慢，或者最终用户认为软件使用效果不好。
+5. 软件没有实现产品说明书没讲但应该实现的功能
 
 #### 1.4.2 产生原因
 1. 软件本身复杂性，产生大量不确定因素。
@@ -396,6 +405,7 @@ IEEE729-1983 对缺陷有一个标准的定义：从产品内部看，缺陷是
 4. 两级思维方式
 5. 比较思维方式
 6. 发散思维方式
+7. 正向思维方式 
 
 ### 1.6 测试认识的误区
 1. 使用了测试工具，就进行了有效的测试
@@ -414,6 +424,7 @@ IEEE729-1983 对缺陷有一个标准的定义：从产品内部看，缺陷是
 14. 规范化软件测试是增加项目成本
 15. 越多测试越有效
 16. 软件测试工作只负责项目上线/产品发布之前的部分
+17. 软件测试没有前途，只有程序员才是软件高手
 ### 1.7 知识点总结
 
 ## 第2章 软件测试基础知识
@@ -435,6 +446,7 @@ IEEE729-1983 对缺陷有一个标准的定义：从产品内部看，缺陷是
 2. 检测产品是否符合用户要求。
 3. 没有发现错误的测试也是有价值的，完整的测试是评定软件质量的一种方法。
 4. 提升用户体验。
+5. 是为了证明程序有错，而不是证明程序无错
 
 #### 2.2.2 测试的原则
 1. 软件测试是证伪而非证实。
@@ -533,7 +545,7 @@ IEEE729-1983 对缺陷有一个标准的定义：从产品内部看，缺陷是
 ### 2.5 测试停止标准
 #### 2.5.1 软件测试停止总体标准
 1. 测试超过了预定时间
-2. 执行了所有的测试用例，并没有发现故障
+2. 执行了并多次测试了所有的测试用例，并没有发现故障
 3. 使用特定的测试用例设计方法作为判断测试停止的基础
 4. 给出测试停止的要求
 5. 根据经单位时间内查出故障的数量决定是否停止测试