PDF微软的协议文档计划：大规模互操作性测试
与Nico Kicillof、Wolfgang Grieskamp和Bob Binder的讨论
2002年，微软开始了验证其Windows通信协议的大部分技术文档的艰难过程。这项工作是微软与美国司法部和几个州检察长达成的同意法令的结果，该法令要求公司向第三方许可方提供某些客户端-服务器通信协议。随后，为相关的Windows客户端-服务器和服务器-服务器通信协议编写了一系列类似RFC的技术文档，但为了确保互操作性，微软需要验证这些文档的准确性和完整性。从一开始，就很明显这不会是一个典型的QA（质量保证）项目。首先，需要一个团队来测试文档，而不是软件，这与正常的QA流程是相反的；而且所涉及的文档非常广泛，包含超过250份文档，总计30,000页。此外，合规期限也很紧迫。为了取得成功，微软团队必须找到高效的测试方法，确定适当的技术，并在很短的时间内培训一支测试人员队伍。
本案例研究考虑了该团队如何找到应对这一巨大测试挑战的方法。更具体地说，它侧重于使用的一种测试方法——基于模型的测试——以及在为大型项目采用该方法时出现的主要挑战。来自微软团队的两名首席工程师和一位在审查微软工作方面发挥作用的工程师讲述了这个故事。
Wolfgang Grieskamp当时在微软的Windows服务器和云互操作性小组（Winterop）工作，该小组负责测试微软的协议文档，更广泛地说，负责确保微软的平台与微软以外的世界的软件具有互操作性。此前，Grieskamp是微软研究院的研究员，在那里他参与了开发基于模型的测试能力的工作。
Nico Kicillof曾在微软研究院与Grieskamp一起开发名为Spec Explorer的基于模型的测试工具，他继续作为Winterop小组的一员指导测试工作。
Bob Binder是通信协议测试相关事务的专家。他也参与了微软的测试项目，担任测试方法顾问，并审查了中国和印度的测试团队执行的工作。
在本案例研究中，Binder与Kicillof和Grieskamp讨论了他们在大规模测试工作中面临的一些关键挑战。
BOB BINDER 当您首次参与Winterop团队[负责推动Windows通信协议的创建、发布和QA的团队]时，主要挑战有哪些？
NICO KICILLOF 最大的挑战是我们面临的是测试协议文档，而不是协议软件。我们之前在测试软件方面有专业知识，但这个项目要求我们定义一些新的流程，我们可以用这些流程来测试超过30,000页的文档，并对照已向全球发布的现有软件实现进行测试，甚至在某些情况下，原始开发人员已不在微软工作。这意味着软件本身将成为我们衡量文档的黄金标准，而不是反过来。这代表了视角上的巨大转变。
WOLFGANG GRIESKAMP 需要的是一种新的测试方法。更重要的是，我们需要在相对较短的时间内将这种新方法应用于非常大量的文档。当您将所有这些放在一起时，这构成了一个非常大的挑战。我的意思是，提出新的东西是一回事。但是，随后立即面临将其应用于关键任务问题，并尽快让很多人掌握它——这真是了不起。
BB 这些文档包含什么内容，它们的目的是传达什么？
WG 它们实际上类似于用于描述互联网协议标准的RFC（征求意见稿），并且它们包括对协议通过线路发送的数据消息的描述。它们还包含对每当发送数据时应该出现的协议行为的描述——也就是说，应该如何更新一些内部数据状态以及预期发生的顺序。为此，这些文档遵循相当严格的模板，也就是说，它们具有非常规则的结构。
BB 您的测试方法与通常用于验证规范的技术相比如何？
WG 当涉及到测试这些文档之一时，您最终会测试文档中包含的每个规范性陈述。这意味着确保每个可测试的规范性陈述都符合该协议的现有微软实现实际执行的操作。因此，如果文档说服务器应该执行X，但是您发现实际的服务器实现执行Y，那么显然存在问题。
在我们的例子中，在大多数情况下，这意味着我们的文档存在问题，因为实现——无论对错——都已经在外地使用了一段时间。这与通常采用的方法完全不同，在通常的方法中，您会在部署软件之前根据规范测试软件。
BB 一般来说，协议指的是数据格式化标准以及关于如何对遵循这些格式的消息进行排序的一些规则，但我认为我们在这里讨论的协议不仅仅如此。在这种背景下，您能更详细地解释一下这里涉及的协议吗？
WG 我们讨论的是适用于通过网络连接发送的流量的网络通信协议。除了数据包本身之外，这些协议还包括许多管理客户端和服务器之间交互的规则——例如，当客户端发送错误消息时，服务器应如何响应。
我们项目面临的挑战之一是确保Windows服务器执行的功能也可以由其他服务器执行。假设您有一个基于Windows的服务器正在共享文件，而一个基于Windows的客户端正在访问这些文件。这都是微软的基础设施，所以它们应该能够彼此通信而没有任何问题。很久以前就进行了测试以确保这一点。但是现在假设提供共享的服务器正在运行Unix，并且Windows客户端在同一配置中运行。您仍然应该能够以与Windows文件服务器相同的可靠性和质量访问Unix文件服务器上的共享。但是，为了实现这一点，基于Unix的服务器需要遵循与基于Windows的服务器相同的协议。这就是挑战往往变得更有趣的地方。
NK 这为说明我们必须在什么条件下进行测试设定了背景。特别是，如果您考虑到Windows服务器最终可能会被Unix服务器取代这一事实，您必须从黑盒测试的角度来考虑。我们不能仅仅假设我们知道服务器是如何实现的，或者它的代码是什么样的。实际上，作为我们检查互操作性工作的一部分，许多相同的测试已经针对非微软的实现运行过。
WG 除了在内部运行这些测试以确保Windows服务器实际上按照我们的文档所说的应该做的那样运行之外，我们还将这些相同的测试提供给PlugFest，在那里邀请已经实现了可比服务器的被许可人针对他们的服务器运行这些测试。那里的目标是实现互操作性，而实现这一目标的最基本方法是在客户端上启动测试，该客户端基本上可以针对网络中的任何任意服务器运行，无论是Windows服务器、Unix服务器还是其他服务器。
BB 您测试的许多协议都使用了Microsoft远程过程调用堆栈——除了SOAP和TCP/IP等标准协议。在处理这些不同的底层堆栈的过程中，您遇到了哪些类型的挑战？
WG 首先，我们将数据或多或少直接放在线路上，这样我们就可以绕过其中一些层。例如，Windows堆栈中的某些层允许您通过TCP发送数据而无需建立直接TCP连接，但我们选择不使用它。相反，我们直接与TCP套接字对话以发送和接收消息。
这使我们能够绕过堆栈问题的一部分。另一个问题是，一些协议通过其他协议传输——就像TCP例如通常通过IP传输一样，而IP又通过以太网传输。因此，我们为解决这个问题所做的是在我们的测试方法中假设一定的组件化。这使我们能够在我们关心的抽象级别上测试协议——假设堆栈中的底层传输层运行良好。如果我们无法做出这个假设，我们的任务将几乎不可能完成。
由于项目的独特限制，协议文档团队需要找到一种最适合他们问题的测试方法。早期的工作重点是从系统之间的真实交互中收集数据，然后过滤这些信息，以将被测系统的行为与协议文档中描述的行为进行比较。这种方法的问题在于，这有点像大海捞针。必须收集和筛选天文数字般的数据，才能获得足够的信息来彻底涵盖文档中描述的所有可能的协议状态和行为——请记住，这种艰巨的过程随后必须为总共超过250个协议重复进行。
最终，该团队在与负责监督其工作的美国技术委员会协商后，开始考虑基于模型的测试。与传统的测试形式相比，基于模型的测试涉及从被测系统的精确模型生成自动化测试。在这种情况下，被测系统将不是整个软件系统，而仅仅是文档中描述的协议，这意味着团队可以专注于建模协议的状态和行为，然后将后续测试定位在堆栈中感兴趣的级别以进行测试。
微软研究院的一个团队自2002年以来一直在试验基于模型的测试，并已成功地将其应用于各种测试情况，尽管规模要小得多——包括微软Web服务实现的协议测试。在这些初步工作中，微软研究院的团队已经设法解决了其中一些最棘手的问题，例如处理非确定性。他们还设法创建了一个名为Spec Explorer的测试工具，该工具将被证明对Winterop团队非常宝贵。
BB 请稍微谈谈您是如何最终确定基于模型的测试作为合适的测试方法的。
WG 从一开始就审视这个问题，很明显这将是一件需要大量时间和资源的大事。我们面临的挑战是找到一种智能技术，可以帮助我们获得高质量的结果，同时还可以优化我们对资源的使用。包括技术委员会中的一些人在内的许多人都建议基于模型的测试作为我们应该考虑的有前途的技术。所有这些都发生在Nico和我加入团队之前。
然后，团队四处寻找基于模型测试方面的专家，结果发现我们在微软研究院已经有了一些专家。这引发了一些关于基于模型测试已被采用的几个测试案例的讨论，以及该技术可能为该特定项目带来的潜力。其中一个测试案例与SMB（服务器消息块）文件共享协议有关。结果令人印象深刻，足以让人们认为也许我们真的应该推进基于模型的测试。那时，我们这些具有基于模型测试经验的人最终从微软研究院被调来协助验证工作。
NK 我们在微软研究院采取的基于模型的测试的具体方法被证明非常适合这个问题。使用我们创建的工具Spec Explorer，您可以生成软件模型，该模型指定了一组规则，这些规则详细说明了软件预期如何运行，以及状态应如何因软件与其环境之间的每次潜在交互而改变。在此基础上，然后可以生成测试用例，其中包括的不仅是预先编写的测试序列，还包括oracle，它是所有可能从采取的每个步骤中产生的预期结果的目录。
这样，就可以创建测试，让您可以在整个序列中进行检查，以确保系统以您期望的方式做出响应。这与通信协议文档的编写方式完全匹配，因为它们旨在被解释为管理您应该期望接收哪些消息以及应该发送哪些响应消息的规则。
BB 这意味着许多有趣的事情。很容易说，“我们有一个模型和一些支持自动化模型探索的功能。”但是您最初是如何获得该模型的？将每份协议文档中相当密集的散文翻译成模型的过程是什么？
WG 基于模型的测试的第一步是从所有这些文档中提取规范性陈述。这必须手动完成，因为我们尚无法自动化——并且在我们能够自动化之前，计算机需要能够阅读和理解自然人类语言。
下一步是将所有这些规范性陈述转换为“需求规范”，这是一个大表，其中每个规范性陈述都已编号，并且已描述了其所有属性。之后，又进行了另一步手动步骤，创建了一个模型，试图执行然后捕获所有这些需求。这需要一些更高级别的测量方法，以便您可以确保您实际上已经考虑了所有需求。对于您的平均协议，我们这里谈论的是大约数百个不同的需求。在某些情况下，您甚至可能有数千个需求，因此这是一个相当大规模的工作。
但总的想法是从文档到需求，然后从那里到模型或传统测试设计——无论哪一个与您的总体方法一致。
由于微软选择为该项目采用基于模型的测试，因此遇到了挑战。一方面，微软研究院开发的技术和方法似乎与测试协议文档的问题完美契合。另一方面，这是一项不成熟的技术，学习曲线陡峭。尽管如此，在技术委员会的支持下，该团队决定推进一项计划，将微软研究院的技术快速发展为适用于生产测试环境的技术。
不出所料，这并不容易。除了在任何时间紧迫的软件工程项目中都可能出现的常见挫折之外，微软协议文档团队还面临着在中国和印度培训数百名测试开发人员学习新的、不熟悉的测试方法的基础知识的挑战。
即使在他们拥有一批训练有素的测试人员之后，仍然存在许多障碍。在工具工程团队面临着以惊人的速度稳定和基本产品化Spec Explorer软件的压力时，测试团队不得不开始艰难地处理数百份文档，提取规范性陈述，构建需求规范，并构建模型以生成自动化测试套件。尽管Spec Explorer提供了一种自动化测试的方法，但该过程中仍然有几个重要步骤需要人工判断。这些领域最终给团队带来了一些最大的挑战。
BB 您是如何让自己相信您可以招募数百名在该领域几乎没有经验的测试开发人员，并教他们一种相当深奥的技术，将文字翻译成规则系统？
WG 就采用基于模型的测试方法而言，这确实是核心风险。直到最近，基于模型的测试技术一直被认为是只有专家才能应用的东西，尽管多年来它已在微软内部以多种不同的方式应用。
关于基于模型的测试的许多担忧都与所涉及的学习曲线有关，这确实非常陡峭，但并非特别高。也就是说，这是一种不同的范例，需要真正的思维转变，但它并非真的那么复杂。因此，并非只有拥有高级学位的工程师才能访问它——每个人都可以做到。但是，当您第一次面对它时，事情看起来确实有点不寻常。
BB 为什么会这样？人们必须适应的那些关键差异是什么？
NK 基本区别在于模型实际上由规则系统组成。因此，我们构建的模型由规则组成，这些规则表明在某些特定的使能条件下，应该对状态执行一些相应的更新。
但是，从开发人员的角度来看，程序永远不只是一组规则。他们创建并完全控制控制流。程序员将确切地知道首先要执行什么，然后根据收到的输入应该遵循什么。
在我们这种情况下，幸运的是，我们正在使用协议规范，这些规范本身就是一组规则，让您知道，例如，如果您收到了消息A，那么您应该以某种方式更新您的抽象数据模型和您的内部状态，之后您应该发出消息B。它没有解释协议从那时起如何流动。所有这些规则的组合决定了协议的实际行为。因此，每份技术文档中的某些陈述与我们必须构建的模型类型之间通常存在直接的对应关系。这使得构建模型以及检查以确保它们已根据文档中找到的陈述正确构建变得非常容易。
WG 因为这实际上并没有那么复杂，所以我们最大的担忧与让人习惯于新的思维方式有关。因此，为了让测试人员克服最初的挑战，我们非常依赖于建立良好的培训计划。最初，这涉及聘请人员为我们在中国和印度的供应商雇用的每位新人提供培训，以执行我们的测试。该培训不仅涵盖了我们基于模型的测试方法，还涵盖了整体方法的其他方面。
BB 对于以前从未接触过基于模型的测试的中等能力开发人员来说，需要多长时间才能达到他们实际上可以非常高效的程度？
NK 平均而言，我想说这需要将近一个月的时间。
BB 一旦您的测试人员接受了培训，您的测试方法是如何演变的？您在沿途遇到任何重大问题吗？
WG 事实证明这是一个相当平稳的过渡，因为我们只是在使用我们在微软研究院已经开发的原型中的概念。话虽如此，当这个团队接手时，它实际上只是一个原型，所以我们面临的主要挑战是稳定这项技术。您知道原型是什么样的——它们会崩溃，您最终不得不进行变通方法等等。在过去的三年中，我们有一个开发团队致力于改进该工具，并且已经进行了数千次修复。
另一个潜在问题与基于模型的测试中经常出现的问题有关：状态爆炸问题。每当您建模时——如果您天真地定义一些规则，以便在满足某些条件时更新您的状态，然后您只是让它运行——您很可能会最终被所有这些状态更新淹没。例如，当使用此工具时，如果您要求探索，那应该导致可以检查的探索图的可视化。但是，如果您不小心，您可能会最终得到系统将尝试为您探索的成千上万个状态。您根本无法可视化所有这些状态。
此外，为了了解实际发生了什么，您需要有一种方法来修剪潜在的状态空间，以便您可以切出您知道您需要测试的那些区域。这就是我们最大的挑战之一：找到正确的模型切片方法。
这里的想法是为任何给定问题找到正确的切片方法，该工具为实现这一目标提供了很多帮助。对于我们来说，找到正确的空间切片方法最终会成为一个问题并不奇怪——我们已经预料到了这一点。实际上，我们已经向该工具添加了一些东西来处理这个问题，这可能也是该项目被证明是成功的原因之一。
NK 秘诀是将测试目的用作切片的标准。
BB 只有您在某些特定用例中会看到的全部行为的子集？
WG 对。所以这就是为什么必须明确，无论何时您进行一些切片，您都会切掉系统的一些潜力，这意味着您可能会丢失一些测试覆盖率。这就是为什么这最终变得如此具有挑战性的原因。但是，正如Nico所说，由于切片也与您的测试目的紧密结合，因此您仍然应该能够覆盖文档中的所有需求。
NK 是的，与测试目的的耦合是关键，因为如果切片仅根据您的用例完成，则可能只会测试系统最常用的使用模式。但这里的情况并非如此。
此外，在整个工具链中，我们提供了从规范中提取的陈述与测试日志中记录的步骤之间的完整可追溯性。我们有工具可以告诉您，您决定的模型切片方式是否遗漏了您打算测试的任何需求。然后在最后，您会收到一份报告，告诉您您的切片是否被证明是过度或充分的。
总而言之，测试项目在帮助确保微软的协议文档具有足够高的质量以满足公司与Windows客户端和Windows服务器通信相关的监管义务方面非常成功。但是这项工作并没有止步于此，因为相同的方法已用于测试Office、SharePoint Server、SQL Server和Exchange Server的协议文档。
这项旨在为与微软的大批量产品实现互操作性的工作非常适合于产品化的基于模型的测试技术，以支持法院命令的协议文档计划。由于项目可以通过将工作划分为没有交叉依赖性的明确定义的单元来扩展，因此测试项目的大小仅受可用测试人员数量的限制。由于这种可扩展性，项目也可以高效地完成，这对于该技术在微软内部以及外部的持续使用来说是个好兆头。更重要的是，微软的协议文档测试工作似乎对公司的整体世界观和工程文化产生了深远的影响。
BB 在微软内部，您是否看到您正在做的工作有更广泛的作用？还是它几乎只是以遵守法院法令开始和结束？
NK 它超越了法令。提高我们产品的互操作性本身就是一个有价值的目标。我们显然处于一个异构技术的世界中，客户期望产品能够互操作。
这也正在改变产品的开发方式。实际上，我们的目标之一是改进微软内部创建协议的方式。这涉及我们设计协议的方式、我们记录协议的方式，以便第三方可以使用它们与我们的产品对话，以及我们检查以确保我们的文档正确的方式。
WG 其中一个方面与认识到需要更系统的方法来进行协议开发有关。首先，我们目前在质量保证上花费了大量资金，而我们过去在产品发货后才创建产品文档在很大程度上与此有关。因此，就在那里，我们有机会节省大量资金。
规范或模型驱动的开发是优化所有这些的一种可能方法，我们已经在研究这一点。其想法是，从开发过程的每个工件中，您可以派生出根据定义是正确的文档、代码存根和可测试的规范。这样，我们就不会最终得到所有这些独立创建的工件，然后必须在事后将它们拼凑在一起以进行测试。
特别是对于基于模型的测试，我认为这个项目是使用该技术可以实现的效率和经济性的有力证明。这是因为这是迄今为止在工业环境中进行的最大规模的尝试，在同一项目中，传统测试方法和基于模型的测试方法都得到了使用。这为两种方法的并排比较创造了难得的机会。
我们一直在仔细衡量各种指标，因此我们现在可以凭经验证明，我们如何通过使用基于模型的测试基本上将效率提高了一倍。实际记录这种能力非常重要。
BB 是的，这太棒了。
WG 基于模型的测试社区中有人预测效率会提高十倍。如果您的所有用户都拥有博士学位或非常擅长基于模型的测试，那么这实际上是可能的。但我认为我们已经能够证明，对于由没有基于模型测试背景的普通人组成的用户群体，效率有了显着——尽管不如戏剧性——的提高。此外，我们的数字还包括我们为使测试人员尽快上手而必须投入的所有启动和教育时间。
无论如何，在考虑了所有这些以及进行文档研究和完成各种其他事情所花费的时间之后，我们能够证明，在使用基于模型的测试方法时，工作量减少了42%。我认为这应该对微软的管理层以及微软以外的很多人都具有相当大的说服力。
问
进一步阅读
• Grieskamp, W., Kicillof, N., Stobie, K., Braberman, V. 2011. 协议文档的基于模型的质量保证：工具和方法。软件测试、验证、确认和可靠性杂志 21: 55-71 (3月).
• Grieskamp, W., Kicillof, N., MacDonald, D., Nandan, A., Stobie, K., Wurden, F., Zhang, D. 2008. SMB2协议文档的基于模型的质量保证。 第8届国际软件质量会议。
• Grieskamp, W., Kicillof, N., MacDonald, D., Stobie, K., Wurden, F., Nandan, A. 2008. Windows协议文档的基于模型的质量保证。 第1届国际软件测试、V & V会议。
• Stobie, K., Kicillof, N., Grieskamp, W. 2010. 用于端到端可追溯性测试的技术文档离散化。 第2届系统测试和验证生命周期进展国际会议 (最佳论文奖).
喜欢它，讨厌它？ 让我们知道
© 2011 1542-7730/11/0500 $10.00
最初发表于 Queue 杂志第 9 卷第 6 期—
在 数字图书馆 中评论这篇文章
更多相关文章
Jesse Robbins, Kripa Krishnan, John Allspaw, Thomas A. Limoncelli - 弹性工程：学习拥抱失败
在 2000 年代初期，亚马逊创建了 GameDay，这是一个旨在通过有目的地定期向关键系统注入重大故障来提高弹性的程序，目的是发现缺陷和细微的依赖关系。 基本上，GameDay 演练在为应对灾难性事件做准备的过程中，测试公司的系统、软件和人员。 GameDay 概念的广泛接受经历了几年时间，但现在许多公司看到了它的价值，并已开始采用自己的版本。 本文讨论了其中的一些经验。
© 版权所有。