BUG与测试用例
今天小编来继续分享下关于软件测试中的BUG和测试用例
BUG
讲这个BUG之前，得首先提一下什么是软件测试生命周期
软件测试的生命周期：
需求分析——>测试计划——>测试设计、测试开发——>测试执行——>测试评估——>上线——>运行维护
具体内容如下：
| 阶段 | 核心任务 | 关键产出 |
| 1. 需求分析 | 评审需求、定义验收标准、识别测试范围 | 可测试性报告、RTM 初稿 |
| 2. 测试计划 | 制定策略、资源、工具、风险应对 | 测试计划文档 |
| 3. 测试设计 & 测试开发 | 编写用例 + 开发自动化脚本/工具/框架 | 测试用例、自动化代码、测试数据 |
| 4. 测试执行 | 手工/自动化执行、缺陷管理、回归测试 | 缺陷报告、测试日志、执行结果 |
| 5. 测试评估 | 分析覆盖率、缺陷趋势、质量风险，给出发布建议 | 测试评估报告、发布决策建议 |
| 6. 上线 | 参与发布评审、执行上线验证（冒烟/健康检查） | 上线验证报告 |
| 7. 运行维护 | 监控线上质量、复现问题、优化测试覆盖 | 线上问题分析报告、测试资产迭代 |
什么是Bug？
定义：一个计算机bug指在计算机程序中的一个错误、缺陷、疏忽或故障，这些bug使程序使无法正确的运行。
Bug产生于程序的源代码或程序设计阶段的疏忽或者错误
那么回归到软件测试中呢，bug可以更加准确来说：
1.当且仅当需求规格说明书是存在的并且正确，程序与规格说明之间的不匹配才是错误
2.当需求规格说明书没有提到的功能，判断标准以最终用户为准，当程序没有实现其最终用户合理预期的功能要求时，就是软件错误
如何描述一个Bug
以下是一个基础骨架
| 要素 | 说明 | 示例 |
| 1. 出现的版本（Version） | 软件/APP/服务的具体版本号 | v2.3.1、Build #1285 |
| 2. 问题环境（Environment） | 操作系统、浏览器、设备型号、网络、数据库等 | iOS 16.5 / iPhone 13；Chrome 124；测试环境（test-env） |
| 3. 复现步骤（Steps to Reproduce） | 清晰、有序、可操作的操作步骤 | 1. 打开APP → 2. 点击“我的” → 3. 输入错误密码5次… |
| 4. 预期结果（Expected Result） | 按需求或设计应有的行为 | 账户应被锁定30分钟，并提示“账号已锁定” |
| 5. 实际结果（Actual Result） | 当前系统实际表现 | 页面无任何提示，仍可继续输入密码 |
当然，除了这些，还可以进行其他一些要素扩展：
严重程度、优先级、复现频率、附件、相关模块、缺陷类型、初步根因分析…………
值得一提的是，提交这个bug报告最好遵守以下原则
可复现（Reproducible）：步骤清晰，别人能按描述复现。
简洁明确（Concise & Clear）：避免模糊词如“有时候”“好像”。
信息完整（Complete）：一次提交包含所有必要上下文，减少来回沟通。
客观中立（Objective）：描述事实，不带情绪（如“开发又写错了！”）
Bug级别
是软件测试中用户衡量缺陷对系统影响的程度的关键指标，直接影响修复优先级，资源分配和发布决策
常见的定级：
| 级别 | 名称 | 定义 | 典型场景示例 |
| 1 | Blocker（阻塞性） （或 Critical） | 系统无法使用、核心流程完全中断，或存在重大安全/数据风险。 | - 系统崩溃、闪退 - 数据库连接失败 - 支付接口被绕过 - 用户数据泄露 |
| 2 | Critical（严重） | 核心功能失效，但有临时绕过方式；或严重影响多数用户。 | - 登录失败（但可用短信验证码） - 订单无法提交 - 搜索功能完全无结果 |
| 3 | Major（一般） | 非核心功能缺陷，或核心功能部分异常，影响体验但可接受。 | - 按钮文字错误 - 列表排序错乱 - 图片加载慢 - 次要流程报错 |
| 4 | Minor（轻微） （或 Trivial / Cosmetic） | 界面、文案、样式等不影响功能的小问题。 | - 字体颜色不一致 - 标点符号错误 - 图标轻微偏移 |
那么如何去定义这个Bug级别呢？
以下是一些简易的判断方法
| 维度 | 高级别（Blocker/Critical） | 低级别（Major/Minor） |
| 是否阻断主流程 | 是（如无法注册、支付失败） | 否（如帮助页打不开） |
| 影响用户范围 | 全量用户 / 核心用户 | 少数用户 / 边缘场景 |
| 是否导致数据错误/丢失 | 是（如订单金额计算错误） | 否（如页面加载慢2秒） |
| 是否存在安全/合规风险 | 是（如越权访问、明文密码） | 否 |
| 是否有临时解决方案 | 无 | 有（如刷新页面可恢复） |
Bug生命周期
是指一个缺陷从被测试人员发现、提交，经过开发修复、测试验证，直到最终关闭或延迟的全过程所经历的状态序列
如下图：
解释如下图所示：
| 状态 | 说明 |
| 1. New（新建） | 测试人员首次提交 Bug，尚未被确认。 |
| 2. Open / Assigned（已分配） | Bug 被确认有效，分配给对应开发人员处理。 |
| 3. Fixed / Resolved（已修复） | 开发完成修复，提交代码，等待测试验证。 |
| 4.Rejected（拒绝 | 开发认为不是 Bug（如需求如此、无法复现） |
| 5. Reopened（重新打开） | 测试验证未通过，Bug 重新打开并返回开发。 |
| 6. Closed（已关闭） | 测试验证通过，Bug 正式关闭。 |
在这个Bug方面，有一个常见高频考题:
与开发人员产生争执怎么办？
解决思路：
1.先检查自身，是否是bug描述不清楚
2.站在用户的角度考虑并抛出问题，可以争执过程中，问上一句：如果你是用户，你可以接受吗？
3.Bug定级要有理有据
4.提高自身技术和业务水平，做到不仅能题出问题，最好也能提出解决方案
5.bug评审（这是最后关头）
那么对于软件测试中的bug，就分享到这里，接下来分享下软件测试中的测试用例
测试用例
什么是测试用例？
它是软件测试中用于验证一个特定的功能或路径是否按预期工作的具体集合、执行条件以及语气结果的文档化描述。它是用来检查应用程序是否满足了业务需求和技术要求的关键工具之一。
测试用例的主要组成部分包括：
测试用例ID：每个测试用例都有一个唯一的标识符，以便于跟踪和管理。
测试项/标题：简短地描述测试的目的或者要验证的功能点。
前置条件：在执行测试用例之前需要满足的条件或环境设置。例如，用户必须登录系统等。
测试步骤：详细列出为了达到测试目的所需执行的操作步骤。
测试数据：提供给系统的输入值，这些数据对于验证软件行为非常重要。
预期结果：根据提供的输入数据，系统应该表现出的行为或输出结果。
实际结果（执行后填写）：当测试被执行时，记录下实际得到的结果。
状态：表明测试用例执行后的状态，如通过、失败、未执行等。
优先级：定义测试用例的重要性和执行顺序。
负责人：负责编写、执行或审核该测试用例的人员
如何设计测试用例呢？
正确设计测试用例的思想：常规思维+逆向思维+发散性思维
当然，思想有了，这里也讲一些具体的方法
设计测试用例方法：
基于需求的设计方法
这个方法的核心理念是：
1.每一条需求都必须被测试
2.每一个测试用例都必须追溯到某条需求
其核心思想是：
| 关键点 | 说明 |
| 需求是测试的源头 | 测试不是凭空想象，而是对需求的验证。 |
| 可追溯性（Traceability） | 建立 需求 ↔ 测试用例 的双向映射（通常通过需求跟踪矩阵 RTM 实现）。 |
| 覆盖完整性 | 目标是实现 100% 需求覆盖（功能 + 非功能）。 |
| 避免过度测试 | 只测“需求里有的”，不测“需求里没有的”（除非是探索性测试）。 |
等价类：
它是一种黑盒测试技术，它将所有可能的输入数据划分为若干个”等价类“，每个类的任意一个输入，其测试结果具有代表性。因此，只需从每个等价类中选取一个典型值来测试，即可覆盖该类的所有情况
核心思想：
1.如果一个等价类中的某个值能发现缺陷，那么该类中其他值也能发现相同缺陷
2.如果一个等价类某个值不能发现缺陷，那么该类中其他值大概率也不能
等价类分为两类
| 类型 | 说明 | 测试目标 |
| 有效等价类（Valid EC） | 符合需求规范的合法输入 | 验证系统正常处理能力 |
| 无效等价类（Invalid EC） | 不符合需求的非法、异常或边界外输入 | 验证系统容错与错误处理能力 |
通常是：1 个有效类 + 多个无效类
设计步骤（通用）：
分析输入条件 明确被测功能的输入字段、类型、范围、格式等（如：年龄、手机号、密码强度）。
划分等价类
根据需求，将输入域划分为若干有效/无效等价类。
注意：无效类应彼此独立（一个无效类只违反一个规则）。
为每个等价类设计测试用例
有效类：至少选 1 个代表值。
无效类：每个无效类单独设计 1 个用例（避免多个错误混在一起，掩盖问题）。
补充边界值（通常与边界值分析法结合使用）
正交法：
全称：正交试验设计法，是一种高效的多因素组合测试用例设计方法，特别适用于输入参数多，组合爆炸的场景。它能在大幅减少测试用例的数量同时，保持较高的缺陷检出能力。
核心思想：
软件缺陷大多由 1~2 个参数的交互 引起（研究显示：约 70% 的缺陷由两因素组合触发，90% 由三因素以内触发）。
正交法优先保证两两组合覆盖（Pairwise Coverage），而非穷举所有组合。
用数学方法（正交表）确保均衡、无偏、高效的采样。
举例： 若有 4 个参数，每个有 3 个取值，
穷举组合：3⁴ = 81 种
正交法（L9 表）：仅需 9 种 → 减少 89% 用例，仍覆盖所有两两组合！
设计步骤：
识别输入因素（Factors）和水平（Levels）
因素 = 输入参数（如：操作系统、浏览器、语言）
水平 = 每个参数的可选值（如：Win/Mac；Chrome/Firefox/Safari）
选择合适的正交表
常用符号：Lₙ(qᵏ)
n：测试用例数，代表表中，有几行q：每个因素的水平数（通常要求各因素水平数相同或近似）k：最多可安排的因素数
常见正交表：L4(2³)、L8(2⁷)、L9(3⁴)、L16(4⁵) 等
映射因素到正交表列
将实际参数填入正交表的列中
生成测试用例
每一行对应一个测试用例
补充约束或高风险组合（可选
判定表法：
它是一种结构化、逻辑驱动的黑盒测试用例设计方法，特别适合于业务规则复杂，输入条件组很多，输出结果依赖多个条件判断的场景（如金融审批、折扣计算、权限控制等）
标准判断表的组成：
| 部分 | 说明 |
| 1. 条件桩（Condition Stubs） | 列出所有输入条件（如“用户是否 VIP”“订单金额 > 100”） |
| 2. 条件项（Condition Entries） | 每个条件的可能取值（通常用 Y/N、T/F 或具体值表示） |
| 3. 动作桩（Action Stubs） | 列出所有可能的系统动作或输出结果（如“打 9 折”“发送优惠券”） |
| 4. 动作项（Action Entries） | 在每种条件组合下，应执行的动作（用 √ / × 或 “是/否” 表示） |
设计步骤：
分析需求，识别所有输入条件
条件应是布尔型或可枚举型（如“年龄≥18”“支付方式=微信”）
识别所有可能的动作/输出结果
如“允许注册”“拒绝下单”“计算运费=0”
构造判定表
列出所有条件组合（理论上为 2ⁿ，n=条件数）
根据业务规则，填写每种组合对应的动作
简化判定表（合并冗余规则）
若某些条件不影响结果，可合并列（使用 “-” 表示“无关”）
为每列（规则）设计一个测试用例
举例一个经典示例：电商满减优惠
需求规则：
若用户是 VIP 且订单金额 ≥ 200 元，则打 8 折
若订单金额 ≥ 100 元（无论是否 VIP），则包邮
其他情况无优惠
步骤 1：识别条件与动作
条件：
C1：是否 VIP（Y/N）
C2：订单金额 ≥ 200？（Y/N）
C3：订单金额 ≥ 100？（Y/N）
注意：C2 为真 ⇒ C3 必为真，存在逻辑依赖
动作：
A1：打 8 折
A2：包邮
步骤 2：构造初始判定表（考虑逻辑约束后）
| 规则编号 | R1 | R2 | R3 | R4 |
| 条件 | ||||
| C1: VIP？ | N | N | Y | Y |
| C2: ≥200？ | N | Y | N | Y |
| C3: ≥100？ | N | Y | Y | Y |
| 动作 | ||||
| A1: 打8折 | × | × | × | √ |
| A2: 包邮 | × | √ | √ | √ |
说明：
R1：非VIP，<100 → 无优惠
R2：非VIP，≥100但<200 → 仅包邮
R3：VIP，100~199 → 仅包邮（不满足≥200，不打折）
R4：VIP，≥200 → 打8折 + 包邮
步骤 3：生成测试用例
| 用例ID | VIP | 订单金额 | 预期结果 |
| TC_PROMO_01 | 否 | 80 | 无折扣，不包邮 |
| TC_PROMO_02 | 否 | 150 | 无折扣，包邮 |
| TC_PROMO_03 | 是 | 150 | 无折扣，包邮 |
| TC_PROMO_04 | 是 | 250 | 打8折，包邮 |
那么还有很多设计测试用例的方法，小编这里就不一一介绍。
当然，可能工作中不常用这些方法，但是这些方法也是起到了拓展思维的用处。
那么有两点值得注意是：
1.工作中常用的脑图或是思维导图来进行设计测试用例的
2为了遇到一般性产品，可以快速想出更多测试用例，这里提供一个万能公式：
测试用例万能公式：
功能测试+界面测试+性能测试+兼容测试+易用测试+安全测试+弱网测试+安装卸载测试（可选）
具体内容如下：
| 维度 | 测试目标 | 典型测试内容 | 示例 |
| 1. 功能测试 （Functional Testing） | 验证系统是否按需求规格正确实现功能 | - 正常业务流程（Happy Path） - 异常处理（错误输入、边界值） - 业务规则（如折扣、权限） - 数据一致性（增删改查） | - 用户注册成功 - 密码错误5次锁定账户 - 订单金额计算正确 |
| 2. 界面测试 （UI / UX Testing） | 验证界面是否符合设计规范，用户体验是否良好 | - 布局对齐、字体、颜色 - 控件可用性（按钮可点击、输入框可编辑） - 提示信息清晰（错误/成功提示） - 响应式适配（横竖屏、缩放） | - 登录页Logo位置正确 - “提交”按钮点击后有加载状态 - 表单必填项标红提示 |
| 3. 性能测试 （Performance Testing） | 验证系统在负载下的响应速度、稳定性、资源消耗 | - 响应时间（如页面加载 ≤ 2s） - 并发用户支持（如支持1000人同时下单） - 系统吞吐量（TPS/QPS） - 资源监控（CPU、内存、DB连接） | - 首页接口平均响应时间 800ms - 高峰期系统无宕机 - 内存泄漏检测 |
| 4. 兼容性测试 （Compatibility Testing） | 验证系统在不同环境下的表现一致性 | - 操作系统（Windows/macOS/iOS/Android） - 浏览器（Chrome/Firefox/Safari/Edge） - 设备型号（iPhone/华为/小米） - 分辨率 & 屏幕尺寸 | - 在 Safari 上支付流程正常 - 华为手机上APP不闪退 - 1366x768 分辨率下布局不错乱 |
| 5. 易用性测试 （Usability Testing） | 验证产品是否易于学习、操作和理解 | - 操作流程是否简洁 - 是否有帮助提示/引导 - 是否符合用户习惯 - 错误恢复是否容易 | - 新用户3步完成注册 - 支付失败后有明确指引 - 返回按钮逻辑符合直觉 |
| 6. 安全测试 （Security Testing） | 验证系统是否能抵御常见安全威胁 | - SQL注入、XSS攻击 - 越权访问（水平/垂直权限） - 敏感信息加密（密码、手机号） - 会话管理（Token有效期、退出登录） | - 输入 <script> 不执行 - 普通用户无法访问管理员接口 - HTTPS 传输 |
| 7. 弱网测试 （Network Resilience Testing） | 验证在网络不稳定下的用户体验与容错能力 | - 高延迟（如 300ms+） - 低带宽（2G/3G） - 网络切换（WiFi ↔ 4G） - 网络中断后恢复 | - 弱网下图片加载有占位符 - 网络断开时提示“请检查网络” - 重连后自动续传 |
| 8. 安装卸载测试 （Installation/Uninstallation Testing） （可选，主要针对客户端） | 验证安装/升级/卸载过程是否顺畅、干净 | - 安装包完整性 - 安装过程无报错 - 升级后数据保留 - 卸载后无残留文件/注册表 | - Android APK 安装成功 - 从 v1.0 升级到 v2.0 配置不丢失 - 卸载后无缓存残留 |
这里值得一提的是，在安全测试中，越权访问中的水平越权和垂直越权如下：
水平越权：即通俗理解，同事A可以访问同事B的空间，并操作
垂直越权：即通俗理解，同事A可以访问到领导的空间，并操作