开源云测框架Hydra Lab的智能化测试实战

在软件测试领域，“猴子测试”一直是一种广受欢迎的方法，但其也存在着动作随机的局限性。如果引入大模型，创造一只更聪明的猴子，它可以真正理解应用并像人类一样与之互动，将会怎样？

此前，微软内部团队打造并开源了下一代跨平台软件测试基础设施 Hydra Lab（ https://github.com/microsoft/hydralab），目前在微软内部由 Hydra Lab 支持的云测试系统服务与微软 Phone Link，Link to Windows，Teams，Outlook，Edge 等多个产品线。为创造一只更聪明的猴子，今年 Hydra Lab 接入了 LLM（Azure OpenAI Service），以提高在测试结果分析、探索性测试和测试用例生成方面的能力。

在今年 9 月 3-5 日举办的 QCon 全球软件开发大会·北京站 中，微软中国高级研发经理步绍鹏将分享 Hydra Lab 的技术思路，以及其对软件测试智能化的理解与实践经验。在大会开始前，InfoQ 对步绍鹏、微软测试平台后端技术专家周乐进行了专访。以下为对话实录，经编辑。

InfoQ：步老师在今年 9 月举办的 QCon 全球软件开发大会·北京站上的演讲主题是《利用大模型打造更聪明的猴子：下一代跨平台软件测试基础设施 Hydra Lab》，为什么会选择这一主题？

步绍鹏：Hydra Lab 是一个在微软内打磨了两年左右的项目，团队规模约为 10 人，随着项目不断发展，更多的小伙伴也参与了该项目，大家在一起踩了很多坑，也得到了领导层的各种支持，非常不容易，在此先对团队表示衷心感谢。眼下软件测试已经进入了自动化的时代，但仍存在大量的手工测试。近些年，随着 AI 技术的不断发展，我们可以看到软件测试从自动化向智能化进阶的可行性。有一次团队内部闲聊中，小伙伴们聊到强化学习在游戏领域的应用（当时 flappy bird 还很火），很有意思，我们顺势想到是否可以将这种像人一样玩游戏的感觉移植到软件测试中。通过将被测软件视为一个强化学习中“环境”的概念，如同玩游戏一样进行交互反馈，不断增强智能体的探索能力，最终实现智能探索。

在这个过程中，我们参考了很多相关的学术论文，也借助微软亚洲研究院和 DKI 团队同事的支持，发现学术研究界也有类似的想法和探索。同时，借鉴软件测试经典理论中提到的 Monkey Test 概念（即对被测应用输入一系列的随机输入，如同让猴子随机敲击键盘或者胡乱点击手机屏幕，然后观察软件在该情形下的表现），我们也进一步探索了 Smart Monkey 的实现，请更聪明的猴子去测试软件。其中，如何让“猴子”能“理解”被测应用，是一个关键问题。随着大语言模型技术在工业界的普及，利用该技术赋能这个“猴子”也是我们目前探索实践的重心。

总的来说，不同于一般的测试框架，Hydra Lab 旨在提供一套测试工程化解决方案，或者说是一套开源云测平台，我们希望它方便地能够与 DevOps 系统、编译系统或 GitHub 等开发工具或平台结合，给开发团队带来低成本的测试全流程方案。同时，我们将智能化引入其中，大家可以在这个项目中看到一些自动化生成测试用例的模块、方案以及 prompt。工程化和智能化是 Hydra Lab 的关键词，而工程化是智能化赋能的基础。此次分享中我也会围绕这两个问题展开一些案例探讨。

InfoQ：对于这波大模型结合软件开发应用热潮，您观察到哪些有趣的趋势？

步绍鹏：我最近做了很多分享，也参加了不少活动，发现大家在探讨大模型与各个领域的融合，比如各种 copilot 产品体验。目前，虽然大模型的能力令人激动，但还没有到达 AGI 对一切赋能的阶段，我们需要了解它的长处和短处，扬长避短的去应用，而且需要人的配合参与，所以我们更多在讲 copilot，而不是 autopilot。目前大模型在内容生成和信息摘要展现出了很好的前景，但如果打算解决一个容错度低、上下文庞大的问题，可能在关键技术产生突破之前，还没有成熟的方案。

这次的不同之处在于，创新的驱动力大量来源于工业界，而不仅只有学术界，可以从软件行业的一线开发工程师和实际产品实战中看到越来越多的创新。这与 AI 模型达到一定规模后产生的能力涌现，能够执行多目标任务和解决一些通用问题分不开关系。

