【GameLook专稿，未经授权不得转载！】

GameLook报道/对绝大部分游戏来说，测试都是必要的环节，无论是玩法上的调整、debug还是体验上的优化，都可以让你的产品在被更多用户接触之前做到尽可能优秀。

然而，对的测试方法可以得到有价值的信息帮助游戏迭代，错误的方式则可能获得的是重复而且没有用的反馈，浪费团队的人力和时间。那么，怎么测试才是对的呢？在此前的GDC分享中，索尼圣莫妮卡工作室的助理制作人Ed Dearien分享了这款游戏的测试推翻重来的过程，并表示如果没有测试，就不会有现在的《战神》。

以下是GameLook听译的完整内容：

Ed Dearien：

简单来说，如果没有测试，游戏就不是现在的样子，测试给我们的游戏带来了极大的优势，希望你们能够在分享结束的时候看到这些。通过对《战神》测试过程的分享，我们希望能够给你们带来一些启发，或者你们可以直接使用我们的一些测试方法，亦或者让你们知道《战神》这样的大游戏测试需要的是什么。

需要指出的是，我这里说的测试是外部测试，因为你可以做的测试类型有很多种，比如内部审核、聚焦小组、市场调研等，但这些都不是我们今天要说的。我今天说的测试是让其他人体验你的游戏，然后他们给你反馈。

今天到场的工作室成员还有Jeet Shroff和Kevin Keeker，Jeet是圣莫妮卡工作室玩法总监，他在《战神》测试中从创意负责人的角度提供了指导，Kevin是SIE首席用户体验研究员，目前聚焦于PS独占游戏，他负责用户调研策略，帮我们获得了大量数据，并且对所有的《战神》研究报告做了分析。

我是Ed Dearien，在圣莫妮卡工作室做执行制作人，我的主要职责是协调所有外部测试，也就是我们团队与Kevin团队之间的桥梁。需要提醒的是，这里的内容会有剧透，如果不希望看到的话可以提前离开。

为什么要推翻之前的测试流程？

开始之前，先快速讲一下背景，是什么让我们重新思考测试问题。一切都是从这张图开始的，它代表了《战神》的新愿景，虽然与最终游戏里的版本不太一样，但呈现了我们创意总监Cory Barlog想要实现的效果。

这款游戏的愿景与过去的战神系列都不太一样，它采取了更偏娱乐的方式，并聚焦于奎爷的关系链，在这些愿景中最中心的是为整个系列带来角色成长的想法。围绕角色成长主要有三个方法：剧情、战斗和探索。

需要强调的是，这款游戏不是重置也不是重制，它是一个重新想象的产品、是奎爷故事的继续，换句话说，这是玩家们熟悉了几十年的同一个奎托斯。这一点之所以重要，是因为有些人玩过之前的游戏，他们玩这款游戏的时候就会带着从之前游戏而来的期望，所以工作室在研发新《战神》的时候面临很多的挑战。

第一个挑战就是全新的愿景，它加入了新武器、设定是北欧神话，还增加了一个男孩。另外，由于这不是个新IP，我们知道会有新玩家和老玩家之间的期待差异，我们还知道，这将是一个研发比较困难的游戏，因为它是一个具有很高品质标准的大游戏项目，这是工作室在PS4平台的首个游戏，因此需要熟悉新技术和设备。

由于新游戏的目标与之前的游戏差别很大，因此在策划和创意原型阶段就需要投入大量的努力，所有这些挑战都让游戏研发初期变的很困难，而且这些东西之间似乎一直是相互冲突的，结果就是，我们一开始的工作就是分开做这些不同的部分，因此从预制作到Alpha测试用了很长时间而且进度艰难，给团队带来了很大的挫败感，甚至带来了一些问题：这还是战神游戏吗？更重要的是，它有什么好的地方吗？

所以在2016年的Alpha测试之前，我们一直都有这些负担，这也是我们第一次从开始从头体验完整的游戏。我们一开始就知道并不是每个功能都会完全加入到最终游戏版本之中，但这是我们作为一个团队首次完整体验自己研发的游戏。

那么结果如何？坦白来说，当时的游戏版本没有趣味。

尽管大部分的游戏alpha都会遇到这样的情况，但游戏里仍然有很多令玩家感到沮丧的时刻，而且很容易就能看出很多事情还需要进一步迭代，举例来说，游戏里一些关键的功能还没有能够实现，所以当时的版本有很多需要填补的空白。

