大到无法测试 -

2005年2月16日
第3卷，第1期

规模过大，难以测试

测试大型系统是一项艰巨的任务，但我们可以采取一些步骤来减轻痛苦。

KEITH STOBIE，微软

软件规模和复杂性的日益增加，加上并发和分布式系统，已经明显表明仅使用手工测试的无效性。代码覆盖率的误用和对随机测试的规避加剧了这个问题。我们必须重新开始，从良好的设计（包括依赖性分析）、良好的静态检查（包括模型属性检查）和良好的单元测试（包括良好的输入选择）开始。代码覆盖率可以帮助选择和优先排序测试，从而提高效率，全对偶技术也可以控制配置的数量。最后，测试人员可以使用模型来生成测试覆盖率和良好的随机测试，并充当测试预言。

手工测试已被硬件和软件超越

多年来，硬件发展一直遵循摩尔定律，在相同的成本平台上实现了运行日益复杂的软件的能力。开发人员利用这一点，将他们的抽象层次从汇编语言提高到第一代编译语言，再到诸如C#和Java之类的托管代码，以及诸如Visual Basic之类的快速应用程序开发环境。尽管每个程序员每天的代码行数似乎保持相对固定，但每行代码的功能已经增强，从而可以构建复杂的系统。摩尔定律每18个月提供两倍的计算能力，而软件代码规模趋于每七年翻一番，但软件测试似乎并没有跟上步伐。

不幸的是，通常来说，计算能力的提高并没有使测试变得更容易。虽然在少数情况下，更强大的硬件意味着我们可以进行更全面的测试，但总的来说，测试问题正在变得更糟。您可以在合理的时间内测试平方根的所有32位值，^1,2 但我们现在正转向具有64位值（甚至更长的浮点数）的64位机器。假设每个测试用例花费一纳秒，则测试所有值将需要584年。当然，您可以扩展到例如1,000个处理器，但仅此一项测试用例仍然需要六个月的时间。

需要考虑的另外两个复杂性问题是：软件可以经历的不同执行状态的数量和并发性。用户界面最初非常僵化，允许用户通过一组固定的操作进行操作，例如，一组分层菜单和提示。现在，良好的用户设计是事件驱动的，用户可以控制操作顺序。此外，许多操作可以通过多种方式完成（例如，通过菜单[文件/关闭]、快捷键[ALT-F4]或鼠标[单击关闭图标]关闭窗口）。项目（例如，文件名）的多种表示形式通常也意味着多个执行路径。这种情况的一个体现是当应用程序基于名称的非规范表示形式做出错误决策时，会发生安全问题。³ 这些爆炸性的组合使得测试人员几乎不可能构思并测试所有组合的合理抽样。

并发性在许多层面上变得越来越普遍。除了多进程之外，我们还看到越来越低级别的并发性，特别是由于多核芯片组鼓励通过线程和超线程实现并行性；很快，每个人都将拥有一台双处理器机器。机器集群和Web服务正在增加跨应用程序的并发性。

所有这一切都为引入更隐蔽的错误创造了更大的可能性，同时也使这些错误更难检测。

误解代码覆盖率和随机测试

在讨论解决这些问题的可能方法之前，让我们澄清一些普遍存在的误解。

误解：代码覆盖率意味着质量。 用于测量结构代码覆盖率的工具变得越来越易于使用和部署，因此理所当然地在测试武器库中获得了更大的认可。许多组织（尤其是通过数字进行衡量的管理层）犯下的一个根本性错误是，假定低代码覆盖率指标表明测试效果不佳，或者由于良好的测试集具有高覆盖率，因此高覆盖率意味着良好的测试（请参阅“逻辑谬误”侧边栏）。代码覆盖率仅仅衡量语句、块或分支是否已被执行。它不能衡量被执行的代码是否行为正确。随着代码变得太大而无法轻松汇总定性评估，人们开始总结代码覆盖率而不是测试信息。因此，我们知道低代码覆盖率是不好的，因为如果我们从未执行过代码，那么似乎不可能说我们已经“测试”过它。然而，虽然拥有仅执行代码的东西可能会因此揭示一些可能的缺陷（例如，完整的系统故障），但这并没有真正表明代码是否已经达到了大多数人认为的测试标准。

