• 软件测试基础知识
  • 软件测试
  • 测试基础
    • 什么是软件测试
    • 测试主流技能
    • 测试分类
      • 1. 按测试阶段分类
      • 2. 按代码可见度分类
    • 拓展-总结
    • 拓展-测试策略
      • 冒烟测试
    • 模型
      • 质量模型
    • 质量模型
      • 1. 功能性（Functional Suitability）
      • 2. 性能效率（Performance Efficiency）
      • 3. 兼容性（Compatibility）
      • 4. 可用性（Usability）
      • 5. 可靠性（Reliability）
      • 6. 安全性（Security）
      • 7. 维护性（Maintainability）
      • 8. 可移植性（Portability）
      • 测试模型
        • W模型
    • 测试流程
    • 测试用例
      • 什么是用例
      • 用例的作用
      • 用例设计编写格式
        • 测试用例的核心要素
      • 如何设计用例设计
        • 1.等价类划分法–针对穷举场景
        • 2.边界值分析法-针对边界范围规则
        • 3.判定表法-针对多条件依赖关系
        • 4.场景法-使用对于项目业务
        • 5.错误推荐法
        • 测试用例标准格式
    • 缺陷
      • 1．能够知道软件缺陷判定标准
      • 2.能够知道项目中缺陷的管理流程
      • 3.能够使用Excel对于缺陷进行管理
      • 4.掌握禅道工具管理缺陷
    • 能够知道常见HTML标签的作用
      • 什么是抓包
    • 根据测试流程对于黑马头条登录需求进行分析
    • 能够对于登录模块提取测试点和设计用例
    • 能够使用工具进行记录缺陷
  • 其他
    • 软件开发模型

软件测试基础知识

软件测试

1-334 python测试 性能测试 UI自动化测试

测试基础

什么是软件测试

(概念\过程\目的)

概念：

软件测试是通过人工或自动化手段，对软件系统进行验证和确认的过程，目的是检查软件是否满足规定的需求或识别实际结果与预期结果之间的差异。

软件测试存在的意义是：通过一系列测试活动，“提前” 发现和定位软件产品质量的薄弱环节，并倒逼开发人员修正，从而保证交付的软件质量满足客户需求。

过程：

1. 需求分析：理解需求文档，明确测试范围。
2. 测试计划：制定测试策略、资源分配和时间表。
3. 测试设计：编写测试用例，覆盖功能和非功能需求。
4. 测试执行：执行测试用例，记录缺陷。
5. 缺陷管理：跟踪、修复和验证缺陷。
6. 测试报告：总结测试结果，评估软件质量。
7. 测试闭环：确认所有问题解决，输出最终报告。

目的：

• 确保软件质量，满足用户需求。
• 发现缺陷，降低生产环境风险。
• 验证功能、性能、安全性等非功能指标。
• 提供产品发布决策依据。

测试主流技能

1. 功能测试：
   • 黑盒测试方法（等价类划分、边界值分析等）。
   • 测试用例设计与管理（如使用TestLink、Excel）。
2. 自动化测试：
   • UI自动化：Selenium、Appium、Cypress。
   • API自动化：Postman、RestAssured、JMeter。
   • 单元测试：JUnit、TestNG、pytest。
3. 性能测试：
   • 工具：JMeter、LoadRunner、Gatling。
   • 指标：响应时间、吞吐量、并发用户数。
   • 场景设计：负载测试、压力测试、稳定性测试。
4. 安全测试：
   • 常见漏洞：SQL注入、XSS、CSRF。
   • 工具：OWASP ZAP、Burp Suite、Nmap。
5. 持续集成/交付（CI/CD）：
   • 集成工具：Jenkins、GitLab CI、Azure DevOps。
   • 容器化：Docker、Kubernetes。
6. 数据库与SQL：
   • 基本操作：增删改查、多表连接。
   • 性能调优：索引、慢查询分析。
