ACM通信

实践

ea的自动QA测试

ACM通信，2014年7月，第57卷第7期，50-57页
10.1145 / 2617754
评论

对于数以百万计的游戏极客来说，艺电的质量保证(QA)测试员的职位似乎是一份理想的工作。但从公司的角度来看，与QA相关的开销看起来非常可怕，特别是在大型多人游戏时代。

因此，自动化QA测试具有比手动测试更快、更经济、更高效和更可扩展的潜力。虽然自动化不能模仿人类测试人员所能做的所有事情，但它对于许多类型的基本测试非常有用。然而，事实证明，向自动化测试的过渡并不像乍一看那么简单。这里考虑了一些最棘手的挑战。

在不列颠哥伦比亚省温哥华的艺电公司(Electronic Arts)，迈克尔Donat说是自动化的倡导者。他目前的工作重点是玩家和业务分析团队的流程改进。他曾在Silicon Chalk和ActiveState Corp.担任QA经理，并曾在微软担任软件设计工程师。

加入讨论的是魔法师侯赛因他是Netflix的首席软件开发人员。此前，他在微软工作，其中一项任务涉及为Silver-light开发平台创建测试环境。在那里，他被介绍到模型视图视图模型(MVVM);他说，他是一个皈依者，现在喜欢在适用的地方传播MVVM的福音。

特里Coatta的成员ACM队列董事会召集了这个小组讨论自动化QA测试的潜力。他和多纳曾在Silicon Chalk一起工作，在那里创建复杂的测试环境是他们面临的挑战之一。Coatta现在是海洋学习系统的CTO，为海洋工人开发学习管理系统。

特里COATTA:到目前为止，你在EA应用自动QA测试的努力，我想你已经发现了一些坎坷。

迈克尔DONAT说一开始我们认为自动化是个好主意，但后来我们尝试了，结果失败了。尽管如此，我们还是找到了问题所在，并修复了它。但是，虽然我们达到了一个良好的平台，我们意识到还有很长的路要走。我们的解决方案显然不能得到我们想要的一切，这是一种广泛应用自动化测试的方法。为了达到这个目标，以及其他一些原因，我们中的一些人得出结论，我们真正需要的是一个沿着MVVM路线的新体系结构。

魔法师侯赛因:你当初选择自动化的动机到底是什么?

DONAT说:我们的主要动机纯粹是为了节省手动测试的成本，考虑到我们游戏的复杂性，这一点变得相当重要。基本上，需要我们手动重新测试所有内容的代码更改可能会非常昂贵。通过减少这些成本，我们觉得我们有机会将测试人员从我所说的“稳定性测试”中转移出来，这是自动化能够处理的事情，所以他们可以开始更多地关注我们游戏体验的真实性和趣味性。

---

“迈克尔·多纳特:我们正试图确定如何指定这些东西，使它们在面对变化时能够被理解、可维护和健壮。”

---

COATTA:在稳定性测试方面，您认为自动化的第一个机会是什么?

DONAT说:当我们致力于EA Sports的《FIFA 10》(足球游戏)时，我们开始认真考虑这一问题。最初，这是一种10对10的游戏玩法，然后随着守门员的加入变成了11对11。所以我们需要20或22个测试者。但这还不是全部，因为我们还需要测试不同匹配之间的交互，以确保服务器不会混淆向哪个匹配发送什么信息。所以，除了要求测试人员负责一场比赛外，我们还需要同时安排至少一场其他比赛，这意味着我们需要40名左右的测试人员同时参与其中。

然后，即使我们成功地将所有人组织起来，我们也可能会在比赛开始几秒钟后遇到一些琐碎的漏洞，从而导致整个游戏的失败。除了浪费，这让很多人非常沮丧，他们本可以在那段时间里做一些更有成效的事情。所有这些都为自动化提供了强有力的论据。

COATTA在你为实现这个目标而努力的过程中，你遇到了哪些问题?

DONAT说首先，在《FIFA 10》中设置一场OTP(在线团队游戏)比赛需要用户通过几个屏幕。有20个控制台，脚本是基于时间的，这意味着它向控制台发送命令，然后等待规定的时间，使所有控制台进入正确的状态。然后它会发出下一批命令。我们的目标是在一系列屏幕转换中移动主机，以便为游戏设置内容:参与者选择他们想玩哪一边，他们想穿什么球衣，他们想玩什么位置，以及各种其他参数。所有这些事情都需要协调发生，以保持游戏编程尽可能简单。

