BUG与测试用例
今天小编来继续分享下关于软件测试中的BUG和测试用例
BUG
讲这个BUG之前，得首先提一下什么是软件测试生命周期
软件测试的生命周期：
需求分析——>测试计划——>测试设计、测试开发——>测试执行——>测试评估——>上线——>运行维护
具体内容如下：
什么是Bug？
定义：一个计算机bug指在计算机程序中的一个错误、缺陷、疏忽或故障，这些bug使程序使无法正确的运行。
Bug产生于程序的源代码或程序设计阶段的疏忽或者错误
那么回归到软件测试中呢，bug可以更加准确来说：
1.当且仅当需求规格说明书是存在的并且正确，程序与规格说明之间的不匹配才是错误
2.当需求规格说明书没有提到的功能，判断标准以最终用户为准，当程序没有实现其最终用户合理预期的功能要求时，就是软件错误
如何描述一个Bug
以下是一个基础骨架
当然，除了这些，还可以进行其他一些要素扩展：
严重程度、优先级、复现频率、附件、相关模块、缺陷类型、初步根因分析…………
值得一提的是，提交这个bug报告最好遵守以下原则
可复现（Reproducible）：步骤清晰，别人能按描述复现。
简洁明确（Concise & Clear）：避免模糊词如“有时候”“好像”。
信息完整（Complete）：一次提交包含所有必要上下文，减少来回沟通。
客观中立（Objective）：描述事实，不带情绪（如“开发又写错了！”）
Bug级别
是软件测试中用户衡量缺陷对系统影响的程度的关键指标，直接影响修复优先级，资源分配和发布决策
常见的定级：
那么如何去定义这个Bug级别呢？
以下是一些简易的判断方法
Bug生命周期
是指一个缺陷从被测试人员发现、提交，经过开发修复、测试验证，直到最终关闭或延迟的全过程所经历的状态序列
如下图：
解释如下图所示：
在这个Bug方面，有一个常见高频考题:
与开发人员产生争执怎么办？
解决思路：
1.先检查自身，是否是bug描述不清楚
2.站在用户的角度考虑并抛出问题，可以争执过程中，问上一句：如果你是用户，你可以接受吗？
3.Bug定级要有理有据
4.提高自身技术和业务水平，做到不仅能题出问题，最好也能提出解决方案
5.bug评审（这是最后关头）
那么对于软件测试中的bug，就分享到这里，接下来分享下软件测试中的测试用例
测试用例
什么是测试用例？
它是软件测试中用于验证一个特定的功能或路径是否按预期工作的具体集合、执行条件以及语气结果的文档化描述。它是用来检查应用程序是否满足了业务需求和技术要求的关键工具之一。
测试用例的主要组成部分包括：
测试用例ID：每个测试用例都有一个唯一的标识符，以便于跟踪和管理。
测试项/标题：简短地描述测试的目的或者要验证的功能点。
前置条件：在执行测试用例之前需要满足的条件或环境设置。例如，用户必须登录系统等。
测试步骤：详细列出为了达到测试目的所需执行的操作步骤。
测试数据：提供给系统的输入值，这些数据对于验证软件行为非常重要。
预期结果：根据提供的输入数据，系统应该表现出的行为或输出结果。
实际结果（执行后填写）：当测试被执行时，记录下实际得到的结果。
状态：表明测试用例执行后的状态，如通过、失败、未执行等。
优先级：定义测试用例的重要性和执行顺序。
负责人：负责编写、执行或审核该测试用例的人员
如何设计测试用例呢？
正确设计测试用例的思想：常规思维+逆向思维+发散性思维
当然，思想有了，这里也讲一些具体的方法
设计测试用例方法：
基于需求的设计方法
这个方法的核心理念是：
1.每一条需求都必须被测试
2.每一个测试用例都必须追溯到某条需求
其核心思想是：
等价类：
它是一种黑盒测试技术，它将所有可能的输入数据划分为若干个”等价类“，每个类的任意一个输入，其测试结果具有代表性。因此，只需从每个等价类中选取一个典型值来测试，即可覆盖该类的所有情况
核心思想：
1.如果一个等价类中的某个值能发现缺陷，那么该类中其他值也能发现相同缺陷
2.如果一个等价类某个值不能发现缺陷，那么该类中其他值大概率也不能
等价类分为两类
通常是：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⁵) 等
映射因素到正交表列
将实际参数填入正交表的列中
生成测试用例
每一行对应一个测试用例
补充约束或高风险组合（可选
判定表法：
它是一种结构化、逻辑驱动的黑盒测试用例设计方法，特别适合于业务规则复杂，输入条件组很多，输出结果依赖多个条件判断的场景（如金融审批、折扣计算、权限控制等）
标准判断表的组成：
设计步骤：
分析需求，识别所有输入条件
条件应是布尔型或可枚举型（如“年龄≥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：非VIP，<100 → 无优惠
R2：非VIP，≥100但<200 → 仅包邮
R3：VIP，100~199 → 仅包邮（不满足≥200，不打折）
R4：VIP，≥200 → 打8折 + 包邮
步骤 3：生成测试用例
那么还有很多设计测试用例的方法，小编这里就不一一介绍。
当然，可能工作中不常用这些方法，但是这些方法也是起到了拓展思维的用处。
那么有两点值得注意是：
1.工作中常用的脑图或是思维导图来进行设计测试用例的
2为了遇到一般性产品，可以快速想出更多测试用例，这里提供一个万能公式：
测试用例万能公式：
功能测试+界面测试+性能测试+兼容测试+易用测试+安全测试+弱网测试+安装卸载测试（可选）
具体内容如下：
这里值得一提的是，在安全测试中，越权访问中的水平越权和垂直越权如下：
水平越权：即通俗理解，同事A可以访问同事B的空间，并操作
垂直越权：即通俗理解，同事A可以访问到领导的空间，并操作
