2014 年 5 月 19 日
第 12 卷，第 5 期

EA 自动化质量保证测试：事件驱动

与 Michael Donat、Jafar Husain 和 Terry Coatta 的讨论

对于数百万游戏爱好者来说，在 Electronic Arts 担任质量保证 (QA) 测试员的职位似乎是一份梦想的工作。但从公司的角度来看，与质量保证相关的管理费用可能看起来非常可怕，尤其是在大型多人在线游戏时代。

因此，自动化质量保证测试的吸引力在于它有可能比手动测试更快、更具成本效益、效率更高且更具可扩展性。虽然自动化无法模仿人工测试人员可以做的所有事情，但对于许多类型的基本测试来说，它可能非常有用。然而，事实证明，向自动化测试的过渡远没有最初看起来那么简单。本文将探讨其中一些最棘手的挑战。

在 EA，Michael Donat 是自动化的倡导者。他目前的工作重点是玩家和业务分析团队的流程改进。他之前曾担任 Silicon Chalk 和 ActiveState Corp. 的质量保证经理，并在微软担任软件设计工程师。

加入讨论的是 Netflix 的首席软件开发人员 Jafar Husain。他之前曾在微软工作，在那里他的任务之一是为 Silverlight 开发平台创建测试环境。在那里，他接触到了 MVVM（模型-视图-视图模型）；他说他是一个转变者，现在喜欢在适用的地方传播 MVVM 的福音。

Terry Coatta， 委员会成员，召集了这个小组讨论自动化质量保证测试的潜力。他和 Donat 曾在 Silicon Chalk 共事，在那里创建复杂的测试环境是他们面临的挑战之一。Coatta 现在是 Marine Learning Systems 的首席技术官，该公司正在为海事工人开发学习管理系统。

TERRY COATTA 就您迄今为止在 EA 应用自动化质量保证测试方面所做的努力而言，我了解到您发现进展并非一帆风顺。

MICHAEL DONAT 我们最初开始认为自动化是个好主意，但后来我们尝试了，结果失败了。不过，我们弄清楚了问题所在，并修复了它。但是，当我们到达一个不错的平台时，我们意识到还有很长的路要走。我们的解决方案显然无法满足我们想要的一切——即广泛应用自动化测试的方法。为了实现这一目标，以及其他一些原因，我们中的几个人得出结论，我们真正需要的是一种类似于 MVVM 的新架构。

JAFAR HUSAIN 您最初自动化测试的驱动因素到底是什么？

MD 我们的主要动机纯粹与手动测试的成本有关，鉴于我们游戏的复杂性，手动测试的成本已经变得非常高昂。基本上，需要我们手动重新测试一切的代码更改可能会非常昂贵。通过降低这些成本，我们认为我们将有机会将我们的测试人员从我所说的“稳定性测试”（自动化能够处理的事情）中转移出来，以便他们可以开始更多地关注我们游戏体验的真实性和乐趣。

TC 就稳定性测试而言，您认为自动化的首要机会是什么？

MD 当我们开发 EA Sports 的 FIFA 10 [足球游戏] 时，我们开始认真考虑这个问题。最初，这涉及 10 对 10 的游戏玩法，后来随着守门员的加入，变成了 11 对 11。因此，我们需要那么多测试人员——要么 20 个，要么 22 个。但这还不是全部，因为我们还需要测试不同比赛之间的交互，以确保服务器不会对向哪场比赛发送哪些信息感到困惑。因此，除了覆盖一场比赛所需的测试人员外，我们还需要同时进行至少另一场比赛——这意味着我们实际上需要同时有大约 40 名测试人员参与。

然后，即使在我们设法组织好所有人之后，我们也可能在比赛开始几秒钟后遇到一些微不足道的错误，导致整个比赛崩溃。除了浪费之外，对于许多本可以在这段时间内做更有成效的事情的人来说，这非常令人沮丧。所有这些加在一起，为自动化提供了非常有力的论据。

TC 在您朝着这个目标努力的过程中，您遇到了一些什么问题？

MD 首先，在 FIFA 10 中设置 OTP（在线团队游戏）比赛需要用户浏览几个屏幕。有 20 个控制台，脚本是基于时间的，这意味着它向控制台发送命令，然后等待一段规定的时间让所有控制台都进入正确的状态。然后它会发送下一批命令。目标是以同步方式移动控制台，使其通过一系列屏幕转换，以便为游戏玩法进行设置：参与者选择他们想要玩的阵营、他们想要穿的球衣、他们想要打的位置以及各种其他参数。所有这些事情都需要协调一致地发生，才能使游戏的编程尽可能简单。