“已测试”表示您已经以有用的方式验证了代码执行的结果。随着下一代自动单元测试工具（稍后讨论）的出现，高代码覆盖率的谬误将变得更加明显，这些工具可以在不进行结果检查的情况下生成高代码覆盖率。此外，将代码覆盖率和缺陷密度（每千行代码的缺陷数）进行比较的实际软件结果表明，仅使用覆盖率指标作为缺陷密度（软件质量/可靠性）的预测指标是不准确的。

逻辑谬误

否定前件
如果 A，则 B；非 A；因此，非 B
如果低覆盖率，则测试效果不佳；非低覆盖率；因此，测试效果不差
肯定后件
如果 p，则 q；q；因此，p
如果良好的测试，则高覆盖率；高覆盖率；因此，良好的测试

误解：随机测试是不好的。 测试中的一大争论是分区（通常是手工的）测试设计与基于操作配置文件的随机测试（一种随机测试方法）。尽管如今许多组织仍然将测试（例如选择分区）作为一种技术（手动或半自动）来执行，但尚不清楚这是否是最有效的方法，尤其是在软件复杂性日益增加的情况下。目前的证据表明，除非您对故障可能性增加的区域有可靠的了解，否则随机测试可以做得和手工测试一样好。^4,5

例如，最近一项关于故障注入的学术研究表明，在某些情况下，应用于函数参数的全对偶测试技术（请参阅本文后面的“使用全对偶选择配置交互”）在检测故障方面并不比随机测试更好。⁶

进行随机测试的真正困难（就像覆盖率问题一样）是验证结果。对于随机输入，我们如何判断输出？拥有具有预先计算输出的静态测试更容易。在测试中，能够验证输出被称为测试预言问题。^7,8 目前有许多领域正在研究这个问题。

另一个问题是，随机测试很可能会忽略非常低概率的子域，但如果这些子域中故障的代价非常高，则它们可能会产生很大的影响。这是随机测试的一个主要缺陷，也是将其用作补充策略而不是唯一测试策略的一个很好的理由。

测试学科的一部分是了解我们在哪里对故障可能性增加有可靠的了解。经典的边界值分析技术之所以成功，是因为差一错误增加了边界处的故障可能性。许多其他分析技术没有经过充分验证的潜在故障模型来可靠地指示故障可能性增加。例如，基于代码覆盖率的分区并不能保证找到故障，因为必须使用正确的输入来激发故障，并且必须进行充分的验证才能意识到故障已经产生了失败。

测试问题：重新开始

很明显，增加结构代码覆盖率并不能解决测试问题，并且随机测试通常与手工测试用例一样好或更好。鉴于这种情况，我们如何解决“规模过大，难以测试”的问题？有几种方法需要考虑：单元测试、设计、静态检查和并发测试。

良好的单元测试（包括良好的输入选择）。 在集成之前获得高质量的单元是使大型系统测试易于处理的首要关键。做到这一点的简单方法是遵循几十年来的建议，从良好的单元测试开始。《IEEE软件单元测试标准》已经存在多年 [Std. 1008-1987]，要求 100% 的语句覆盖率。这已经通过测试驱动开发运动得到了很好的复兴，该运动还提倡以前很少有人遵守的在编写代码之前编写测试的想法。当底层组件和单元质量低下时，测试大型系统尤其困难。

为什么良好的单元测试不普遍？在许多地方，问题部分是文化上的。软件开发人员假定除了他们之外，还有其他人负责测试。一些开发团队在构建存根组件和测试工具方面花费了比构建实际组件更多的精力。现在，许多环境都存在标准单元测试工具，并且模拟对象的创建正在变得半自动化。单元测试效果不佳的另一个原因是，软件曾经更简单，可靠性期望更低。在当今世界，因简单问题（例如，缓冲区溢出）而引起的不安全系统，良好的单元测试本可以捕获这些问题，这确实促使管理层推动更好的单元测试。

