软件测试基础入门：从 BUG 到测试用例设计完整指南

文章目录

• 一、软件测试生命周期
• 二、BUG相关内容
• • [2.1 什么是BUG](#2.1 什么是BUG)
  • [2.2 BUG的描述](#2.2 BUG的描述)
  • [2.3 BUG 级别的分类与判断标准](#2.3 BUG 级别的分类与判断标准)
  • [2.4 BUG的生命周期](#2.4 BUG的生命周期)
• 三、测试与开发的争执处理方法
• [四、BUG 评审的流程与角色职责](#四、BUG 评审的流程与角色职责)
• 五、测试用例
• • [5.1 什么是测试用例？](#5.1 什么是测试用例？)
  • [5.2 为什么需要测试用例？](#5.2 为什么需要测试用例？)
  • [5.3 测试用例设计的万能公式](#5.3 测试用例设计的万能公式)
  • [5.4 常用测试用例设计方法](#5.4 常用测试用例设计方法)
  • • [5.4.1 基于需求设计法](#5.4.1 基于需求设计法)
    • [5.4.2 等价类划分法](#5.4.2 等价类划分法)
    • [5.4.3 边界值分析法](#5.4.3 边界值分析法)
    • [5.4.4 正交法](#5.4.4 正交法)
    • [5.4.5 判定表法](#5.4.5 判定表法)
    • [5.4.6 场景法](#5.4.6 场景法)
    • [5.4.7 错误猜测法](#5.4.7 错误猜测法)
• 六、总结

文章作者: 当战神遇到编程

文章专栏:测试理论和实践

欢迎大家点赞👍评论📝收藏⭐文章

一、软件测试生命周期

软件测试生命周期是贯穿软件全流程的测试步骤，核心是通过有序步骤保障产品质量，各阶段目标与交付物明确：

各阶段具体内容：

阶段	核心工作	关注点	主要产出
需求分析	分析需求是否合理、完整、可测试	从用户、技术、测试三个角度判断需求是否存在问题	需求评审意见、疑问点、风险点
测试计划	制定测试安排	明确测试开始时间、结束时间、测试周期、测试范围、测试资源	测试计划
测试设计与开发	编写测试用例和测试文档	参考需求文档、技术文档，设计覆盖业务流程的测试场景	测试用例、测试文档
测试执行	按测试用例执行测试，发现并提交 BUG	尽可能全面验证系统功能、流程、数据、页面和异常场景	BUG 单、测试执行记录
测试评估	判断本轮测试是否通过	分析测试结果、遗留 BUG、风险点，判断是否满足上线条件	测试报告
上线	将项目发布到线上环境，并进行线上验证	确认线上环境功能是否正常，是否存在环境差异问题	上线验证结果
运行维护	跟踪线上问题，收集用户反馈	参与用户培训、试运行支持，及时反馈线上问题	用户反馈记录、线上问题跟踪表

二、BUG相关内容

2.1 什么是BUG

BUG 指的是计算机程序中的错误、缺陷、疏忽或故障，这些问题会导致程序无法按照预期正常运行。

更准确地说，可以从两个角度判断 BUG：

1.与规格说明不一致

如果需求规格说明书存在且正确，而程序实现与规格说明不一致，那么这就是 BUG。

例如：

需求要求手机号不能为空，但系统允许用户空手机号提交。

2.不符合用户合理预期

如果需求文档没有明确说明某个功能，但最终用户有合理预期，而程序没有满足，也可以视为软件错误。

例如：

用户点击"保存"按钮后，页面没有任何提示，用户不知道是否保存成功。

2.2 BUG的描述

假设发现某网站登录页二维码被遮挡，可以这样描述：

BUG 标题

登录页二维码被登录模块遮挡，导致扫码失败

问题版本

Chrome 浏览器 123.0.6312.123，64 位

问题环境

Windows 11 家庭中文版

复现步骤

• 打开 Chrome 浏览器
• 输入网址并进入首页
• 等待页面渲染完成
• 查看登录区域二维码展示效果

预期结果

二维码与登录模块不应发生遮挡，二维码可以正常扫描。

实际结果

二维码被登录模块遮挡，导致无法正常扫码。

2.3 BUG 级别的分类与判断标准

级别	关键词	判断标准
崩溃	用不了	系统或核心功能完全不可用
严重	影响主流程	核心功能异常、数据错误、安全或稳定性问题
一般	有缺陷但能用	功能不完善，但不影响整体使用
次要	体验问题	页面、提示、排版、性能优化类问题

2.4 BUG的生命周期

测试人员发现 BUG 后，先提交为 New 状态；

确认是 BUG 后，状态变为 Open，并指派开发处理；

如果开发修复完成，则变为 Fixed；

测试人员进行回归验证，验证通过后关闭为 Closed；

如果验证不通过，则 Reopen，重新交给开发修复；

如果确认不是 BUG，则 Rejected，最终关闭；

如果暂时不修复，则 Delay，后续再重新评估是否修复。

三、测试与开发的争执处理方法

测试过程中与开发的争执（如开发认为 "不是 bug""级别太高" 等），可通过以下步骤理性解决：

• 自查 BUG 描述：确保 BUG 信息（版本、环境、步骤等）完整清晰；若表述模糊，需主动向开发解释说明，避免信息偏差。
• 站在用户角度沟通：向开发强调 BUG 对用户的影响（如 "如果你是用户，能否接受这个问题？"），推动开发重视修复。
• BUG 定级有理有据：定级需结合 BUG 级别标准 + 用户视角，说明其对业务流程的实际影响，而非仅依赖测试内部标准。
• 提升技术与业务能力：不仅提出问题，还可给出解决方案（如建议的修改思路），建立专业权威；但需避免强制开发按自己的方案修改。

四、BUG 评审的流程与角色职责

若友好沟通无法解决争执，需召开 BUG 评审，核心目标是确定 BUG 处理方案 + 分析原因并预防，参与角色及职责如下：

角色	关注点
测试代表	BUG 表现、严重程度、复现方式、处理建议
开发代表	修改难度、影响范围、技术风险、修复方案
产品代表	用户价值、版本计划、是否必须当前版本修复

五、测试用例

5.1 什么是测试用例？

测试用例是为了实施测试，向被测系统提供的一组信息集合。

通常包括：

要素	说明
用例编号	测试用例的唯一标识，便于管理和追踪
用例标题	简要描述测试目标或验证点
测试方式	执行测试的类型，如功能测试、接口测试、兼容性测试等
测试模块	用例所属的功能模块或业务模块
重要性	用例的优先级或重要程度，如高、中、低
测试前提	执行该用例前必须满足的条件
测试环境	执行测试所需的系统、浏览器、设备、版本等环境信息
测试数据	执行测试时需要使用的输入数据或准备数据
测试步骤	具体的操作流程，需清晰、可执行
预期结果	系统应返回或展示的正确结果

5.2 为什么需要测试用例？

不写测试用例也可以测试，但会带来很多问题：

• 覆盖范围不清楚(不知道功能是否已经测全)。
• 测试过程不可复现(其他人很难按照同样步骤重新测试)。
• 回归测试成本高(新版本发布后，无法快速确认旧功能是否仍然正常)。
• 容易重复测试或遗漏测试(测试效率低，风险也高)。
• 问题责任难以界定(出现线上问题时，无法准确说明当时是否覆盖过相关场景)。

所以，测试用例的价值不只是"写文档"，而是让测试工作变得可规划、可执行、可衡量、可追踪。

5.3 测试用例设计的万能公式

功能测试 + 界面测试 + 性能测试 + 兼容性测试 + 易用性测试 + 安全测试

测试维度	核心关注点	设计测试点时怎么想	常见测试用例示例
功能测试	功能是否符合需求	正常流程能否完成；异常输入是否拦截；业务规则是否正确	正确输入账号密码能登录；密码错误提示失败；必填项为空提示错误；重复注册提示账号已存在
界面测试	页面展示是否正确	页面元素是否完整；布局是否合理；文案是否准确；控件是否可操作	按钮、输入框、提示语是否显示正确；页面是否错位；错误提示是否清晰
性能测试	系统处理能力是否满足要求	响应时间是否可接受；高并发是否稳定；大数据量是否卡顿	登录接口 2 秒内响应；多人同时访问不崩溃；大文件上传时系统不卡死
兼容性测试	不同环境下是否正常运行	浏览器、操作系统、设备、分辨率、版本是否兼容	Chrome、Edge、Firefox 是否正常；Android/iOS 是否可用；不同屏幕下页面是否适配
易用性测试	用户是否容易理解和操作	操作流程是否简单；提示是否友好；新用户是否容易上手	注册流程是否清晰；错误提示是否能指导用户修改；按钮位置是否明显
安全测试	是否存在安全风险	敏感信息是否保护；权限是否正确；输入是否有安全校验	密码是否密文显示；是否防止 SQL 注入；普通用户不能访问管理员功能；登录失败是否有限制

5.4 常用测试用例设计方法

5.4.1 基于需求设计法

这是最基础、最常用的方法。

步骤如下：

1. 阅读需求文档。
2. 提取功能点。
3. 分析每个功能点的输入、处理逻辑和输出。
4. 结合测试类型设计测试点。
5. 编写测试用例。

例如注册功能，可以先提取：

功能点	测试方向
账号注册	正常注册、重复注册、必填校验
账号登录	正常登录、密码错误、账号不存在
验证码	正确验证码、错误验证码、验证码过期
协议勾选	未勾选协议是否禁止注册

5.4.2 等价类划分法

当输入范围很大，无法穷举测试时，可以使用等价类。

把输入数据划分为若干类，每类选择一个代表值测试。

例如需求：姓名长度为 6 ~ 15 位。

类型	数据	预期
有效等价类	8 位字符	通过
无效等价类	3 位字符	不通过
无效等价类	20 位字符	不通过
无效等价类	空	不通过

等价类可以减少用例数量，但它主要关注输入分类，不能充分覆盖边界问题。

5.4.3 边界值分析法

很多缺陷都出现在边界附近，所以边界值是测试重点。

仍以姓名长度 6 ~ 15 位 为例：

测试数据	类型	预期
5 位	无效边界	不通过
6 位	有效边界	通过
7 位	有效范围内	通过
14 位	有效范围内	通过
15 位	有效边界	通过
16 位	无效边界	不通过

边界值通常和等价类一起使用。

5.4.4 正交法

当多个输入条件组合较多时，直接排列组合会导致用例爆炸。

例如注册功能有 5 个输入项：

• 姓名
• 邮箱
• 密码
• 确认密码
• 验证码

每个字段都有"填写 / 不填写"两种状态，完整组合是：

2⁵ = 32 条用例

正交法的目标是：

用较少的用例覆盖主要组合关系，尤其是两两组合。

适用场景：

场景	是否适合正交法
多字段组合测试	适合
多配置组合测试	适合
不同条件对应不同业务结果	不完全适合
强业务逻辑判断	更适合判定表

正交法不能完全替代测试人员判断，生成用例后还需要补充重要业务场景。

5.4.5 判定表法

当多个条件组合会产生不同结果时，适合使用判定表法。

例如需求：

用户账号包含 admin，或者通过内部注册链接进入注册页，并点击注册按钮，则成为管理员；否则不是管理员。

可以拆成：

条件	说明
A	账号包含 admin
B	内部注册链接
C	点击注册按钮

输出结果：

结果	说明
管理员	获得管理员身份
非管理员	不获得管理员身份

示例用例：

A	B	C	预期结果
是	否	是	管理员
否	是	是	管理员
是	是	是	管理员
是	否	否	非管理员
否	否	是	非管理员
否	否	否	非管理员

判定表适合处理复杂条件判断、权限判断、规则判断等场景。

5.4.6 场景法

场景法关注的是完整业务流程。

它通常包含：

类型	说明
基本流	用户按正常流程完成操作
备选流	中途出现其他合理分支
异常流	出现错误、失败、中断等情况

以邮箱注册为例：

基本流

1. 输入账号和密码。
2. 点击注册。
3. 系统发送确认邮件。
4. 用户在 24 小时内确认。
5. 注册成功。

异常流

场景	预期结果
账号为空	提示重新输入
密码为空	提示重新输入
邮箱已注册	提示账号已存在
网络异常	提示发送失败或允许重试
邮件超时未确认	注册失败或链接失效
用户点击旧确认邮件	提示链接无效

场景法特别适合测试业务流程型系统，例如注册、下单、支付、审批、退款等。

5.4.7 错误猜测法

错误猜测法依赖测试人员经验，推测系统可能出错的位置。

例如注册功能：

猜测点	测试方向
特殊字符	姓名中输入空格、emoji、特殊符号
大小写问题	密码是否区分大小写
明文风险	密码是否明文传输或展示
重复提交	多次点击注册按钮是否重复创建账号
输入粘贴	是否允许复制粘贴特殊格式内容

错误猜测法不够系统，但在实际项目中很有价值，尤其适合补充隐藏缺陷。

六、总结

测试用例设计不是简单罗列操作步骤，而是一种系统化分析能力。

可以记住这条主线：

先理解需求，再拆功能点；先覆盖正常流程，再覆盖异常流程；先用通用测试维度扩展，再用具体方法细化。

常见方法可以这样选：

方法	适用场景
基于需求设计	所有测试的基础
等价类	输入范围大，无法穷举
边界值	有长度、数量、范围限制
正交法	多参数组合过多
判定表法	多条件决定不同结果
场景法	完整业务流程
错误猜测法	基于经验补充潜在缺陷