当时，我们原始的测试自动化系统使得前端导航成为问题。时间必须恰到好处，否则测试就会失败。因此，我开始倡导一种完全跳过前端的方法，但我不得不改变我的观点。在 FIFA 10 OTP 的手动测试期间，出现了很多问题——事实上，非常多，以至于手动测试的预算不得不大幅增加。组织内部的问题是：“我们如何才能阻止这种情况在未来再次发生？”

这促使我分析了大约 300 个崩溃错误，我们在质量保证周期中获得了这些错误的数据。我的部分目标是看看是否可以通过继续追求自动化来实现任何显著的投资回报率。我发现，略多于一半的崩溃错误实际上是在最初的屏幕转换中出现的。事实证明，我一直都在告诉游戏开发者完全错误的事情。也就是说，我们确实需要在前端以及后端进行测试。我们不能仅仅通过去掉前端来简化自动化。

TC 这很有趣。似乎前端发生的一切只是人们从菜单中选择东西，那么在那里找到错误的可能性有多大？实际上，看起来像选择菜单项的简单过程实际上相当于分布式计算。你有 20 件不同的事情在进行，输入来自所有这些不同的地方，现在所有这些都必须协调。

MD 完全正确。很明显，我们需要一种完全不同的机制。仅仅发送控制输入是不够的。我们需要测试程序知道它在特定控制台上的位置，然后能够以可纠正错误的方式将其向前推进。

最初为 FIFA 构建测试自动化框架的人员已经意识到这将是必要的，但是处理它的能力多年来已经腐朽，并且在我们准备好处理 FIFA 11 时，这种能力实际上并不存在。因此，我们必须做的事情之一是获取我们需要看到的来自 UI 的详细信息，以便我们能够判断事情实际上在哪里。

JH 我猜想，您需要绕过视图，直接进入模型本身，而不是从视图层驱动事物——也就是说，通过控制器和视图。

MD 信不信由你，我们当时还没有到那个阶段。在那时，我们只是很高兴拥有更可靠的脚本，仅仅是因为它们知道它们在程序状态中的位置。

TC 这样，您实际上可以闭环反馈。在此之前，您会发送一个命令，然后不得不等待并相信上帝，相信在此期间不会发生任何事情，而现在您不需要有那种信任，因为您可以进行验证。

MD 对。我们到达了一个我们拥有更多受控状态转换的地方。我们在 FIFA 11 上做的另一个重大的质量保证改进是添加了自动辅助功能，通过该功能，自动化可以自行运行游戏，而一到两名手动测试人员通过为选定的控制台提供控制器输入来驱动实际的游戏玩法。他们不需要有 20 个人在场。这代表了巨大的进步。

TC 有些人可能在那时就功成名就了。

MD 也许吧，但这对我来说只是一步。虽然为 FIFA OTP 等特定应用程序引入一些测试自动化是一件很棒的事情，但我真正想要的是更广泛地应用于稳定性目的，因为这才能使我们的测试人员能够专注于整体游戏体验。这是构建卓越产品的方法。

在 FIFA 11 上的工作帮助 EA 确信了自动化测试的潜在好处，但要实现这一目标显然需要不同的架构。答案似乎在于 MVVM 范式，这是一种主要基于 MVC 的架构模式。MVVM 有助于清晰地分离图形用户界面的开发和后端逻辑的开发，这意味着它应该允许 EA 将 OTP 游戏玩法测试与 UI 测试分离。

TC 回顾一下您完成 FIFA 11 测试自动化后的情况，您认为您的下一步是什么？

MD 尽管 FIFA 11 被证明是令人鼓舞的，但问题是我们不得不花费大量时间进行编码。主要是因为在游戏开发过程中，某些屏幕经常会发生更改，然后我们不得不在我们的测试自动化脚本中进行相应的更改。这并不总是得到适当的协调，因此事情最终会崩溃。因此，我们有一个非常脆弱的测试自动化脚本，需要一名软件工程师几乎专门致力于维护工作。

