当前位置：首页 > news >正文

【测试理论和实践 2.测试概念】

news 2025/10/28 9:13:36

5斤的棉花和5斤的铁一样重，
幸福和痛苦拥有同样的重量。
—— 25.10.26

一、什么是需求

在多数软件公司，会有两部分需求，一部分是用户需求，一部分是软件需求。

1.用户需求

用户需求：可以简单理解为甲方提出的需求，如果没有甲方，那么就是终端用户使用产品时必须要完成的任务。该需求一般比较简略，通常是一句话。

2.软件需求

软件需求：或者叫功能需求，该需求会详细描述开发人员必须实现的软件功能。软件需求是测试人员进行测试工作的基本依据。

测试的概念：验证软件的特性是否满足用户的需求，软件测试人员主要的工作职责是保障产品的测试质量，但是软件的质量并不是只由测试人员来保障；而是由项目组（产品经理、前端开发、后端开发、测试、交互、设计、……）所有成员都需要为产品质量负责。测试贯穿于软件的整个生命周期。

3.软件需求规格说明书

Ⅰ、用户需求

平台支持邮箱注册

Ⅱ、软件需求

软件需求规格说明书

项目名称： [请填写您的平台名称]
功能模块：用户注册模块 - 邮箱注册子模块
文档版本：V1.0
日期：2023年10月27日
1. 引言
1.1 目的
本文档旨在定义[请填写您的平台名称]平台“邮箱注册”功能模块的详细软件需求。本文档的预期读者包括项目经理、产品经理、UI/UX设计师、软件开发工程师、测试工程师以及项目相关方。
1.2 项目范围
本项目将在平台用户注册体系中，新增一个通过电子邮箱地址进行账号注册、验证并完成账号创建的功能流程。此功能是平台获取新用户的主要渠道之一。
1.3 定义、首字母缩略词和缩写
SRD：软件需求规格说明书
UI：用户界面
API：应用程序编程接口
验证码：用于验证用户对邮箱控制权的一次性密码或链接。
2. 总体描述
2.1 产品前景
邮箱注册作为互联网产品的标准配置，旨在为用户提供一个便捷、安全、通用的账号创建方式，降低用户注册门槛，提升用户转化率。
2.2 用户特征
新用户：尚未拥有平台账号的互联网用户，具备基本的电子邮箱使用能力。
系统管理员：负责监控注册数据和处理注册相关异常。
2.3 假设与依赖
假设：用户拥有一个有效且可正常接收邮件的电子邮箱。
依赖：
平台需要集成一个稳定可靠的第三方邮件发送服务（如SendGrid, Amazon SES，或自建SMTP服务器）。
平台后端用户数据库和身份认证系统已就绪。
3. 系统特性：邮箱注册功能
3.1 特性描述
本特性允许用户使用其电子邮箱地址作为用户名，通过接收邮件验证码或链接的方式，完成身份验证并设置密码，最终成功创建平台账号。
3.2 功能需求
3.2.1 注册入口与界面 (REQ-01)
需求ID：REQ-01
需求描述：平台应在登录页面提供明显的“邮箱注册”入口（如按钮或链接）。
优先级：高
3.2.2 邮箱地址输入与校验 (REQ-02)
需求ID：REQ-02
需求描述：系统应提供一个输入框供用户输入邮箱地址。
补充规格：
系统需对输入的邮箱格式进行**前端实时校验**（如：包含"@"符号，有合法的域名部分）。
格式不正确时，应实时提示用户“邮箱格式不正确”。
用户点击“发送验证码”后，系统需进行**后端校验**，检查该邮箱是否已被注册。
若邮箱已被注册，应明确提示用户“该邮箱已被占用，请直接登录或使用其他邮箱”。
优先级：高
3.2.3 发送邮箱验证码 (REQ-03)
需求ID：REQ-03
需求描述：用户输入合法且未被占用的邮箱后，点击“发送验证码”按钮，系统应向该邮箱发送一封包含验证码的邮件。
补充规格：
按钮点击后，应有**冷却机制**（如：60秒内不可再次点击），并显示倒计时。
邮件内容应清晰、专业，包含平台Logo、验证码数字/字母组合（建议6位）、以及该验证码的有效期限（如10分钟）。
邮件主题应明确，如“[平台名称] - 您的注册验证码”。
优先级：高
3.2.4 验证码输入与校验 (REQ-04)
需求ID：REQ-04
需求描述：系统应提供一个输入框供用户输入收到的验证码。
补充规格：
系统需在后端校验用户输入的验证码是否正确且在有效期内。
验证码错误时，提示“验证码错误，请重新输入”。
验证码过期时，提示“验证码已过期，请重新获取”。
用户有最多5次尝试机会，超过后当前验证码失效，需重新获取。
优先级：高
3.2.5 密码设置 (REQ-05)
需求ID：REQ-05
需求描述：验证码校验通过后，用户需设置登录密码。
补充规格：
密码需输入两次（密码、确认密码）。
系统需强制密码安全策略，例如：长度至少8位，需包含字母和数字。
密码输入时，应以掩码形式显示（如圆点或星号）。
两次输入的密码不一致时，应实时提示。
优先级：高
3.2.6 完成注册 (REQ-06)
需求ID：REQ-06
需求描述：用户点击“注册”或“完成”按钮后，系统应创建新用户账号。
补充规格：
系统应将邮箱、加密后的密码存入用户数据库，并将账号状态标记为“已激活”。
注册成功后，应清晰提示用户“注册成功”，并**自动跳转至用户登录页面或个人中心**。
优先级：高
3.2.7 用户体验与交互 (REQ-07)
需求ID：REQ-07
需求描述：整个注册流程应流畅，并提供必要的用户引导和反馈。
补充规格：
每个步骤应有明确的加载状态提示（如：正在发送...）。
网络异常或系统错误时，应有友好的错误提示，并告知用户如何解决。
提供返回上一步的选项。
优先级：中
4. 非功能性需求
4.1 性能需求
邮箱验证码应在用户请求后的 5秒内发出。
注册接口的平均响应时间应小于 2秒。
系统应能支持每分钟1000次的注册请求并发。
4.2 安全性需求
用户密码必须在传输和存储过程中进行强加密（如使用bcrypt, Argon2等哈希算法）。
验证码必须在服务器端生成，并具备有效期，防止暴力破解。
必须对发送验证码的请求频率进行限制，防止恶意刷邮箱（如：同一IP/邮箱地址每小时最多发送5次）。
通信必须使用HTTPS协议，保证数据传输安全。
4.3 可用性需求
注册流程应在 3分钟内完成。
界面设计应简洁明了，符合无障碍设计基础标准。
提示信息应清晰、友好，避免使用技术术语。
4.4 可靠性需求
注册功能的系统可用性应达到 99.9%。
邮件服务出现临时故障时，系统应有重试机制和降级方案（如提示用户“邮件服务暂时不可用，请稍后重试”）。
5. 其他需求
5.1 数据需求
用户表需新增字段：
`email` (VARCHAR, 唯一索引)
`password_hash` (VARCHAR)
`email_verified` (BOOLEAN, 注册成功后默认为True)
`created_at` (DATETIME)
5.2 接口需求
需要与第三方邮件服务商API进行集成，以发送邮件。
文档批准：
角色姓名签字日期
产品经理
开发经理
测试经理
注意：用户的需求不能直接作为开发和测试的依据。针对用户的需求，产品经理需要进行需求分析（技术可行性、市场可行性、成本投入和收益占比等）后才可转变为软件需求。