7. 编程语言：
   • 基础语法：Python、Java、JavaScript。
   • 脚本编写：用于自动化或测试工具扩展。
8. 移动端测试：
   • 专项测试：兼容性、耗电量、网络模拟。
   • 工具：ADB、Monkey、XCTest。
9. 敏捷与DevOps：
   • 参与Scrum/Kanban，理解CI/CD流程。
   • 协作工具：Jira、Confluence、Trello。
10. 云测试：
    • 云平台：AWS、Azure、阿里云。
    • 云化测试工具：Sauce Labs、BrowserStack。
11. AI与测试结合：
    • 智能测试生成、缺陷预测。
    • 工具：Testim、Applitools。
12. 软技能：
    • 沟通协作、缺陷描述能力、风险意识。

测试分类

1. 按测试阶段分类

• 单元测试（Unit Testing）
  • 针对程序源代码进行测试（开发）
  • 对象：代码的最小单元（函数、类、方法）。
  • 工具：JUnit（Java）、pytest（Python）、NUnit（.NET）。
• 集成测试（Integration Testing）
  • 又称接口测试，主要针对模块与模块或系统与系统直接的接口进行验证
  • 对象：模块或系统间的接口交互。
  • 类型：自顶向下、自底向上、增量式集成。
• 系统测试（System Testing）
  • 针对软件全面进行验证（功能、兼容、文档）
  • 对象：完整的系统，验证是否符合需求规格说明书。
  • 重点：功能、性能、兼容性等端到端验证。
• 验收测试（Acceptance Testing）
  • 对象：最终用户或客户验证是否满足业务需求。
  • 类型：用户验收测试（UAT）、Alpha/Beta测试。

2. 按代码可见度分类

• 黑盒测试（Black Box Testing）（功能测试，看不见源代码）
  • 特点：不关注内部代码，基于需求和功能设计测试用例。
  • 技术：等价类划分、边界值分析、决策表、场景法。
• 白盒测试（White Box Testing）（单元测试，针对源代码进行测试）
  • 特点：基于代码结构设计测试用例，覆盖路径、分支、条件等。
  • 技术：语句覆盖、分支覆盖、路径覆盖。
• 灰盒测试（Grey Box Testing）（接口测试）
  • 特点：结合黑盒与白盒，关注接口和部分内部逻辑。

3. 按是否执行代码分类

• 静态测试（Static Testing）
  • 对象：文档、代码（不运行程序）。
  • 方法：代码审查、需求评审、静态分析工具（SonarQube）。
• 动态测试（Dynamic Testing）
  • 对象：运行中的程序，验证实际输出是否符合预期。

4. 按是否自动化分类

• 手动测试（Manual Testing）
  • 场景：探索性测试、用户体验测试、复杂业务流程测试。
• 自动化测试（Automation Testing）
  • 场景：回归测试、性能测试、大规模数据驱动测试。

5. 按测试目标分类

• 功能测试（Functional Testing）

  • 验证：系统是否按需求实现功能（如登录、支付）。

• 非功能测试（Non-Functional Testing）

  • 性能测试：响应时间、吞吐量、负载能力。
  • 安全测试：漏洞扫描、渗透测试。
  • 兼容性测试：不同浏览器、操作系统、设备。
  • 可用性测试：用户界面友好性、易用性。
  • 可靠性测试：系统长时间运行的稳定性。

拓展-总结

1.系统测试和黑盒测试重点核心是**功能测试**
2.集成测试和灰盒测试又称**接口测试**
3.单元测试和白盒测试是对**代码**进行测试
4.自动化测试归属**功能测试**
5.性能测试、安全测试归属**专项测试**

拓展-测试策略

冒烟测试

大规模执行测试之前，针对程序主功能进行验证，保证程序具备可测性

模型

质量模型

质量模型为评估软件质量提供系统化框架，指导测试设计和结果分析。

得到需求、测试功能，可以从以下八个方向进行考虑：

功能、性能、兼容、易用、可靠、安全、维护、迁移