在 FIFA 11 OTP 的案例中，这种费用是合理的，但我无法为在游戏的每个其他领域应用类似级别的测试自动化工作辩护。我们不得不继续依靠大量的手动测试人员来覆盖全面的测试。这使得我们很明显需要找到一种编码测试的方法，以便可以减少执行持续维护的频率，并使用更廉价的资源。

TC 这将您引向了哪里？

MD 基本上，这意味着架构需要改变。应该很容易看出游戏是如何根据其屏幕转换进行布局的，而且还应该可以轻松访问这些屏幕所作用的数据。总的来说，事情应该在比目前更高层次的抽象中更容易访问。

JH 可以说您希望专注于独立于实际 UI 控件的工作流程吗？

MD 完全正确。一旦这一点明确，我们就意识到我们需要不同的架构——更像 MVVM 的架构。这并不是说它必须是 MVVM；它只需要是能够提供这种能力的东西。

TC MVVM 范式中重要的是什么？

MD 本质上，它允许我们将屏幕使用的数据与屏幕本身分离。我们需要这种分离，以便自动化系统可以访问它们需要连接到的东西。

JH 将 MVVM 方法与许多开发人员可能更熟悉的其他模式（例如 MVC）进行对比可能很有用。在 MVC 架构中，控制器和视图彼此了解并直接相互发送消息。在 MVVM 架构中，您有一个视图模型而不是控制器，它只是视图的模型。视图模型存储视图的状态，视图对象决定应如何呈现视图模型的状态。

与 MVC 模式不同，视图模型不直接了解视图。视图模型不是直接向视图发送消息，而是通过观察者模式间接更新视图。当视图模型更改时，它会广播这些更改，并且视图通过更新自身来响应。这的主要优点是，即使不实例化视图对象也可以测试视图模型是否处于正确状态，这将增加许多异步操作（通常与渲染相关），而这些异步操作又必须进行协调。

以这种方式测试新模型很容易，因为您的模型公开了可以直接调用的方法。通过视图层测试逻辑更容易出错，因为它需要等待按钮加载并依赖于模拟鼠标单击和按键事件等脆弱消息的传递。

无论如何，当您超越 FIFA 11 后，您朝着 MVVM 类型的架构采取了哪些其他步骤？

MD 我应该指出，改进的测试自动化只是 MVVM 的好处之一。EA 的其他几个团队也出于各种原因朝着这个方向发展。我们迄今为止采取的步骤主要是为了使数据与屏幕的分离更加明显。不幸的是，FIFA 有太多的屏幕，我们不能只是进去重写一切。但是，我们可以做的是将新范式融入到新功能中。

JH 有趣的是，面对如此多的挑战，您选择以这种逐步的方式向 MVVM 演进您的架构。似乎您发现添加遵循这种新模式的新事件或额外组件，然后在您可以时开始使用它们更容易。我推测，在某个时候，计划是更全面地过渡到 MVVM——或类似的东西——因为机会会自己出现。

MD 这就是计划，因为这是我们实际可以进行的方式。在我们能够实现我所推动的全面自动化之前，还需要一段时间，但至少我们正朝着正确的方向前进。

我们接下来的挑战是弄清楚如何指定我们的测试，因为我们现在拥有一个架构，可以让我们访问这些东西。但我们仍然不知道这些测试应该是什么样子，它们应该如何打包，或者如何包含信息，以便易于维护并且对维护它们的人员有意义。

TC 对于 MVVM 类型环境的论点有什么阻力？人们是否担心转型会太难？

MD 毫无疑问，这将是困难的。更糟糕的是，软件工程师将不得不做出这些更改，而不是添加一些新功能——这可能是一个非常难以证明合理的牺牲。我甚至无法准确地说出他们可以通过自动化节省多少成本。事实是，他们可能不会节省那么多，因为我们只是在谈论将手动资源从一种测试转移到另一种测试。

TC 您是否认为构建 MVVM 实际上会更昂贵？或者这实际上更多的是软件工程师抵制改变他们习惯的工作方式？

MD 这取决于所涉及的底层代码。此外，我们有时会对现有功能进行增量更改。也就是说，我们有时需要重写功能，因为它们需要超越原始设计发展。如果我们无论如何都要重写一个功能，那么这当然提供了一个采用新方法的绝佳机会。

另一方面，如果我们为现有的游戏模式添加新的变化，或者为已经存在的东西添加一个小功能，那么当所有旧的东西仍然存在时，以新的方式来做这件事将非常困难。那只会使这些增量更改变得更加昂贵。