二、软件生命周期

需求分析 ——> 计划 ——> 设计 ——> 编码 ——> 测试 ——> 运行维护

需求分析：分析用户需求是否合理，分别从市场需求、技术等方面进行分析，该阶段会输出需求等文档。

计划：对成立的需求执行需求执行计划，多长时间内完成该需求，每段时间具体完成哪些功能，该阶段会输出计划等文档。

设计：将需求细化成一个个任务，团队成员各司其职领取任务并进行技术设计（如何进行架构设计，设计哪些接口、采用什么技术），该阶段会输出技术等文档。

编码：开发人员参考需求文档、设计文档、交互图等等文件进行代码的编写。产出代码文件等文档。

测试：测试人员需要介入到软件的测试中来，参考测试用例对软件进行测试。产出测试用例、测试设计与计划、测试报告等文档。

运行维护：项目测试结束之后，项目需要进行上线，并对产品进行线上的维护。线上的维护主要分为三个方面。分别为修复性维护、完善性维护和预防性维护。

修复性维护：对项目中未发现的问题进行修复。

完善性维护：对功能进行完善。

预防性维护：居安思危，为了避免产品在线上出现一些其他不可预料的问题，进行一些防护的手段。

三、开发模型

1.瀑布模型

start ——> 需求分析 ——> 计划 ——> 设计 ——> 编码 ——> 测试 ——> End

