软件测试 ——概念篇（2）

需求的概念

用户需求和软件需求

简单来说用户需求是用户自身表达的需求，这类需求可能很抽象，不易理解（比如什么五彩斑斓的黑），而软件需求是对用户需求进行分析之后，可以落地执行的需求。

用户需求和软件需求是软件开发过程中两个重要的概念，它们分别代表了不同的层次和视角的需求描述。理解这两者之间的区别对于确保最终产品既满足用户的期望又能有效实现至关重要。

1. 用户需求 (User Requirements)

定义

用户需求是从最终用户的角度出发，描述他们希望从软件系统中获得的价值或解决的问题。这些需求通常较为抽象，关注的是“为什么”需要这个系统以及它应该为用户提供什么样的体验或功能。

特点

• 业务目标导向：强调系统的业务价值和用户目标。
• 高层次描述：不涉及具体的技术实现细节，而是表达用户的目标、愿望和限制条件。
• 非技术性语言：使用自然语言或图形化方式（如用例图、故事板）来描述，易于被非技术人员理解。
• 动态变化：随着市场环境、用户反馈和技术进步而可能发生变化。

示例

• 用户希望能够通过手机应用快速预订餐厅座位。
• 用户要求在线购物网站提供个性化推荐服务。
• 用户希望视频会议软件具备屏幕共享功能以提高沟通效率。

2. 软件需求 (Software Requirements)

定义

软件需求是对用户需求的具体化和技术化，明确了如何在软件系统中实现这些需求。它们详细规定了系统的功能特性、性能指标、接口规范等，为开发团队提供了明确的指导。

特点

• 技术实现导向：侧重于“如何”实现用户需求，包括具体的算法、数据结构、API设计等。
• 详细具体：包含详细的规格说明，如输入输出格式、处理逻辑、错误处理机制等。
• 形式化语言：常使用正式文档（如SRS - Software Requirements Specification）、UML图、伪代码等形式来表达。
• 稳定固定：相对静态，一旦确定下来就尽量保持不变，除非经过严格的变更管理流程。

示例

• 系统应支持iOS和Android平台上的移动应用程序，允许用户通过GPS定位查找附近的餐厅，并显示可用时间表进行预订。
• 在线购物网站需集成机器学习算法分析用户浏览历史和购买行为，生成个性化的商品推荐列表，刷新频率不超过5分钟。
• 视频会议软件必须支持至少4K分辨率的屏幕共享，延迟不超过200毫秒，同时兼容主流浏览器和桌面操作系统。

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

软件的生命周期

软件的生命周期简单来说就一句话：需求分析⸺计划⸺设计⸺编码⸺测试⸺运行维护

我们可以用建房子的过程来了解这个过程

步骤	建房过程	软件开发流程
为什么（目标）	为什么要建房子？商品房还是普通住宅？建造100层技术上是否可行？	明确合理的开发目标：需求分析，确定项目类型和技术可行性
什么时候（计划）	什么时候开发建房子？计划竣工时间？多久可以交房？	计划好时间：制定详细的项目计划和时间表
如何（设计）	建房前明确流程：先打地基，做基础框架，砌墙、粉刷、水电工程等	设计好具体的开发流程：系统架构设计、数据库设计、UI/UX设计
实施（编码）	按照前面的流程和时间实施建房中…	编码：按照设计文档编写代码，实现功能模块
检查（测试）	房屋建造完成，开发商验收成果、买家验收房子品质（房子是否牢固，是否漏水等）	测试：进行单元测试、集成测试、系统测试、用户验收测试
使用与维护	检查结束开始逐步入住，使用中出现了各种情况如房屋漏水等问题，一边使用一边找物业修理	运行维护：部署产品，监控性能，修复bug，根据用户反馈改进

每个阶段干了什么事呢？