---

JAFAR HUSAIN:在一个代码库中拥有两个不同但相似的库是一回事，而在同一个代码库中拥有两个不同的范例又是另一回事。当你处于这种情况下，对于新手开发者来说，你便很难明确该做些什么。”

---

当时，我们原始的测试自动化系统使得前端导航存在问题。时机必须恰到好处，否则测试就会失败。因此，我开始提倡一种完全跳过前端的方法，但我被迫改变了我的观点。在FIFA 10 OTP的手动测试过程中，出现了许多问题，事实上，手动测试的预算不得不大幅增加。围绕着公司的问题是，“我们如何阻止这种情况在未来发生?”

这促使我分析了我们在QA周期中获得的大约300个崩溃bug。我的部分目标是看看继续追求自动化是否有任何显著的ROI可以实现。我发现略多于一半的崩溃bug实际上是在最初的屏幕转换中出现的。事实证明，我一直在向游戏开发者传达错误的信息。也就是说，我们确实需要在前端和后端进行测试。我们不能仅仅通过取消前端来简化自动化。

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

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

最初为《FIFA》整合测试自动化框架的人意识到这是必要的，但处理它的能力在过去几年里已经腐烂了，当我们准备好处理《FIFA 11》时已经不存在了。我们需要做的一件事是获取我们需要从UI中看到的细节这样我们就能知道东西实际在哪里。

侯赛因:我认为不是从视图层驱动东西，也就是通过控制器和视图，你需要绕过视图，直接到模型本身。

DONAT说信不信由你，我们还没到那个阶段。在这一点上，我们很高兴有更可靠的脚本，因为它们知道它们在程序的状态中处于什么位置。

COATTA:那样的话，你实际上可以关闭反馈循环。在此之前，你会发出一个命令，然后必须等待并相信上帝，在此期间不会发生什么事情，而现在你不需要有这种信任，因为你可以验证。

DONAT说:对。我们达到了一个更可控的状态转变。我们在《FIFA 11》中所做的另一大QA改进便是添加了自动辅助功能，即让自动化机制去运行游戏本身，同时让一至两名手动测试者通过为选定的主机提供控制器输入去推动真正的游戏玩法。他们不需要20个人在场。这是一个巨大的进步。

COATTA有些人可能已经安于现状了。

DONAT说也许吧，但对我来说只是迈出了第一步。虽然将一些测试自动化引入到像FIFA OTP这样的特定应用中是一件很棒的事情，但我真正想要的是一个更广泛的应用，因为这将使我们能够将测试人员的注意力集中在整体游戏体验上。这是打造卓越产品的必经之路。

《FIFA 11》的工作帮助EA相信了自动测试的潜在好处，但要实现这一目标显然需要一个不同的架构。答案似乎在于MVVM范式，这是一种很大程度上基于MVC的架构模式。MVVM促进了图形用户界面开发和后端逻辑开发之间的清晰分离，这意味着它应该允许EA将OTP玩法测试从UI测试中分离出来。

COATTA:当你完成了FIFA 11的自动化测试后，回顾一下事情的进展，你认为你的下一步是什么?

DONAT说:尽管《FIFA 11》的表现令人鼓舞，但问题是我们必须花大量时间进行编码。这主要是因为在游戏开发过程中，我们会频繁地改变某些屏幕，然后我们就必须在测试自动化脚本中做出相应的改变。这并不总是正确的协调，所以事情最终会破裂。结果，我们有一个非常脆弱的测试自动化脚本，它需要一个软件工程师专门从事维护工作。

在《FIFA 11 OTP》中，这种花费是合理的，但我却不能在游戏的其他领域中使用类似的自动化测试。我们不得不继续依靠大量的手工测试人员来完成测试的全部范围。很明显，我们需要找到一种方法来编码我们的测试，这样就可以减少执行持续维护的频率，使用更便宜的资源。

COATTA:那你到底去了哪里?

