From ca0c897f05d0e34cd679f8bed05fae4950447476 Mon Sep 17 00:00:00 2001 From: zhangjianwen19990274 <9730490+zhangjianwen19990274@user.noreply.gitee.com> Date: Tue, 14 Sep 2021 14:03:32 +0000 Subject: [PATCH] =?UTF-8?q?19990274=E5=BC=A0=E5=BB=BA=E9=9B=AF?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- README.md | 20 ++++++++++++-------- 1 file changed, 12 insertions(+), 8 deletions(-) diff --git a/README.md b/README.md index dbaae73..38a6984 100644 --- a/README.md +++ b/README.md @@ -2,7 +2,7 @@ ## 写在最前面 ### 1 课程目标 * 掌握基础的软件测试理论、测试方法和策略 -* 掌握常用工具使用 +* 掌握常用工具使用的方法 * 根据需求和设计文档独立编写测试计划、测试方案、测试用例以及测试报告 ### 2 主要内容 * 软件测试基础知识 @@ -24,7 +24,7 @@ ## 第1章 软件测试概论 ### 1.1 软件 -#### 1.1.1 软件定义 +#### 1.1.1 软件的定义 软件是一系列按照特定顺序组织的计算机数据和指令的集合。 **软件 ≠ 程序（代码）** 软件包含如下内容： @@ -112,6 +112,7 @@ - 测试执行 - 回归测试 - 测试评估 + - 测试范围 #### 1.2.9 部署/发版 **描述：** 经过前面的各个阶段，产品已经可以出售或者面向大众了。配置管理人员进行封版、版本制作（针对产品来说）/部署上线（针对项目应用来说）。 **参与人：** 配置管理人员、测试 @@ -214,7 +215,7 @@ W 模型是顺序性的、不可逆的，需求的变更和调整，依旧不方 在工作形式上，整个团队平时坐在一起工作，从物理空间上创造了更加便捷面对面的沟通机会。在团队职责上，团队内部具备完成软件交付的角色(能力)，团队所有人对软件的质量负责，开发过程由团队内部把控，业务价值团队内部快速流动，在任何环节都能及时获得反馈。同时，每个角色都更容易从全局视角去思考软件，避免了传统部门墙模式下的视角割裂和协作障碍。 * 工作的软件高于详尽的文档 -为客户交付可工作的软件是我们的核心目标，我们应该尽早交付可进行端到端测试的代码，该目标决定了我们不应该花过多精力在面面俱到的文档上，但这不代表我们要抵制任何文档。实践证明，轻量级的文档策略有助于团队高质量交付可工作的软件。 +为客户交付可工作的软件是我们的核心目标，我们应该尽早交付可进行端到端测试的代码，该目标虽然明确了我们不应该花过多精力在面面俱到的文档上，但这不代表我们要抵制所有文档。实践证明，轻量级的文档策略有助于团队高质量交付可工作的软件。 * 客户合作高于合同谈判 主动拥抱变化，及时响应，持续交付。 @@ -236,6 +237,7 @@ IEEE729-1983 对缺陷有一个标准的定义：从产品内部看，缺陷是 2. 软件出现了产品说明数中指明的不会出现的错误。 3. 软件功能超出了产品说明书中指明的范围。 4. 软件难于理解，不易使用，运行速度慢，或者最终用户认为软件使用效果不好。 +5. 软件测试员认为软件难以理解、不易使用、运行速度缓慢，或者最终客户认为不好。 #### 1.4.2 产生原因 1. 软件本身复杂性，产生大量不确定因素。 @@ -432,7 +434,7 @@ IEEE729-1983 对缺陷有一个标准的定义：从产品内部看，缺陷是 ### 2.2 测试的目的和原则 #### 2.2.1 测试的目的 -1. 测试不仅仅是找出错误。通过分析错误产生的原因和错误的发展趋势，可以帮助项目管理者发现当前软件开发过程中的缺陷，以便即时改进。 +1. 测试不仅仅是找出错误。通过分析错误产生的原因和错误的发展趋势，可以帮助项目管理者发现当前软件开发过程中的缺陷，以便及时改进。 2. 检测产品是否符合用户要求。 3. 没有发现错误的测试也是有价值的，完整的测试是评定软件质量的一种方法。 4. 提升用户体验。 @@ -486,7 +488,7 @@ IEEE729-1983 对缺陷有一个标准的定义：从产品内部看，缺陷是 2. 自动化测试 ### 2.4 测试用例 #### 2.4.1 简介 -测试用例是指对一项特定的软件产品进行测试任务的描述，体现测试方案、方法、技术和策略。其内容包括：测试目标、测试环境、输入数据、测试步骤、预期结果、测试脚本等，最终形成文档。 +测试用例是指对一项特殊的软件产品进行测试任务的描述，体现测试方案、方法、技术和策略。其内容包括：测试目标、测试环境、输入数据、测试步骤、预期结果、测试脚本等，最终形成文档。 简单的认为，测试用例是为某个特定目标而编制的一组测试输入、执行条件和预期结果，用于核实是否满足某个特定的软件需求。 @@ -497,6 +499,8 @@ IEEE729-1983 对缺陷有一个标准的定义：从产品内部看，缺陷是 2. 评估测试结果的度量基准 3. 保证软件的可维护性和可复用性 4. 分析缺陷的标准 +5. 指导测试数据规划 +6. 指导脚本编写 #### 2.4.3 测试用例设计准则 1. 有效性 @@ -545,7 +549,7 @@ IEEE729-1983 对缺陷有一个标准的定义：从产品内部看，缺陷是 1. 单元测试用例已经通过评审 2. 按照单元测试计划完成了所有规定单元测试 3. 达到了测试计划中关于单元测试所规定的覆盖率要求 -4. 被测试的单元每千行代码必须发现至少3个错误 +4. 被测试的单元每千行代码必须发现最多3个错误 5. 软件单元功能与设计一致 6. 单元测试中发现的错误已经得到修改，各级缺陷修复率达到标准 @@ -553,7 +557,7 @@ IEEE729-1983 对缺陷有一个标准的定义：从产品内部看，缺陷是 1. 集成测试用例已经通过评审 2. 按照集成测试计划和增量集成策略完成了整个系统的集成测试 3. 达到了测试计划中关于集成测试所规定的覆盖率要求 -4. 被测试的集成工作版本每千行代码必须发现至少2个错误 +4. 被测试的集成工作版本每千行代码必须发现最多2个错误 5. 集成工作版本满足设计定义的各项功能、性能要求 6. 在集成测试中发现的错误已经得到修改，各级缺陷修复率达到标准 @@ -561,7 +565,7 @@ IEEE729-1983 对缺陷有一个标准的定义：从产品内部看，缺陷是 1. 系统测试用例已经通过评审 2. 按照系统测试计划完成了系统测试 3. 达到了测试计划中关于系统测试所规定的覆盖率要求 -4. 被测试的系统每千行代码必须发现至少1个错误 +4. 被测试的系统每千行代码必须发现最多1个错误 5. 系统测试满足设计需求规格说明书要求 6. 在系统测试中发现的错误已经得到修改，各级缺陷修复率达到标准 -- Gitee