您如何从游戏测试者那里获得有用的数据？[关闭]

您可以从游戏测试者那里得到几种反馈，我想知道如何最好地为他们中的每一个收集数据。

1. 崩溃报告。当我的C ++游戏在有人玩时崩溃时，如何最好地确保自己知道它，甚至更好……是什么原因引起的？即使获取导致崩溃的文件和行号之类的简单信息也将非常有用。

2. 设计反馈。当游戏测试员在玩游戏时，我如何确定他们是否玩得开心，为什么他们玩得开心，为什么他们没有玩得开心以及我们应该花些时间进行调整？

我假设您是在谈论现场游戏测试人员，而不是Internet Beta测试人员。

规则1：不要帮助他们。挫败感应该是您应该首先检查的事情。理想的情况是使用两面镜，您的团队在一侧，游戏测试仪在另一侧，一台摄像机在脸上，另一台在屏幕上。显然，这对大多数人来说是不可行的，所以请尽力而为。让您的设计师坐下来观察人们被困在哪里是非常有用的信息。当他们将游戏带回家时，您不会站在他们的肩膀上，因此，就如何通过某些部分提供建议不会为您提供所需的信息。 编辑：另一种表达方式是：不要以为他们在“玩错了”

规则2：不要给他们他们想要的东西。在游戏测试课程结束后，您将填写某种调查表。他们提出的具体建议通常不明智。通常，有一些根本原因会触发大多数响应，而他们只是不知道如何表达。如果您能弄清楚，这样做会更好。尽管目前我在提出具体示例方面遇到困难。

规则3：数据为王。如果可以（说实话，这实际上是另一个愿望清单项目），请跟踪所有可以追踪的内容。追踪玩家死亡的地方。跟踪他们从特定枪支弹药中耗尽的位置。跟踪他们错过了哪些皮卡。跟踪他们购买了什么升级。追踪敌人对他们造成的伤害。显然，这些是特定于FPS的示例，但是我敢肯定，无论您从事哪种游戏，都存在特定于域的示例。如果每个人都在做某事或不做某事，那么通常是您应该花更多时间研究的领域。

基本上，您不在乎玩家的想法。您关心获取球员行为的原始数据。您需要处女的眼睛来观看您的游戏，并告诉您是什么使他们感到沮丧以及被引导去做。

对于崩溃，请调查小型转储。它们不是完美的，但是是确定崩溃位置的非常有用的工具。

还要考虑内置的错误报告工具。用户可以在其中进行屏幕快照，添加描述并通过游戏内部将其通过电子邮件自动发送给某人的东西。理想情况下，如果您的游戏支持，则提供有关世界的快照（即快速保存或某种内存转储）。

要扩展数据，请稍加一点国王的情绪（对Tetrad +1！）：

研究录音和播放：