就像是一个巨大的解谜游戏做了很多碎片却并不能拼到一起，我们需要加速，因为已经到了Alpha阶段，我们剩下的时间不多了，所以这个阶段的游戏状态告诉我们应该加速制作。但问题不止如此，我们甚至开始质疑自己是否有能力胜任这个项目的研发，我们很清楚，当时所作的很明显是不够的，因此必须重新思考我们的研发方式。

这时候我们开始审视当前的玩法测试进展，因为我们一直都在做测试，工作室也一直都有内部测试，但我们知道这些测试不会那么有效率，它们是有问题的。

首先，这些测试并没有告诉我们任何的新信息，有时候给人的感觉就像是在看沙漠里的沙子，得到的反馈非常表面，但大多数时候，只是用不同的方式在描述已经存在的问题。人们经常说很难控制游戏内摄像头，或者难以追踪敌人，在我们得到这些问题之后，无法得到在此之外的任何信息。

第二个问题是，我们没有一个全局流程，如我之前所说，团队在不断测试，但不同部分之间是隔绝的，没有什么是从整个游戏角度来审视的，比如我们有些反馈是关卡的、有些是战斗的，但没有什么是将它们融合在一起的，正因为如此，我们得到了不少相互冲突的反馈，这让我们很难决定下一步该怎么走。

这是一个更大的游戏，与我们之前习惯的项目都不一样，这个新游戏有新的目标，它更复杂、有更深度的剧情，所以以前我们测试游戏的方法行不通了。

有人甚至开始怀疑整个测试，团队里的质疑情绪日益增长：我们为什么要做测试？我们一直得到的都是同样的反馈，这是浪费时间。

与此同时，我们的姊妹工作室Guerrilla Games刚好完成了《地平线：零之曙光（Horizon Zero Dawn）》的研发，他们听到我们要对测试流程推翻重来，所以给了一些建议。

于是我们给他们打电话，在沟通过程中，他们表示最初也和我们一样遇到了这些测试问题，并且讲述了他们如何打造高效率测试流程的方法，他们还遇到了一个问题，那就是在测试的时候应该投入多大的努力，他们最终的经验是，你必须“all-in”，如果你全身心投入测试，一定会得到不错的结果。

这次通话给了我们灵感，立即联系Kevin开始工作，这时候我们才发现大幅低估了Kevin团队所具备的潜力，但并不是所有团队都有这么强大的用户调研团队支持，所以今天我的分享主要集中于能够被更多工作室通用的一些概念。

全新的测试流程

所以我们重新调整了测试流程，先是搞清楚为什么测试、测试目标是什么，然后进入不同类型的测试，并对得到的数据进行分析。

我们首先做的是问这个问题：为什么要做游戏测试？我们发现最主要的目的就是通过测试来验证我们的愿景实现的如何，需要注意的是，我说的不是验证游戏愿景，因为游戏的愿景已经确定了，我们要做的就是通过反馈来了解我们的愿景实现的怎样。

我们需要确保能够得到可执行的数据，如此前所说，我们很难得到已经知道问题之外的信息。最后，我们通过游戏测试的目的是让游戏变得更有趣，但我们并不是在测试的时候问玩家这款游戏是否有趣。对我们来说，更重要的是通过对反馈数据的理解，做出对应的提升，让游戏变得更好。

以这种方式思考对我们是很重要的，因为这确定了测试基调并不是告诉开发者他们是对了还是错了，我们测试的目的是收集反馈数据，然后由研发团队决定如何利用这些数据，所以我们要确保研发团队得到他们需要的数据，以便做出最佳的决策。

所以，整个过程是从确定测试目标开始的，我们需要确保这些目标清晰且可以衡量，因为在此之前，我们只是问人们UI是否足够直观，然后就停止了进一步的了解。但我们发现，UI是否只管只是一个不错的起始点，我们必须将反馈聚焦于真正聚焦的地方，比如我们会问更多细节的问题，比如菜单流程、人们对新手教程的理解如何。

其次，我们意识到这需要大量的工作，因此我们开始将游戏测试作为游戏功能的一部分，这意味着我们需要有强大的制作团队支持，就像其他功能一样，这需要有发起人、还需要有人为之努力，所以我们组建了一个测试突击队，由创意总监Cory Barlog领队。

对我们来说很重要的是，领导团队需要在整个过程中成为核心。因为在不断地测试过程中，你会遇到问题需要更多部门的参与才能做出改变，最终，我们需要一个能够衡量测试是否成功的方式，来确定我们在游戏里做出的改变是否有效，因此我们每次只做一样测试。