瀑布模型在软件工程中占有重要地位，是所有其他模型的基础框架。瀑布模型的每一个阶段都只执行一次，因此是线性顺序进行的软件开发模式。

瀑布模型的一个最大缺陷在于，可以运行的产品很迟才能被看到。这会给项目带来很大的风险，尤其是集成的风险。因为如果在需求引入的一个缺陷要到测试阶段甚至更后的阶段才发现，通常会导致前面阶段的工作大面积返工，业界流行的说法是：“集成之日就是爆炸之日”。尽管瀑布模型存在很大的缺陷，例如，在前期阶段未发现的错误会传递并扩散到后面的阶段，而在后面阶段发现这些错误时，可能已经很难回头再修正，从而导致项目的失败。但是目前很多软件企业还是沿用了瀑布模型的线性思想，在这个基础上做出自己的修改。例如细化了各个阶段，在某些重点关注的阶段之间掺入迭代的思想。在瀑布模型中，测试阶段处于软件实现后，这意味着必须在代码完成后有足够的时间预留给测试活动，否则将导致测试不充分，从而把缺陷直接遗留给用户。

优缺点总结

瀑布模型是软件开发中最经典、最线性的生命周期模型。它将项目划分为一系列按顺序执行的阶段，每个阶段的输出作为下一个阶段的输入，如同瀑布一般自上而下流动。

特点	优点	缺点
工作方式	1. 简单易用，易于理解和管理 • 阶段划分清晰，流程简单明了，对技术和管理经验要求较低。 2. 阶段性强，纪律严明 • 要求每个阶段都必须有明确的交付物，并且需要经过严格的评审。这保证了开发过程的规范性和可追溯性。 3. 便于计划和管理 • 在项目初期就设定了明确的时间表和里程碑，便于项目经理进行进度跟踪和资源分配。	1. 缺乏灵活性，难以应对变化 • 一旦进入下一个阶段，再返回上一阶段进行修改的代价非常高，几乎需要“推倒重来”。这使得它难以适应需求频繁变更的项目。
需求处理	4. 需求明确 • 在编码开始之前，需求分析阶段已经完成并冻结。这确保了开发团队有清晰、稳定的目标。	2. 需求变更困难 • 客户在项目后期才能看到可运行的软件，此时提出需求变更，成本（时间、人力、资金）会非常高昂。
风险控制	5. 文档详尽 • 每个阶段都需要生成详细的文档，这有利于知识传承、系统维护和后续版本迭代。	3. 风险滞后，晚期才能看到成果 • 最大的风险（如架构缺陷、需求理解错误）可能直到测试阶段甚至项目后期才暴露出来，导致项目失败的风险大增。
成果与反馈		4. 客户参与度低，反馈周期长 • 客户只有在项目末期才能看到最终产品，无法在过程中提供持续反馈，可能导致成品与客户期望不符。
适用性	6. 适用于需求稳定、明确的项目 • 对于政府项目、军工软件、或需求极其固定且变更受合同严格约束的项目非常有效。	5. 不适用于需求模糊或可能变化的项目 • 在当今快速变化的市场和互联网产品开发中，瀑布模型显得过于僵化，难以适用。

2.螺旋模型

螺旋模型中各个阶段都引入了风险分析 + 原型

优缺点总结

