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

【测试】Bug+设计测试用例

news 2025/8/13 5:45:27

🔥个人主页：中草药

🔥专栏：【Java】登神长阶史诗般的Java成神之路

一、Bug

概念

⼀个计算机bug指在计算机程序中存在的⼀个错误(error)、缺陷(flaw)、疏忽(mistake)或者故障(fault)，这些bug使程序无法正确的运行。Bug产生于程序的源代码或者程序设计阶段的疏忽或者错误。准确而言：

1、当且仅当规格说明是存在的并且正确，程序与规格之间的匹配才是错误的。

2、当需求规格说明书没有提到的功能，判断标准以最终用户为终；当程序员没有实现其最终用户合理的功能要求时就是软件错误。

描述Bug的要素

核心要素：

标题：简洁描述问题（如“首页轮播图在iOS 15下无法滑动”）。
环境：操作系统、浏览器版本、设备型号等。
步骤：可复现的操作流程（附截图或视频）。
预期与实际结果：明确对比差异。

举例

标题微信发红包领取总金额与实际发送金额不符

问题出现的版本：8.0.54(线上版本)

问题出现的环境：Android 16

问题出现的步骤

打开微信
打开群对话框
点击对话框右下角“+”
选择“红包“功能
选择拼手气红包
输入金额
输入密码，点击发送
红包被群友领取

预期结果：红包被领取，不同的用户领取到的金额不完全相同，整体存在差异，领取总金额等于发送的金额不同的用户领取到的金额

实际结果：红包被领取，不同的用户领取到的金额不完全相同，整体存在差异，领取总金额不等于发送的金额

优先级：

指定负责人：

备注：

Bug描述要素实际根据企业需求来定，描述项并不完全相同

Bug的级别

Bug级别帮助团队确定哪些问题需要优先修复，根据Bug的严重性，团队可以合理分配开发、测试和运维资源

崩溃，严重，一般，次要

1. 崩溃（Critical）