周乐：从我自身的开发体验来看主要有两方面，首先是随着 GPT、BERT、DALL-E 等预训练模型的出现，开发人员可以很方便的调用 API 接口去使用这些模型的能力，应用于不同的领域。其次是代码生成和优化，例如 GitHub Copilot 可以根据代码上下文给出代码补全建议，GitHub Copilot Chat 甚至可以通过对话的方式帮忙定位问题、帮助修复 Bug。

Hydra Lab 的技术设计与构建思路

InfoQ：软件测试的自动化已经极大地改善了测试效率和质量，但随着软件系统越来越复杂，测试环境的多样性增加，传统的自动化测试面临不少挑战，具体主要体现在哪些方面？

步绍鹏：首先，我们的团队是一个全球协作的团队，我们的产品 Phone Link 也是一个跨平台互联的产品，这从“人”和“事”的层面都增加了我们在测试自动化合作推进的复杂性。我们希望自动化测试能真的全自动，减轻大家写测试维护测试的负担，同时可以真的发现问题。此外，我们也想把手机放到云上，建立云测试设备集群，全球共享。现在有 Hydra Lab，只要我们搭建好这个平台，并配置好相应的编组和权限，真机的地理位置就不再是一个障碍。各地团队可以突破物理的边界，在测试上更有效地合作。

其次，UI 自动化测试任务可能会出现一些不稳定的情况，比如突然找不到某个元素，或者出现一些意外遮挡情况。这种情况下的测试任务失败可能没有反映真实的质量问题。而有了 Hydra Lab 这样的平台级方案，我们可以对这类 flakiness 做识别，重新运行任务，从而提高稳定性。这同时也相当于我们把识别和处理测试不稳定因素的经验沉淀到了 Hydra Lab 开源工程中，一人贡献，全社区受益。

另外，从安全和隐私合规性方面考虑，开发团队如果使用外部第三方云测服务对持续集成系统构建的应用进行测试，由于这个阶段构建的应用一般包含大量的 Debug 信息，也可能涉及未公开的新特性甚至商业机密，上传给外部第三方多少有些顾虑，所以一个开源和可定制的系统在这种场景下非常有价值，换言之，有了 Hydra Lab，开发团队可以直接利用已经采购的测试设备，搭建一套内部的持续测试的工程化系统，成本上十分划算，数据流也能完全掌控。

周乐：对于定制化需求方面，再额外补充一点，由于我们的产品 Phone Link、Link to Windows 同时具备 PC 端和手机端，所以需要跨平台即在 Windows 和手机上同时测试验证。这个特性需要我们研发内部先实践支持，这也是 Hydra Lab“与生俱来”的能力。

InfoQ：您带领团队推动了云测试平台 Hydra Lab 的构建和完善，当初构建 Hydra Lab 的契机和思路是什么？

步绍鹏：Hydra Lab 目前刚刚开源几个月，我觉得构建 Hydra Lab 的契机和微软的工程师驱动的文化有很大关系。另外我们也借鉴了很多测试领域的经典著作，如：

《软件测试艺术》：这本书谈到了很多测试的名词和概念，以及如何对测试进行分类和认识。这本书对我们平台的一些架构和类的关系有很大的影响。

《探索式软件测试》和《微软测试之道》：这两本书都是由微软员工在 2010 年之前编写的。它们提出了一些有趣的概念和方法，如“Money Tuor”卖点测试法。这种方法选择用户兴趣点的串联路径进行测试，有利于提高软件核心功能的覆盖率。《微软之道》这本书主要介绍了微软在软件质量非常重要的年代所采用的大规模测试方法和严格的标准，尤其是生命周期的定义，对云测平台框架和架构的设计非常有指导性。此外，在智能化的探索上，我们与微软亚洲研究院 MSRA 和微软 DKI 团队也有非常多的合作共创，也共同推进了一些该领域的专利，因此真的非常感谢他们的帮忙。在构建 Hydra Lab 平台的过程中，我们先解决来自团队内部和微软兄弟团队的实际需求、测试痛点。服务好他们的同时，也伴随着我们平台稳定性和功能性的提高。在稳定性问题基本解决之后，我们开始考虑如何结合智能化，将 AI 引入进来。前段时间的开源是一个重要的时间点，同时大语言模型的到来也带来了新的变革。

InfoQ：Hydra Lab 能够解决您刚才提到的自动化测试痛点吗？Hydra Lab 在安全性上有哪些设计？