只做一次测试是不可能解决所有问题的，所以我们利用这些测试不断积累、推动游戏前进，因此我们每次测试都会得到一些关键的反馈，这让我们有了更清楚的下一次测试目标。确定测试目标是很重要的，你要知道通过测试想要实现的是什么。

接下来我们确定的是测试频率，这是我们最初提议的测试日历，我是3月份做的日历，它展示了到11月份的测试安排，蓝色是可用性测试，棕黄色是比较大的游戏测试，我随后会具体说。

就像很多的研发日历一样，一旦开始之后，这些计划就会发生很多的改变，所以这并不是我们真正使用的测试日程，但有些心得还是值得分享的。

首先测试永远都还有下一次，让团队有信心是很重要的，让他们觉得测试是可以信任的，意味着连贯性是关键，如果你不断地取消和改变测试时间，这就让测试结果显得不那么可信，所以我们一开始就确定了测试频率，并尽力去做到。

对我们来说，这意味着必须承担风险，平衡新功能，因为我们的游戏还在研发之中，测试迭代是其中的一部分，所以确保领导团队了解这种思维方式很重要的。有时候我们会要求游戏进行比较大的改动，这对我们来说是必要的，因为每次测试都很重要。

最后，我们需要确保每次的测试都能给游戏带来微小的进步，每次测试都是建立在上一次的基础之上，这意味着我们使用不同类型的测试。我们从整体看问题，然后找到痛点，随后深入了解问题原因，比如你不会因为一次测试就搞定摄像头问题，我们一直都在不断地调整，所以我们需要确保不断地取得有意义的进展。

两种测试类型

接下来我们看看都用了哪些测试类型，以及它们分别带来了什么样的测试反馈。我们主要使用两种类型的测试，一个是无引导通关（unguided playthrough），另一种是可用性测试（usability test），他们都有非常具体的测试目标。策略化运用这些测试，帮我们找到了核心问题，我先从第一个类型开始说。

无引导通关测试主要的目的是找到痛点，它从整体游戏出发，并测试你的目标完成度如何，总体来说，这让你知道人们玩游戏的时候在哪里遇到了最多的问题、你需要在哪里投入更多精力。这类测试的目的是尽可能少地与测试者互动，让他们就像在自己家里玩游戏那样自然，这意味着除非他们请求帮助，否则我们是不会干预测试的，要么就是我们知道测试者遇到了游戏bug或者问题。

这类测试帮我们验证了整体游戏的一些部分，比如衡量整体节奏、剧情理解、难度平衡等等，这些问题帮我们从更高的层次了解问题出在哪里。

另一种是可用性测试，我们通过上一种测试找到了一些痛点，然后通过这类测试对其深入挖掘，它的目的是找到导致这些痛点的根源，让你快速找到具有针对性的解决方案。因为在整体测试中，你会遇到很多的噪音，往往会和其他游戏系统相关，带来非常普通的反馈。

比如，有人可能会说战斗没有乐趣，然而在可用性测试中，你会发现真正的问题是摄像头灵敏度，所以对于我们这样大的游戏来说，必须有一种机制能够过滤这些无用的信息，找到核心问题之所在。

这些测试都是比较小规模、短时间的，这时候我们的用户调研人员会与测试者一起找到问题，我们鼓励测试者与调研人员进行开放式的对话，尽管有问题的反馈是具有建设性的，但这些反馈也让我们知道走在对的方向上。

这些功能是我们做了可用性测试的，你们可以发现这些都是非常核心的功能，这是我们有意为之，因为我们的时间有限，所以必须确保这些功能始终以对的方式迭代。

这就带来了下一个问题：你该如何从测试反馈抽取有意义的数据？

在我们测试过程中，我们主要依赖于如何提出这些问题，所以我们将反馈分为两类，一种是用户自发给出的反馈，另一种是我们具体提问的信息，我们将前一种归类为非直接反馈，Kevin将其称之为红色按钮，因为玩家们会因为游戏测试中的体验不断给出反馈，这种信息能够带来随时反馈，通常这会让研发团队发现需要深度了解的具体问题。

直接反馈指的是我们通常用调查形式得到的结果，所以我们始终先通过非直接反馈开始，因为我们不希望针对游戏系统提出的问题偏离玩家体验。

