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

『测试』测试基础

java 2025/5/12 10:22:31

文章目录

- 1. 调试与测试的区别
- 2. 开发过程中的需求
- 3. 开发模型
- - 3.1 软件的生命周期
  - 3.2 瀑布模型
  - - 3.2.1 瀑布模型的特点/缺点
  - 3.3 螺旋模型
  - - 3.3.1 螺旋模型的特点/缺点
  - 3.4 增量模型与迭代模型
  - 3.5 敏捷模型
  - - 3.5.1 Scrum模型
    - 3.5.2 敏捷模型中的测试
- 4 测试模型
- - 4.1 V模型
  - 4.2 W模型(双V模型)

1. 调试与测试的区别

调试与测试两词只有一字之差, 但两者目的并不相同, 调试的目的在于发现并解决问题, 而测试的目的在于发现问题;

权限

通常在gitee等代码仓库中都具有权限管理, 而一般测试人员只有读权限, 没有写权限, 因此测试人员只能读, 不能写;
参与角色

测试与调试的人员角色也不同, 通常大部分情况, 调试由开发人员进行, 而测试通常由测试人员进行;

测试人员的主要工作职责是为了保障产品质量, 但产品质量并不只由测试人员保障, 产品质量由整个项目组(产品经理, 前/后端开发, 测试, 交互, 设计…)共同保障;

阶段

测试与调试的阶段也不同, 调试通常只在开发阶段进行, 而测试需要贯穿项目(软件)的整个生命周期;

测试人员通常是产品质量最后的把关者;

2. 开发过程中的需求

开发过程中一般分为两种需求, 分别为用户需求与软件需求;

用户需求

一般用户需求指甲方或是终端用户使用产品时必须要完成的任务, 通常用户需求较为简单;

如:
- 用户可以随时查看商品库存量
软件需求

软件需求通常是用户需求转化而来, 通常是技术化的描述;

如:
- 系统需为管理员提供实时库存量查询接口, 响应时间<=1s;

总而言之用户需求是用户(甲方/客户)以自然语言提出, 反映业务目标和使用场景的, 而软件需求是由开发团队通过分析用户需求转化而来, 更加表现为技术化的描述;

用户需求与软件需求的表现形式不同, 通常用户需求以业务视角描述, 可能存在模糊性和主观性, 通常情况下, 用户需求不会第一时间就被解决, 而是需要对用户需求进行评估, 分析, 细化等过程转化为对应的软件需求才能着手被解决;

软件需求通常使用结构化文档, 如例图, User Story, SRS文档等进行描述;

用户需求	软件需求
口头描述, 邮件/会议记录, 业务流程图	功能需求, 非功能需求, 数据模型

其次用户需求更关注高层次需求, 如"做什么", 不涉及实现方式;

而软件需求明确"怎么做", 需具备技术实现细节;

用户需求典型问题	软件需求典型问题
- 表述模糊（如"更方便"） - 隐性需求未明示 - 不同用户需求冲突	- 技术要求不完整（如缺少性能指标） - 需求不可测试（如"代码要优雅"） - 技术可行性判断失误

简要软件需求文档示例(实现用户注册功能)

1.1.1.1 注册账号
1.1.1.1.1 功能概述
1.1.1.1.1.1 匿名用户通过邮箱注册账户，需激活后登录。
1.1.1.1.2 输入规则

字段名称	必填性	长度/位数	格式要求	附加规则
姓名	必填	6~15字符	汉字/字母/空格	-
邮箱	必填	-	标准邮箱格式	格式错误时提示
密码	必填	6~15字符	字母+数字组合	两次输入不一致时提示
验证码	必填	6位数字	纯数字	邮箱发送，有效期5分钟

1.1.1.1.3 处理规则

1.1.1.1.3.1 用户同意协议后填写信息，提交时校验字段合法性：
1.1.1.1.3.1.1 校验失败：高亮错误字段并提示原因。
1.1.1.1.3.1.2 校验成功：发送含24小时有效激活链接的邮件。