重点在：功能、性能、兼容、易用、安全

• 质量模型

  质量模型定义了软件质量的评价标准，最常用的是 ISO/IEC 25010 标准，包含以下八大特性：

1. 功能性（Functional Suitability）

• 子特性：功能是否满足需求
  • 功能完备性：是否覆盖所有需求。
  • 功能正确性：输出结果是否准确。
  • 功能依从性：是否符合行业标准（如金融合规）。

2. 性能效率（Performance Efficiency）

• 子特性：性能满足实际需求
  • 时间特性：响应速度、处理时间。
  • 资源利用率：CPU、内存、网络消耗。
  • 容量：最大并发用户数、数据处理能力。

3. 兼容性（Compatibility）

• 子特性：软件能与主流硬件和软件兼容
  • 互操作性：与其他系统交互能力（如API兼容）。
  • 共存性：与其他软件共存时不冲突。
  • 环境适配性：支持不同操作系统、浏览器、设备。

4. 可用性（Usability）

• 子特性：便于使用
  • 易学性：用户快速上手的难度。
  • 易操作性：界面交互是否直观。
  • 错误防御性：防止用户误操作的设计。

5. 可靠性（Reliability）

• 子特性：性能和功能应用可靠
  • 成熟性：系统长期运行的稳定性。
  • 容错性：故障后恢复能力。
  • 可用性：系统持续可用的时间比例（如99.9% SLA）。

6. 安全性（Security）

• 子特性：信息在传输或者储存过程的安全程度
  • 机密性：数据加密与权限控制。
  • 完整性：防止数据篡改。
  • 抗抵赖性：操作可追溯（如日志审计）。

7. 维护性（Maintainability）

• 子特性：便于维护
  • 模块化：代码结构是否易于修改。
  • 可测试性：是否容易添加新测试用例。
  • 可分析性：定位问题的难易程度。

8. 可移植性（Portability）

• 子特性：具备迁移和便捷性
  • 适应性：适配不同环境的成本。
  • 易安装性：部署流程是否简单。
  • 可替换性：是否可被其他系统替代。

测试模型

W模型

简称为”双V模型”

开发流程：需求分析、概要设计、详细设计、编码、集成、实施、交付。
测试流程：单元测试、集成测试、系统测试、验收测试

优点：

缺点：

测试流程

软件测试流程

1.需求分析：让参与项目的各部门对 “需求是什么” 达成一致理解，避免后续偏差。

2.计划编写：明确测试的核心问题 ——“测什么内容、谁来执行测试、用什么方法 / 流程测”。

3.用例设计：编写 “操作指南式” 的文档，用来验证项目是否符合需求（即 “测试用例”）。

4.用例执行：等项目模块开发好后，按照之前设计的测试用例，实际开展测试工作。

5.缺陷管理：对测试中发现的问题（“缺陷”）进行全流程管理（比如记录、追踪修复、验证修复效果等）。

6.测试报告：把测试的最终结果整理成文档，总结测试的情况（比如发现了多少问题、项目是否符合要求等）。

• 需求分析

前置：阅读需求分析文档，记录不明确之处

1、确定各部门对需求理解一致。
2、站在不同角度对需求进行（查、漏、补缺）

• 测试计划

核心：
1、测什么：测试目标及范围
2、谁来测：人员进度安排
3、怎么测：测试策略、测试工具

团队计划 --》  个人计划
团队计划：

个人计划：

• 用例设计

设计执行测试的文档

• 用例执行

执行测试的文档

• 缺陷管理

提交->验证->关闭

• 测试报告

测试背景、测试过程、缺陷统计、缺陷分析、测试总结

测试用例

什么是用例

• 测试用例：执行测试的文档（用户使用的文档）
• 考虑点：质量模型

**什么是测试用例？**

测试用例（Test Case）是为特定测试目标设计的一组**执行条件、输入数据、操作步骤和预期结果**，用于验证软件是否满足需求或发现潜在缺陷。它是测试执行的最小单位，是测试活动的核心指导文档。

