功能性缺陷（Functional Bugs）
功能性缺陷与软件的功能相关。
示例：
按钮无法提交表单
搜索对用户输入没有反应
应用程序崩溃
每当你执行操作，而网站或应用没有按预期响应时，可能就是功能性问题。由于我们对客户产品的信息有限，对其实现方式缺乏了解，很难判断观察到的行为是故意设计的还是实际的缺陷。基于经验做出合理推测，并通过测试不同场景分析产品行为，有助于你判断问题。
如何判断应用行为是否为功能性缺陷
尝试判断功能是否按特定方式设计，还是确实存在问题。单独测试该功能，并与其他功能组合使用以发现潜在差异。
考虑客户的意图，产品可能只是按照他们的实现方式工作。
找到某功能未按预期工作的证据，支持你的判断。
示例：
一个电商网站的功能与其他网站不同，这并不意味着功能有问题。客户可以自由实现他们的产品。
你声称某表单字段没有进行验证，这是一个缺陷。是否有迹象表明他们打算验证该字段？提供证据，显示字段在某些情况下被验证，而在其他情况下未被验证。没有证据，则是未经证实的主张。
注意：
当视觉或内容问题妨碍功能时，应将其作为功能性缺陷报告。
如果某功能在不同场景下始终正常工作且无明显问题，则可能是设计意图（非缺陷），你可以提出改进建议（可用性建议）。
严重性评估（Severity Assessment）
评估功能性缺陷严重性时需考虑多个因素：
功能影响
问题范围
是否存在变通方法或是否为阻断性缺陷
潜在销售损失
可与同等级别其他缺陷对比
方法：
首先考虑功能影响：功能不可用有多严重？
判断受影响用户、产品或项目数量。
考虑是否有替代方法完成目标。可行变通方法会降低严重性。
没有变通方法的主要功能缺陷属于阻断性缺陷（showstopper）。
潜在销售损失为次要评估因素，但仍需考虑损失程度。
提示： 可将缺陷与团队领导已批准的缺陷进行对比，以确认严重性评估是否适当。
功能性缺陷严重性等级
低（LOW）
对产品使用影响最小
产品行为异常，但整体使用不受影响
受影响用户/产品数量少
功能损坏或不可用，但简单变通方法可解决
高（HIGH）
对产品使用有严重影响，但主要功能仍可用
受影响用户/产品数量多
关键功能损坏且无简单变通方法
重要功能损坏，但存在变通方法（非阻断性）
严重（CRITICAL）
阻止应用或网站核心功能使用
阻断性缺陷阻止用户完成主要流程，例如结账
导致潜在重大销售损失
常见评估
我们有一份固定严重性等级的案例列表。上述评估方法不适用于列表中的案例。
边缘案例缺陷（Edge Case Bugs）
边缘案例缺陷在功能被非典型方式使用时出现。使用典型数据和操作时功能正常。
示例：
点击按钮后立即最小化应用
重复相同操作，例如反复打开/关闭菜单
仅在非典型操作序列下出现的缺陷
评估：
对客户相关 → 报告为低（LOW）缺陷
无关 → 通常被拒绝
强制缺陷（Forced Bugs）
通过非典型行为或特殊条件触发的缺陷通常不在范围内，因为客户不关心此类问题。非典型行为不代表正常用户行为。
示例：
同时点击多个元素
随机点击按钮
快速连续点击按钮
将窗口缩小到非典型尺寸
内存满导致异常行为
使用非官方、测试版或修改过的操作系统