1.1.1.1.4 异常规则
1.1.1.1.4.1 未收到激活邮件：登录界面可重新发送，每邮件限24小时有效。

1.1.1.1.5 数据规则
1.1.1.1.5.1 存储表user_account，含user_id（自增主键）、email（唯一）、is_activated（默认false）。
1.1.1.1.5.2 密码SHA-256加盐存储，激活链接含一次性Token。

1.1.1.1.6 后置条件
1.1.1.1.6.1 未激活账户禁止登录及操作系统功能。

需要明确一点的是并不是所有的用户需求都是合理的, 因此用户需求才需要经过评估, 分析等过程转化为软件需求;

用户需求不能直接作为开发和测试的依据, 针对用户需求, 产品经历需要进行需求分析(技术可行性, 市场可行性, 成本投入和收益占比等)后才可转变为软件需求;

3. 开发模型

3.1 软件的生命周期

实际上软件的生命周期就是软件的开发模型;

软件生命周期是指软件从规划, 需求分析, 设计, 开发, 测试, 部署, 维护到最终退役的完整过程, 是软件开发的全流程框架, 覆盖软件"从生到死"的各个阶段;

常见的几种开发模型有: 瀑布模型, 敏捷模型, 螺旋模型…

瀑布模型生命周期(严格线性, 不可逆)

需求分析 -> 设计 -> 编码 -> 测试 -> 维护
敏捷模型生命周期(持续迭代)

需求 -> 开发 -> 测试 -> 交付 -> 反馈 -> 新需求
螺旋模型生命周期(强调风险管理)

计划 -> 风险分析 -> 开发 -> 评估 -> 下一轮循环

假设存在一个用户需求为"邮箱注册功能", 其生命周期大概为如下:

计划
1. 目标：明确功能范围和用户场景。
  用户通过邮箱注册账号（必填项）。
  需验证邮箱有效性（发送验证链接或验证码）。
  防止重复注册或恶意注册（如频率限制、CAPTCHA）。
需求分析
1. 功能定义：
  邮箱注册为核心流程，需覆盖验证、防重复、安全防护。
  非功能需求：邮件送达率 > 95%，响应时间 < 2秒。
设计
1. 前端设计：
  注册页面布局（邮箱输入框、验证码/验证链接触发按钮）。
  错误提示（邮箱格式错误、重复注册、验证码超时）。
2. 后端设计：
  邮箱格式校验（正则表达式）。
  验证邮件/短信服务集成（如SMTP、第三方API）。
  数据库设计（存储邮箱、密码哈希、验证状态）。
编码
1. 前端开发：
  实现表单提交逻辑，绑定邮箱验证接口。
  处理验证成功/失败的交互反馈。
2. 后端开发：
  实现邮箱验证码生成、存储（Redis缓存）。
  邮件发送服务调用（异步队列）。
  用户信息加密存储（如bcrypt哈希密码）。
测试
1. 功能测试：
  正常流程：输入有效邮箱 → 接收验证邮件 → 激活账号。
  异常流程：无效邮箱格式、重复注册、验证码过期/错误。
2. 安全测试：
  SQL注入、XSS攻击防御。
  验证码防爆破（限流策略）。
3. 部署验证：
  灰度发布：先小范围开放注册功能，监控异常。
  配置生产环境：邮件服务参数、数据库连接、日志监控。
运行维护
1. 修复性维护
2. 完善性维护
3. 预防性维护
退役
1. 替代方案：
  逐步迁移用户至新注册方式（如手机号登录）。
2. 数据清理：
  标记废弃邮箱账号，归档或删除历史数据。

不同企业对不同的软件的生命周期的框架不同, 如可能针对软件特定的特色功能在不同的阶段将会有不同的差异;

3.2 瀑布模型

瀑布模型是最早提出的软件生命周期模型, 其特点是:

每个流程只执行一次
线性的开发流程

3.2.1 瀑布模型的特点/缺点

瀑布模型最大的缺点在于一个可以运行的产品很迟才能被看到;