DONAT说:基本上，这意味着体系结构需要改变。玩家应该很容易看到游戏如何根据屏幕过渡进行布局，但同时也应该能够随时访问这些屏幕所依据的数据。一般来说，事物应该在比当前情况更高的抽象级别上更容易访问。

侯赛因:是否可以这样说，您希望将重点放在独立于实际UI控件的工作流上?

DONAT说:完全正确。一旦这一点变得清晰，我们意识到我们需要一个不同的架构——一个更像MVVM的东西。这并不是说它必须是MVVM;它只需要是能够提供那种能力的东西。

COATTA: MVVM范例的什么是重要的?

DONAT说从本质上说，它允许我们将屏幕使用的数据与屏幕本身分开。我们需要这种分离，这样自动化系统才能访问它们需要连接的东西。

侯赛因例如，将MVVM方法与许多开发人员可能更熟悉的mvc模式进行对比可能是有用的。在MVC架构中，控制器和视图相互了解，并直接向对方发送消息。在MVVM体系结构中，不是控制器，而是视图模型，它只是视图的模型。视图模型存储视图的状态，视图对象决定视图模型的状态应该如何表示。

与MVC模式不同，视图模型对视图没有直接的了解。视图模型不是直接向视图发送消息，而是通过观察者模式间接更新视图。当视图模型发生更改时，它会广播这些更改，视图通过更新自身来响应。这样做的主要好处是，可以在不实例化视图对象的情况下测试视图模型是否处于正确的状态，这将添加许多异步操作(通常与呈现相关)，而这些操作反过来又必须进行协调。

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

不管怎样，当你们超越FIFA 11的时候，你们在MVVM的架构上又采取了哪些额外的步骤呢?

DONAT说:我应该指出，改进的测试自动化只是MVVM的一个好处。由于各种原因，EA的其他几个团队也在朝着这个方向发展。到目前为止，我们所采取的措施主要是使数据与屏幕的分离更加明显。不幸的是，《FIFA》拥有如此多的屏幕，我们不能只是进入并重写所有内容。然而，我们所能做的是将新的范式应用到新的特性中。

侯赛因:有趣的是，面对如此多的挑战，您选择以这种逐步的方式向MVVM发展您的体系结构。您似乎已经发现，添加遵循此新模式的新事件或额外组件，然后开始尽可能地使用它们会更容易。我认为在某个时候，计划是更大规模地过渡到MVVMor类似的东西，当机会出现的时候。

DONAT说这是我们的计划，因为这是我们真正能做的唯一办法。我们还需要一段时间才能实现我所推动的全面自动化，但至少我们正在朝着正确的方向前进。

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

COATTA:对于mvvm类环境的争论有什么阻力?人们是否担心转型会太过艰难?

DONAT说毫无疑问，这将是困难的。更糟糕的是，软件工程师将不得不做出这些改变，而不是添加一些新功能，这可能是一个非常艰难的牺牲。我甚至不能确切地说，他们能通过自动化节省多少钱。事实是，他们可能不会节省那么多，因为我们只是在讨论将手工资源从一种测试类型转移到另一种测试类型。

COATTA:你认为在MVVM中构建会更昂贵吗?或者这实际上更多的是软件工程师对改变他们习惯的工作方式的抗拒?

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

另一方面，如果我们要在现有的游戏模式中添加新内容，或者在已有的内容中添加一个小功能，那么在旧内容仍然存在的情况下，采用新方法是非常困难的。这只会使那些渐进式的改变变得更加昂贵。

侯赛因:看起来，为了达到一个你真正得到一些有用的东西的地方，你需要将整个工作流移动到MVVM。我想这很难循序渐进地实现。

DONAT说:没错。

侯赛因我们在Netflix就遇到过这种情况。因此，我认为您已经触及了一些值得指出的东西，即在一个代码库中拥有两个不同但相似的库是一回事，而在同一个代码库中拥有两个不同的范式则完全是另一回事。当你处于这种情况下，对于新入职的开发人员来说，弄清楚到底该做什么是非常困难的。你觉得这是一个绊脚石吗?这引起摩擦了吗?

DONAT说:绝对的。世界上有许多FIFA开发者，所以将他们统一起来以支持向MVVM方向发展的想法是很难想象的。