JH 似乎为了到达您实际获得一些有用的东西的地方，您需要将整个工作流程转移到 MVVM。我想这很难逐步完成。

MD 是的，没错。

JH 我们在 Netflix 遇到了这种情况。所以我认为您触及了一个值得指出的问题——即，在代码库中拥有两个不同但相似的库是一回事，而在同一个代码库中拥有两种不同的范式则完全是另一回事。当您处于这种情况时，入职开发人员可能很难弄清楚到底该怎么做。您是否发现这是一个绊脚石？这是否引起了任何摩擦？

MD 绝对是。世界各地有很多 FIFA 开发人员，因此将他们所有人统一起来以支持更多地朝着 MVVM 方向发展，这真是难以想象。

JH 我想知道这些开发人员目前对 MVVM 的态度是否反映了这样一个事实，即您所吹捧的好处只会稍后实现。除此之外，他们是否也意识到 MVVM 在一般开发方面可能是一种更好的架构，这与任何测试好处无关？

MD 实际上，我对在这里与我合作的软件工程师印象深刻。他们似乎都知道什么是正确的事情。但时间也是一个问题。

JH 可以说开发人员对 MVVM 没有任何异议，甚至非常赞成进行必要的更改以使用 MVVM 吗？

MD 通常，我会与一群游戏开发人员讨论一些想法，他们会说：“哦，是的，我们已经知道我们应该走那条路”，但是当涉及到实施时，由于时间限制，他们无法贯彻执行。

JH 就您如何前进而言，我了解到您仍然对架构有一些疑问，并且您仍在尝试弄清楚测试人员的 API 应该是什么样子。

MD 是的，没错，尽管我会将重点放在规范而不是 API 上，因为编程很昂贵。我们正在努力确定如何以一种可理解、可维护且在面对变化时具有鲁棒性的方式来指定这些东西。也就是说，以最纯粹的形式，您希望运行一个 OTP 测试，其中有 22 个控制台，其中 11 个分配给一个团队，另外 11 个分配给另一方，并且能够将所有适当的参数与每个控制台关联起来。

然后问题就变成了：您如何以一种能够涵盖广泛测试的方式来指定它？当然，这是因为每次您运行测试时，您都希望能够做不同的事情。例如，如果您遇到多场比赛的情况，您可能希望滚动浏览所有不同的球队、体育场和球衣，以便在数周的测试过程中，您最终会循环浏览尽可能多的不同组合——而所有这些都基本上只指定一个测试。无论如何，那是我们的目标，但目前尚不完全清楚我们将如何管理它。

JH 这里实际上有两个问题：（1）是否有可能？（2）它是否可以扩展？您还可以使用一些更高级的方法来构建异步测试，但这些方法是否对初级开发人员或测试工程师来说是可访问的？

MD 是的，没错。除非我们能够以低成本的方式做到这一点，否则做这件事毫无意义。

当涉及到人力资源的使用时，向自动化测试的过渡具有显着的成本维度。首先，必须说服习惯于以一种方式做事的软件工程师改变。他们必须学习一种新的范式，从同步编程转向异步编程，甚至可能学习一种 DSL（领域特定语言）来编写基于事件的测试。

其次，在低成本的质量保证测试人员所做的工作与为高薪专家保留的工作之间取得适当的平衡至关重要。这意味着利用游戏异步的性质，强调由事件启动和门控的声明式测试，同时设计旨在利用这些事件的编排测试。这可能允许大量廉价的编码人员编写声明式测试，而一小部分精选的高薪编码人员则专注于更复杂的编排问题。

JH 您是否探索过不同的语言，这些语言可以使低技能开发人员更容易编写基于事件的测试？

MD 我一直在考虑使用 DSL 的可能性。然而，令我担忧的是，曾经有一段时间我们不得不在测试代码中编码游戏信息，我担心如果我们选择错误的 DSL，我们最终可能会回到在某种其他类型的代码中编码信息。

我们希望使用的 DSL 的属性之一是游戏信息的容器，该容器需要足够透明，以便人们可以轻松访问该信息。重要的是，可以使用质量保证人员和游戏制作人员都熟悉的词汇来访问信息。

JH 明白了。DSL 从哪里开始，库在哪里结束之间的界限可能有些模糊。但是 DSL 也可以作为您已使用的通用编程语言的一部分嵌入。