阶段	具体内容	产出
需求分析	分析用户需求是否合理，分别从市场需求、技术等方面进行分析。 确定项目的业务目标，明确系统需要解决的问题。 与利益相关者沟通，收集并整理需求。 评估需求的可行性，确保技术和资源上可实现。	需求规格说明书（SRS）、用例图、需求优先级列表等文档
计划	对成立的需求执行详细的项目计划。 定义项目的时间表，包括开始日期、里程碑和预计完成日期。 分配资源，明确团队成员的角色和责任。 规划每个时间段内需完成的具体功能或任务。	项目计划书、甘特图、任务分配表等文档
设计	将需求细化成一个个具体的任务，团队成员各司其职领取任务并进行技术设计。 确定系统的架构设计，包括数据库设计、接口设计、模块划分等。 选择合适的技术栈和工具。 制定详细的设计规范和技术标准。	系统设计文档、架构图、接口文档、数据库模型等
编码	开发人员参考需求文档、设计文档、交互图等文件进行代码编写。 遵循编码规范，确保代码的可读性和可维护性。 实现系统功能，集成第三方库或API。 进行单元测试，确保每个组件正常工作。	源代码文件、版本控制系统记录、代码审查报告等
测试	测试人员介入到软件的测试中来，参考测试用例对软件进行全面测试。 执行单元测试、集成测试、系统测试、验收测试等不同层次的测试。 记录并跟踪缺陷，确保所有问题得到妥善处理。 编写详细的测试报告。	测试用例、测试计划、测试结果报告、缺陷跟踪表等
运行维护	项目测试结束之后，项目需要进行上线，并对产品进行线上的维护。 主要分为三个方面： - 修复性维护：对项目中未发现的问题进行修复。 - 完善性维护：对功能进行优化和完善。 - 预防性维护：采取措施避免潜在问题的发生。	上线部署文档、维护日志、故障报告、性能监控数据等

开发模型

瀑布模型

瀑布模型和软件生命周期是一样的：start -> 需求分析 -> 计划 -> 设计 -> 编码 -> 测试 -> 运行维护

优点/特点	缺点
强调开发的阶段性 每个阶段有明确的目标和产出，便于管理和跟踪进度。	测试后置 前面各阶段遗留的风险推迟到测试阶段才被发现，导致项目大面积返工，失去了及早修复的机会。 必须留有足够的给测试活动时间，否则导致测试不充分，将缺陷直接暴露给用户（产品质量差）。
线性结构，每个阶段只执行一次 流程清晰，易于理解和遵循，适合初学者或小型团队。	周期太长 产品很迟才能被看到和使用，可能会导致需求/功能过时，无法快速响应市场变化。 长时间的开发周期可能导致客户失去耐心或兴趣。
是其他模型的基础框架 为后续更复杂的开发模型提供了基础，许多现代方法论都借鉴了瀑布模型的某些元素。

瀑布模型适用的范围：需求固定小的项目

螺旋模型

如果项目的规模过大，风险大，就比较适合用螺旋模型：

优点	缺点
强调严格的全过程风险管理 在每个阶段都进行风险评估和管理，确保项目按计划推进，减少不确定性。	项目中可能存在的风险性与风险管理人员的技能水平有直接关系 如果风险管理人员的经验不足，可能导致风险评估不准确或管理不当。
强调各开发阶段的质量 每个阶段都注重质量控制，确保交付的产品符合高标准，提高用户满意度。	需求人员、资金、时间的增加和投入，可能会导致项目的成本太高 额外的风险分析和原型制作需要更多资源，增加了项目的总体成本。
增加风险分析和原型 通过构建原型和早期用户反馈，可以更早地识别和解决问题，降低后期返工的可能性。

适用场景：规模庞打、复杂度高、风险大的项目。

增量模型和迭代模型

增量模型：一次给出一个完整的小功能，小功能逐步完善，完成整体的功能
迭代模型：先给出整体功能的初级版，然后逐步修复完善，直到最后完整功能的发布

