diff --git a/README.md "b/\345\262\263\345\270\205+19990152.md"
similarity index 98%
rename from README.md
rename to "\345\262\263\345\270\205+19990152.md"
index 7edbc23d33a9045d730d88e372d8101ea489c5f0..023436ba7bae9d919d59bcc7a823f4e0be884104 100644
--- a/README.md
+++ "b/\345\262\263\345\270\205+19990152.md"
@@ -38,7 +38,7 @@
 
 #### 1.1.2 文档
 ##### 开发文档
-开发文档是描述软件开发过程，包括软件需求、软件设计、软件测试、保证软件质量的一类文档，开发文档也包括软件的详细技术描述、程序逻辑、程序间相互关系、数据格式和存储等。
+开发文档是描述软件开发过程，包括软件需求、软件设计、软件测试和保证软件质量的一类文档，开发文档也包括软件的详细技术描述、程序逻辑、程序间相互关系、数据格式和存储等。
 
 * 《可行性研究》
 * 《项目任务书》
@@ -100,17 +100,17 @@
 #### 1.2.3 需求分析  
 **描述：** 需求分析其实是在做需求细化，按照任务说明书中的任务内容和指标具体细化各个点，细化到每个输入框、每个按钮的样式，输入输出等各项值。     
 
-**参与者：** 产品经理、架构师、项目经理、测试人员/质量管理员(很多公司把这个统称为QA)、开发人员    
+**参与者：** 产品经理、架构师、项目经理、测试人员、质量管理员(很多公司把这个统称为QA)、开发人员    
 
 **输出：**《需求规格说明书》
 
 #### 1.2.4 评审  
-**描述：** 评审就是做审查，对这个阶段的工作进行审查，看是否偏离或者有遗漏（比如：设计和工厂的各个环节都有相关的审查，审查材料是否合格、设计是否符合规定、按照工人/设计出的材料需求是否足够或者多余等等，这些审查都是评审）；评审一般由相应工作人员来参与。    
+**描述：** 评审就是做审查，对这个阶段的工作进行审查，看是否偏离或者有遗漏（比如：设计和工厂的各个环节都有相关的审查，审查材料是否合格、设计是否符合规定、按照工人设计出的材料需求是否足够或者多余等等，这些审查都是评审）；评审一般由相应工作人员来参与。    
 
-**参与者：** 每个阶段的评审一般都是各职能部门内部审核，也可以申请其他相关人员审核，比如需求评审，一般是产品经理、项目经理、测试人员、开发人员一起评审；系统设计一般是项目经理、开发人员评审；测试策略评审一般是测试组内部评审等等
+**参与者：** 每个阶段的评审一般都是各职能部门内部审核，也可以申请其他相关人员审核，比如需求评审，一般是产品经理、项目经理、测试人员、开发人员一起评审；系统设计一般是项目经理、开发人员评审；测试策略评审一般是测试组内部评审等等。
 
 #### 1.2.5 设计  
-**描述：** 架构师根据需求确定产品或者项目的场景、特点，选择合适的框架，技术使项目实现最优化。在此基础上将系统进行概要设计，包括系统总体数据结构、数据库结构、模块结构以及它们之间的关系等。开发人员根据概要设计对具体模块进行详细设计，包括接口、参数等。此处设计会形成概要设计文档和详细设计文档。    
+**描述：** 架构师根据需求确定产品或者项目的场景、特点，选择合适的框架、技术使项目实现最优化。在此基础上将系统进行概要设计，包括系统总体数据结构、数据库结构、模块结构以及它们之间的关系等。开发人员根据概要设计对具体模块进行详细设计，包括接口、参数等。此处设计会形成概要设计文档和详细设计文档。    
 
 **参与者：** 项目经理、架构师、开发人员、测试人员
 
@@ -139,9 +139,9 @@
 
 #### 1.2.10 支持维护  
 
-**描述：** 支持维护类似于我们日常中的售后，主要是对已卖出的产品/已上线的项目进行日常维护。包括纠错性维护和改进性维护两个方面。  
+**描述：** 支持维护类似于我们日常中的售后，主要是对已卖出的产品和已上线的项目进行日常维护。包括纠错性维护和改进性维护两个方面。  
 
-**参与人：** 支持维护人员/售后工程师
+**参与人：** 支持维护人员、售后工程师
 
 ### 1.3 软件测试概述
 #### 1.3.1 软件测试定义
@@ -388,11 +388,11 @@ IEEE729-1983 (电气和电子工程师协会标准IEEE) 对缺陷有一个标准
 
 以上是上报bug、创建bug必须要做的，在后续我们还会对bug进行修复、复测等工作，那么为了记录后续工作，bug还应该包含：
 
-1. bug状态：开始、修复中、修复完成、提测、测试中、测试通过/失败、关闭等，后续bug周期中会讲到。
+1. bug状态：开始、修复中、修复完成、提测、测试中、测试通过、失败、关闭等，后续bug周期中会讲到。
 2. bug修订人：bug修订人员。
-3.  bug复测人：通常是谁报的bug最后返回给谁测试，但是在某些情况下比如bug报告人任务积累太多/不在的情况下也会分给其他人，所以通常会记录bug复测责任人。
-4.  bug修订说明：由bug修订人来写，说明bug产生原因，修改思路等。
-5.  bug复测说明：由复测人员来写，说明复测过程，复测结果等。
+3.  bug复测人：通常是谁报的bug最后返回给谁测试，但是在某些情况下比如bug报告人任务积累太多或不在的情况下也会分给其他人，所以通常会记录bug复测责任人。
+4.  bug修订说明：由bug修订人来写，说明bug产生原因、修改思路等。
+5.  bug复测说明：由复测人员来写，说明复测过程、复测结果等。
 6.  bug备注：备注，以便记录一些额外信息。
 
 #### 1.4.8 缺陷预防
@@ -473,7 +473,7 @@ IEEE729-1983 (电气和电子工程师协会标准IEEE) 对缺陷有一个标准
 13. 自动化测试终会取代手工测试；
 14. 规范化软件测试是增加项目成本；
 15. 越多测试越有效；
-16. 软件测试工作只负责项目上线/产品发布之前的部分。
+16. 软件测试工作只负责项目上线及产品发布之前的部分。
 ### 1.7 知识点总结
 
 ## 第2章 软件测试基础知识