diff --git a/README.md b/README.md index f0b77dce6d628e7369bdebae6328d21d35209408..0383081bd4fe9e0b31e2fc8cecf03a53a2eb76ea 100644 --- a/README.md +++ b/README.md @@ -38,7 +38,7 @@ #### 1.1.2 文档 ##### 开发文档 -开发文档是描述软件开发过程，包括软件需求、软件设计、软件测试、保证软件质量的一类文档，开发文档也包括软件的详细技术描述、程序逻辑、程序间相互关系、数据格式和存储等。 +开发文档是描述软件开发过程，包括软件需求、软件设计、软件测试、软件质量的一类文档，开发文档也包括软件的详细技术描述、程序逻辑、程序间相互关系、数据格式和存储等。 * 《可行性研究》 * 《项目任务书》 @@ -64,7 +64,7 @@ * 《实施方案》 ##### 产品文档 -为使用和运行软件产品的任何人规定培训和参考信息，促进软件产品的市场流通或提高可接受性。使得那些未参加开发本软件的程序员维护它。 +为使用和运行软件产品的任何人规定培训和参考信息，促进软件产品的市场流通或提高可接受性。使得那些未参加开发本软件的程序员得以维护它。 * 《产品手册》 * 《用户指南》 @@ -74,15 +74,15 @@ #### 1.1.3 软件发展史 1. 程序设计阶段：个体化生产、专用软件、规模小、功能单一、开发者即使用者。（软件 = 程序） 2. 程序系统阶段：多用户人机交互，实时系统和数据库管理系统。 -3. 软件工程阶段：以软件的产品化、系列化、工程化和标准化为特征的软件产业发展起来，软件开发有了可以遵循的软件工程化的设计准则、方法和标准。 +3. 软件工程阶段：以软件的产品化、系列化、工程化和标准化为特征的软件产业发展起来，软件开发有了可以遵循的软件工程化的设计准则、方法。 4. 多层分布结构，面向服务架构。 #### 1.1.4 软件项目 软件项目是一种特殊的项目，具有如下特点： -1. 知识密集型，技术含量高 +1. 知识密集，技术含量高 2. 涉及多个专业领域，多种技术综合应用 3. 项目范围广和目标的灵活性高 -4. 风险大，收益大 +4. 风险大，收益高 5. 客户化程度高 6. 过程管理重要 @@ -93,7 +93,7 @@ **参与者：** 产品经理、需求分析师、客户 #### 1.2.2 可行性分析 -**描述：** 由项目组相关成员去研究需求是否可行，能不能做出来。 +**描述：** 由项目组相关成员去研究需求是否可行，能不能做出来。 **参与者：** 产品经理、架构师、项目经理、开发人员 @@ -115,7 +115,7 @@ **参与者：** 项目经理、架构师、开发人员、测试人员 #### 1.2.6 编码 -**描述：** 开发人员根据详细设计文档对系统进行模块化开发，在确定参数和接口的情况下，根据需求对模块内部进行方法级别的设计和编码以及自测，对产品功能进行一一实现。 +**描述：** 开发人员根据详细设计文档对系统进行模块化开发，在确定参数和接口的情况下，根据需求对模块内部进行方法级别的设计和编码以及自测，将产品功能进行一一实现。 **参与者：** 开发 @@ -146,7 +146,7 @@ ### 1.3 软件测试概述 #### 1.3.1 软件测试定义 软件测试的经典定义是：在规定的条件下对程序进行操作，以发现程序错误，衡量软件质量，并对其是否能满足设计要求进行评估的过程。 -IEEE：使用人工或自动手段来运行或测定某个软件系统的过程，其目的在于检测他是否满足规定的需求或弄清预期结果和实际结果的差别。 +IEEE：使用人工或自动手段来运行或测定某个软件系统的过程，其目的在于检测他是否满足规定的需求或弄清预期结果和实际结果的差距。 #### 1.3.2 测试发展历程 1. 1957年之前－调试为主(Debugging Oriented) @@ -174,8 +174,8 @@ The process of executing a program with the intent of finding errors. 5. 1988–至今－预防为主(Prevention Oriented) - 尽量早地介入并发现这些明显的或隐藏的bug，发现得越早，修复起来的成本越低，产生的风险也越小。 - + 尽量早地介入并发现这些明显的或不明显的bug，发现得越早，修复起来的成本越低，产生的风险也越小。 + #### 1.3.3 测试与开发的关系 **瀑布模型** @@ -183,8 +183,8 @@ The process of executing a program with the intent of finding errors. 这是一种经典模型,提供了软件开发的基本框架。 -强调开发工作（计划、设计、开发、测试、维护等）各阶段之间的先后顺序，不可以并行操作。 - +强调开发工作（设计、开发、测试、维护等）各阶段之间的先后顺序，不可以并行操作。 + 瀑布模型认为，测试是指代码完成后，处于运行维护阶段之前。如果需求和设计上存在缺陷，就会造成大量返工，增加成本。 为了更早的发现问题，测试应延伸需求评审，设计审查活动中，软件生命周期的每个阶段都应包含测试。 @@ -205,7 +205,7 @@ The process of executing a program with the intent of finding errors. ![V模型](https://gitee.com/XiaFuXiangFei/software-testing/raw/main/images/v-model.png) -强调将测试和开发同等重要，对于开发阶段都有与之对应的测试阶段。 +强调将测试和开发同等重要，对于每个开发阶段都有与之对应的测试阶段。 **优点：** @@ -233,8 +233,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) @@ -253,7 +252,7 @@ W 模型是顺序性的、不可逆的，需求的变更和调整，依旧不方 5. 围绕斗志高昂的人进行软件开发，给开发者提供适宜的环境，满足他们的需要，并相信他们能够完成任务。 6. 在开发小组中最有效率也最有效果的信息传达方式是面对面的交谈。 7. 可以工作的软件是进度的主要度量标准。 -8. 敏捷过程提倡可持续开发。出资人、开发人员和用户应该总是维持不变的节奏。 +8. 敏捷过程提倡可持续开发。出资人、开发人员和用户应该总是维持稳定的节奏。 9. 对卓越技术与良好设计的不断追求将有助于提高敏捷性。 10. 简单——尽可能减少工作量的艺术至关重要。 11. 最好的架构、需求和设计都源自自我组织的团队。 @@ -269,7 +268,7 @@ W 模型是顺序性的、不可逆的，需求的变更和调整，依旧不方 * 工作的软件高于详尽的文档 - 为客户交付可工作的软件是我们的核心目标，我们应该尽早交付可进行端到端测试的代码，该目标决定了我们不应该花过多精力在面面俱到的文档上，但这不代表我们要抵制任何文档。实践证明，轻量级的文档策略有助于团队高质量交付可工作的软件。 + 为客户交付可工作的软件是我们的核心目标，我们应该尽早交付可进行的端到端测试的代码，该目标决定了我们不应该花过多精力在面面俱到的文档上，但这不代表我们要抵制任何文档。实践证明，轻量级的文档策略有助于团队高质量的交付可工作的软件。 * 客户合作高于合同谈判 @@ -290,13 +289,13 @@ W 模型是顺序性的、不可逆的，需求的变更和调整，依旧不方 IEEE729-1983 (电气和电子工程师协会标准IEEE) 对缺陷有一个标准的定义：从产品内部看，缺陷是软件产品开发或维护过程中存在的错误、毛病等各种问题；从产品外部看，缺陷是系统所需要实现的某种功能的失效或违背。 符合下面4个条件之一就是缺陷： -1. 软件未达到规格说明书中规定的功能。 +1. 软件未达到规格说明书中规定的功能标准。 2. 软件出现了产品说明书中指明的不会出现的错误。 3. 软件功能超出了产品说明书中指明的范围。 4. 软件难于理解，不易使用，运行速度慢，或者最终用户认为软件使用效果不好。 #### 1.4.2 产生原因 -1. 软件本身复杂性，产生大量不确定因素。 +1. 软件本身复杂性，导致大量不确定因素。 2. 成本、时间限制，导致流程不够完善，文档缺失，缺乏严谨的评审。 3. 人员本身技能水平、责任心、交流沟通不顺畅。 4. 不全面或者没有复审。