• 如果您的游戏是确定性游戏和基于帧的游戏，则只要(key/button state, joystick/mouse coords, frame #)输入状态发生变化，您可能只需要存储初始随机种子和元组即可。播放就像将输入重定向到此流一样简单。（过去，我们已经在许多平台跳跃游戏中做到了这一点。）
• 如果您的游戏具有定义明确的API或消息系统来执行操作（基于回合的策略游戏，纸牌游戏，棋盘游戏等），则您也许可以在某个关键时刻收获API调用或消息。（我们是针对手持平台的纸牌游戏这么做的。）
• 在某些系统上比较困难（确定性较低，线程化或任意时间步长的系统可能很麻烦），但是仍然值得记录数据。对于某些用途，您可以获得“足够接近”的结果。

基于这些方法的“重播”系统具有许多优点：

• 用它来在调试或以其他方式检测的内部版本或环境中重现崩溃；
• 在概要分析构建中加载重放，并获取性能或资源使用情况数据；
• 将其连接到游戏中以提供“即时重播”功能，可能使用不同的相机或时间步长；
• 如果用户坚持在菜单上不执行任何操作，则设置“吸引模式”演示游戏玩法；
• 将它作为烟雾测试放到您的构建系统上：如果我可以通过重播而不会崩溃，则很可能是一个好的构建；
• 观看人们玩的例子，看看他们做了什么和没做过。

连接随机输入而不是记录的流，您将获得一个很棒的猴子测试，您可以整夜浸泡或在开发机器空闲时浸泡。

接下来，进行一些事件记录。对于假设的FPS，请从“时间T：X在Z点用武器W杀死Y”开始：将其记录在日志中。

收集了一些数据后，请找出如何自动进行收集。在开发过程中不必优雅：

• 连接到SQL Server并插入行，
• 在一些简单的系统日志服务器上触发并忘记UDP数据包，
• 在下次游戏启动时通过电子邮件发送日志，
• 只需将可执行文件包装在Shell脚本或批处理文件中，即可将.log文件重命名并将其复制到通用共享驱动器中，
• （后来，对于生产版本）使用Windows错误报告或类似的服务来收集崩溃数据...

没关系，只要您可以收集数据即可。

现在扩展它：收集故障转储，堆栈跟踪以及输入或事件记录。添加更多事件和更多数据源：

• 每隔10秒取样一次玩家位置或手，然后将其绘制在地图上-“嘿，没人用这个角，我花了一个星期的时间建模，有时间在那儿加电
• getFreeMemoryBytes() 每半分钟
• getFPS() 定期地
• 通过网络摄像头拍摄用户正在做的照片或视频（非常适合进行自动可用性测试-当然，只有在获得用户许可和理解的情况下）
• 获取系统信息（再次，具有用户权限）

一段时间后，将其“绘制在地图上”的事情会变得非常棒：设想一下RTS或FPS地图的鸟瞰图。在上面放一个滑块，代表游戏开始后的时间。选择事件类型（“获取金币”，“杀死某人”，等等）。选择一个数据集：过去几个月可能一个游戏，可能是500个游戏。开始向右拉动滑块，然后观察活动弹出到地图上。

而且，如果您找不到很好的库来帮助您处理这些问题（不过，到处都是很多！），请考虑自己滚动：这是一种很好的学习体验，不需要特别优雅有用。

获取数据，您将弄清楚如何处理它。=）

当然，这很大程度上取决于... a）您想进行哪种测试，b）您正在测试哪种游戏，以及c）您可以使用哪种测试器和基础架构...

如果您要测试a）功能，b）平衡c）游戏设计，也有很大的不同

但总的来说，您可能需要考虑这些方面...

* a）选择合适的人选 听起来太简单了，但我看过很多次了，只是又活了一次。一如既往，人与人之间在不同工作上的表现有很大差异。一些愿意或可能愿意进行测试的人可能玩的不够透彻，无法发现异常（甚至简单）的错误。有些不擅长描述错误。有些擅长测试平衡性问题，有些更专注于视觉上的弱点，有些更擅长以异常的方式玩游戏并发现隐藏/稀有的错误，有些更专注于技术或视觉质量，有些更善于理解方面游戏技师的角色，甚至可以提出有意义的更改（如果您希望测试人员这样做；）。

* b）使用问题跟踪器/错误跟踪器软件 这些工具不仅可以帮助组织问题，还可以通过为测试人员提供一个工作框架并从他们的反馈中学习来提高测试人员输出的质量。来自开发人员的有关他们的问题的信息。与不使用它时相比，它可以更快地提高测试人员的输出质量。（这也有很大帮助，远程测试器）所使用的游戏工作室是即螳螂，JIRA，（和ofcourse许多人的..）见典型软件维基百科对于一般的列表，也是这个职位上的SO。

c）添加游戏中测试工具 典型的快捷方式是测试游戏的特定级别或部分。在游戏过程中向测试人员显示其他信息，以便他们可以将其添加到错误报告中。这可能是关卡中的位置，场景中活动对象的数量，当前正在使用的纹理内存或调色板的数量，以及对开发人员有用的信息。

d）将经验丰富的测试人员与新鲜血液相结合 ，拥有对您的游戏非常有经验并了解典型问题以及如何（重新）测试它们的测试人员，总是一件好事。同时，您不时需要新的“处女”球员，尤其是为了保持平衡。

e）有一名测试经理 ，负责协调流程并根据手头的游戏，当前的优先级以及可用的测试人员和测试环境对其进行定制。

f）有一个Testplan文档 这将是一个额外的职位。

正如Tetrad所述，请获取尽可能多的客观数据。放入钩子来存储某些事件并将所有事件转储到.csv并不是很困难。一旦在Excel中获得了它，就可以研究，绘图和绘图，直到母牛回家。

此外，还有您要回答的特定问题。科学家们不仅坐下来，进行一些实验并“做科学”。他们有特定的，可衡量的问题，他们想要获得有关数据的信息。如果采用相同的方法，则通常会从游戏测试中获得最大收益。很难判断您的游戏是否“好”。但是，可以弄清楚简单的辅导任务是否仅花费了您期望的5分钟，或者测试人员是否正在努力解决某个难题，实际上可以进行评估。

有时，最有效的测试方法是在短时间内反复进行测试。上午让几个测试人员去一个小时左右，对他们发现的问题进行一些更改，然后在第二天早上与新测试人员一起去。显然，您必须查看一个足够小的功能以在下午进行改进。但是对于一个特别顽固的问题，此方法可能会非常成功。

绝对同意Tetrad的规则＃1。不要帮助他们。我要警告的是，是要向他们解释您将不会帮助他们，如果他们需要帮助请询问。这样玩家就不会最终感到沮丧。

问卷应该问开放式问题，而不是简单的是/否问题，这取决于测试人员的年龄和人数，这些可以是他们填写的表格，也可以提出问题。询问有关他们的历史以及对您正在测试的游戏类型的熟悉程度也很重要；这将为他们有关您游戏的特定答案添加上下文。

幸运的是，当我的游戏崩溃时，它为我提供了有关该错误的信息转储，因此我可以拍摄一张照片，并记下玩家在做什么。通常，我会测试年龄较小的年龄段的人群，因此当我们遇到车祸时，我必须记得向他们解释他们的表现很棒-他们在打破比赛后会感到沮丧。事实证明，测试人员非常擅长发现晦涩的bug，这些bug使得开发团队永远不会以“正确”的方式玩游戏。

可以编写捕获崩溃并记录调用堆栈的代码。这对于错误报告很有帮助。生成有用的日志文件也有帮助。您可以提示用户下次播放时发送这些文件，也可以根据需要让独立工具在游戏关闭或崩溃后运行。

对于崩溃报告，您应该依靠有薪的质量检查人员，而不是游戏测试人员。QA是您专门聘请的人，他们具有发现错误并以有意义的方式报告错误的能力，并且一个好的测试人员值得其金本钱（与程序员相比，仅是其金本钱的十分之一！）。

如果您担心“哦，如果他们不小心发现了崩溃该怎么办，我们就不会因为他们没有对此进行测试而错过它”。...这就是记录的目的。一个足够好的日志系统应该记录足够的游戏元素，以便能够准确地重现崩溃。

对于设计反馈，没有什么替代方法可以让游戏设计师实际观看他们的比赛（如果需要，可以使用录像机等）。不要依赖于测试者的记忆力或观点，这两个都是众所周知的差劲。但是，如果您正在观看他们的实时比赛，那么通过观察他们的面部和身体姿势，无论他们是否订婚，无聊或沮丧，显然是显而易见的。