【软件测试】软件开发模型与需求分析

一、需求

一般在一轮开发中，会有两种需求，即软件需求与用户需求。

1. 用户需求

• 用户需求通常指的是来自终端用户或客户的需求。 这些需求是描述软件必须完成的目标和功能，但它们是从业务角度来看的，主要关注解决用户的问题和满足业务需求。
• 用户需求通常不涉及实现细节，而是关注 “软件应该做什么”。
• 用户需求一般较为简单，没有条件限制，可能只是一句口头描述，比如：实现一个美观的界面，写一个安全性高的登录功能。

2. 软件需求

• 软件需求又称功能需求；

• 软件需求则是从开发团队的角度来定义的，它描述了实现用户需求所需的具体功能、行为、性能等要求。 软件需求通常包括功能需求和非功能需求，并且具有一定的技术性，明确了软件系统的设计、架构、接口、数据流等细节。

• 软件需求是 “如何实现用户需求” 的描述，是开发团队用来构建和验证软件的基础。

3. 两种需求 对比

我们从多种角度进行对比，总结出下表：

显然，用户的需求不能直接作为开发和测试的依据。针对用户的需求，产品经理需要进行需求分析（技术可行性、市场可行性、成本投⼊和收益占比等）后才可转变为软件需求。

二、开发模型

模型 是什么？

• 参考上图，随着软件工程的发展，软件工作的范围不仅仅局限在程序编写，其扩展到了整个软件生命周期，如软件基本概念的形成、需求分析、设计、实现、测试、安装部署、运行维护，直到软件被更新 / 替换新版本。

• 软件工程还包括很多技术性的管理⼯作，例如过程管理、产品管理、资源管理和质量管理，在这些方面也逐步地建立起了标准 / 规范。

三、常见的开发模型

瀑布模型

瀑布模型（Waterfall Model）是软件开发中的一种传统方法，属于线性顺序开发模型。

它是一种按阶段顺序推进的开发方式，阶段之间有明确的界限，每个阶段的输出作为下一个阶段的输入，像瀑布一样逐步向下流动。瀑布模型强调的是在开发的早期就进行详细的需求分析和设计，避免后期频繁修改。

瀑布模型在软件工程中占有重要地位，是其他模型的基础框架。

瀑布模型的优缺点：

瀑布模型一般适用于：需求固定的较小的项目

螺旋模型

螺旋模型（Spiral Model）是一种结合了原型模型和瀑布模型的优点的过程模型，适用于复杂、长期的大型软件开发项目。

螺旋模型强调项目通过反复迭代（螺旋式上升）来进行开发，每个周期（即螺旋的每一圈）都涉及风险评估、原型设计和反馈。

螺旋模型的基本过程：
每一圈螺旋模型的过程都包括以下四个基本阶段：

1. 规划阶段：确定目标、需求、约束和可能的解决方案。
2. 风险评估和分析：识别项目中可能出现的风险，并评估其影响，采取缓解措施。
3. 工程实施和开发：根据需求进行开发和构建原型，或者编写代码。
4. 客户评估和反馈：客户评估原型，提出改进意见，为下一周期提供反馈。

螺旋模型的优缺点：

螺旋模型适用于：

• 需求不明确、容易变化的复杂项目。
• 高风险、高不确定性的项目。
• 对项目结果有较高期望、需要持续客户反馈的大型软件系统。

增量模型 & 迭代模型

增量模型是一种将系统分解为多个较小的、独立的增量（模块）进行开发的模型。每个增量都是系统的一部分，逐步构建和完善，最终完成整个系统的开发。

增量模型一般适用于需求较为明确、可模块化的大型系统。

迭代模型是一种通过多次迭代（即重复开发和改进）逐步开发软件的过程模型。每次迭代都会包括从需求、设计到实现的完整过程，并产生一个新的可用版本，逐步改进并最终实现完整的系统。

迭代模型一般适用于需求不完全明确、变化频繁的项目。

敏捷模型

敏捷模型（Agile Model）是一种基于迭代和增量的软件开发方法论，强调快速交付、持续改进和与客户的紧密合作。

• 敏捷开发方法倡导灵活应变、快速反馈和透明的沟通，尤其适用于需求不确定或变化频繁的项目。
• 敏捷开发通常通过短周期（称为“迭代”或“冲刺”）来完成开发，能够在每个周期内交付一个可用的、经过测试的软件版本。

且敏捷模型中有一个很重要的《敏捷宣言》：

• 个体与交互重于过程和工具
• 可用的软件重于完备的文档
• 客户协作重于合同谈判
• 响应变化重于遵循计划

通过这个敏捷宣言，我们可以得出敏捷开发的特点：

轻文档，轻流程，重目标，重产出

敏捷模型中有一些常见的 开发方法 / 框架，这里我们以Scrum 为例，其他的方法放在附录部分：

• Scrum 是最流行的敏捷框架之一，也称为迭代式增量软件开发模型。
• Scrum 有三个角色与五个重要的会议：

三个角色

1. 产品负责人（Product Owner）
   • 主要职责：确保团队的工作与产品的业务目标和价值对齐。管理产品待办列表（Product Backlog），明确和优先排序需求。
2. 项目经理（Scrum Master）
   • 主要职责：确保Scrum框架的有效执行，帮助团队消除障碍，促进团队自组织。