侯赛因:我不知道这些开发人员目前对MVVM的态度是否反映了这样一个事实，即您所兜售的好处只会在下游实现。除此之外，除了测试方面的好处，他们是否也意识到MVVM对于开发来说可能是一个更好的架构?

DONAT说实际上，和我一起工作过的软件工程师给我留下了很深的印象。他们似乎都知道该怎么做。但时间也是一个问题。

侯赛因是否可以说开发人员对MVVM没有任何异议，甚至可能非常支持进行必要的更改以使用MVVM?

DONAT说:通常情况下，当我与一群游戏开发者谈论某个想法时，他们会说:“哦，是的，我们已经知道我们应该走那条路了。”但当涉及到执行时，由于时间限制，他们无法坚持到底。

侯赛因:关于你如何前进，我猜你仍然有一些关于架构的问题，你也仍然试图弄清楚你的测试人员的API应该是什么样子的。

DONAT说:没错，不过我会把重点放在规范而不是API上，因为编程是昂贵的。我们正试图确定如何指定这些东西，使它们在面对变化时是可理解的、可维护的和健壮的。也就是说，在其最纯粹的形式中，您希望运行一个OTP测试，其中有22个控制台，其中11个分配给一个团队，另外11个分配给另一个团队，同时能够将所有适当的参数与每个控制台关联起来。

那么问题就变成了:如何以一种涵盖广泛测试范围的方式来指定呢?当然，这是因为每次运行测试时，您都希望能够做不同的事情。例如，如果你有一个多场比赛的情况，你可能想要滚动所有不同的球队，体育场，和球衣，这样在数周的测试过程中，你将循环通过尽可能多的不同组合，所有这些基本上只指定一个测试。无论如何，这是我们的目标，但目前还不完全清楚我们将如何做到这一点。

侯赛因:这里确实有两个问题:(1)这可能吗?(2)是否可伸缩?还有一些更高级的方法可以用来构建异步测试，但是初级开发人员或测试工程师可以使用这些方法吗?

DONAT说:对。除非我们能以低成本的方式做这件事，否则做这件事没有意义。

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

其次，在低成本QA测试人员所做的工作和高收入专家所做的工作之间保持适当的平衡是非常必要的。这意味着利用游戏的异步特性，强调由事件启动和门控的声明性测试，同时设计针对这些事件的测试。这可以让大量廉价的编码员编写声明性测试，而让一组精选的昂贵的编码员专注于更复杂的编排问题。

侯赛因:您是否探索过不同的语言，可以让低技能的开发人员更容易编写基于事件的测试?

DONAT说我一直在考虑使用DSL的可能性。然而，让我担心的是，我们曾经不得不在测试代码中编码游戏信息，我担心如果我们选择了错误的DSL，我们最终可能会回到用其他类型的代码编码信息。

我们希望使用的DSL属性之一是游戏信息的容器，它必须足够透明，以便人们能够轻松访问这些信息。使用QA人员和游戏制作人都熟悉的词汇来访问信息是很重要的。

侯赛因:理解。DSL的开始和库的结束之间的界限可能有些模糊。但是DSL也可以作为您已经使用的通用编程语言的一部分嵌入。

DONAT说:目前，我不认为我们真的会看到任何if-then-else循环编码。我们可能只讨论刺激和反应层面的测试，也就是说，“当程序以这种特定方式响应时，就提供这种刺激。”

COATTA:贾法尔，你在Netflix有使用dsl的经验吗?

侯赛因:实际上，我们目前正在努力进行类似的转换，与其说是为了测试，不如说是为了找到一种更好的方法来协调我们应用程序中的并发性。我们现在使用的是Rx(反应扩展)库。这个库的有趣之处在于它实际上已经集成到c#中，这意味着您可以在比if-then-else更高的级别上使用它来协调异步进程。还有一个JavaScript版本的响应式扩展，就是我们现在使用的。

虽然这应该使事情变得非常简单，但在实践中，我们发现这对开发人员来说是一种非常新的思维方式，特别是那些具有if-then-else、命令式和自顶向下编程背景的开发人员。尽管Rx抽象是在一个更高的层次上，而且实际上是非常具有声明性的，显然非常灵活、强大，足以处理各种复杂的异步操作。这与使用这种新语言是否困难无关;只是，当你从同步的思维方式来的时候，向异步编程的转变可能是非常具有挑战性的。