这个领域存在各种工具。单元测试框架包括 XUnit 工具系列、集成测试框架 (Ward Cunningham’s Fit)、Team Share 等。此外，IDE（集成开发环境），如 Eclipse 和 Rational，可以生成单元测试大纲。任何开发部门都应该能够找到并使用适用的工具。

一般来说，今天的单元测试要求开发人员通过定义输入和预期输出来手工制作每个测试用例。未来，更智能的工具将能够创建良好的输入覆盖率测试用例和一些预期输出。我们可能会看到 100% 的代码覆盖率，而没有结果检查。我们需要更加关注结果检查的彻底性，而不仅仅是代码覆盖率。如何衡量结果检查的彻底性尚未真正解决。

当前的自动单元生成测试技术从简单的已知故障模式（例如空参数作为输入）到对使用的数据结构的分析。数据结构生成可以基于约束求解器、模型和符号执行。

其他工具可以增强现有的一组测试。例如，Eclat 从测试套件创建一个近似的测试预言，然后使用该预言来帮助生成可能揭示错误或暴露新行为的测试输入，同时忽略那些无效输入或执行已测试功能的输入。

即使没有工具，仅对人们进行简单的功能测试技术培训也可以帮助他们为单元测试选择更好的输入。您也可以从要测试的事项的通用清单开始，然后通过记录您组织的历史记录来使它们成为您自己的清单，了解什么会产生有趣的输入。您可以在几本书中找到行业清单，名称各异，例如：“常见软件错误”（Kaner, C., Falk, J. 和 Nguyen, H.Q. 1993. 测试计算机软件。Van Nostrand Reinhold）；“测试目录”（Marick, B. 1994. 软件测试工艺。Prentice Hall PTR。www.testing.com/writings/short-catalog.pdf）；或“攻击”（Whittaker, J.A. 2002. 如何破坏软件：实用测试指南。Addison Wesley）；以及在 Web 上（例如，http://blogs.msdn.com/jledgard/archive/2003/11/03/53722.aspx）。

良好的设计（包括依赖性分析）。 许多书籍和论文解释了如何进行良好的前期设计（最好的类型），但如果您已经有了代码怎么办？

依赖性分析可用于重构代码（重写以提高代码可读性或结构；请参阅 http://www.refactoring.com/）。许多 IDE 正在集成使代码重构更容易的功能。敏捷方法提倡的良好单元测试提供了更多信心，即重构没有破坏或回归系统。

依赖性分析允许测试人员仅选择那些针对更改的测试用例。通过查看结构代码依赖性可以进行简单的分析，并且它可能非常有效。更复杂的数据流分析允许更准确的依赖性确定，但成本更高。这两种技术都可以比一直运行所有内容有很大的改进。这的测试设计含义是创建相对较小的测试用例，以减少无关的测试或将大型测试分解为小测试。⁹

良好的静态检查（包括模型属性检查）。 静态分析工具与形式化方法的融合现在为确保高质量的单元以及在某种程度上它们的集成提供了强大的工具。例如，PREfix 是一种用于 C/C++ 的模拟工具，它沿着一组选定的程序路径模拟程序执行状态，并查询执行状态以识别编程错误。¹⁰ 对于大多数静态检查，造成最大抵制采用的问题仍然是误报率。有些工具只能做出可靠的猜测，有时会猜错。如果开发人员无法在他们知道工具出错的地方关闭工具，他们会感到沮丧。有时开发人员会得意忘形并关闭太多，然后错过工具本可以捕获的问题。有些开发人员甚至在发现问题时也不相信这些问题真的是错误。

许多更高级的检查需要额外的注释来描述意图。您可以使用编译器或语言构造（如 assert()）在任何语言中模拟一些更严格的检查。说服许多开发人员相信额外的注释将为更高质量、更健壮和更易于维护的代码带来回报仍然是一个挑战。然而，其他使用过它并看到本需要数小时、数天或数周才能调试出来的棘手问题被轻松地提前发现的人，永远不会回头。

所有这些数据也可以帮助以后的独立测试人员，因为通过静态分析发现的缺陷是预发布系统缺陷密度的早期指标。静态分析缺陷密度可用于区分高质量和低质量的组件（易出错和不易出错的组件）。