对比项	增量模型 (Incremental Model)	迭代模型 (Iterative Model)
定义	将项目分解为多个增量部分，每个部分独立开发并在完成后集成到整体中。	通过多次迭代逐步完善系统，每次迭代都包含完整的开发周期：计划、分析、设计、实现、测试。
开发过程	每个增量都是一个小的瀑布模型，完成一个增量后交付一部分功能给用户。	每次迭代都会产生一个可工作的版本，逐步增加和完善系统的功能。
需求处理	需求在早期明确，后续增量基于初始需求逐步实现。	需求可以在迭代过程中不断调整和细化，允许更灵活地响应变化。
风险处理	早期识别关键需求并优先开发，降低后期重大变更的风险。	每次迭代都进行风险评估，逐步解决高优先级问题，确保项目的稳定推进。
用户反馈	用户可以在每次增量完成后提供反馈，但主要集中在功能完整性上。	用户可以在每次迭代后提供详细的反馈，影响后续迭代的内容和优先级。
灵活性	相对固定，需求变更需要重新规划增量。	高度灵活，可以快速响应需求变化和用户反馈。
适合场景	需求明确且稳定的项目，如政府项目或大型企业应用，资源有限但希望分阶段交付产品的项目。	需求不确定或经常变化的项目，如互联网应用、移动应用等，以及需要频繁发布更新的项目。
优点	- 可以逐步交付功能，降低一次性失败的风险。 - 用户可以更早地看到产品，提出改进建议。 - 减少初期规划的压力。	- 灵活适应需求变化。 - 早期可见成果，快速获得用户反馈。 - 提高产品质量和客户满意度。 - 有效管理风险。
缺点	- 后期集成可能会遇到困难。 - 如果初期规划不当，可能导致返工。 - 对需求变更的支持较弱。	- 文档可能不够详尽。 - 对团队技能要求较高。 - 初期看不到完整的产品形态，可能导致用户不满意。
示例	开发一个办公自动化系统，先实现文档管理模块，再逐步添加邮件系统、日程安排等功能。	开发一款社交应用，第一版只包括用户注册和登录功能，后续迭代逐步加入消息发送、好友列表、动态发布等功能。

适用场景：大型项目，需求不明确

敏捷模型

敏捷模型（Agile Model）是一种强调灵活性、快速响应变化和持续交付价值的软件开发方法论。它鼓励团队与客户之间的紧密合作，通过短周期的迭代（通常称为Sprint，一般为2-4周）来逐步构建软件产品。以下是关于敏捷模型的详细介绍，包括其特点、流程、优点和缺点，并以Markdown表格的形式总结。

敏捷模型概述

敏捷宣言：敏捷开发基于《敏捷软件开发宣言》，该宣言提出了四大价值观和十二项原则，强调个体和互动、可工作的软件、客户协作以及响应变化的重要性。

主要框架：

• Scrum：最流行的敏捷框架之一，定义了角色（如Scrum Master、Product Owner、开发团队）、事件（如Sprint、Daily Scrum、Sprint Review、Sprint Retrospective）和工件（如Product Backlog、Sprint Backlog）。
• Kanban：一种可视化工作流管理方法，专注于限制在制品（WIP）数量，优化流程效率。
• Extreme Programming (XP)：强调技术实践，如持续集成、测试驱动开发（TDD）、结对编程等。

敏捷模型的特点

1. 用户故事（User Stories）：将需求表示为简短的叙述，描述用户的行为或期望的结果，便于理解和优先级排序。
2. 迭代开发（Iterative Development）：通过短周期的迭代（Sprints），每个迭代都包含完整的开发周期，从计划到部署。
3. 持续反馈（Continuous Feedback）：频繁地与客户和其他利益相关者沟通，确保产品始终符合用户的期望。
4. 适应性规划（Adaptive Planning）：允许根据最新的信息和反馈调整项目计划，灵活应对变化。
5. 自组织团队（Self-organizing Teams）：赋予团队成员更多的自主权，鼓励他们共同决定如何最好地完成任务。
6. 每日站会（Daily Stand-ups）：每天举行简短会议，团队成员汇报进展、遇到的问题及当天计划。
7. 回顾会议（Retrospectives）：在每个迭代结束时进行反思，讨论哪些做得好、哪些需要改进，从而不断优化流程。

敏捷模型的优点

• 提高客户满意度：通过频繁交付可用的产品增量，客户可以更早地看到成果并提供反馈。
• 增强团队协作：促进跨职能团队间的紧密合作，减少沟通障碍。
• 快速响应变化：能够迅速适应需求的变化，降低变更带来的风险。
• 高质量的产品：强调持续集成和测试，确保每次迭代都能产生高质量的代码。
• 透明度高：所有参与者都能清楚了解项目的进展和状态，便于及时调整策略。

敏捷模型的缺点

