> ## Documentation Index > Fetch the complete documentation index at: https://devdocs.xbox.com/llms.txt > Use this file to discover all available pages before exploring further. # 失效模式分析（FMA）参考概览 > XBOX 认证 FMA 框架 —— 用于将问题一致地分类为 CFR、SRI 或 ION 的严重性、可能性与可复现性评分。 # XBOX 认证失效模式分析（FMA） *提升测试中决策的一致性、质量与相关性。* ## 摘要 认证工作需要在保证决策准确一致的同时，让团队仅将时间投入到真正有价值的问题上。 ## 简介 认证团队每年会做出数千次决策，用以判定问题的严重性与不合规性。 在一个跨区域业务、并拥有从一线测试员到组长、经理和软件工程师等多层内部评估的组织中，做到决策一致本身就是一项挑战。 FMA 提供了一个严格的框架，让所有相关人员都能快速且一致地做出关键决策，同时通过标记那些被认为过于轻微、无需完整记录的问题，节省大量时间。 ## 概览 FMA 提供一个为每个问题分配三种不同分数的框架：**严重性**、**可能性** 与 **可复现性**。这三项分数之和决定了问题类型，为以下之一。 * **Condition for Resubmission (CFR)：** 这些问题严重到在开发者修复并重新提交之前无法发售，或者可以通过在特定时间范围内（通常是终端用户交互的第 1 天前）发布的内容更新来修复。 * **Standard Reporting Issue (SRI)：** 这些问题较为严重，但严重程度还不足以阻止提交发布。 * **Issue of Note (ION)：** 这些 SRI 问题无法直接映射到已有的测试用例。 判定每个问题归属的逻辑推进部分依赖于测试用例的措辞，以及对该事件在零售环境中发生的可能性与可复现性的个人判断。 为覆盖所有决策场景，严重性、可能性与可复现性这三个关键概念被统一放在一处。这样的做法虽然可行，但会需要一个可能包含数万条记录的数据库以覆盖所有可能情形。 将问题拆分为组成部分很重要，可以避免为描述某个结果而列出大量条目。对认证而言，FMA 使用了一个具有以下变量的系统。 * **严重性（Severity）：** 六种可能的结果 * **可能性（Probability）：** 六种可能的结果 * **可复现性（Repeatability）：** 六种可能的结果 严重性（如下一节所述）由描述性字符串组成，因此需要一个场景数据库来整理数据。可能性与可复现性则均由问题本身通过数学方法推导而来。 通过保持这种分离，仅需为每个测试用例定义 6 个严重性场景，就能覆盖 216 种可能。根据测试用例的复杂程度，实际数目可能略多，但不会多太多。 通过编写 6 条严重性陈述，并单独应用可能性与可复现性的数学计算，就能获得与写出 216 个独立场景等价的效果。同时你也获得了可管理性与易用性上的好处。 ## FMA 的第一块基石：严重性 严重性使你能够在不考虑事件之外因素的情况下，定义一个问题有多严重。 FMA 将不同的严重性等级拆分为一个易于使用的层级。围绕认证的需要，产生了以下严重性等级。 | 严重性评级 | 含义 | | ----- | --------------------------- | | -4 | 对用户或平台没有相关影响。 | | 1 | 对用户或平台影响极小。 | | 2 | 对用户或平台影响较小。 | | 6 | 对用户或平台影响中等。 | | 12 | 对用户或平台影响严重。 | | 22 | 灾难性（高业务影响 / HBI）。例如，产品无法运行。 | 这六种可能类别定义了每个问题，从无影响到影响极高。通过总体评级练习，为每个类别得出了加权评分。 这些评级构成框架中稳健的一部分，因为在多个个体之间将问题一致地归到正确的类别相对容易。我们没有满足于此，而是选择针对每个测试用例调整具体步骤，以创建一个高度易用、并能反映特定测试用例特殊性的系统。 一个示例是耳机状态变更（HSC）。 **图 1. HSC 示例。** HSC 示例 严重性陈述采用两种具体形式。第一种形式以聚焦的陈述覆盖大多数问题。例如，*"游戏在耳机状态变化后表现出中等程度的音频破损/失真，影响了用户体验。"* 这种风格让测试团队能够就严重性把问题准确分到正确的类别。 第二种风格更加具体。例如，*"游戏在耳机状态变化后不再通过电视或耳机输出音频。"* 这种风格捕捉在实验室中经常观察到的具体行为，让问题的归类不留疑问。 ## FMA 的第二块基石：可能性 可能性让我们评估终端用户可能遭遇某个问题的可能性。使用与严重性类似的表格，但做了修改。 | 可能性 | 评分 | | ------------------------------------------------------ | -- | | **极不可能** 发生：0–10% 的用户会执行可能触发该问题的步骤。 | -3 | | **偶发（Remote）：** 11–20% 的用户会执行可能触发该问题的步骤。 | 2 | | **偶尔（Occasional）：** 21–40% 的用户会执行可能触发该问题的步骤。 | 3 | | **中等（Moderate）：** 41–70% 的用户会执行可能触发该问题的步骤。 | 4 | | **频繁（Frequent）：** 71–90% 的用户会执行可能触发该问题的步骤。 | 6 | | **几乎必然（Almost Inevitable）：** 91–100% 的用户会执行可能触发该问题的步骤。 | 8 | 示例： 1. 该问题在启动游戏时发生。可能性 = 8。 2. 该问题在加入在线会话时发生。可能性 = 4。 3. 该问题仅在某一游戏模式内的一个特定子菜单中发生，其他地方不发生。可能性 = -3。 评估存在一定的主观性。然而，即使测试员做出略有不同的判断，系统仍能保持可靠并产生正确的最终结果。 ## FMA 的第三块基石：可复现性 可复现性表示在最初出现后，终端用户再次遭遇该问题的可能性。使用与严重性和可能性类似的表格，但做了修改。 | 可复现性 | 评分 | | --------------- | -- | | 问题不会再次发生 | -3 | | 低 | 2 | | 中 | 3 | | 高 | 4 | | 在首次事件之后几乎必然再次发生 | 5 | | 在首次事件之后必然再次发生 | 6 | 与可能性一样，请使用测试结果中的频次数值。例如： **频次：** * 主机 1：5/5 * 主机 2：4/5 要计算数值，将成功复现的尝试数（第一个数字）加总，再除以尝试总次数（第二个数字）的总和。将该结果乘以 6 得到最终数值。在此示例中，计算为：9 ÷ 10 × 6 = 5.4，即最终可复现性数值为 5。 ## FMA 评分详解 在正确使用这三个系统后，你将得到三个数字。把它们相加得到最终分数，然后映射到一个问题类型： | 分数区间 | 问题类型 | | ------- | ------------------------------------- | | 18 到 36 | **CFR** —— Condition for Resubmission | | 14 到 17 | **SRI** —— Standard Reporting Issue | | 13 及以下 | **INT** —— Internal / Issue of Note | ## Related topics - [XR 失败模式分析](/zh-CN/publishing/certification/xr-fma.md) - [PlayFab REST API 参考概览](/zh-CN/services/playfab/api-references/index.md) - [认证分步指南](/zh-CN/publishing/game-publishing/concepts/certification/certification-guide.md) - [Unity 概览](/zh-CN/paths/unity/overview.md) - [PartyXboxLive C/C++ API 概览](/zh-CN/services/playfab/multiplayer/networking/xblreference/partyxboxlive_members.md)