用例的作用

• 防止漏测
• 实施测试的标准

测试用例的作用

1. 指导测试执行
   • 明确测试步骤和预期结果，避免遗漏或误操作。
   • 示例：登录功能测试用例确保覆盖“正确密码”“错误密码”“空密码”等场景。
2. 保障测试覆盖率
   • 通过设计用例，系统化覆盖功能、边界条件、异常场景。
   • 结合等价类划分、边界值分析等方法，减少测试盲区。
3. 缺陷发现与追踪
   • 通过比对实际结果与预期结果，快速定位缺陷。
   • 缺陷报告中可关联用例编号，便于复现和修复验证。
4. 团队协作与沟通
   • 作为测试与开发、产品之间的沟通桥梁，确保需求理解一致。
   • 用例评审（Review）可提前暴露需求歧义或设计漏洞。
5. 自动化测试的基础
   • 自动化脚本通常基于测试用例设计，确保脚本可维护性和可扩展性。
   • 示例：Selenium脚本按用例步骤执行登录操作。
6. 回归测试的保障
   • 维护用例库，便于后续版本快速执行回归测试，防止修复引入新问题。
7. 质量评估与报告
   • 统计用例通过率、缺陷密度等指标，评估软件质量，支持发布决策。
8. 知识沉淀
   • 用例文档化保留测试经验，方便新人快速上手或项目交接。

用例设计编写格式

测试用例的核心要素

• 用例编号：项目+模块+编号
• 用例标题：预期结果+操作步骤
• 模块/项目：所属项目或模块
• 前置条件：要执行此条用例，有哪些前置操作
• 优先级：表示用例的重要程度或者影响力P0~p4（PO最高）
• 测试步骤；描述操作步骤
• 测试数据：操作的数据，没有的话可以为空
• 预期结果：期望达到的结果

1. 用例编号：唯一标识（如TC_Login_001）。
2. 测试标题：简洁描述测试目的（如预期结果+测试点“注册成功（验证码6位）”）。
3. 前置条件：执行前的环境或数据状态（如“用户已注册”）。
4. 输入数据：测试所需的参数或操作（如用户名：[email protected]，密码：123456）。
5. 执行步骤：详细的操作流程（如：输入用户名 → 输入密码 → 点击登录按钮）。
6. 预期结果：符合需求的标准输出（如“跳转到用户主页”）。
7. 实际结果：执行后的实际输出（测试执行时填写）。
8. 优先级：标记重要性（如P0-紧急，P1-高，P2-中）。

测试用例与质量模型的关联

• 功能性：用例验证功能是否正确实现（如支付流程是否完整）。
• 性能效率：性能测试用例设计并发用户数、响应时间等场景。
• 安全性：安全测试用例覆盖SQL注入、越权访问等漏洞场景。
• 兼容性：用例验证不同浏览器、设备下的功能一致性。

总结

测试用例是软件测试的“作战计划”，其核心价值在于：

• 标准化：确保测试活动系统化、可重复。
• 高效性：减少重复劳动，提升测试效率。
• 可追溯性：缺陷、需求、用例三者关联，形成闭环管理。
• 质量保障：通过覆盖多维度场景，支撑软件质量目标的达成。

如何设计用例设计

1.等价类划分法–针对穷举场景

• • 说明：在所有测试数据中，具有某种共同特征的数据集合进行划分。

  • 分类：

    • 有效等价类：满足需求的数据集合，取一个进行测试即可
    • 无效等价类：不满足需求的数据集合，取一个进行测试即可

  • 步骤

    1.明确需求
    2.确定有效和无效等价类
    3.提取数据编写测试用例

• 案例

有效：

• 使用场景

  • 针对：需要有大量数据测试输入，但是没法穷举测试的地方。

    输入框 下拉列表 单选复选框

  • 典型代表：页面级的输入框类测试。

2.边界值分析法-针对边界范围规则