周乐：对，其实这几个问题相对容易解决。举例说明，有了云平台之后，跨地区的协作就变得容易多了。美国有五台手机，中国也有五台手机，我们可以把它们都接入到 Hydra Lab 这个平台上。而且，中国这边的团队可以在美国的五台手机上部署测试并验证新的改动，美国那边的团队也可以在中国这台手机上进行验证。这样，跨地区的问题就得到了很好的解决。

此外，我们还实现了一些规则和配置性的约定，可以在测试任务中进行配置。在每个测试任务的定义描述中，我们可以配置一些执行规则、前置后置脚本等。我们还基于 OAuth 2.0 实现了简单的用户权限系统，可以比较方便地对接用户服务器，并支持粗粒度的权限管控。

针对跨平台测试场景，大家在项目里可以找到一个叫 AppiumCrossRunner 的存在，就是通过 Appium 实现跨平台测试的测试执行器 （Test Runner），在 Hydra Lab 里大家可以找到各类不同平台的 Runner，也反映了我们对测试执行过程的抽象。

黑盒测试领域的智能化测试探索

InfoQ：和其他同类型平台相比，Hydra Lab 有哪些技术特性以及差异化优势？

步绍鹏：我们的项目刚开源几个月的时间，目前我个人在开源社区里面还没有找到跟 Hydra Lab 定位相同的项目。在 GitHub 上，Hydra Lab 的核心分类标签标签是 Cloud Testing，也就是云测试系统，在这个标签下 Hydra Lab 是 top 1，在当前比较火的 platform engineering 这个概念下 Hydra Lab 也跻身前五。这也侧面说明，当下开源云测平台同类竞品方案很少。

Hydra Lab 提供了 RESTful API 和 Azure DevOps 平台的集成插件；为了方便安卓开发者集成，也提供了 Gradle 插件。此外，Hydra Lab 还支持安卓和 Windows 平台应用的性能测试，目前可以提取被测应用的电量和内存消耗数据，并在测试报告中可视化呈现。

最后，智能化测试方面，我们在 Hydra Lab 中已经可以看到很多大语言模型的应用案例，我们近期也合入了很多相关 PR。这样的开源项目可能目前是仅此一家。

周乐：关于测试生成智能化，最近我们团队的 Dexter 同学在写工程化单测生成的方案，已经在 Hydra Lab 里进行 PR code review，欢迎大家参与吐槽拍砖，一起共创。

InfoQ：您提到团队率先探索了黑盒测试领域的智能化测试用例生成，能具体介绍一下吗？主要采用了哪些方法？

周乐：我这边先简单介绍一下应用的探索过程吧。在探索应用期间，我们会先用屏幕理解模型对当前页面进行特征提取、UI 分类，然后借助大语言模型做出判断，对特定页面元素操作，以求覆盖尽可能多的页面或完成特定的用户场景。

步绍鹏：是的，周乐提到的是基于 UI 探索的智能测试方案，更多是从黑盒视角出发的。而目前大语言模型带来的测试智能化，尤其是测试生成，大多基于白盒测试的视角，相当于把代码发给大语言模型，要求它能够写出提升代码测试覆盖率的单元测试用例。而黑盒测试下的测试远比白盒复杂，目前还属于比较前沿的探索。对于黑盒测试，代码就像一个黑盒，内部逻辑是不可见的，而且应用界面或可执行程序的包体内包括丰富的信息，“上下文”庞大，多模态，很难直接转换成 prompt。这种情况下，我们怎么让大语言模型发挥作用呢？

这里 Hydra Lab 团队 brainstorm 出来的、目前所采用的核心思路是：先探索，再利用。先通过一些策略探索和漫游一个软件，然后转换理解，形成数据结构，最后再利用这些数据，作为后续探索和用例生成的基础。这就相当于通过探索，对黑盒内部逻辑进行了总结提炼，完成了一次“有损压缩”。这个思路也很像一个测试人员第一次用一个软件，一定会先探索理解，同时在旁边整理一个信息图，这在测试领域被称为“功能图”或“状态图”，然后再设计用例；这非常自然和接近人的操作。如果我们能用计算机做这件事情，就能自动化地完成探索，绘制状态图，并生成测试用例。

“工程师的价值仍非常重要， 未来大有可为”

InfoQ：大模型技术的发展为软件测试带来了更多可能性，对于那些于希望在项目中应用大模型做软件测试的团队，您会给他们提供哪些建议？