MD 目前，我认为我们真的不会考虑任何 if-then-else 循环编码。我们可能只谈论刺激和响应级别的测试——也就是说，“当程序以这种特定方式响应时，然后提供这种刺激。”

TC Jafar，您在 Netflix 有过使用 DSL 的经验吗？

JH 我们实际上目前正在努力进行类似的转型——与其说是为了测试，不如说是为了找到一种更好的方法来协调我们应用程序中的并发性。我们现在为此使用的是 Rx（Reactive Extensions）库。关于这个库的有趣之处在于，它实际上已经集成到 C# 中，这意味着您可以比 if-then-else 更高的级别使用它来协调异步进程。还有一个 Reactive Extensions 的 JavaScript 版本，这是我们现在正在使用的。

虽然这应该使事情变得非常容易，但在实践中我们发现，对于开发人员来说，这是一种非常新的思维方式——尤其是那些来自 if-then-else、命令式、自上而下编程背景的开发人员。尽管事实上 Rx 抽象处于更高的层次，并且实际上非常声明式，并且显然足够灵活、强大和有能力处理各种复杂的异步操作。这与其说这种新语言更容易或更难使用，不如说当您来自同步思维方式时，过渡到异步编程可能非常具有挑战性。

异步编程需要大量投资，以便学习新事物和对代码进行全新思考。也就是说，我怀疑您是否能找到一种 DSL，可以在几周内，甚至在一个产品周期内，将同步程序员转变为异步程序员。

MD 这也是我的担忧。循环中肯定需要一些精通异步编程的人员。无论是谁在编写这些奇异的 OTP 测试，其中我们同时进行两到三场比赛，都绝对需要这些技能。

但对我来说，悬而未决的问题是：您如何做到这一点，同时仍然让质量保证人员指定大部分测试？如果我们能够达到让质量保证人员编写的测试覆盖 80% 的游戏代码的程度，那就太棒了。然后，如果其他 20% 的 OTP 测试必须由高薪专家编写，那就这样吧。只要我们能够以较低的成本覆盖大部分代码，我就可以接受。

JH 这些专业的开发人员可能很昂贵，但如果他们使用正确的工具、语言、框架或范式，那么您就有可能从他们身上榨取更多价值。识别那些天生倾向于异步编程并对他们进行强化培训的个人具有真正的价值。除此之外，我认为我们开始看到更多的框架和工具，一旦您开始利用它们，以便这些专家每天可以生成六个、七个甚至八个测试，而不是仅仅两个，它们就有可能产生巨大的节省。

TC 最初，Michael，我感觉您希望找到一种 DSL，让您可以更好地利用质量保证人员，使他们能够执行相当广泛的测试集。同时，Jafar，听起来您迄今为止的经验是，异步的东西足够复杂，真正的胜利在于找到那些在异步方面有天赋的人，然后让他们超级高效。

从长远来看，这将如何发展？异步编程是否太难了，以至于它将永远是少数精英的领域？或者有什么迹象表明这可以更容易地为不太复杂的程序员所接受？

MD 我认为我们会看到两者的结合。任何产品都将有很大一部分保持相当简单，一旦您有了合适的框架，编码很可能属于可以由低成本人员处理的那种。但是，该框架需要由了解异步性并具有处理其他相当复杂要求的培训和经验的人员来设置。肯定会有一些训练有素且才华横溢的个人的角色，但您也希望确保您可以利用这些努力使他们的贡献具有广泛的适用性。

JH 我对此有点悲观。我们最近正在考虑在 Netflix 的服务器上构建一些异步框架，我认为我们的一些开发人员最初的态度也类似，他们假设也许我们 80% 的异步问题可以通过一些辅助方法轻松解决。这个想法是为一些更常见的并发模式提供一些简单的 API，以便初级开发人员能够解决大多数异步问题。我们发现简单的 API 仅解决了我们最终用户案例的约 10-15%——而不是 80%。那是因为很容易从悬崖上掉下来，此时有必要恢复到处理诸如信号量或事件订阅之类的原语。

事实证明，即使是看似微不足道的异步问题实际上也非常复杂。例如，如果您发出远程请求，它总是需要一些错误处理，例如重试。如果两个操作同时执行，则需要一种为每个操作指定不同错误处理策略的方法。更重要的是，这些操作中的每一个都可能由其他几个顺序和并发操作组成。实际上，您需要一个组合系统来表达如此丰富的语义。

