先厘清指标：平均帧率、1% Low与帧生成时间

游戏帧率测试并非只记录一个“平均 FPS”数字。平均帧率反映一段时间内的整体渲染速度，但会掩盖瞬时卡顿；如果一款游戏平均 120 FPS，却在关键时刻掉到 30 FPS，玩家仍会感到明显顿挫。因此，现代测试通常同时记录 1% Low、0.1% Low 和帧生成时间。1% Low 表示最差 1% 帧的平均值，用来衡量偶发掉帧；0.1% Low 更敏感，能暴露严重卡顿。帧生成时间则是每帧渲染耗时的毫秒数，比 FPS 更能反映帧与帧之间是否均匀。举例来说，60 FPS 对应约 16.7 ms，如果帧生成时间在 8 ms 与 40 ms 之间反复跳动，即使平均帧率不低，体验也可能不稳定。测试者还应关注帧生成时间曲线、直方图和百分位分布，而不是只看最高帧或平均帧。只有把平均帧率、百分位低帧与帧时间结合起来，才能对游戏流畅度作出较完整判断。

控制测试变量：硬件、驱动、画质与场景设计

可复现是帧率测试的生命线。若两次测试之间更换了显卡驱动、后台更新了系统、开启或关闭了光线追踪，数据就失去可比性。测试前应固定硬件平台，包括 CPU、GPU、内存频率与时序、存储、电源模式以及散热状态；同时记录驱动版本、操作系统补丁、游戏版本和 API 模式，如 DX11、DX12 或 Vulkan。画质设置也要明确：分辨率、预设等级、纹理、阴影、抗锯齿、光追、DLSS/FSR/XeSS、帧生成等选项都会显著影响结果。测试场景同样关键，优先选择内置 Benchmark，因为它通常具有固定路线和相同负载；若没有，则应设计可重复的路线，例如同一存档点出发、沿固定路径移动、触发相同战斗或爆炸效果。多人游戏还要考虑服务器、网络延迟和玩家行为差异，最好多次运行并取统计值。环境温度、风扇曲线和功耗墙也可能导致前后成绩波动，因此测试报告应交代这些条件，避免把变量差异误判为硬件性能差异。

选对采集工具：从Fraps到PresentMon与CapFrameX

帧率采集工具决定了数据的粒度和可信度。早期常用 Fraps，它能显示实时 FPS 并记录帧时间，但兼容性和开销在现代游戏中已显不足。MSI Afterburner 配合 RivaTuner Statistics Server 仍是流行方案，可叠加显示 FPS、帧时间、GPU 占用、温度和功耗，适合边玩边观察，但记录分析能力有限。更专业的工具包括 PresentMon、OCAT、CapFrameX、NVIDIA FrameView 和 AMD Radeon Software 的性能监控。PresentMon 基于 ETW 事件追踪，能记录呈现时间、GPU 时间、显示延迟等指标，适合深入分析；CapFrameX 则提供友好的采集、对比和报告功能，可自动计算平均帧、1% Low、0.1% Low 与帧时间曲线。测试时要注意工具自身开销、捕获方式以及是否支持 DX12、Vulkan 和帧生成。某些叠加层可能与反作弊冲突，在线游戏需谨慎使用。理想做法是交叉验证：用同一场景分别以两种工具采集，确认趋势一致，再输出最终数据。

正确解读与呈现：别让平均帧率掩盖卡顿问题

拿到数据后，解读方式直接影响结论。平均帧率适合概述性能档位，但不能单独作为流畅度结论；如果两套平台平均帧同为 100 FPS，一套 1% Low 为 85 FPS，另一套 1% Low 仅 45 FPS，后者在复杂场景中更容易出现可感知卡顿。帧生成时间曲线能揭示周期性的尖峰，例如着色器编译、场景加载、爆炸特效或显存不足导致的卡顿。报告时应列出测试平台、驱动、画质、分辨率、API、测试路线、运行次数和统计方法，并给出平均帧、1% Low、0.1% Low、帧时间中位数与最大值。图表比单一数字更有说服力：折线图展示帧时间波动，直方图展示分布，柱状图对比不同设置。若测试支持可变刷新率、垂直同步或帧生成，也应说明这些功能是否开启，因为它们会改变呈现节奏和延迟。最终结论应围绕“是否稳定、是否跟手、卡顿出现在何处”展开，而不是制造一个漂亮的平均帧数字。