螺旋模型是一种将迭代开发与系统化、受控的瀑布模型相结合，并特别强调风险分析的软件开发过程模型。它由巴里·博姆在1986年提出，其核心在于通过一系列迭代循环（称为“螺旋”），逐步构建和细化系统，每个循环都包含四个象限的活动。

特点	优点	缺点
核心机制	1. 风险驱动，降低项目失败概率 • 这是其最核心的优点。在每个迭代周期开始时都进行正式的风险分析，能够提前识别和化解技术、需求、管理等方面的重大风险，避免项目后期陷入困境。	1. 对风险评估的依赖性极高 • 项目的成功高度依赖于风险评估的准确性和有效性。如果风险识别不当或分析有误，会导致迭代方向错误，造成资源浪费。
需求与变更	2. 灵活性强，能很好地适应变化 • 采用迭代方式，允许在项目后期轻松地融入需求变更。客户和用户可以在早期迭代中看到原型并提出反馈，使最终产品更符合实际需求。	2. 过程复杂，管理成本高 • 每个迭代周期都需要经过四个象限的完整流程，需要大量的文档、评审和会议，导致管理开销巨大，对项目经理的要求非常高。
风险控制	3. 早期可交付和客户反馈 • 在早期迭代中就能产生可工作的原型或部分功能，让客户参与进来并提供持续反馈，增强了客户的信心和对项目的控制感。	3. 成本高，周期可能过长 • 大量的风险分析、原型构建和迭代评审会显著增加项目的总体成本和开发时间。可能不适用于预算紧张或周期紧迫的小型项目。
客户与成果	4. 适用于大型、复杂、高风险项目 • 它是为应对高不确定性项目而设计的，在航空航天、国防、大型系统集成等领域非常成功，这些项目的失败代价极高。	4. 不适合低风险或简单项目 • 对于需求明确、技术成熟、风险很低的小型项目，使用螺旋模型会显得“杀鸡用牛刀”，得不偿失。
适用性	5. 软件可在早期迭代中投入使用 • 重要的功能可以优先在早期迭代中完成并交付使用，从而更快地产生业务价值。	5. 对专业知识要求高 • 要求开发团队，特别是架构师和项目经理，必须具备出色的风险识别和分析能力，否则模型无法有效运作。
技能要求	6. 通过原型降低不确定性 • 构建原型是应对风险和验证需求、技术方案的有效手段，能够直观地暴露问题。	6. 存在“无限迭代”的风险 • 如果没有明确的范围和终止标准（如“当主要风险已解决时”），项目可能会陷入无休止的迭代循环，迟迟无法交付最终产品。

螺旋模型中需要额外的招聘专业风险分析人才，各阶段是否遗留问题完全取决于风险分析人员，与风险分析人员的技术能力直接挂钩。

3.增量模型、迭代模型

Ⅰ、增量模型

增量模型将软件产品划分为一系列相互独立的增量（构件）。每个增量都是一个可交付的、包含特定功能子集的软件产品。开发团队在每个发布周期内，集中完成一个增量，并交付给用户。最终，所有增量组合在一起，形成完整的软件系统。

Ⅱ、迭代模型

迭代模型不追求一开始就交付完整的功能，而是通过一系列重复的循环（称为迭代） 来逐步完善软件。每次迭代都会产生一个可执行的软件版本，但这个版本可能只实现了部分功能，或者所有功能都还比较粗糙。每次迭代的目标是基于上次的成果和新的反馈进行细化、增强和修正。

迭代模型和增量模型现在已经不会单独去使用，而是配合着去使用。

增量模型：像“造汽车”
先造一个能跑的底盘和引擎（第一个增量：基本功能）。
然后加上车身和座位（第二个增量：更舒适了）。
最后安装空调和音响（第三个增量：功能完整且豪华）。
每个阶段都产生一个可用的、功能更加强大的产品版本。
迭代模型：像“画一幅画”
先画一个粗糙的素描稿（第一次迭代：确定布局和主体）。
然后修改构图，并涂上大色块（第二次迭代：色彩和细节更清晰）。
最后深入刻画细节，调整光影（第三次迭代：成为精美的作品）。
每个阶段都在完善同一个产品，使其从粗糙走向成熟。