• 文档不足：由于注重快速迭代，可能导致文档不够详尽，影响长期维护。
• 对团队要求高：需要具备高度自律和专业技能的团队成员，否则难以有效运作。
• 初期规划较难：对于大型复杂项目，难以在早期做出详细的长期规划。
• 依赖客户参与：如果客户不能积极参与或提供明确指导，可能会影响项目的顺利进行。

敏捷模型的适用场景

• 需求不明确或经常变化的项目：如互联网应用、移动应用等，这些领域的需求和技术发展迅速，需要灵活的开发方法。
• 小型团队或初创企业：这类组织通常资源有限但反应迅速，适合采用敏捷方法快速验证想法并推向市场。
• 需要频繁发布更新的项目：例如SaaS（Software as a Service）产品，定期推出新功能或修复bug是常态。

对比项	敏捷模型 (Agile Model)
定义	强调灵活性、快速响应变化和持续交付价值，通过短周期迭代逐步构建软件产品。
开发过程	每个迭代（Sprint）都包含完整的开发周期：计划、分析、设计、实现、测试和部署。
需求处理	需求可以在迭代过程中不断调整和细化，允许更灵活地响应变化。
风险处理	每次迭代都进行风险评估，逐步解决高优先级问题，确保项目的稳定推进。
用户反馈	用户可以在每次迭代后提供详细的反馈，影响后续迭代的内容和优先级。
灵活性	高度灵活，可以快速响应需求变化和用户反馈。
适合场景	需求不确定或经常变化的项目，如互联网应用、移动应用等；需要频繁发布更新的项目；小型团队或初创企业。
优点	- 提高客户满意度。 - 增强团队协作。 - 快速响应变化。 - 高质量的产品。 - 透明度高。
缺点	- 文档不足。 - 对团队要求高。 - 初期规划较难。 - 依赖客户参与。
示例	开发一款社交应用，第一版只包括用户注册和登录功能，后续迭代逐步加入消息发送、好友列表、动态发布等功能。

解释

1. 定义：敏捷模型强调灵活性、快速响应变化和持续交付价值，通过短周期迭代逐步构建软件产品。
2. 开发过程：每个迭代（Sprint）都包含完整的开发周期，从计划到部署，确保每次迭代都能产生可用的产品增量。
3. 需求处理：需求可以在迭代过程中不断调整和细化，更加灵活地响应变化。
4. 风险处理：每次迭代都进行风险评估，逐步解决高优先级问题，确保项目的稳定推进。
5. 用户反馈：用户可以在每次迭代后提供详细的反馈，影响后续迭代的内容和优先级。
6. 灵活性：高度灵活，能够快速响应需求变化和用户反馈。
7. 适合场景：适用于需求不确定或经常变化的项目，如互联网应用、移动应用等；需要频繁发布更新的项目；小型团队或初创企业。
8. 优点与缺点：表格中详细列出了敏捷模型的优点和缺点，帮助理解其适用性和局限性。
9. 示例：提供了具体的例子来说明如何在实际项目中应用敏捷模型。

这个表格不仅总结了敏捷模型的主要特点，还突出了它的优缺点和适用场景，帮助团队更好地选择最适合其项目的开发方法。

Scrum模型（迭代式增量软件开发模型）

在scrum模型中，主要有三个角色和五个重要会议。

三个角色：

角色	职责
Product Owner (产品经理)	- 整理用户故事（User Story）：收集和编写用户故事，确保它们清晰、可理解和可测试。 - 定义商业价值：为每个用户故事赋予明确的商业价值，确保团队了解其重要性。 - 排序优先级：根据业务需求和技术可行性对用户故事进行优先级排序。 - 制定发布计划：规划产品的发布版本，确定每次迭代的目标。 - 对产品负责：作为产品的唯一责任人，确保最终产品满足市场需求和用户期望。
Scrum Master (项目经理)	- 召开各种会议：组织并主持Sprint Planning、Daily Scrum、Sprint Review和Sprint Retrospective等会议。 - 协调项目：移除团队遇到的障碍，确保Scrum流程被正确理解和实施。 - 服务研发团队：帮助团队解决外部干扰，促进团队内部及与其他部门之间的沟通与协作。 - 培训和支持：提供必要的培训和支持，确保团队成员掌握Scrum方法论。
Development Team (研发团队)	- 不同技能的成员组成：团队由具备多种技能的成员构成，如开发人员、测试人员、设计师等，确保能够独立完成所有任务。 - 紧密协同工作：通过每日站会和其他协作机制，保持高效的沟通和协作。 - 完成迭代目标：在每个Sprint中实现预定的工作项，并交付可用的产品增量。 - 自我管理：团队自主决定如何最好地完成工作，提高效率和责任感。