假设一个非常简单的用户需求被提出, 那么在上述过程, 包括"问题定义, 问题可行性…"等过程的阶段时间都很短, 上线过程也会比较快;

但若是出现一个非常复杂的用户需求被提出时, 对应的各个过程的时间开销将被延长, 因此可能当前较为流行的功能或者板块在长时间未上线后在对应功能板块不再流行时上线, 对应的资源开销将会贬值(没有收益/收益太低);

同时瀑布模型还有一个缺点就是, 由于所有流程只执行一次并且是线性执行, 因此如果在开发过程当中某个流程出现了问题后将需要向前追溯, 如测试人员在测试阶段发现问题需要反馈给编码对应人员, 开发人员认为没有问题将会继续向前追溯(设计), 以此类推, 这意味追溯甚至可能一直到源头, 即重新从问题定义, 即瀑布模型的源头, 否则如果出现问题并未解决的问题将暴露给用户, 将会降低用户的使用体验;

优点/特点	缺点
- 强调开发的阶段性 - 线性结构, 每个阶段只执行一次 - 是其他模型的基础框架	1. 测试后置: - 各阶段的遗留风险推迟到测试阶段才被发现, 导致大面积返工, 失去及早修复的机会 - 必须留有足够的时间给测试, 否则导致测试不充分, 将缺陷直接暴露给用户(产品质量差) 2. 周期太长, 产品可能在需求/功能过时时才被看到和使用

瀑布模型的适用场景一般是需求固定的小型项目, 一般不适用于规模庞大, 复杂度高, 风险大的项目;

3.3 螺旋模型

螺旋开发模型的适用场景通常是一些规模庞大, 复杂度高, 风险大的项目;

螺旋模型是基于瀑布模型进行修改的模型, 将螺旋模型进行展开后得到的是一个类似于瀑布模型的"迭代式瀑布模型";

螺旋模型与瀑布模型最大的差别就在于螺旋模型在各阶段都引入了风险分析;

同时螺旋模型还引入了原型, 其中原型在螺旋模型中属于风险缓解工具, 主要用于验证关键技术的可行性与确认需求理解一致性, 原型通常不进入生产代码, 其生命周期仅限于当前迭代, 若原型验证失败, 触发的则是风险对应策略;

每个阶段均以 计划 -> 风险分析 -> 原型开发 -> 用户评估 的顺序进行;

3.3.1 螺旋模型的特点/缺点

螺旋模型引入了风险分析和原型, 其目的是减少各阶段遗留的风险问题, 避免把问题留到后面的阶段;

螺旋模型同样具有缺点, 对一个项目而言, 使用了螺旋模型进行开发, 那么意味着项目组需要存在对应的风险分析人员来进行风险分析;

各阶段是否遗留问题取决于风险分析人员, 该项与风险分析人员的技术能力直接挂钩;

优点/特点	缺点
- 强调严格的全过程分析管理 - 强调各开发阶段的质量 - 增加风险分析和原型	- 项目中可能存在的风险性与风险管理人员的技能水平有直接关系 - 需求人员, 资金, 时间的增加和投入可能会导致项目成本提高

3.4 增量模型与迭代模型

增量模型

当存在一个需求时, 增量模型旨在将大需求拆分成若干个小需求, 将每个小需求独立开发上线;

增量模型的每个增量都是一个完整的功能子集, 按照顺序开发并逐步集中到系统中;
迭代模型

相比于增量模型而言, 迭代模型同样会将一个需求细化为几个小需求, 随后对小需求进行基本实现, 随后进行上线, 通过由抽象逐步细化实施将抽象转化为具象, 不断优化;

迭代模型中的每一次迭代都可以是一个可运行的版本, 逐步优化功能和设计;

通常情况下迭代模型和增量模型会在一个项目的开发中配合使用;

迭代模型和增量模型的适用场景通常为大型项目, 且需求不明确的场景;

3.5 敏捷模型

敏捷模型又被成为增量开发迭代模型;