这些是一些比较具体的反馈，你们可以想象，我们得到了大量用户反馈，不过Kevin和他的团队根据这些问题分为加法和减法，加法意味着加强，减法意味着减少，这让我们可以不将问题过度复杂化，也能让我们看到哪些是重要的问题。

这是我们的非直接反馈收集的重要问题，比如第一行，有4名测试者告诉我们Valkyries过于困难，我知道这很令人意外，这个列表都是用户通过自己的体验反馈的。

接下来再看直接反馈，你们可以发现测试者最多的问题出现在敌人难度上，40%的人都提到了这个问题，我们随后会邀请一部分玩家进行更多测试，以确定问题出在哪里。

通过将问题简化为直接和非直接反馈，帮我们建立了共识，因为它向我们展示了整个游戏的数据，如果你在团队中，你研发的功能就会成为这个问题列表当中的一个，这种展示方式让你可以从全局看问题，也让我们很清楚地知道应该将注意力聚焦在哪。

随着我们想要知道的东西开始变化，我们需要知道的数据也开始不一样，因此随着游戏优化越来越好，我们也在不断改变和迭代这些数据表格，因为非常重要的是，每个研发部门都在寻求不一样的数据类型。

关卡策划可能更希望看到关卡分解方面的数据，战斗策划可能希望看到玩家数据，所以与不同团队沟通是很必要的，你要确定他们需要的数据是什么，因为不同部门很难使用通用的数据。

那么，我们的测试流程是怎样的？我们回顾一下之前的总结：确保你的测试有清晰的目标，形成可靠的测试节奏并坚持下去，用不同类型的测试来发挥你的优势，确保你给出的测试反馈是考虑了整个团队需求的。

不过，流程和使用它的人同样重要，我们的一部分新的就是，只管去做（测试），所以我会给出一些案例，它们给我们带来了很有价值的经验教训。

当我们设计游戏的时候，团队更喜欢以“幻想与功能”描述它，幻想指的是想要带来的用户体验，功能指的是更具体的玩法，比如操作以及摄像头等。

了解了这些之后，我们做测试的时候有了非常明确的目标，无引导通关测试帮我们验证幻想方面的体验，可用性测试帮我们验证功能方面的问题。

我用游戏里的船举例。

用早期的游戏设计文档来说，小船是为了探索而设计的，是为了收集、听故事，体验战斗，这是它的设计优先级。如果你们玩过《战神》，就会发现与实际体验与最初的设计非常接近，除了战斗之外，后者根本没有在游戏里出现。

为什么？战神系列几乎任何时候都可以战斗，在《战神2》当中，即使飞行的时候也依然可以战斗。

坦白来说，我们去掉了船上的战斗主要是为了整体游戏体验，小船的主要设计目标是让玩家探索世界并了解更多剧情，战斗是小船设计中优先级最低的。不过，去掉这个功能是团队做出的一个艰难决定，战神本来就是要战斗的，因此这个决策之后，团队提出了质疑，因为这打破了战神系列的经典传统。

但我们依旧在没有船体战斗的情况下继续测试，当时的剧情还没有做进去，但整体的感觉是，人们不希望在乘船的时候战斗，因为这太慢、太无聊，他们不喜欢，船上的战斗很糟糕。我们alpha得到的反馈是乘船是一个糟糕体验，所以这些负面反馈全是和战斗相关，我们开会也经常讨论，要么把战斗加到小船当中，要么直接砍掉小船这个功能。

所以我们可以总结成两个方面，幻想角度来看，玩家们抱怨游戏里乘船场景太多，功能角度，他们觉得船走的太慢而且难以控制。如我之前所说，船相关的幻想部分（剧情）还没有加入进来，所以很明显问题出现在船体操作比较无聊上。

我们必须提醒自己，不要去管与船相关的幻想部分的反馈，但我们可以解决功能上的问题。因此我们问自己：现在可以做什么来提升乘船体验？还是必须等到船体剧情到来的时候？我们能否通过可用性测试找到其中的问题？

于是我们这么做了，我们对小船做了很多的高品质更新，这让我们解决了游戏内很多类似的功能，当最终剧情加进来的时候，我们就可以从整体看待这个问题，然后你就可以听到奎托斯的经典故事。

对于船上的故事，我也有一个故事要说。当时刚刚完成了测试，当时是没有船坞的，每次测试者想要下船的时候，都需要我们的工作人员帮助，因为这需要我们进一步debug，这种体验很糟糕。所以我们不得不进行下一次测试，这对团队是个重要时刻，因为这是第一次我们看到我们想要的船体测试体验。