并发测试。 可以静态（形式化方法属性，如活性、活锁/死锁等）和动态（自动竞争锁集跟踪）检测并发问题。静态检测通常需要使用附加信息对源代码进行大量注释，以便对代码进行必要的推理。静态分析的优点是它有可能揭示所有竞争条件。

动态竞争检测器（如代码覆盖率工具）需要一组良好的测试用例作为输入，因为它们只查看测试强制发生的事情。然而，即使测试本身没有强制发生，它们也可以确定竞争条件。只要测试执行重叠锁的代码，就可能检测到它。已经创建了几个工具，例如 Java PathExplorer (JPAX)，它们扩展了 Eraser 锁集算法。¹¹ 除了在没有完整测试用例的情况下无法保证完整性之外，动态竞争检测器仍在解决的其他问题包括它们的性能和它们产生的误报数量。

更传统的并发测试方法包括控制线程调度程序（如果可能），以创建不寻常的时序。故障注入工具（如 Security Innovation 的 Holodeck）可用于创建人为延迟并增加竞争条件的可能性。作为最后的手段，只是在不同条件下同时运行大量活动在发现缺陷方面是富有成效的（尽管可能不如许多较新的方法有效）。

优先排序测试

上一节帮助在基本层面上使用代码单元和分析来奠定基础，但大多数测试组织都在处理集成整体的测试。测试人员必须在解决当今软件系统庞大规模的问题上发挥创造力。当规模太大而无法测试时，您必须有选择地测试您要测试的内容，并使用更强大的自动化（例如建模）来帮助您进行测试。当通过整个大型系统变得令人生畏时（这种情况很快就会发生！），故障注入工具再次派上用场，作为一种调整事物的方法。

使用代码覆盖率来帮助选择和优先排序测试。 在过去的二十年中，优先排序测试用例变得越来越实用。如果您知道每个测试用例的覆盖率，则可以优先排序测试，以便在最短的时间内运行测试以获得最高的覆盖率。这里的主要问题是获取覆盖率数据并保持其最新。并非所有工具都允许您合并来自不同构建的覆盖率数据，并且一直运行覆盖率会降低测试速度。计算最小化所需的时间也可能成为一种阻碍。

对于许多测试用例集合，运行提供与所有测试用例相同覆盖率的最小测试用例集通常会发现几乎所有运行所有测试用例都会发现的错误。

几家公司的工业经验似乎证实了这一点。例如，对于一个包含 20,929 个块的工业程序，仅通过函数调用覆盖率选择测试仅需要 10% 的测试，同时提供了 99.2% 的相同覆盖率。按块覆盖率减少意味着 34% 的测试提供了相同的块覆盖率和 99.99% 的相同分支（段）覆盖率。此外，没有发现任何现场报告的缺陷，这些缺陷本应被全套测试捕获，但被覆盖率减少的测试集遗漏了。

最棒的是，任何人都可以轻松地运行实验比较。首先运行提供与所有测试相同的覆盖率的最小测试集，然后运行剩余的测试，看看会发现多少额外的缺陷。

您还可以将其与依赖性分析相结合，首先仅针对已更改的代码。根据您的依赖性分析的复杂程度，您可能不必进行任何进一步的测试。

使用客户使用数据。 另一种很好的方法是基于实际客户使用情况来定位测试。客户根据他们对产品的使用情况来感知产品的可靠性。少数客户在极少数情况下使用的功能对客户满意度的影响小于几乎所有客户始终使用的核心功能。尽管开发团队总是可以对产品使用情况做出推测，但这会是一个有用的开始，但实际数据会改进定位。

理想情况下，您可以自动记录并让实际客户使用情况发送给您。这种方法存在几个问题，包括隐私、性能和安全性。这些问题都可以解决，但这并非易事。或者，您可能只有少数几个客户报告数据，您可能进行随机抽样，或者您可能退回到案例研究或可用性研究。您还可以与您的客户合作进行早期测试，通过 Beta 程序甚至更早的预发布披露。¹²

客户使用数据在可靠性测试中尤为重要，在可靠性测试中，操作配置文件提高了可靠性数据的意义。客户使用数据对于优先排序您测试的配置也至关重要。设置类似于客户环境的环境有助于您找到您可能错过的交互。