我承认，由于测试的要求不如应用程序开发那么严格，因此一些简单的辅助 API 可能在构建测试方面更有用。因此，也许您是对的，Michael，认为您可以将低技能程序员与高技能程序员混合使用。尽管如此，这种混合究竟是什么样子还有待观察。

MD 我完全同意。我认为这是最大的问题。

TC 从稍微不同的角度来看，我的团队一直在为异步环境开发，而有限状态机在这方面效果非常好。我们发现它们是捕获有关事件和转换等信息的绝佳方式。那么您对使用状态机和围绕状态机构建的某种语言有什么看法？状态机是否足够简单，可以让不太熟练的开发人员（如质量保证人员）有效地使用它们？

MD 我当然认为状态机足以很好地描述数学原理。一个转换实际上相当于一个刺激-响应对。所以，是的，你可以把我们正在讨论的描述为分层状态机。是的，那是用于讨论这个问题的完美的数学范例。但是你不能把这个呈现给低成本人员，并期望他们能够用它做任何事情。然而，你可以做的是使用相同的数学原理来创建驱动所有这些东西的工具和机制。但是，就你放在 QA 人员面前的东西而言，那只能是他们已经认识到的作为他们正在寻找的响应的刺激。

JH 我完全同意。的确，这些原语非常简单，每个人都可以理解如何连接到一个事件，设置一个变量，然后从一个状态移动到另一个状态。然而，在实践中，这些简单的原语并不意味着整个程序本身就会很简单。事实上，它会非常复杂，因为有太多不同的活动部件。

JavaScript 世界中另一种越来越流行的异步编程方法是围绕一个名为 Promises 的抽象概念，它正在被集成到 CommonJS 和 F# 中。这为你提供了一种异步类型，它提供了可组合性，同时让你能够以无状态的方式构建异步程序。这可能最终是你不得不接受的模型——一种描述异步计算的声明式无状态方式——因为这是一个较低技能的开发人员可能能够利用的抽象级别。

TC 你能提供一个例子吗？

JH 关键在于，有一种关于异步程序的新思维方式。从 GOTO 跳转到结构化程序提高了抽象层次。今天，我们使用回调和状态机构建异步程序，而这些程序遭受了与旧的基于 GOTO 的程序相同的许多缺点：逻辑倾向于被碎片化成许多不同的部分。我们可以用我们早先解决这个问题的方式来解决这个问题——通过提高抽象层次。我们可以将异步程序建模为数据序列，而不是使用回调和状态机来构建它们。例如，一个事件可以被看作是一个数据序列——事实上，一个没有终点的序列。鼠标移动事件不可能说，“嘿，我完成了。”它只是永无止境地继续下去。

有趣的是，我们已经有一种在同步编程中对序列进行建模的方法：熟悉的迭代器是一种同步地遍历数据结构的方式，从左到右，只需不断请求下一个项目，直到迭代器最终报告没有更多数据。Erik Meijer 在微软时，将迭代器模式由内而外地翻转，发现了观察者模式。用数学术语来说，观察者模式是迭代器模式的对偶。这是一个非常重要的统一，因为它意味着我们可以对迭代器做的任何事情也可以对观察者（如事件监听器）做。

这里的意义在于，我们有几种用于操作可以表示为迭代器的数据结构的高级语言。最相关的例子是 SQL，我认为 SQL 是一种非常成功的高级语言，因为它允许开发人员创建复杂但易于理解且功能强大的查询。现在，基于观察者和迭代器模式是对偶的发现，Erik 已经设法构建了一个框架，允许使用类似 SQL 的语言来创建异步程序。

这个想法是，事件和异步数据请求是集合，就像数组一样。唯一的区别是异步集合是随时间到达的。可以在内存中的集合上执行的大多数操作也可以在随时间到达的集合上执行。因此，我们发现最初构建到 C# 中的 DSL 来组合同步数据序列也可以用于组合异步序列。结果是一种用于构建异步程序的高级语言，它具有 SQL 的表达性和可读性。

MD 这是一个朝着正确方向迈出的一步。我肯定会进一步研究这个。

JH 我们正在我们的 Xbox 平台上使用这项技术。它似乎正是你正在寻找的，Michael。