第一个测试者完成两小时测试之后，他的操作遇到了船坞bug，所以我们不知道该如何应对。第二个测试者没有遇到船坞的问题，于是我们采访他在小船停了之后的反应是什么，他说在等奎托斯讲完他的故事，这时候我们才发现，小船完成了它在游戏里的使命，人们可以在没有战斗的情况下享受乘船体验。

那么，我们可以从这学到什么？

我们随时可以把战斗加回去，甚至有时候得到的反馈是直接把战斗加回来，然而在测试中，你不知道最终的乘船体验应该是什么，因为当时还没有加入完整的内容。所以，我们发现一定要谨慎对待反馈，尤其是策划意图没有完全实现之前。

接下来的故事是最终Boss

这是玩家第一次体验完整的游戏结局，我们觉得非常好。然而测试者们直接告诉我们，他们不喜欢芙蕾雅在最后突然黑化，我们也觉得惊讶，芙蕾雅原本并不是一个反派，遇到了这种不可能的情况，她应该怎么做？

我们发现玩家对此的态度是分化的，有些玩家同情芙蕾雅，还有些人则觉得她很暴力，因此我们问自己：为什么玩家会觉得芙蕾雅是个暴徒？我们觉得玩家可能没有理解她遭遇的情形，所以这个场景之后立即增加了一个场景。

让阿特柔斯问出了这个问题，“你遇到同样的情况也会让我杀掉你？”奎托斯的回答是肯定的，并且说只有身为父母才能真正理解这种选择。我们发现增加了这一段之后，非常有效，玩家们不再对芙蕾雅给出负面反馈。

我们学到了什么？

有时候你开启测试的时候，可能觉得搞定了一切，但突然之间你可能得到预料不到的反馈，甚至与你想要达到的效果完全相反。每个玩游戏的人都会有自己独特的角度，因此他们会对一些东西产生误解，测试告诉我们要认真倾听人们的反馈，因为我们很容易直接说玩家没有get到我们想要表达的内容，这可能会孤立很大一部分玩家。

很重要的一点是，我们发现测试不仅是用来测试玩法的，有时候也可以测试人们对剧情的理解。

你们可能不理解这张图说的是什么，但我会谈谈我们的好朋友“橄榄披萨男孩”。

当有人体验了你的游戏并且非常厌恶的时候，会发生什么？他们写了一个很长的差评列表，在给出的所有反馈中都提到了痛点，我们测试就遇到过这样的事情。

我给你们读一下他的反馈，“解谜令人厌烦，更糟糕的是，解谜部分比动作部分还要多，当这款游戏被叫做战神的时候，这是不能接受的。试想你点了一个肉食者披萨，当外卖送到之后，你发现披萨上的橄榄比肉还多，我对游戏里的这部分就是这么感觉的。我玩游戏的时候希望有很多的动作场景，希望我的披萨上有很多肉粒，但没有，我体验到大量的解谜，就像是铺满了橄榄的肉披萨，谁会希望自己点的肉食披萨上全是橄榄？没有人！谁会希望奎托斯或者劳拉在游戏里一直完成解谜？也没有人！给我们更多的动作、少一些愚蠢的解谜，另外，这些解谜很枯燥，喂喂，是1998年的《塞尔达传说：时之笛》吗？他们只是把20年前的一个地牢平台游戏带回到了战神系列。”

所以，研发团队都阅读了这条评论，在测试的中间，这个用披萨打比方的人成为了团队里的名人，他的反馈很清楚地展示，他是以前战神游戏的忠实粉丝。因此，一方面，我们发现了令人担忧的事情，战神系列老粉丝不喜欢新游戏，然而，用大量的披萨打比方，很明显表达了他对战神系列的热爱，对我们新游戏的新愿景带来了挑战。

所以，我们学到了什么？首先，新游戏不会让所有人满意，我们做的是一个对战神系列的重塑项目，是一个解谜与战斗同样多的游戏，这是不会改变的，有人不喜欢也没关系。而且我们还从其它反馈发现，我们做的非常不错，人们喜欢游戏角色、设定和剧情，玩法方面的迭代达到了平衡。

因此下一个心得是，要有策略地看待玩家反馈，这个玩家清楚地告诉我们他不喜欢解谜，但那些喜欢解谜玩法的用户怎么办？但他喜欢游戏里的战斗部分，所以我们聚焦于他和战斗相关的评论，我们发现，他要说的是游戏开始的战斗节奏很缓慢，因此我们决定调整战斗节奏，让喜欢战斗的玩家一开始就找到自己喜欢的挑战，同时也能参与到解谜之中，哪怕他们不喜欢解谜，所以这是一个很有价值的反馈。