使用全对偶选择配置交互。 使测试任务规模过大而难以测试的一个主要问题是担心所有可能的配置。配置涵盖诸如不同的硬件、不同的软件（操作系统、Web 浏览器、应用程序等）或软件版本、配置值（例如网络速度或内存量）等内容。如果您了解哪些配置交互会导致问题，则应明确测试它们。但是，当所有软件“应该”独立于配置时，并且经验表明并非如此时，您就会担心。设置配置进行测试通常很昂贵，并且运行全套测试通常也不便宜。

如果您正在进行性能测试，则需要与稳健测试相关的更正式的实验设计技术，并且需要正交数组。然而，对于简单的验证，许多测试部门使用的另一种简单、廉价的技术是全对偶。最常见的缺陷不需要任何交互。只需在任何配置下触发缺陷，大约 80% 的时间都会导致失败。在基本测试消除这些缺陷后，下一个最常见的缺陷原来只需要配置的两个方面的交互。哪两个方面？这就是诀窍！使用全对偶，您可以廉价地验证配置中的任何一对交互。公共领域工具存在（http://tejasconsulting.com/open-testware/feature/allpairs.html），下载该工具并创建配置问题的描述不到半小时。然后，您将得到一个非常快速的答案。

作为一个简单的例子，我咨询了一个测试组，该测试组测试了 100 种不同的配置，但仍然从现场收到错误。我向他们教授了这项技术和工具，在不到一个小时的时间里，他们就得到了一个结果，表明只需要 60 种配置就可以覆盖所有对偶交互，并且最近从现场报告的交互就是其中之一。也就是说，如果他们使用更少的配置进行测试，他们本可以在发货前找到该错误。

全对偶测试可能在其他领域也很有用，但研究尚无定论。

模型在随机测试中的应用

走向随机测试的一种方法是通过使用模型。您可以从最简单的模型开始，例如“笨猴子”测试工具或“模糊”测试器。您可以将它们增强为“智能猴子”工具，并使用各种建模语言（例如有限状态机、UML2（统一建模语言，版本 2）和抽象状态机）将它们形式化。过去测试人员不愿接受形式化方法，主要是因为状态爆炸问题，该问题似乎将大多数形式化方法降级为“玩具”问题，而不是许多测试人员必须处理的大型系统级问题。

许多领域的最新进展有所帮助，但尤其是最近的突破，使 SAT（命题可满足性）求解器变得非常高效，并且能够处理超过 100 万个变量和操作。模型可用于生成有限大小数据结构的所有相关变体。^13,14 您还可以使用随机模型，该模型定义目标系统如何受到其环境的刺激。¹⁵ 这种随机测试采用与分区测试和简单随机测试不同的采样方法。

即使是非自动化模型也可以为测试设计提供有用的见解。简单的有限状态机模型可以显示设计人员未曾考虑或预料到的状态。它们还有助于澄清测试人员的预期行为。您几乎可以使用任何语言构建自己的有限状态机。C# 的一个简单示例是 goldilocks。¹⁶

基于模型的测试的主要问题是改变测试人员的思维模式。许多测试人员没有接受过抽象思考他们正在测试的内容的培训，而建模需要能够抽象出一些细节，同时专注于特定方面。对于不习惯系统地处理问题的临时测试人员来说，建模可能尤其困难。建模失败的另一个原因是人们期望它解决他们所有的问题。通常，最好只添加一些手动设计的测试用例，而不是扩展模型以涵盖所有情况的所有细节。

测试中的经济性

当今软件的规模和复杂性要求测试人员在测试方法上具有经济性。测试人员需要很好地理解其技术的故障模型以及何时以及如何在应用它们，以使其优于随机测试。代码覆盖率应用于提高选择和优先排序测试的效率，但不一定用于判断测试。关于客户使用情况的数据对于在资源受限的情况下选择测试和配置也至关重要。成对测试可用于控制测试不同配置的增长。

尝试对低质量组件的集成进行黑盒测试（传统的“大爆炸”技术）一直无效，但大型系统使其呈指数级恶化。测试组必须要求产品开发人员必须接受彻底的单元测试，最好是在编写代码之前进行测试（测试驱动开发）。必须控制单元之间的依赖关系，以使集成质量真正可行。