描述：导致系统崩溃、数据丢失、或主要功能完全失效阻碍开发和测试工作的Bug。
影响：用户无法继续使用系统，可能导致重大业务损失或安全风险。
示例：系统崩溃、登录功能完全失效、代码错误、死循环、数据库发生死锁、重要的一级菜单功能不能使用等(该问题在测试中较少出现，一旦出现应立即中止当前版本测试）

2. 严重（Major）

描述：影响主要功能，但系统仍可运行。
影响：用户无法完成关键操作，体验严重受损。
示例：系统主要功能部分丧失、数据库保存调用错误、用户数据丢失，一级功能菜单不能使用但是不影响其他功能的测试。功能设计与需求严重不符，模块无法启动或调用，程序重启、自动退出，关联程序间调用冲突，安全问题、稳定性等。

3. 一般（Moderate）

描述：影响次要功能或非核心业务流程，不影响使用。
影响：用户可能通过其他方式完成任务，但体验不佳。
示例：界面显示错误、部分功能响应缓慢、操作时间长、查询时间长、格式错误、边界条件错误，删除没有确认框、数据库表中字段过多等(该问题实际测试中存在最多)

4. 次要（Minor）

描述：对系统功能影响较小，通常为界面或用户体验问题。
影响：用户可能注意到问题，但不影响主要功能。
示例：错别字、界面格式不规范，页面显示重叠、不该显示的要隐藏，描述不清楚，提示语丢失，文字排列不整齐，光标位置不正确，用户体验感受不好，可以优化性能的方案等(此类问题在测试初期较多，优先程度较低;在测试后期出现较少，应及时处理)

Bug的生命周期

Bug的生命周期（Bug Life Cycle）是指一个Bug从被发现到最终关闭的整个过程。它描述了Bug在不同阶段的状态流转，帮助开发团队和测试人员跟踪和管理问题。以下是Bug生命周期的典型阶段：

1. 新建（New）

描述：测试人员发现并报告一个新的Bug。
操作：测试人员提交Bug报告，包括详细描述、重现步骤、截图等信息。
下一状态：待分配（Open）。

2. 待分配（Open）

描述：Bug被确认并等待分配给开发人员。
操作：测试负责人或项目经理确认Bug的有效性，并将其分配给相关开发人员。
下一状态：已分配（Assigned）。

3. 已分配（Assigned）

描述：Bug已分配给具体的开发人员。
操作：开发人员开始分析问题并尝试修复。
下一状态：修复中（In Progress）。

4. 修复中（In Progress）

描述：开发人员正在修复Bug。
操作：开发人员编写代码、修复问题，并在本地环境中测试。
下一状态：已修复（Fixed）。

5. 已修复（Fixed）

描述：开发人员完成修复并提交代码。
操作：开发人员将修复后的代码合并到主分支，并标记Bug为“已修复”。
下一状态：待验证（Pending Verification）。

6. 待验证（Pending Verification）

描述：修复后的Bug等待测试人员验证。
操作：测试人员在最新版本中验证Bug是否已修复。
下一状态：
- 如果修复成功，状态变为“已验证（Verified）”。
- 如果修复失败，状态变为“重新打开（Reopen）”。

7. 已验证（Verified）

描述：测试人员确认Bug已修复。
操作：测试人员验证并通过Bug修复。
下一状态：已关闭（Closed）。

8. 已关闭（Closed）

描述：Bug已完全解决并关闭。
操作：Bug被归档，不再需要进一步处理。
下一状态：无（生命周期结束）。

9. 重新打开（Reopen）

描述：测试人员验证后发现Bug未完全修复。
操作：Bug被重新打开，并再次分配给开发人员。
下一状态：修复中（In Progress）。

10. 拒绝（Rejected）

描述：开发人员认为Bug无效或不符合预期行为。
操作：开发人员拒绝修复，并说明原因。
下一状态：已关闭（Closed）。

11. 推迟（Deferred）

描述：Bug在当前版本中不修复，计划在后续版本中处理。
操作：Bug被标记为“推迟”，并记录在后续版本的修复计划中。
下一状态：在后续版本中重新打开（Reopen）。

12. 重复（Duplicate）

描述：Bug已被其他测试人员报告过。
操作：标记为“重复”，并关联到原始Bug。
下一状态：已关闭（Closed）。

13. 无法重现（Non-Reproducible）

描述：开发人员或测试人员无法复现Bug。
操作：标记为“无法重现”，并记录相关信息。
下一状态：已关闭（Closed）。

14. 建议（Enhancement）

描述：Bug实际上是功能改进建议。
操作：标记为“建议”，并记录为需求或改进点。
下一状态：已关闭（Closed）。

与开发发生争执怎么办（高频）

1、首先检查自身，是否将Bug表述清楚，或者误操作导致的无效Bug，理解对方诉求

2、站在用户角度考虑并抛出问题

3、Bug定级应该有理有据（站在用户角度）

4、努力提高自身技术和业务水平，做到不仅能提出问题，最好也能够出解决方案

5、如果确实有Bug，友好沟通不能够解决问题，召开Bug评审

Bug评审

目的

决定如何处理Bug
分析缺陷产生的原因，找出预防的对策

代表参加

测试代表：主要从Bug的具体表现、严重程度等方面提供信息，并提出自己对Bug的处理意见。
开发代表：开发代表主要从修改缺陷的难度和风险出发，考虑缺陷修改需要付出的代价，以及可能影响的范围、可能引发的风险等，如果决定要修改，还要讨论出修改的初步方案
产品代表：产品代表主要从产品的整体计划、用户的要求等方面对缺陷的修改必要性、缺陷修改的时间和版本提出自己的意见

二、测试用例

概念

测试用例（Test Case）是软件测试中为了实施测试而向被测试的系统提供的一组集合，这组集合包含：测试环境、测试步骤、测试数据、预期结果

正确设计测试用例的思想：常规思维+逆向思维+发散性思维

设计测试用例原则一：

测试用例中的一个必须部分是对预期输出或结果进行定义

设计测试用例的原则二:

1.测试用例的编写不仅应当根据有效和预料到的输入情况，而且也应该根据无效和未预料到的输入情况。

2.检查程序是否“未做其应该做的”仅是成功的一半，测试的另一半是检查程序是否“做了其不应该做的”。(是上一条原则的必然结果)

3.计划测试工作时不应默许假定不会发现错误。

万能公式

万能公式：功能测试+界面测试+性能测试+兼容性测试+易用性测试+安全测试

功能测试

验证软件的功能是否符合需求规格说明书（或用户需求），确保每个功能模块按预期逻辑正常运行的测试类型。

功能测试通常是一项黑盒操作，在进行测试时，需要对规格说明进行分析以提炼出测试用例，此外为了明确需求，可以进行以下操作

1、查找其他相关文档，来帮助理解所要测试的产品需要完成的目标;

2、尽量多参加项目组内的会议，比如需求讨论、设计讨论、计划讨论等，能够加深对产品的理解

3、召集相关人员，对你整理的结果进行讨论，通过评审后，这份文档就可以作为依据来设计你的case了;

4、如果是一款已经上线的产品，可以多使用产品，有不懂的问产品经理;也可以去看历史bug，可以了解到一些需要关注的东西。

核心关注点：

功能是否完整覆盖需求（无遗漏）；
功能逻辑是否符合设计（如流程跳转、数据计算、条件判断是否正确）；
边界条件和异常场景是否处理（如输入为空、超范围值、错误操作时的表现）。

常见测试点：

核心功能流程（如电商的 “浏览 - 加购 - 下单 - 支付” 全流程）；
按钮、表单、接口等交互功能的正确性（如提交表单后数据是否正确保存）；
错误处理机制（如输入无效数据时是否提示明确的错误信息）；
权限相关功能（如普通用户是否无法访问管理员功能）。

界面测试

对软件界面上的所有内容进行测试，观察测试界面实现是否与设计图一致，验证界面元素，控件操作

核心关注点：

界面元素的显示正确性（如文字、图片、按钮、图标是否正常显示，无错位 / 缺失 / 模糊）；
布局适配性（如不同屏幕尺寸下布局是否合理，无重叠 / 溢出）；
交互反馈的及时性（如点击按钮后是否有状态变化，加载时是否有提示）；
界面风格的一致性（如字体、颜色、控件样式在全系统中是否统一）。

常见测试点：

控件尺寸、位置、颜色是否符合设计稿；
文字是否清晰、无错别字，字体大小 / 行距是否合理；
响应式布局在不同分辨率（如 PC 端、平板、手机）下的适配效果；
交互状态（如按钮点击、hover、禁用状态）是否正确反馈；
弹窗、菜单、导航栏等组件的显示与关闭逻辑是否正常。

性能测试

在不同负载条件下，测试软件的响应速度、稳定性、资源占用等性能指标，验证其是否满足性能需求。性能测试和功能测试的区别是：功能测试检查软件是否做了，而性能测试测试软件做的好不好。

核心关注点：

响应时间（如接口返回时间、页面加载时间是否在预期范围内）；
吞吐量（如单位时间内处理的请求数、数据量）；
资源利用率（如 CPU、内存、磁盘 IO、网络带宽的占用是否合理）；
稳定性（如长时间运行或高负载下是否无崩溃、无内存泄漏）。

常见子类型及测试点：

负载测试：在预期用户量（如 1000 用户并发）下，测试系统性能是否达标；
压力测试：逐步增加负载（如并发用户从 1000 增至 5000），找到系统崩溃的临界点；
并发测试：验证多用户同时操作时是否存在资源竞争、数据混乱（如秒杀场景下的库存准确性）；
耐久性测试：系统连续运行 24 小时 / 7 天，观察是否有性能退化（如内存泄漏导致响应变慢）；
基准测试：对比不同版本或优化前后的性能指标（如优化后接口响应时间是否缩短）。

兼容性测试

验证软件在不同环境（硬件、操作系统、浏览器、设备等）下是否能正常运行的测试。例如：如QQ可以在PC端打开，也可以在移动端打开;移动端又分为I0S系统和Android系统，且市面上手机又有不同的品牌、不同的机型、不同的版本。

核心关注点：

环境多样性适配（如不同操作系统、浏览器、设备型号的兼容）；
软硬件依赖的兼容性（如软件与数据库版本、中间件版本是否兼容）。

常见测试点

平台兼容：Windows（不同版本如 Win10/11）、macOS、Linux 等操作系统下的运行效果；
浏览器兼容：Chrome、Firefox、Edge、Safari 等不同浏览器及版本的适配（如 CSS/JS 兼容性问题）；
设备兼容：手机（不同品牌如华为、苹果，不同尺寸屏幕）、平板、PC 等设备的适配；
分辨率兼容：不同屏幕分辨率（如 1080P、2K、4K）下的界面与功能表现；
软件版本兼容：与其他依赖软件（如数据库 MySQL 5.7 vs 8.0，JDK 11 vs 17）的兼容性。

易用性测试

从用户视角出发，测试软件的使用便捷性、学习成本、操作效率等，评估用户体验是否友好。确认 “软件是否好用、易上手”，即普通用户能否高效完成操作，无使用障碍。

核心关注点：

操作流程的直观性（如完成一个任务的步骤是否简洁，逻辑是否符合用户习惯）；
学习成本（如新手是否能快速理解功能，无需复杂培训）；
反馈的清晰度（如操作结果、错误原因是否明确告知用户）；
人性化设计（如是否有快捷操作、历史记录、防错提示等）。

常见测试点：

核心任务流程的步骤数（如注册流程是否能在 3 步内完成）；
导航与菜单的逻辑性（如用户能否快速找到目标功能）；
错误提示的友好性（如提示 “密码错误” 而非 “系统错误”）；
帮助文档 / 引导的有效性（如是否有新手引导、 tooltip 提示）；
用户习惯适配（如支持键盘快捷键、常用操作记忆功能）。

安全测试

识别软件中的安全漏洞，验证系统对未授权访问、数据泄露、恶意攻击等风险的抵御能力。确保 “软件数据和功能安全”，即防止敏感信息泄露、系统被非法操控。

核心关注点：

身份认证与授权（如是否能有效验证用户身份，权限分配是否合理）；
数据保护（如敏感数据是否加密，传输 / 存储过程是否安全）；
漏洞防御（如是否能抵御常见攻击手段，如 SQL 注入、XSS 等）；
审计与应急（如是否有操作日志，异常攻击时是否能快速响应）。

常见测试点：

认证机制（如密码复杂度校验、多因素认证、防暴力破解）；
授权控制（如普通用户能否越权访问管理员接口 / 数据）；
数据安全（如密码是否明文存储，API 传输是否用 HTTPS 加密）；
漏洞检测（如输入特殊字符是否触发 SQL 注入，页面是否防御 XSS 攻击）；
会话管理（如会话超时是否自动登出，token 是否易被窃取）；
日志审计（如关键操作是否记录日志，是否可追溯操作人）。

除此万能公式所见的测试之外，还有几个常用的测试类型

弱网测试

通过模拟低带宽、高延迟、网络波动、丢包甚至断网等恶劣网络环境，验证软件在非理想网络条件下的功能稳定性、数据可靠性及用户体验的测试类型。

需要工具构造弱网，比如fiddler

安装卸载测试

验证软件从 “安装→运行→升级→修复→卸载” 全生命周期关键环节的完整性、稳定性及用户体验的测试类型，覆盖软件与系统环境的适配及资源清理能力。

核心关注点

安装过程流畅性：安装步骤是否简洁、指引是否明确，进度反馈是否及时，无卡顿或无响应。
环境兼容性校验：安装前是否检查系统版本、硬件配置、依赖组件（如.NET Framework、JRE）是否符合要求。
安装后完整性：安装完成后，文件、目录、注册表（Windows）、权限配置是否完整，核心功能能否正常启动。
升级 / 降级可靠性：跨版本升级、降级时，用户数据（如配置、缓存、账号信息）是否保留，功能是否兼容无异常。
卸载彻底性：卸载后，安装目录、临时文件、注册表项、服务进程是否完全清除，无残留占用系统资源。
异常场景容错性：安装 / 卸载中断（如断电、磁盘满、强制关闭）后，能否恢复或清理残留，避免系统污染。

常见测试点

安装测试：

安装方式验证：覆盖官方安装包（.exe/.msi）、应用商店下载、离线安装包、绿色版解压等不同安装途径。
前置条件校验：检测系统版本（如 Windows 10 是否支持）、硬件要求（如内存 / 磁盘空间是否达标）、依赖组件是否缺失（缺失时是否提示安装）。
安装过程监控：进度条是否准确、步骤指引是否清晰（如许可协议、安装路径选择），异常中断（如断电、手动终止）后重启能否继续或回滚。
安装后验证：程序能否正常启动，桌面快捷方式 / 开始菜单是否生成，安装目录文件是否齐全（无缺失.dll/.so 文件），注册表 / 配置文件是否正确写入。

升级 / 降级测试：

覆盖安装：高版本覆盖低版本安装，验证功能是否正常，用户数据（如设置、历史记录）是否保留。
跨版本升级：跳过中间版本直接升级（如 v1.0→v3.0），验证数据兼容性（如数据库结构变更是否兼容旧数据）。
降级安装：高版本卸载后安装低版本，验证数据是否兼容（如是否提示 “数据可能不兼容”）。
修复安装测试：
模拟文件损坏（如删除关键.dll），执行 “修复安装”，验证能否恢复文件完整性及功能正常。
修复过程是否保留用户配置，无数据丢失。

卸载测试：

常规卸载：通过控制面板 / 卸载程序执行卸载，验证是否完全移除安装目录、快捷方式、启动项。
残留检查：卸载后检查注册表（Windows）、配置文件目录（如 Linux 的/etc、macOS 的~/Library）、临时文件夹是否有残留文件 / 键值。
进程清理：卸载后相关后台进程、服务是否完全终止，无僵尸进程占用资源。
权限场景：非管理员权限下能否正常卸载，是否提示 “需要管理员权限”。

异常场景测试：

安装时磁盘空间不足，是否提示 “空间不足” 并终止，无半安装状态残留。
安装过程中强制断电，重启后是否识别 “未完成安装” 并提供 “继续 / 卸载” 选项。
卸载时文件被占用（如程序正在运行），是否提示 “请关闭程序后重试”，而非强制删除导致文件损坏。

设计测试用例

基于需求的设计方法

等价类

依据需求将输入划分为若干个等价类，从等价类中选出一个测试用例，如果这个测试用例通过，则认为所代表的等价类测试通过，这样就用较少的测试用例达到尽量多的功能覆盖

等价类分类：有效等价类和无效等价类

边界值

对输入或输出的边界值进行测试的一种黑盒测试方法，是对等价类的补充

边界值包括边界值+次边界值

判定表法（注重思维）

判定表是一种逻辑判断的工具，将复杂的问题照各种可能情况全部列举出来

正交法（注重思维）

正交法（Orthogonal Array Testing）是一种基于正交实验设计（Orthogonal Experimental Design）的测试用例设计方法，核心目标是在减少测试用例数量的同时，尽可能覆盖多因素（参数）之间的关键组合，确保测试的高效性和有效性。

正交表是一种标准化的数学表格，记为 (L_n(t^k))，其中：

n：正交表的行数（即测试用例数量）；
t：每个因素的水平数（每个参数的取值数量）；
k：正交表可容纳的因素数（参数数量）。

L4(2^3)

正交表性质：

每一列中，不同数字出现次数相等
任意两列中，数字的排列方式齐全均衡

使用allpairs工具生成正交表

1、找到因素和水平并填入Excel（电脑自带）

2、在allpairs创建新的文本文件txt，复制excel中的因素和水平直接粘贴到文本保存

3、使用命令生成正交表：allpairs.exe new.txt>demo1.txt

生成结果

~表示可是填写也可以是不填写

4、根据正交表编写测试用例

5、补充遗漏的重要测试用例（补全全不填写的情况）

场景法（思维）

场景法（Scenario Testing）是一种基于业务流程或用户操作场景的测试用例设计方法，核心是通过模拟用户真实使用软件的 “场景”（即一系列连续操作步骤），来验证软件在完整业务流程中的功能正确性和流程连贯性。

场景法通过 “基本流” 和 “备选流” 来描述业务流程的不同路径：

基本流（Base Flow）：
指 “理想情况下” 用户完成业务目标的正常流程，是最常见、无异常的操作路径。
例：电商 “下单支付” 的基本流为：
浏览商品 → 加入购物车 → 点击结算 → 填写收货地址 → 选择支付方式 → 支付成功 → 订单生成。
备选流（Alternative Flow）：
指偏离基本流的异常或特殊流程，可能是用户操作错误、系统异常或特殊条件触发的分支路径。
例：上述下单流程的备选流可能包括：
- 备选流 1：加入购物车时商品库存不足；
- 备选流 2：结算时收货地址未填写；
- 备选流 3：支付时余额不足；
- 备选流 4：支付过程中网络中断。