针对边界范围规则，使用边界值分析法+等价类划分法

• 边界范围节点

选取正好等于、刚好大于、搞好小于边界的值作为测试数据

• 上点：边界上的点（正好等于） 绿点
• 离点：距离上点最近的点（刚好大于、刚好小于） 黄点
• 内点：范围内的点（区间范围内的数据） 内点

​ 用例设计最多7条，最少5条

案例优化 结论：7个优化为5个点 上点：必选(不考虑区间开闭) 内点：必选(建议选择中间范围） 离点：开内闭外(考虑开闭区间，开区间选择内部离点，闭区间选择外部离点）

• 步骤

  2、边界值法设计用例步骤 1.明确需求 2.确定有效和无效等价类 3.确定边界范围值 4.提取数据编写测试用例

• 案例

案例一

案例二

• 使用场景

在等价类的基础上针对有边界范围的测试数据输入的地方（重点关注边界）

• 常见词语描述:大小、尺寸、重量、最大、最小、至多、至少等修饰词语

• 典型代表:有边界范围的输入框类测试

• 提示：边界值可以覆盖等价类的长度，但是无法覆盖类型。所以设计用例时，必须两者结合。

3.判定表法-针对多条件依赖关系

判定表定义及组成部分

是一种以表格形式表达多条件逻辑判断的工具 组成：

• 条件桩：列出问题中的所有条件，列出条件的次序无关紧要。
• 动作桩：列出问题中可能采取的操作，操作的排列顺序没有约束。
• 条件项：列出条件对应的取值，所有可能情况下的真假值。
• 动作项：列出条件项的、各种取值情况下应该采取的动作结果。

规则:

判定表中贯穿条件项和动作项的一列就是一条规则

假设有n个条件，每个条件的取值有两个（0,1），全组合有2的n次方种规则

判定表法设计用例步骤

1、明确需求 2、画出判定表 1）、列出条件桩和动作桩 2）、填写条件项，对条件进行全组合 3）、根据条件项的组合确定动作项 4）、简化、合并相似规则（有相同的动作） 3、根据规则编写测试用例

验证码就4条：

正确、错误、过期、为空

• 案例

案例一

案例二

• 使用场景

• 有多个输入条件，多个输出结果，输入条件之间有组合关系，输入条件和输出结果之间有依赖（制约）关系

• 判定表一般适用于条件组合数量较少的情况（比如4个条件以下）

• 4个相互依赖条件可以使用正交表和因果图

4.场景法-使用对于项目业务

说明：

场景法也可以叫流程图法，是用流程图描述用户的使用场景，然后通过覆盖流程路径来设计测试用例。 意义： 用户使用角度：用户平时使用的不是单个功能，而是多个功能组合起来进行使用 测试人员角度：平时测试的都是单个功能点进行测试，容易忽略多个功能的组合测试

• 案例

案例一

成功的最长的这条线一般用于冒烟测试。

用例二

案例三

• 使用场景

流程图

流程图对测试人员有什么作用？ 1、能够看懂流程图，设计业务用例 2、当需求文档信息不全是，能够根据需求，梳理出流程

5.错误推荐法

定义 通过经验推测系统可能出现的问题

场景： 1、时间紧任务量大时根据之前项目类似经验找出易出错的模块重点测试

2、时间宽裕时通过该方法列根据经验列举可能出现问题的、之前出现问题较多的模块题的清单，根据清单分析问题再次测试、推测发现缺陷

以下是测试用例的标准格式说明及示例，帮助团队统一规范、提升测试效率：

测试用例标准格式

测试用例模板示例

功能测试用例（Excel/工具模板）

性能测试用例（JMeter场景示例）

不同测试类型的格式差异

1. 功能测试用例

   • 强调步骤和结果的细节，适合手动测试。
   • 示例：UI操作流程、表单提交验证。

2. 自动化测试用例

   • 增加脚本路径、参数化数据源字段。

   • 示例：

     script_path: tests/login/test_login.py  
     data_source: data/login_data.csv  
     

3. 接口测试用例

   • 包含请求方法、URL、Headers、Body等字段。

   • 示例：

     **Request**:  
     - Method: POST  
     - URL: /api/login  
     - Body: { "username": "test", "password": "123" }  
     **Response**:  
     - Status Code: 200  
     - Body: { "token": "xxxx" }  
     

4. 安全测试用例

   • 描述漏洞场景和攻击向量。

   • 示例：

     测试标题：验证SQL注入漏洞  
     步骤：在用户名输入框输入 `' OR 1=1 --`  
     预期结果：系统返回错误提示，而非泄露数据库信息。  
     

注意事项

1. 清晰简洁
   • 避免冗长步骤，每一步只包含一个操作。
   • 示例：❌ 错误写法：“输入用户名和密码，点击登录”；✅ 正确写法：分步骤描述。
2. 可复用性
   • 参数化输入数据（如使用变量 ${username}），便于数据驱动测试。
3. 独立性
   • 单个用例不依赖其他用例结果，前置条件需明确初始化数据。
4. 版本控制
   • 用例文档需标注版本号和修订记录（如下表）：

常用工具与模板

1. Excel/Google Sheets：适合小型团队，灵活但不易维护。
2. TestLink/TestRail：专业测试管理工具，支持用例库、执行计划和报告生成。
3. JIRA + Zephyr：与缺陷管理无缝集成，适合敏捷团队。
4. Markdown/Confluence：便于文档协作和版本跟踪。

总结

规范的测试用例格式能：

• 提升团队协作效率，减少沟通成本。
• 确保测试覆盖率和执行一致性。
• 为自动化测试和回归测试提供可靠基础。
• 根据项目需求调整模板（如金融行业需增加合规性验证字段）。

缺陷

1．能够知道软件缺陷判定标准

缺陷介绍 1、缺陷的定义：软件在使用过程中存在的任何问题都叫软件的缺陷，简称bug。

2、缺陷的判定标准

• 软件未实现需求(规格)说明书中明确要求的功能-少功能
• 软件出现了需求（规格）说明书中指明不应该出现的错误-功能错误
• 软件实现的功能超出需求（规格）说明书指明的范围-多功能
• 软件未实现需求(规格)说明书中虽未明确指明但应该实现的要求-隐性功能错误
• 软件难以理解，不易使用，运行缓慢，用户体验不好-不易使用

3.缺陷产生的原因

需求阶段:需求描述不易理解，有歧义、错误等。 产品经理 设计阶段:设计文档存在错误或者缺陷。 架构师 编码阶段:代码出现错误。 运行阶段:软硬件系统本身故障导致软件缺陷。

IT行业常见岗位及作用

• 产品：梳理需求、设计原型图
• UI：美工
• 前端：写页面
• 后端：写功能
• 测试：找缺陷
• 运维：管理服务器
• 运营：上线运营策划

4、软件缺陷的生命周期

注入bug->发现bug->修复bug
从提交报告到修复关闭

5、软件缺陷的核心内容

缺陷的标题：描述缺陷的核心问题

缺陷的预置条件：缺陷产生的前提

缺陷的复现步骤：复现缺陷的过程

缺陷的预期结果：希望得到的结果

缺陷的实际结果：实际得到的结果

缺陷的必要附件：图片、日志等信息(证据)

6.缺陷提交要素

缺陷报告编号:缺陷的唯一性标志

严重程度:

严重（S1）：主功能 一般 (S2):次要功能

微小 (S3)：易用性、界面 建议（S4）：建议性问题

缺陷优先级：

Priority 0：24小时之内解决

Priority 1：发布前必须修复

Priority 2：可以在下一个版本中修复

Bug类型：

代码错误、兼容性问题、设计缺陷、性能问题

缺陥状态：

New:新建 Open:打开 Closed:关闭 Postponed:延期

7、软件缺陷类型

功能错误如何区分前端、后端错误： 利用抓包，检测请求和响应的数据是否正确

2.能够知道项目中缺陷的管理流程

缺陷报告示例

缺陷ID：用例ID

缺陷标题：操作数据描述+预期+实际

测试步骤：操作步骤+数据

缺陷的跟踪流程

发现BUG后该怎么做 --- 确认BUG可复现

3.能够使用Excel对于缺陷进行管理

4.掌握禅道工具管理缺陷

禅道的特点

三权分立

产品部门-构想者 研发部门-执行者 测试部门-保证者

四角协同

产品经理 项目经理 研发团队 测试团队

禅道使用流程

禅道缺陷管理

• 缺陷管理

• 用例管理

• 缺陷管理

1.提交缺陷  2.关闭缺陷

• 用例管理

能够知道常见HTML标签的作用

什么是抓包

抓包：抓客户端发送服务器的数据包或服务器响应客户度的数据包

根据测试流程对于黑马头条登录需求进行分析

能够对于登录模块提取测试点和设计用例

能够使用工具进行记录缺陷

其他

软件开发模型

1. 瀑布模型

瀑布模型的主要特征在于项目完全按照阶段划分，只有前一阶段完成，才能开始下一阶段。具体到测试活动，则只能在全部编码完成后、发布之前执行，在这种开发模型中，测试活动被完全后置了，测试仅仅是编码后的一个活动阶段，测试的重要性没有被凸显出来。

gantt
	dateFormat YYYY-MM-DD
	title	瀑布模型
	
	section 瀑布模型
	可行性研究 		:d 			des1,1d
	需求分析		:			des2,after des1,1d 
	设计			:			des3,after des2,1d
	编码			:			des4,after des3,1d
	测试			:			des5,after des4,1d
	发布,运行,维护	:			des6,after des5,1d
	
	section V模型

2.V模型

基于此，V 模型出现了。V 模型在整个开发过程中，不仅相对清晰地划分了测试活动的不同级别，还将其不同级别的测试活动与软件开发各阶段清晰地对应起来，强调了测试在整个开发过程中的重要性。但在 V 模型中，测试依旧是编码之后才开始的，测试介入时间还是太晚。比如，需求分析阶段出现的问题，要等到系统测试阶段才能发现。

flowchart LR
A[用户需求] --> B[需求分析] --> C[概要设计] --> D[详细设计]  
E[编码]
F[单元测试] --> G[集成测试] --> H[系统测试] --> I[验收测试]
D --> E --> F

3.W模型

为了弥补这一缺点，V 模型的进一步深化版，即W 模型出现了。从 W 模型的示意图中，可以看到，W 模型是把 V 模型左边的每一个活动都加了一个测试设计活动，体现了“尽早和不断地进行测试”的原则

但是说到底，W 模型和 V 模型都把软件的开发视为需求、设计、编码、测试等一系列串行的活动，无法支持迭代、自发性及变更调整。

4.迭代模型

​ 迭代模型，常用于需求不甚明确、开发难度比较大的项目，比如互联网行业流行的先出 MVP 版本，然后再根据用户反馈进行调整的项目。 ​ 迭代模型将大型项目分为多个迭代，每个迭代本质上是一个小项目，每个小项目都包括了需求分析、设计、编码与测试等一系列项目活动。需要注意的一点是，迭代模型是增量的，它要求先完成部分系统功能或业务逻辑，然后依据客户反馈来进一步明确需求，最后通过一次次的迭代来给用户交付达标的产品。

​ 由于每次迭代都有测试，所以迭代模型客观上实现了测试的更早介入。 ​ 此外，作为一种以人为核心，强调迭代、循序渐进的开发方法，敏捷开发近几年非常流行。它有 Scrum、XP 等多种实现方式，当前 Scrum 模式采用较多。 ​ 虽然敏捷开发中的 Scrum 与上文提及的迭代模型（RUP）看起来很像，但两者概念完全不同，区别如下：