参考文献

Kaner, C. 2000. 测试自动化的架构。 http://www.kaner.com/testarch.html。
Hoffman, D. 时间太少，案例太多。 www.cs.bsu.edu/homepages/dmz/cs639/So%20little%20time,%20so%20many%20cases.ppt。
Howard, M. 和 LeBlanc, D. 2002. 编写安全代码，第 2 版。Microsoft Press。
Nair, V. N., et al. 1998. 一些软件测试策略的统计评估和实验设计技术的应用。Statistica Sinica 8: 165-184。
Ntafos, S. C. 2001. 关于随机、分区和比例分区测试的比较。IEEE Transactions on Software Engineering 27(10)。
Bach, J. 和 Schroeder, P. 2004. 成对测试：一种并非最佳实践的最佳实践。第 22 届太平洋西北软件质量年会，俄勒冈州波特兰市。 http://www.pnsqc.org/proceedings/pnsqc2004.pdf。
Hoffman, D. 1999. 启发式测试预言。软件测试与质量工程（三月/四月）。 http://softwarequalitymethods.com/SQM/Papers/HeuristicPaper.pdf。
Hoffman, D. 1998. 测试预言的分类法。Quality Week ’98。 http://softwarequalitymethods.com/SQM/Slides/ATaxonomyslide.pdf。
Saff, D. 和 Ernst, M. 2004. 用于测试分解的自动模拟对象创建。 SIGPLAN/SIGSOFT 软件工具和工程程序分析研讨会 (PASTE’04)，华盛顿特区（6 月 7-8 日）：49-51。
Larus, J., et al. 2004. 修正软件。IEEE Software 21(3): 92-100。
Savage, S., Burrows, M., Nelson, G., Sobalvarro, P. 和 Anderson, T. 1997. Eraser：多线程程序的动态数据竞争检测器。 Transactions on Computer Systems 15(4): 391-411。
Tate, A. 2003. 最好的测试人员是免费的。软件测试分析与回顾 (STAR West)。
Marinov, D. 和 Khurshid, S. 2001. TestEra：用于 Java 程序自动化测试的新颖框架。第 16 届 IEEE 自动化软件工程会议论文集（十一月）：22-31。
Ball, T., et al. 2000. 状态生成和自动类测试。Software Testing, Verification and Reliability 10(3): 149-170。
Whittaker, J. A. 1997. 随机软件测试。Annals of Software Engineering 4: 115-131。 http://www.geocities.com/harry_robinson_testing/whittaker97.doc。
Robinson, H. 和 Corning, M. C# 调中的基于模型的测试。 http://www.qasig.org/presentations/QASIG_Goldilocks2.pdf。

KEITH STOBIE 是微软 XML Web 服务组 (Indigo) 的测试架构师，他在该组指导和教授质量保证 (QA) 以及测试流程和策略。他还计划、设计和审查软件架构和测试。Stobie 拥有 20 年的分布式系统测试经验，他的兴趣在于测试方法论、工具技术和质量流程。他还积极参与 Web 服务互操作性组织 (WS-I.org) 的测试工作组，为分析和符合 WS-I 规范创建测试工具。他拥有康奈尔大学计算机科学学士学位。

最初发表于 Queue 杂志第 3 卷，第 1 期—
在数字图书馆中评论本文

更多相关文章

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

Robert Guo - MongoDB 的 JavaScript Fuzzer
随着时间的推移，MongoDB 变得功能更丰富、更复杂，开发更复杂的方法来查找错误的需求也随之增长。三年前，MongDB 在其工具包中添加了一个自研的 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 的效率和有效性，提供了管理人员最感兴趣的数据。

Terry Coatta, Michael Donat, Jafar Husain - EA 的自动化 QA 测试：事件驱动
对于数百万游戏爱好者来说，Electronic Arts 的质量保证 (QA) 测试员职位一定看起来像一份梦寐以求的工作。但从公司的角度来看，与 QA 相关的开销可能看起来非常可怕，尤其是在大型多人游戏时代。