> ## Documentation Index
> Fetch the complete documentation index at: https://docs.xbox.com/llms.txt
> Use this file to discover all available pages before exploring further.

# FMA 概览

> 认证如何使用 FMA 按严重性、发生概率和可重复性对问题评分，并将其归类为 CFR、SRI 或 ION，以确保决策一致。

***

## 提升测试中决策的一致性、质量与相关性

## 摘要

认证需要确保决策准确且一致，同时确保团队只将时间投入到真正有价值的问题上。

## 简介

认证团队每年会做出数千项决策，以判定问题的严重性和不合规程度。

在一个既跨区域、又拥有多层内部评估（从一线测试人员到组长、经理和软件工程师）的业务中，做出一致的决策是一项挑战。

FMA 提供了一个严格的框架，使所有参与人员都能快速、一致地做出关键决策，同时通过标记那些被认为过于轻微而无需完整记录的问题，节省大量时间。

## 概述

FMA 提供了一个为每个问题分配三种不同分数的框架：严重性、可能性和可重复性。这些分数的总和决定了问题属于以下哪种类型。

* **Condition for Resubmission (CFR)：** 这些问题严重到在开发者通过重新提交修复问题之前，游戏无法发布；或者该问题可以通过在特定时间范围内（通常是在最终用户开始交互的第一天之前）交付的内容更新来修复。
* **Standard Reporting Issue (SRI)：** 这些问题较为严重，但其严重程度还不足以阻止该提交发布。
* **Issue of Note (ION)：** 这些 SRI 问题无法直接映射到现有的测试用例。

决定每个问题归属的逻辑推进，部分基于测试用例的措辞，部分基于对该事件在零售环境中发生的可能性和可重复性的个人评估。

为了服务于决策的所有方面，严重性、可能性和可重复性这几个关键概念被集中在一处。这种方法虽然可行，但需要一个可能包含数万条条目的数据库来涵盖所有可能的情况。

将问题拆分为各个组成部分非常重要，这样可以避免为描述一个结果而需要过多的条目。
对于认证，FMA 使用具有以下变量的系统。

* **严重性：** 六种可能的结果
* **可能性：** 六种可能的结果
* **可重复性：** 六种可能的结果

严重性（详见下一节）由描述性字符串组成，因此需要一个场景数据库来对数据进行排序。可能性和可重复性则都是通过数学方法从问题本身中提取的。

通过保持这种分离，每个测试用例只需六个严重性场景，即可对 216 种可能性进行排序。根据测试用例的复杂程度，这个数字可能会更多，但不会多出很多。

通过编写六条陈述，并分别应用可能性和可重复性的数学计算，你可以获得与编写 216 个单独场景相同的价值，同时还能获得易于管理和易于使用的好处。

## FMA 的第一个构建基块：严重性

严重性使你能够在不考虑事件之外任何因素的情况下，界定问题的严重程度。

FMA 分析将不同的严重性级别分解为一个易于使用的层级结构。针对认证的需求，制定了以下严重性等级。

| 严重性评级 | 含义 |
| - | - |
| -4 | 对用户或平台没有相关影响。 |
| 1 | 对用户或平台的影响非常轻微。 |
| 2 | 对用户或平台的影响轻微。 |
| 6 | 对用户或平台的影响中等。 |
| 12 | 对用户或平台的影响严重。 |
| 22 | 灾难性（High Business Impact (HBI)。例如，产品无法运行）。 |

这六个可能的类别定义了每个问题，从无影响到影响极大。通过一次整体评级工作，为每个类别创建了加权评级。

这些评级构成了框架中稳健的一部分，因为在多人之间一致地将问题分配到正确类别相对简单直接。我们没有止步于这种方法，而是选择按测试用例修改各个级别，从而创建一个高度易用、并能反映特定测试用例特点的系统。

一个示例是耳机状态更改（Headset State Change，HSC）。

**图 1. HSC 示例。**

![HSC 示例](https://mintcdn.com/microsoft-4404708b/N3T1ucKV7zIMBudj/images/policies/HeadsetState.jpg?fit=max\&auto=format\&n=N3T1ucKV7zIMBudj\&q=85\&s=21454619f3a19639114b3da2d0d813ff)

请注意它们采用两种特定形式。第一种形式以重点明确的陈述涵盖大多数问题。例如，“耳机状态更改后，游戏出现中等程度的音频损坏/失真，影响了用户体验。”

这种形式使测试团队能够就严重性为问题准确分配正确的类别。

第二种形式更为具体。例如，“耳机状态更改后，游戏停止通过电视或耳机输出音频。”

这种形式涵盖了实验室中经常出现的特定行为，使问题的分配方式毫无疑义。

## FMA 的第二个构建基块：可能性

定义：可能性使我们能够评估最终用户可能接触到某个给定问题的可能性有多大。

我们使用与严重性类似的表格，但做了一些修改。

| 可能性 | 评级 |
| - | - |
| 极不可能发生：0-10% 的用户会执行可能导致该问题出现的步骤。 | -3 |
| 很少：11-20% 的用户会执行可能导致该问题出现的步骤。 | 2 |
| 偶尔：21-40% 的用户会执行可能导致该问题出现的步骤。 | 3 |
| 中等：41-70% 的用户会执行可能导致该问题出现的步骤。 | 4 |
| 频繁：71-90% 的用户会执行可能导致该问题出现的步骤。 | 6 |
| 几乎不可避免：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 x 6 = 5.4，即最终的可重复性值为 5。

## FMA 评分说明

正确使用这三个系统后，你会得到三个数字。将这些数字相加即可得到最终分数。

**图 2. FMA 评分示例。**

![FMA 评分示例。](https://mintcdn.com/microsoft-4404708b/N3T1ucKV7zIMBudj/images/policies/FMAScore.jpg?fit=max\&auto=format\&n=N3T1ucKV7zIMBudj\&q=85\&s=9bbdeb41d5cc746b8f27c71a48ae0d1d)


## Related topics

- [Unity 概览](https://docs.xbox.com/zh-CN/paths/unity/overview.md)
- [发布你的移植版本](https://docs.xbox.com/zh-CN/paths/porting/publishing.md)
- [Unreal Engine 概览](https://docs.xbox.com/zh-CN/paths/unreal/overview.md)
- [目录概览](https://docs.xbox.com/zh-CN/services/playfab/economy-monetization/economy-v2/catalog/catalog-overview.md)
- [游戏概览](https://docs.xbox.com/zh-CN/services/playfab/data-analytics/learn-data/reports/title-overview-report.md)