---

TERRY COATTA:我的团队一直在为异步环境开发，有限状态机在这方面工作得非常好。我们发现它们是捕捉有关事件、过渡等信息的极好方法。”

---

异步编程需要大量的投资，学习一些新的东西，并以完全不同的方式思考代码。也就是说，我怀疑你能否找到一种DSL，能够在几周内，甚至在一个产品周期内，将同步程序员转换为异步程序员。

DONAT说这也是我所担心的。在循环中需要精通异步编程的人。无论谁编写了这些奇特的OTP测试，我们同时进行两到三场比赛，都肯定需要这些技能。

但对我来说，悬而未决的问题是:你如何做到这一点，同时还能让QA人员指定大部分测试?如果我们能够让QA人员编写的测试覆盖80%的游戏代码，那就太棒了。如果另外20%的OTP测试必须由高薪的专家编写，那就这样吧。只要我们能以低成本的方式覆盖大部分代码，我就不会介意。

侯赛因:那些专业的开发人员可能很贵，但如果他们使用了正确的工具、语言、框架或范式，那么你就有可能从他们身上榨取更多。识别那些天生倾向于异步编程的人并对他们进行密集培训是有实际价值的。除此之外，我认为我们开始看到更多的框架和工具，一旦您开始利用它们，这些框架和工具就有可能产生一些巨大的节省，这些专家可以每天生产6、7甚至8个测试，而不是仅仅2个。

COATTA: Michael，最初我的感觉是，您希望找到一种DSL，使您能够更好地利用QA人员，使他们能够执行相当广泛的测试集。与此同时，贾法尔，听起来你目前的经验是，异步的东西足够复杂，真正的胜利在于找到那些在这方面有天赋的人，然后让他们超级高效。

这将如何长期发挥作用?异步编程是如此的困难以至于它总是会成为有能力的人的领域吗?或者是否有任何迹象表明，这可以让不太复杂的程序员更容易使用?

DONAT说我认为我们将会看到两者的结合。在任何产品中，都会有一些相当简单的部分，一旦你有了合适的框架，编码很可能是那种可以由低成本人员处理的类型。但是这个框架需要由理解异步的人来建立，并且需要有处理其他复杂需求的培训和经验。肯定会有一些训练有素、才华横溢的人的职位，但你也要确保你能利用这些努力，使他们的贡献广泛适用。

侯赛因我对此有点悲观。我们最近打算在Netflix的服务器上构建一些异步框架，我想我们的一些开发人员一开始也抱着类似的态度，假设我们80%的异步问题都可以通过一些辅助方法轻松解决。其想法是为一些更常见的并发模式提供一些简单的api，以便初级开发人员能够处理大多数异步问题。我们发现简单的api只能解决10% - 15%的最终用户案例，而不是80%。这是因为它很容易掉下悬崖，这时就有必要恢复到处理原语，如信号量或事件订阅。

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

我承认，一些简单的辅助api可能对构建测试更有用，因为它们的要求没有应用程序开发那么严格。也许你是对的，迈克尔，你认为你可以把低技能的程序员和高技能的程序员混在一起。不过，这种混合到底是什么样子还有待观察。

DONAT说我完全同意。我认为这是一个大问题。

COATTA:另一方面，我的团队一直在为异步环境开发，有限状态机在这方面工作得非常好。我们发现它们是一种非常好的方法来捕捉关于事件和过渡之类的信息。那么您对使用状态机以及围绕它构建的某种语言有什么想法?状态机是否足够简单，可以让技能较低的开发人员(如QA人员)有效地使用它们?

DONAT说:我当然认为状态机很好地描述了数学。过渡实际上相当于刺激-反应对。所以，是的，你可以把我们正在讨论的描述为层次状态机。是的，这是用来讨论这个问题的完美数学范式。但你不能把它展示给低成本的员工，并期望他们能够用它做任何事情。但你能做的，就是用同样的数学来创造工具和机器来驱动这些东西。然而，就你摆在QA人员面前的东西而言，那只能是他们已经认识到的对他们正在寻找的反应的刺激。

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