目前的开发人员在使用迭代瀑布模型来进行软件开发时将面临各种问题, 主要的困难包括在项目开发期间处理来自客户的变更请求以及合并这些变更所需的高成本时间, 而敏捷模型主要来解决这种问题;

虽然上述的螺旋模型中可以有效的避免问题的遗留, 但在开发过程中, 一款产品的功能是在不断变化的, 螺旋模型只能避免在计划过程中的问题遗留, 但无法避免用户/甲方的需求变更;

相比长期计划而言, 敏捷模型更强调灵活性和适应性, 相对其他模型而言, 敏捷模型是较为弹性的;

敏捷模型的主要目的是促进项目的快速完成;

通常情况下在敏捷模型中, 需求将被分节为许多可以增量开发的小部分, 敏捷模型采用迭代开发, 每次的迭代都旨在小而易于管理;

一次为客户计划, 开发和部署一个迭代, 通常不制定长期计划, 同时没有固定的风险分析阶段;

在敏捷模型中有一个非常重要的《敏捷宣言》, 其内容为:
- “个体与交互重于过程和工具”
  
  即团队成员的沟通与合作比讲话的流程和工具更为重要, 强调高效的沟通;
- “可用的软件重于完备的文档”
  
  即优先交付实际可运行的软件, 而非追求完美的文档, 强调轻文档;
- “客户协作重于合同谈判”
  
  即与客户持续合作, 而非通过合同条款固定需求, 主动及时了解当下的需求;
- “响应变化重于遵循计划”
  
  即灵活适应需求变化, 而非死守原始计划, 能主动迎接变化;
敏捷宣言强调人本, 实用, 协作, 灵活;

目标是快速交付价值并适应变化;

即轻文档, 轻流程, 重目标, 重产出;

3.5.1 Scrum模型

Scrum模型是敏捷模型中的一种, 其中Scrum中, 主要由三类角色和五个重要会议组成;

三类角色

三类角色分别为产品经理(Product Owner), 项目经理(Scrum Master)以及研发团队(Team)组成;
- 产品经理(Product Owner)
  
  产品经理通常负责整理User Story, 定义其商业价值, 对其进行排序, 制定发布计划并对产品负责;
  
  即收集需求, 产出软件需求文档;
- 项目经理(Scrum Master)
  
  项目经理负责召开各种会议, 协调项目, 为研发团队服务;
- 研发团队(Team)
  
  研发团队则由不同技能的组员组成, 通过紧密协同, 完成每一次迭代的目标并交付产品;

与瀑布模型不同, Scrum模型将会把产品开发分节为若干个小迭代(Sprint), 其中每个小迭代周期为一周到四周不等, 但通常不会超过四周, 参与的团队成员通常是5-9人, 每期迭代要完成的User Story是固定的, 每次迭代完成后都会进行向上交付(重目标, 重交付), 而通常瀑布模型需要集所有人的能力进行开发;

在 Scrum 模型的流程中, 主要围绕五个会议(事件), 分别为发布计划会议, 迭代计划会议, 每日例会, 演示会议, 回顾会议;

发布计划会议(Release Planning Meeting)

通常情况下, 在发布会议中, 产品经理需要负责讲解User Story, 对其进行估算和排序, 发布计划会议产出就是制定出这一期迭代要完成的Story列表, 即Sprint Backlog;
- 目的
  
  确定产品发布的长期目标和范围, 规划多个Sprint(迭代)的总体方向;
- 参与者
  
  产品经理, 项目经理, 开发团队和关键利益相关者;
- 关键内容
  - 梳理产品代办列表(Product Backlog)并确定优先级
  - 估算整体时间框架和资源需求
  - 制定发布路线图
迭代计划会议(Sprint Planning Meeting)

该会议中项目团队将要对每一个Story进行任务分解, 分解的标准是完成该Story的所有任务, 每个任务都有明确的负责人, 并完成工时的初估计;
- 目的
  
  为单个Sprint制定详细任务目标并明确交付内容;