迭代开发

与瀑布不同，scrum将产品的开发分解为若干个小sprint(迭代)，其周期从1周到4周不等，但不会超过4周。参与的团队成员⼀般是5到9人。每期迭代要完成的user story是固定的。每次迭代会产生⼀定的交付。

活动	描述	参与者	产出
整理用户故事	产品负责人（Product Owner）负责收集和编写用户故事（User Story），确保它们清晰、可理解和可测试，并形成左侧的产品待办事项列表（Product Backlog）。	Product Owner	Product Backlog
发布计划会议	Product Owner向团队讲解用户故事，对其进行估算和优先级排序，确定本期迭代要完成的故事列表（Sprint Backlog）。发布计划会议的目的是为即将开始的Sprint制定明确的目标和范围。	Product Owner, Development Team	Sprint Backlog
迭代计划会议	项目团队对每个选定的用户故事进行任务分解，确保完成该故事所需的所有任务都被明确列出。每个任务都有明确的负责人，并初步估计工时，确保团队对工作量有清晰的认识。	Scrum Master, Development Team	Sprint Backlog (细化的任务列表)
每日例会	每天由Scrum Master召集站会（Daily Scrum），团队成员简短汇报昨天完成了什么、今天计划做什么以及遇到的问题。这个会议旨在提高沟通效率，及时发现并解决问题。	Scrum Master, Development Team	团队同步进展，问题记录
演示会议	在每次迭代结束之后，召开演示会议（Sprint Review），邀请相关利益相关者参加，团队展示本次迭代取得的成果。期间收集的反馈由Product Owner整理，形成新的用户故事或更新现有故事。	Product Owner, Scrum Master, Development Team, 利益相关者	用户反馈，更新后的Product Backlog
回顾会议	项目团队对本期迭代进行总结，反思哪些做得好、哪些需要改进，并制定具体的改进措施，以达到持续改进的效果。回顾会议强调团队内部的学习和成长。	Scrum Master, Development Team	改进计划，应用于下一次迭代

测试模型

V模型

V模型最早是由Paul Rook在20世纪80年代后期提出的，⽬的是改进软件开发的效率和效果。是瀑布模型的变种 。

优点： 明确的标注了测试过程中存在的不同类型的测试，并且清楚的描述了这些测试阶段和开发过程期间
各阶段的对应关系，有效提升测试的质量和效率。
V模型指出：

• 单元和集成测试应检测程序的执行是否满足软件设计的要求；
• 系统测试应检测系统功能、性能的质量特性是否达到系统要求的指标；
• 验收测试确定软件的实现是否满足需要或合同的要求

缺点：仅仅把测试作为在编码之后的⼀个阶段，未在需求阶段就介⼊测试。缺点同瀑布模型

W模型（双V模型）

W模型增加了软件各开发阶段中应同步进⾏的验证和确认活动。W模型由两个V字型模型组成，分别代表测试与开发过程，图中明确表⽰出了测试与开发的并⾏关系。

特点：测试的对象不仅是程序，需求、设计等同样要测试，测试与开发是同步进⾏的

优点：

• 有利于尽早地全⾯的发现问题。例如，需求分析完成后，测试⼈员就应该参与到对需求的验证和确认活动中，以尽早地找出缺陷所在。
• 同时，对需求的测试也有利于及时了解项⽬难度和测试⻛险，及早制定应对措施，显著减少总体测试时间，加快项目标进度。

缺点：

• 需求、设计、编码等活动被视为串行的；
• 测试和开发活动也保持着⼀种线性的前后关系，上⼀阶段完全结束，才可正式开始下⼀个阶段工作。
• 重流程，⽆法⽀持敏捷开发模式。对于当前软件开发复杂多变的情况，W模型并不能解除测试管理⾯临着困惑。