步绍鹏：第一，挥剑诀浮云，面对大模型，我们需要冷静思考，它有优势，但目前并不是万能的。我们需要学习和理解它的特性，跟进它的进展，了解它的“禀赋”，并结合自己遇到的问题找切入点，让它为己所用；一定避免生搬硬套，有些问题用普通的算法或者经验规则可能就能够解决。第二，他山之石可以攻玉，多关注开源方案和数据集，可以多去 Hugging Face 和 GitHub 这类宝藏平台上逛逛；接下来可能多模态的开源模型是值得持续关注的。第三，重视数据的价值，高能的模型都是优质数据喂出来的，Hydra Lab 项目团队目前也在探索各场景下用于软件测试数据集的构建。

InfoQ：您认为大模型在软件研发工作流中最大的价值是什么？大模型对软件研发工作流的改变，将会如何影响软件开发行业的未来发展趋势？

步绍鹏：近期大模型之所以如此火热，很大程度上因为它成为了打通工业界和学术界的一个契机。工业界能直接使用大模型涌现出的新能力，并可以大范围投入应用到用户场景，而这些应用又可能很容易成为媒体话题，仿佛“叫好又叫座”，给大家新的曙光。AI 架构从 Seq2Seq、Self-Attention、Transformer、GPT 一路走来，实现了模型规模突破后的质变，语言、代码和图像的生成都产生了突破。而突破发生后，我们发现很多任务都可以转化为自然语言，这样我们就可以将测试用例转换成语言描述，从而使得大模型可以应用于这些场景。一个需求点，只要能够用有限的语言描述清楚，大模型就可以成为一个实际的解决方案。

周乐：大模型在软件研发工作流中的最大价值是可以提高软件开发的效率和质量。通过使用大模型，软件开发者可以自动生成代码，优化代码，测试代码，快速生成文档。

一方面，大模型将使软件开发变得更加普及和便捷，让更多人可以参与到软件创造中来，从而促进软件创新和多样化。另一方面，大模型也将给软件开发带来一些挑战和风险，例如如何保证大模型生成的代码的正确性和安全性，如何处理大模型可能存在的偏见和误导，如何保护大模型使用的数据的隐私和版权等。

总之，大模型是一种强有力的工具，可以为软件开发带来巨大的价值和影响。但是，我们也需要注意其潜在的问题和限制，并合理地使用它。

InfoQ：您在实际的研发过程中是否应用过大模型，使用体验如何？

步绍鹏：我个人几乎每天都频繁使用大模型，也是 GitHub Copilot X 忠实用户，有一些涉及敏感数据的问题我会用 Azure OpenAI Service 或者 Bing Chat Enterprise，这些 AI 工具能帮助开发者写邮件、写代码，的确可以大幅度地提高生产力；也存在一定的局限性，比如有时会无中生有地调用不存在的 API 等。团队层面，我们在探索应用 Copilot for Pull Request，工程化的单元测试生成方案等，有一定的成效，生成了一些内容，方便了大家的工作；也有一些挑战和难点（解决大模型幻觉和不稳定的问题）在攻克。

InfoQ：软件工程师需要具备哪些素质，才能在大模型的冲击下仍具备核心竞争力？

步绍鹏：非常好的热门问题。首先，自信非常重要，不要把自己仅仅看作一个“螺丝钉”或者为自己设限，要跳出初级角色的定位；关注到 AIGC 这个话题的各位已经走在时代的前沿了，未来是跨领域、跨学科创新的时代，拥有复合学科背景的、有独立思考能力的软件工程师人才，驾驭了 Copilot 之后必能创造更多的价值，大有可为；同时，尝试提高自己解决问题的能力和范围，以解决问题为导向，提升自己的综合能力，构建自己的跨领域优势；此外，拆解复杂问题的能力和沟通表达的能力也非常重要：拆解和处理一个项目中的复杂问题往往需要具备很多的领域内知识，并结合环境和形势，调动逻辑思维进行换位思考，这是大模型不太可能具备的。表达和沟通能力与一个人的同理心相连。有了大语言模型之后，我们可能不仅要和人有同理心，和 AI 对话也要有“同理心”，有必要知其然和知其所以然。而 Prompt Engineering 仿佛就是在探索和构建我们和 AI 的同理心。

周乐：非常认同绍鹏的观点，有道无术，术尚可求也，有术无道，止于术。在我看来，我们提升的重点不应该局限于某个技术或框架，如何快速学习新的知识，如何在复杂环境下定位解决问题，如何与团队成员、客户有效沟通，才是我们应该思考和提升的。