- 参与者
  
  产品经理, 项目经理, 开发团队
- 关键内容
  - 从产品代办列表中选取本Sprint要完成的高优先级需求
  - 将需求拆解为具体的开发任务 (Sprint Backlog)
  - 估算任务工作量并分配职责
每日例会(Sprint Planning Meeting)

每天项目经理将会召集站立会议, 团队成员回答昨天做了什么, 今天计划做什么, 有什么问题;
- 目的
  
  同步团队进度, 快速识别障碍, 确保Sprint目标顺利推进;
- 参与者
  
  开发团队, 项目经理(主持)
- 关键内容(每人回答三个问题)
  - 昨天完成了什么
    
    明确知道每个人的进度;
  - 今天计划做什么
    
    今日的目标和计划;
  - 遇到了什么阻碍
    
    及时解决问题能够保证产品在规定的迭代周期内正常交付;
演示会议(Sprint Review Meeting)

迭代结束后, 召开演示会议, 相关人员受邀参加, 团队负责向大家展示本次迭代取得的成果, 期间大家的反馈记录下来, 由产品经理整理, 形成新的Story;
- 目的
  
  向客户或利益相关者展示Sprint成果, 收集反馈;
- 参与者
  
  产品负责人, 开发团队, Scrum Master, 客户/用户代表;
- 关键内容
  - 演示可运行的增量功能
  - 讨论反馈并调整后续需求优先级
回顾会议(Sprint Retrospective Meeting)

回顾上一次迭代流程中的问题, 不断优化;
- 目的
  
  总结Sprint的优缺点, 持续改进团队协作和流程;
- 参与者
  
  开发团队, 产品经理, 项目经理
- 关键内容
  - 讨论"哪些做得好", “哪些需要改进”, “下一步行动”
  - 制定具体的改进措施

会议	核心作用	关键产出
发布计划会议	明确长期目标与路线图	发布计划, 优先级排序
迭代计划会议	制定短期任务清单	Sprint目标, Sprint Backlog
每日例会(站会)	同步进展与解决问题	每日任务清单, 障碍解决方案
演示会议	交付成果并获取反馈	可运行增量, 需求调整方向
回顾会议	优化团队协作与流程	改进措施清单(如流程调整)

3.5.2 敏捷模型中的测试

敏捷模型中的测试主要要求轻文档和快速迭代;

快速迭代

在敏捷模型中的测试需要进行快速迭代, 如在测试过程中的测试用例的迭代速度要快, 需要及时发生变化, 且测试用例要尽可能完整的去写一确保全面, 确保不会将问题暴露给用户;
轻文档

测试人员在测试过程中通常需要撰写多种文档, 包括但不限于测试用例, 测试计划文档, 测试报告等;

在敏捷开发模型过程中, 测试人员不应该使用传统的Excel编写测试用例的方法, 更多的是需要使用类似于思维导图, 探索性测试(强调自由度, 设计和执行同时进行, 根据测试结果不断调整测试计划), 自动化测试等;

在敏捷开发模型过程中, 测试人员应该多主动和开发人员了解需求, 讨论设计, 研究Bug出现的原因;

4 测试模型

下文中出现的两个模型, 即V模型和W模型本质上也是开发模型, 被称作测试模型的原因在于下列两个模型更加注重测试, 因此被称作测试模型;

4.1 V模型

在V模型中, 明确标注了测试过程中存在不同类型的测试;

其中每一阶段的测试都需要参考之前的设计或者需求, 如单元测试需要参考详细设计, 集成测试需要参考概要设计, 系统测试需要参考需求分析与系统, 验收测试需要参考用户需求;

通常在V模型中不同的测试阶段由不同的人员进行
- 单元测试
  
  一般由开发人员进行测试, 如一个类或是一个函数;
- 集成测试
  
  由开发人员与测试工程师完成, 其中开发人员主导, 测试人员辅助;
- 系统测试
  
  由测试工程师完成;
- 验收测试
  
  验收测试通常由客户或业务代表(最终用户, 产品经理)进行;