另一种异步编程的方法在JavaScript世界中获得了追随者，它围绕着一种被集成到常见JS和f#中称为承诺的抽象。这为您提供了一个异步类型，它提供了可组合性，同时允许您以无状态的方式构建异步程序。这可能是你最终不得不接受的模型——一种描述异步计算的声明式无状态方式——因为这是一个抽象级别，低技能的开发人员可能能够利用。

COATTA你能举个例子吗?

侯赛因归根结底，这是一种思考异步程序的新方式。从goto到结构化程序的转变提高了抽象的水平。今天，我们构建带有回调和状态机的异步程序，这些程序与基于goto的旧程序有许多相同的缺点:逻辑往往被分割成许多不同的部分。我们可以用之前解决这个问题的相同方法——提高抽象级别——来解决这个问题。我们可以将它们建模为数据序列，而不是使用回调和状态机来构建异步程序。例如，一个事件可以被看作是一个数据序列，事实上，它没有结束。移动鼠标事件不可能说，“嘿，我完成了。”就这样没完没了。

有趣的是，我们已经有了在同步编程中对序列建模的方法:我们熟悉的迭代器是从左到右在数据结构中移动的同步方法，只需继续请求下一项，直到迭代器最终报告没有更多数据。Erik Meijer，当他在微软的时候，把迭代器模式翻了个底朝天，发现观察者模式掉出来了。在数学术语中，观察者模式是迭代器模式的对偶。这是一个非常重要的统一，因为这意味着我们可以对迭代器做的任何事情也可以对观察器(如事件监听器)做。

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

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

DONAT说这是朝正确方向迈出的一步。我一定会进一步调查的。

侯赛因:我们现在正在Xbox平台上使用这项技术。这似乎正是你想要的，迈克尔。

COATTA:你能描述一下Erik Meijer的响应式扩展在QA环境中的应用吗?假设你有一堆主机，你需要通过一些序列，以便验证你所测试的游戏中发生的某些事情。Rx在哪里适合呢?在这种情况下，您会查询什么?您如何能够将其转化为测试结果?

侯赛因:这是一个很好的问题，因为有些人很难看出查询数据库和创建测试之间的联系。测试实际上是这样的查询:“在某个特定事件触发之前，这个流是否触发，那个流是否触发，然后导致其他事情发生?”这实际上与查询一个表来查看某个条件是否为真没有什么不同。

COATTA:我们仍然需要一些机制来驱动系统通过不同的状态。也许Rx甚至可以用来做这个。在每个阶段，查询将返回为true或false。如果它返回false，那么我们就知道测试没有通过，因为我们所期望的事件序列与我们发出的查询不匹配。

侯赛因:完全正确。但这可以分为两个步骤。第一个是Michael已经提到过的:过渡系统，使其更可观察，总的来说，这只是简单地添加事件，当有趣的事情发生时触发。第二步涉及在这些事件上构建查询。这些查询将非常非常具有声明性——它们根本就不是状态机，因此当您在系统中驾驶时，您将能够确认某些条件得到满足。

COATTA听起来你现在正在把这种方法应用到一个产品上。这种经验被证明是积极的吗?您是否发现Rx语法或查询语法是非专家可以用来捕获有关系统的信息的东西?

侯赛因到目前为止，我不认为语法真的像我预期的那样有帮助。真正的挑战是如何将事件视为集合。大多数人在他们的职业生涯中都非常机械地思考事件。尽管将事件视为集合可能在概念上更简单，但在组织级别进行转换可能也很困难，因为很难打破坏的旧习惯。然而，我的感觉是，如果您能找到一些已经倾向于函数式编程的开发人员，那么当您为他们提供这些用于异步编程的强大新工具时，您将能够实现我们所讨论的各种经济。

相关文章
在queue.acm.org

编排一个自动化测试实验室
迈克尔Donat说
http://queue.acm.org/detail.cfm?id=1046946

用自动化测试发现可用性错误
朱利安·哈蒂
http://queue.acm.org/detail.cfm?id=1925091

在质量保证中采用DevOps实践
詹姆斯罗氏
http://queue.acm.org/detail.cfm?id=2540984

数字图书馆是由计算机协会出版的。版权所有©2014 ACM, Inc.

---

没有找到条目