3. 开发团队（Development Team）
   • 主要职责：实现产品待办列表中的项，交付增量成果。开发团队通常由跨职能成员组成，具备完成工作的所有技能。

五个会议

1. 冲刺规划会议（Sprint Planning）

   • 目的：为即将到来的冲刺（通常为2-4周）定义目标和计划。
   • 内容：
     • 产品负责人介绍待办事项。
     • 团队讨论并选择要在本冲刺中完成的任务。
     • 设定冲刺目标，明确哪些任务能在本次冲刺内完成。
   • 参与者：产品负责人、Scrum Master、开发团队。

2. 每日站会（Daily Scrum）

   • 目的：团队成员分享进展，识别问题和障碍，确保整个团队在正确的方向上。
   • 内容：
     • 每个团队成员回答三个问题：昨天做了什么？今天做什么？遇到什么问题？
     • 会议时间通常是15分钟。
   • 参与者：开发团队，Scrum Master（产品负责人可选）。

3. 冲刺评审会议（Sprint Review）

   • 目的：展示本次冲刺的成果，获取利益相关者的反馈。
   • 内容：
     • 展示完成的功能或增量，产品负责人和开发团队对比目标和实际完成的工作。
     • 听取利益相关者的反馈，以便调整后续工作。
   • 参与者：产品负责人、开发团队、Scrum Master、利益相关者。

4. 冲刺回顾会议（Sprint Retrospective）

   • 目的：反思团队的工作过程，识别改进空间，持续优化工作方式。
   • 内容：
     • 团队讨论哪些方面做得好，哪些地方可以改进。
     • 制定改进计划，找出具体的行动项。
   • 参与者：产品负责人、Scrum Master、开发团队。

5. 冲刺（Sprint）

   • 虽然“冲刺”本身不是一个会议，但它是Scrum框架的一个重要元素。冲刺是一个固定时长的工作周期（通常为2-4周），团队在此期间完成一部分可交付的增量成果。
   • 目的：在固定时间内交付一个可用的、经过验证的增量版本的产品。

敏捷开发中的测试

• 轻文档：敏捷模型强调轻量级的文档，避免过多的文档编写工作。测试人员通常不使用传统的Excel表格来编写测试用例，而是采用更灵活和高效的方式。

• 思维导图：测试人员可以使用思维导图来帮助理清测试思路、设计测试场景、识别潜在的测试路径等，适应快速变化的需求和产品功能。

• 探索性测试：

  • 强调自由度，设计和执行测试同时进行。
  • 测试人员根据执行过程中的发现和反馈，动态调整测试计划，灵活应对需求变化和产品迭代。

• 自动化测试：在敏捷环境中，自动化测试被广泛应用于持续集成和持续交付的流程中，以确保高效、快速地验证产品质量。

• 强调合作：敏捷开发强调团队成员之间的紧密合作。

  • 测试人员应主动与开发人员沟通，了解需求、参与设计讨论，共同确定测试策略和方案。
  • 测试人员还应与开发人员一起分析Bug的根本原因，以便更好地优化产品和开发流程。

测试模型

测试模型中有两个重要且标志性的测试模型：V模型 和 W模型

V 模型

V模型 是 “验证与确认模型”（Verification and Validation Model）的简称，它强调开发阶段与测试阶段的紧密联系。在V模型中，开发和测试活动是并行进行的，且开发阶段和测试阶段一一对应。

特点:

• 严格的阶段性：每个开发阶段都必须完成后，才会进入下一个阶段。
• 早期的验证：通过在开发阶段同步规划和进行相应的测试，确保问题能早期被发现和解决。
• 线性流程：V模型的执行遵循线性步骤，开发和测试的活动基本上是顺序进行的。

优缺点：

• 优点：

  • 通过与开发阶段同步进行的测试活动，测试人员可以及时发现缺陷。
  • 每个阶段都定义了明确的目标和测试标准，能够确保项目按计划执行。

• 缺点：

  • 难以适应需求变更：V模型偏向于瀑布式开发，一旦进入某一阶段，变更就变得困难。
  • 过于严格的流程限制了灵活性，可能会导致开发周期过长。

W模型

W模型 是对V模型的一种扩展，它更加关注于开发和测试活动的交互性。W模型强调在开发和测试的每个阶段，不仅要进行传统的验证和确认，还要注重文档和测试的双向流动。

在W模型中，开发和测试活动呈现出一个“W”字形的结构，既有开发活动的两端，也有测试活动的双向贯穿。

特点:

1. 双向关系：开发与测试之间持续沟通，确保需求和设计的准确性。
2. 注重文档：每个阶段都有文档支持，确保信息透明和一致。
3. 并行活动：开发和测试并行进行，测试人员早期参与，确保需求可测试。
4. 适应性强：比V模型更灵活，能应对需求和设计变更。
5. 紧密协作：测试人员早期与开发团队合作，共同设计和验证测试用例。

优缺点:

• 优点：

  • 测试与开发更加紧密合作，提前发现并解决问题。
  • 可以在项目的任何阶段进行测试，反馈机制更加灵活。
  • 适应需求变化的能力较强，具有更好的灵活性。

• 缺点：

  • 需要更高程度的协作和沟通，可能导致沟通成本较高。
  • 对团队成员的技能要求较高，需要开发和测试人员有更好的协作能力。

附录

敏捷模型 常见开发方法 / 框架