TC 你能描述一下 Erik Meijer 的 Reactive Extensions 如何应用于 QA 环境吗？假设你有一堆控制台需要驱动通过一些序列，以便你可以验证在你正在测试的游戏中是否发生了某些事情。Rx 在其中如何应用？在这种情况下你会查询什么，以及你将如何把这变成一个测试结果？

JH 这是一个很好的问题，因为有些人很难看到查询数据库和创建测试之间的联系。测试本身实际上是一个查询，类似于：“这个流是否触发了，那个流是否在某个特定事件触发之前触发了，然后导致了其他事情发生？”这与查询一个表以查看某个条件是否为真没有什么不同。

TC 我们仍然需要一些机制来驱动系统通过不同的状态。也许 Rx 甚至可以用于此。在每个阶段，查询都会返回真或假。如果返回假，那么我们将知道测试没有通过，因为我们一直期望的事件序列与我们发出的查询不匹配。

JH 完全正确。但这可以分为两个步骤。第一步是 Michael 已经提到的：转换系统，使其更易于观察，并且总的来说，这仅仅是添加在有趣的事情发生时触发的事件。第二步涉及在这些事件上构建查询。这些查询将是非常非常声明式的——它们根本不是状态机——因此你将能够在驱动系统通过时确认某些条件得到满足。

TC 听起来你现在正在将这种方法应用于一个产品。这种经验被证明是积极的吗？你是否发现 Rx 语法或查询语法是非专家可能能够用来捕获关于系统的信息的东西？

JH 到目前为止，我不认为这种语法真的像我预期的那样有帮助。真正的挑战在于跳跃到将事件视为集合的思维方式。大多数人一生都在非常机械地思考事件。尽管将事件视为集合在概念上可能更简单，但如果仅仅是因为很难打破旧的坏习惯，那么在组织层面进行转变可能也很困难。然而，我的感觉是，如果你能找到一些已经倾向于函数式编程的开发人员，那么当你给他们这些强大的新的异步编程工具时，你将能够实现我们正在谈论的经济效益。

喜欢它，讨厌它？请告诉我们

[email protected]

最初发表于 Queue vol. 12, no. 5—
在数字图书馆中评论这篇文章

更多相关文章

Sanjay Sha - 企业应用程序的可靠性
企业可靠性是一门学科，它确保应用程序以一致、可预测和经济高效的方式交付所需的业务功能，而不会损害可用性、性能和可维护性等核心方面。本文描述了一套核心原则和工程方法，企业可以应用这些原则和方法来帮助他们驾驭复杂的企业可靠性环境，并交付高度可靠且经济高效的应用程序。

Robert Guo - MongoDB 的 JavaScript Fuzzer
随着 MongoDB 随着时间的推移变得更加功能丰富和复杂，开发更复杂的方法来查找错误的需求也在增长。三年前，MongoDB 将一个自研的 JavaScript fuzzer 添加到其工具包中，它现在是我们最多产的错误查找工具，负责在两个发布周期中检测到近 200 个错误。这些错误跨越了从分片到存储引擎的各种 MongoDB 组件，症状范围从死锁到数据不一致。fuzzer 作为 CI（持续集成）系统的一部分运行，它经常捕获新提交代码中的错误。

Robert V. Binder, Bruno Legeard, Anne Kramer - 基于模型的测试：它的现状如何？
你可能听说过 MBT（基于模型的测试），但像许多没有使用过 MBT 的软件工程专业人士一样，你可能对其他人使用这种测试设计方法的经验感到好奇。从 2014 年 6 月中旬到 2014 年 8 月初，我们进行了一项调查，以了解 MBT 用户如何看待其效率和有效性。2014 年 MBT 用户调查是 2012 年类似调查的后续调查，向所有评估或使用过任何 MBT 方法的人开放。它的 32 个问题包括 2013 年高级自动化测试用户大会上分发的调查中的一些问题。一些问题侧重于 MBT 的效率和有效性，提供了管理者最感兴趣的数据。

James Roche - 在质量保证中采用 DevOps 实践
在很长一段时间里，软件生命周期管理都是一项受控的活动。产品设计、开发和支持的持续时间足够可预测，公司及其员工可以围绕产品发布安排他们的财务、假期、手术和合并。当开发人员忙碌时，QA（质量保证）就比较轻松。随着发布周期的编码部分接近尾声，QA 接管，而支持人员开始增加。然后，当产品发布时，开发人员松了一口气，休息了一下，然后再次开始循环，而支持人员则过渡到忙于支持新产品。