但故事还没有完，收到反馈的第二天，我接到一条短信，上面说：吃午饭之前，你应该给这个人买披萨，但要在上面撒橄榄，所以我这么做了。

我们在上面撒了很多的橄榄，为了澄清我们不是恶作剧，这个面具后面他是很开心的在笑，我保证，我还给他点了一份肉披萨作为午餐。

最后一个例子是和游戏难度有关，我们的游戏有很多种难度设定，你甚至可以随时调整难度，我们假设你开始选择正常难度，但觉得游戏挑战不够，随时都可以选择给我更多挑战。当选择难度功能没有加入的时候，我们很长时间都依赖普通难度来确定游戏难度是否合理，但有一次测试的时候，我们故意调高了难度，因为之前测试大部分反馈都说太简单了。

不过，我们希望找到最佳的平衡点，希望知道最难的天花板在哪里。所以我们大幅调高了难度，结果玩家反馈说太难了，于是我们又调了回去。

下一次测试的时候，我们加入了难度切换功能，这让战斗策划非常兴奋，因为这让他们可以看到人们对更高难度的反馈是什么。我们得到的反馈非常好，所有人都给出了满分的评价，不过我们的团队成员非常喜欢困难模式，所以他们看到玩家反馈非常好的时候也很高兴，比如有人说游戏体验展示了他们的战斗技巧，很有成就感，但随后看到测试数据才发现，很多玩家选择了简单模式，所以这里面有很多故事。

从这次测试我们学到了一些东西，首先是将重要功能尽早交到玩家手中，因为我们的游戏最初设计就是可以一直调解难度的，这实际上改变了人们对我们游戏的参与方式。我们发现难度调节功能加入之后大量的用户都在使用，而很长时间以来，我们都在基于中难度平衡体验做测试，所以不同的版本都会有人说太简单或者太难，因为你无法确定每个玩家的技术水平。

第二个心得是，我们需要从各个方面看待反馈，因为通过玩家反馈来看，我们以为他们选择的是高难度模式，因为评论中的描述与我们期待的高难度反应一样（但实际上却选择了简单模式），因此从多个角度看待评论是很重要的，比如游戏视频、难度设定选择等，通过这些数据建立尽可能精准的用户数据库。

最后一个心得是，高难度并不等于乐趣，玩家们选择简单难度，并不会影响他们享受游戏功能和体验，依然可以给我们带来有价值的反馈。

总结

我们开始测试并不是为了质疑游戏目标，而是用它来看我们对于这个目标的实现做的有多好，这是一个非常重要的理念。因为有时候你可能会得到一些让你很有挫败感的反馈，但通过测试你可以得到很有价值的信息，对这些反馈你必须有对的心态。

并非所有人都会喜欢你的游戏，这不是问题。

我们一开始就告诉自己all-in，但这需要时间和努力才能做好。每次测试都让我们的游戏变得更好，也让我们慢慢知道哪些数据有价值、哪些没有价值。

最后说一些想法，希望能够对你们的测试流程有所帮助，每个团队的运作模式都是不一样的，有些东西可能对我们有用，但对你们不一定行得通，你们要确定哪些对自己有用。

我们觉得团队成员参与是很重要的，我们将所有的测试都直播给了整个研发团队，任何人都可以观看，这在很多方面给我们带来了帮助，要让人们提出了很多问题。另外，也可以让团队自己评估发生了什么，然后将这些想法说给他们的主管。

其次，测试效果可以通过领导层的加入变得更好，Cory参与了整个测试过程并对此非常相信，你可以听到所有人对测试结果以及下一次测试的想法，这一切都是从领导重视并参与测试开始的。

第三，与QA团队的关系很重要，因为你会在测试之前遇到问题，你还可能加入一些破坏其他功能的东西，这都是游戏研发的一部分，但QA的观点是很有价值的，这一点很重要。

最后但同样重要的是，降低用户调研门槛，关键在于我们要让调研者掌握最新的信息，因为他们对游戏和系统了解的越多，他们能给你的帮助就越大，所以今天的分享一个重要的信息就是，要持续做测试。

测试会遇到很痛苦的情况，我们也的确做过计划调整以适应反馈意见，但测试也以非常重大且正面的方式给游戏带来了影响，以上就是今天分享的全部。